tBane Temat założony przez niniejszego użytkownika |
» 2025-07-12 21:17:17 Zastanawiam się czy nie przestawić kolejności tilesów z tej tekstury.. |
|
pekfos |
» 2025-07-12 21:25:08 Coś jeszcze robisz "prościej"? Ta numeracja to tylko technika optymalizacyjna. Zamiast robić if( corner_0 == 0 && corner_1 == 0 && corner_2 == 0 && corner_3 == 0 )
texture = texture_0;
else
if( corner_0 == 1 && corner_1 == 0 && corner_2 == 0 && corner_3 == 0 )
texture = texture_1;
4 parametry są kodowane w jednej liczbie, a ta jest używana jako indeks w tablicy. Równie dobrze możesz sobie wypełnić tablicę 4-wymiarową. texture = tab[ corner_0 ][ corner_1 ][ corner_2 ][ corner_3 ];
Sprowadzenie tego do jednego indeksu służy tylko temu by można było tego indeksu użyć do obliczenia współrzędnych w większej teksturze. Robienie tekstury z wieloma kaflami to też technika optymalizacyjna. |
|
tBane Temat założony przez niniejszego użytkownika |
» 2025-07-12 22:16:55 Nie. Więcej uproszczeń nie zrobiłem. Tylko podzieliłem teksturę na poszczególne grafiki. Ok czyli mam nie zmieniać kolejności grafik. Chyba jutro wrócę do tego, bo dziś już nic nie rozumiem. |
|
tBane Temat założony przez niniejszego użytkownika |
» 2025-07-13 13:53:20 Ha! Działa! :-) Jednak miałem dobry pomysł, dziś ze świeżą głową napisałem. Kod poniżej i screenshot :-) tileset: screenshot: int getTileIndex( int x, int y, char tile ) {
int index;
if( data[ y * size.x + x ] == '#' )
index = 15;
else {
index = 0;
if( getTileValue( x, y - 1 ) ) index = index | 3; if( getTileValue( x - 1, y ) ) index = index | 5; if( getTileValue( x + 1, y ) ) index = index | 10; if( getTileValue( x, y + 1 ) ) index = index | 12; if( getTileValue( x - 1, y - 1 ) ) index = index | 1; if( getTileValue( x + 1, y - 1 ) ) index = index | 2; if( getTileValue( x - 1, y + 1 ) ) index = index | 4; if( getTileValue( x + 1, y + 1 ) ) index = index | 8; }
return index;
}
int getTileValue( int x, int y ) {
if( x >= size.x || y >= size.y || x < 0 || y < 0 ) {
return 0;
}
return data[ y * size.x + x ] == '#' ? 1: 0;
}
|
|
pekfos |
» 2025-07-13 14:35:59 data =
"................"
"..###......##..."
".#####...#####.."
".############..."
"...##########..."
"..##..#######..."
"..#.....###....."
"................"; Jeśli to jest źródło, a na to wygląda, wynik jest błędny:  Bity zaznaczone według tekstur, nie mam pojęcia czemu miałbyś je odwrócić.. Woda z lądem od góry, prawej i dołu daje 3|10|12 = 15 więc ląd. Jeśli zamierzasz używać typów terenów do określenia kolizji, to takie renderowanie wprowadza gracza w błąd. |
|
tBane Temat założony przez niniejszego użytkownika |
» 2025-07-13 14:48:57 Ej faktycznie :-/ Ty to zawsze potrafisz znaleźć każdego buga, dzięki :-) // edit Nie no, tak musi zostać, bo tak działa niestety algorytm. Jeśli narysuje tam kafelek wody to brzydko to będzie wyglądać. Chyba, że przejścia będę robił na kafelkach "piasku". Jak myślisz? data =
"................"
"..###......##..."
".#####...#####.."
".############..."
"...##########..."
"...##########..."
"...##########..."
"..##..#######..."
"..#.....###....."
"................";
size = sf::Vector2i(16, 10);
 |
|
pekfos |
» 2025-07-13 14:59:35 Mhm.. Tylko jak to naprawić? Najpierw powiedz jakie powinno być tu zachowanie? Aktualnie rysujesz przejścia wody z lądem kosztem pól z wodą, więc logicznie pole wody otoczone lądem powinno mieć kafel który ma wodę na środku i ląd dookoła we właściwych kierunkach, takie "[ U]". Ale nawet jakbyś miał taki kafel to by nie pasował do reszty bo przejście nie byłoby na środku, no i nie masz tylu kombinacji grafik. Temat na stackexchange mówi o 48 kombinacjach, dlatego od początku piszę że masz złe grafiki, albo złe podejście. Te grafiki są przeznaczone do rysowania w przesunięciu o pół kafla, wtedy przejście na środku kafla wypada między polami, więc możesz obrysować dowolny kształt zawsze patrząc tylko na 4 pola i nie rysujesz przejść kosztem dodatkowych pól które nie są ani jednym terenem ani drugim. |
|
tBane Temat założony przez niniejszego użytkownika |
» 2025-07-13 15:08:11 Kurde, trzeba, by wszystko obrócić. Znaczy się zamiast renderować na wodzie granice, trzeba by na piasku renderować granice. Mhm.. tak by chyba było dobrze ale też wtedy gdy pole będzie otoczone woda to "zniknie"
//edit
Chyba zostawie tak jest, zobaczę jak auto-tiling będzie sie zachowywał podczas edycji kafelków i wtedy napiszę.
//edit 2
dobra, zrozumiałem co masz na myśli. Ale nie wiem jak to zrobić. Muszę się zastanowić... |
|
| 1 2 « 3 » 4 5 6 7 8 |