Sprites a custom ots

[sarez]

Cześć. Właśnie zacząłem grać na Medivi. Nie mają .spr a .wad i tu rodzi się moje pytanie - kod zapewne jest taki sam, skoro lata na silniku cipsoftu. Da się jakoś wgrać przeźroczyste drzewa?

 

Dzięki za oddzew.

[rafaeru]

1. żaden ots nie lata na silniku cipsoftu,

2. da się jeśli napiszesz sobie do tego program 

[sarez]

Sprite to dwuwymiarowy obrazek używany w systemach grafiki dwuwymiarowej i 2,5-wymiarowej. Nie wiem kolego, co ma do tego pisanie programów, wystarczy podmienić tekstury. I owszem, każdy ots lata na silniku cipsoft. To impreatyw, bo niby co, otsy na których grasz, to emulatory tibii ? Zmiana silnika gry graniczy z gruntownym przerobieniem kodu, co za tym idzie... praktycznie całkowitą zmianą grywalności, wyglądu, etc.

Jeżeli każdy z Twoich 3000+ postów wygląda podobnie, przykro mi wyciągać szybkie wnioski, ale po tylu latach forum nadal jest pełne.. ludzi :3

 

inb4 argumentum ad personam

również bump

[rafaeru]

1 primo zakładając, że Medivia lata na TheForgottenServerze ( silniku do Tibi ) a jest tak na 99% ponieważ nie ma tak rozwiniętych innych silników. Nie jest to silnik Cipsoftu, został napisany przez grupę programistów z OTlanda m.in. Elf, slawkens, Talaturen, Lithium, KaczooH, Kiper, Kornholijo. 

 

Cytat z oficjalnego Githuba projektu mówi:

 

The Forgotten Server is a free and open-source MMORPG server emulator written in C++. It is a fork of the OpenTibia Server project. To connect to the server, you can use OTClient.

 

Mylisz pojęcia serwera i klienta gry. Co ma piernik do wiatraka ? Silnik odbiera tylko pakiety wysyłane z klienta i odpowiada wg. ustalonych zasad. Możesz przecież na tym silniku zrobić grę platformową czy shootera.

 

2 primo

 

 

 

Sprite to dwuwymiarowy obrazek używany w systemach grafiki dwuwymiarowej i 2,5-wymiarowej.

Znowu mylisz pojęcia. Nie mówimy tu o pojedynczej grafice.

Plik Tibia.spr jest to zbiór wszystkich spirtów ułożonych wg. struktury:

 

3) Tibia.spr Structure + link to code

The first 4 bytes contain information for the sprite version(?), like in the .dat file I'm not sure what this information is used for, maybe so the client can make sure you're using the right sprite file(?). The next 2 bytes are the number of sprites in the file. Then starts each sprites information.

 

Each sprite is offset by 4 and the sprites start 6 bytes from the beginning of the file, because of the sprite version and number of sprites. Also, the first sprite has an ID of 2 so you have to subtract 1 from each sprite ID to get to its offset. The equation used for this is (6 + (spriteID - 1) * 4). Now that we know this let's get back to the sprite information.

 

From what I understand the first 3 bytes of each sprite is unnecessary when getting the sprite's pixel information, so just skip the first 3 bytes. The next 2 bytes are the size of the sprite, ie. if this returned 36 then the sprite would be 6x6 pixels. The next 2 bytes are the amount of transparent pixels until a colored pixel. Then the next 2 bytes are the amount of colored pixels until a transparent pixel. The next 3 bytes are the RGB value of the colored pixels and the amount depends on how many colored pixels were found. (ie. If 1 colored pixel was found then there would just be 3 bytes [r][g], if there were 2 colored pixels found then there would be 2 sets of 3 bytes [r][g][r][g].) The transparent/colored pixel information is read from left to right (starts at the top-left of the sprite and ends at the bottom-right).

 

Here's the structure of the first sprite including the header information (spr version and number of sprites). [x] = number of bytes:

[4] - spr version = 1228754556
[2] - number of sprites = 28729
[3] - ?
[2] - sprite size = 512
[2] - transparent pixels = 397
[2] - colored pixels = 4
[3] - RGB value = [0][0][0]
[3] - RGB value = [0][0][0]
[3] - RGB value = [0][0][0]
[3] - RGB value = [0][0][0]
[2] - transparent pixels = 27
[2] - colored pixels = 5
[3] - RGB value = [0][0][0]
[3] - RGB value = [12][84][17]
[3] - RGB value = [18][145][21]
[3] - RGB value = [8][88][12]
[3] - RGB value = [0][0][0]
[2] - transparent pixels = 3
[2] - colored pixels = 1
[3] - RGB value = [0][0][0]
[2] - transparent pixels = 22
[2] - colored pixels = 6
[3] - RGB value = [0][0][0]
[3] - RGB value = [16][98][28]
[3] - RGB value = [17][199][21]
[3] - RGB value = [21][169][28]
[3] - RGB value = [9][104][15]
[3] - RGB value = [0][0][0]
[2] - transparent pixels = 2
[2] - colored pixels = 4
[3] - RGB value = [0][0][0]
[3] - RGB value = [115][180][44]

ź: https://otland.net/threads/tibia-dat-reader-dat-spr-structure-and-spr-reading-code-link.25117/
 

Więc aby rozwiązać twój problem, musisz przeanalizować budowę pliku który jest odpowiedzialny za sprity ( jak mówisz .wad ) i napisać program który przełoży to na grafikę. Wtedy będziesz mógł zrobić przezroczyste drzewa. 

[sarez]

Jezeli dobrze rozumiem ten .wad to konwersja standardowego spr o ich wlasnej strukturze? 

Nie powinien sie duzo roznic od oryginalu.. zastanawiam sie czy nie zadziala wdrozenie ich customowych grafik w oryginalny spr i zwyczajna zmiana nazwy na wad zeby nic sie nie gryzlo- watpie zeby robili jakies cudowne zabezpieczenia wzgledem przezroczystych drzewek. Teraz musze poszukac kogos kto wykucuje nowy plik, jak zakladam, tutaj brak chetnych :3

[Dakos]

1. zmień rozszerzenie pliku "WAD" na "SPR"

2. za pomocą spr editora [google it] wypakuj spirites

3. edytuj każde drzewko na różowo

[sarez]

1. zmień rozszerzenie pliku "WAD" na "SPR"

2. za pomocą spr editora [google it] wypakuj spirites

3. edytuj każde drzewko na różowo

Niemozliwe. Sprobowalem conajmniej 4 editory, kazdy sie wiesza albo nie chce wczytac pliku. Zmiana nazwy rozszerzenia nie naprawi tego jak te sprites sa skompresowane.