Tučňák na Rovenlandu ještě nezabloudil

21.6.2010 19:12 | Přečteno: 1689× | Linux | | poslední úprava: 21.6.2010 19:13

Pokud jste před necelým rokem s nadšením stahovali první zdrojáky Bran Skeldalu zkompilovatelné pod Linuxem (tedy aspoň někde), nejspíš vaše nadšení během posledního půl roku značně ochladlo. Když se ale podíváte na diff revize 111, nejspíš vám bude jasné, proč se tak dlouho nic nedělo.

Poslední půlrok jsem pomalu přepisoval renderovací jádro Skeldalu na přenositelný kód. Měl jsem při tom na výběr — buď commitovat pravidelně a mít v repozitáři 30 nefunkčních revizí plných bordelu, nebo udělat jeden obří commit, až se přenositelný kód dostane do stejného stavu jako revize 110.

Vzhledem k tomu, že repozitář nejede na GITu, vybral jsem si druhou možnost. Jestli je to dobře nebo špatně můžeme probrat v diskuzi, ale hlavní je, že obří commit už je hotový.

Hlavní změnou je přechod z 15bitové barevné hloubky na 24bitovou a přepis dalšího kusu načítacího kódu, aby nezávisel na endianitě ani velikosti datových typů cílového počítače. Pokud máte ne-x86 systém a chcete zkusit štěstí, klidně můžete. Do hlavního menu byste se s trochou štěstí mohli dostat bez segfaultu a dokonce bude vypadat normálně.

Instalační instrukce se od minule nijak zvlášť nezměnily, jen přibyl configure skript, jak je zmíněno na konci článku. Pokud už máte nainstalovanou starší verzi, prostě si zkompilujte novou binárku a můžete hrát. Pokud se nějaké NPC bude v rozhovoru tvářit, že jste ho už navštívili, přestože jste u něj poprvé (třeba bard v přístavu), nejspíš jste začali hrát před revizí 103 a budete muset začít od začátku.

V nejbližších dnech se můžete těšit na další vylepšování renderovacího jádra, hlavně opravu grafických artefaktů kolem kurzoru myši a konečně i chybějící efekt zemětřesení, který je aktuálně nahlášený jako bug. Pak bude následovat další větší přepis jiného subsystému, tentokrát ale ne tak velký.

       

Komentáře

[CEST]

Nejsem developer, ale admin, presto bych to rekl takhle. Ve one-man projektu je asi jedno, jak si budes delat commity, klidne muzes delat celej vyvoj bez verzovaciho systemu a revidovat rucne pomoci rsync do adresaru.

Nicmene ve vice lidech, pokus bys mel nadrizenyho, tak by te asi pekne zjebnul. I kdybych si sam pro sebe vyvijel, tak bych rozhodne ukladal pravidelne, v nejakych logickych celcich.

Mel bys mozna nastudovat, jak se pracuje s verzovacima systemama, ze to neni jenom na zalohy.

- pravidelny commit umozni presneji sledovat zmeny, at uz tobe, nebo ostatnim. Muzou sledovat, co jsi zmenil, jak jsi to zmenil, pripadne ti i komentovat tvoje zmeny a treba te i upozornit na chyby nebo jenom nevhodnou konstrukci.

- muzes si udelat vlastni vyvojovou vetev, takze trunk zustane porad stary, ale ty delas vyvoj ve vlastni vetvi. Kdyz je nejaka cast prepsana a funkcni (a neni zavisla na dalsim kodu), muzes pouze tyhle upravy prenest z vyvojove vetve do trunku a uzivatele uz muzou testovat novy kod a ty muzes prepisovat dalsi casti.

- pokud budes pravidelne commitovat a budes poctive psat komentare, muzou se ti lip hledat nejaky chyby: bude ti to padat v nejakej casti, budes vedet, co to je za cas, podle logu commitu a komentaru najdes, co jsi tam jak menil a mohl bys tak lip najit chybu. Kdyz budes mit jeden velkej commit, budes muset porovnavat original kod s novym a budes muset proste projit celej usek kodu.

Krome vetvi muzes tvorit taky tagy, ktere budou znazornovat nejakej release (udelas nekolik commitovanych zmen a nejaka cast kodu bude stabilni, tak vydas celej projekt v nejakej verzi). V subversion jsou branche a tagy simulovane kopirovanim, ale svuj ucel to plni.

Rozhodne doporucuju delat commit casteji, ale do vyvojove vetve.

[Martin Doucha]

Nemusíš mi vysvětlovat základy používání systémů na správu verzí. Repozitář na SourceForge spravuje Bredysoft a já mám jen tu jednu větev. Lokálně jedu na GITu a kdyby bylo po mém, tak bude v GITu i hlavní repozitář, takže by s pracovními větvemi nebyl problém. Jenže hlavní repozitář je v SVN a nevidím důvod, proč v GITu prasit větve po vzoru SVN, když na tom stejně budu dělat sám.

[retroslava]

Tak si to můžete dát na github nebo někam jinam, ne ?

[Martin Doucha]

To sice můžu, ale když ten projekt neforknu a nepřestanu commitovat na SourceForge, tak stejně nakonec skončím u lineární historie. Nejjednodušší by bylo přejít na GIT přímo na SourceForge, jenže to by musel schválit Bredysoft.

[stativ]

Mám menší problém, asi bug. Můžu to hodit do bugzilly pokud bude třeba.

Skeldal jsem si zkompiloval na 64 bit Archu (díky za rychlou opravu). Změnil jsem DATA_PATH v unix/init.cpp na /usr/share/skeldal. Do DATA_PATH jsem nakopíroval soubory* podle tvého předchozího návodu ale teď mi při spuštění jen krátce problikne okno a vypíše se:

[lukas@orochi ~]$ skeldal 

Nemohu precist konfiguracni soubor "/home/lukas/.skeldal/skeldal.ini".

skeldal: ../skeldal/libs/memman.cpp:423: virtual size_t File::read(void*, size_t): Assertion `_file' failed.
Aborted

* instalačku jsem musel sosat z uloz.to, protože odkaz od napoleon games hází 404.

[Martin Doucha]

Tohle nebude bug, spíš chybějící soubor. Pusť skeldal pod GDB a až spadne, nech si vypsat backtrace. Z toho se dá poznat, který soubor chybí.

[stativ]

#0  0x00007ffff6e2b565 in raise () from /lib/libc.so.6
#1  0x00007ffff6e2c9e6 in abort () from /lib/libc.so.6
#2  0x00007ffff6e24145 in __assert_fail () from /lib/libc.so.6
#3  0x0000000000449b90 in File::read (this=<value optimized out>, buf=<value optimized out>, size=<value optimized out>) at ../skeldal/libs/memman.cpp:423
#4  0x000000000044980d in ReadStream::readUint8 (this=<value optimized out>) at ../skeldal/libs/memman.cpp:184
#5  0x000000000044982f in ReadStream::readUint16LE (this=0x7c5420) at ../skeldal/libs/memman.cpp:189
#6  0x0000000000429226 in SpellList::load (this=0x6afc80, stream=...) at ../skeldal/game/magic.cpp:280
#7  0x000000000042cfd2 in kouzla_init () at ../skeldal/game/magic.cpp:2352
#8  0x000000000043a310 in init_skeldal () at ../skeldal/game/skeldal.cpp:994
#9  0x000000000043aab6 in main (argc=<value optimized out>, argv=<value optimized out>) at ../skeldal/game/skeldal.cpp:1708

Chce to načítat soubor KOUZLA.DAT, který mám v MAPS.

[stativ]

Příloha:

• soubory (2811 bytů)

Kdyby něco tak v příloze je i seznam všech souborů, co jsem nakopíroval.

[Martin Doucha]

Víš kde je problém? DATA_PATH musí končit lomítkem. Podívej se na Sys_Init() jak se ty cesty generují.

[stativ]

Á, to je ono! Díky moc!

[Martin Doucha]

Jenom pro jistotu dodám, že názvy souborů jsou case sensitive a musí být velkými písmeny. Výjimka jsou jen přípony hudebních MP3 souborů (název souboru velkými, přípona malými).

[Drew]

Super, zkompiloval jsem, spustil, vešel do skřetích jeskyní, začal souboj, všem jsem dal, ať kouzlí fireball, a když se začala vykreslovat animace, spadlo to a vypsalo toto:

 skeldal: game/magic.cpp:302: TKOUZLO& SpellList::operator[](unsigned int): Assertion `_spellData && idx < _size && "Invalid spell index"' failed.
Aborted

Jsem na amd64, stačí toto jako bugreport, nebo je třeba víc?

A mimochodem ,lze to spusti ve fullscreenu?

[Martin Doucha]

Potřeboval bych k tomu backtrace. Spusť Skeldal pod GDB a až spadne, nech vypsat backtrace a ten mi pošli.

[Drew]

Tohle? (formulář si stěžoval, že značka value není povolena, tak [value stojí za "<"value)

skeldal: game/magic.cpp:302: TKOUZLO& SpellList::operator[](unsigned int): Assertion `_spellData && idx < _size && "Invalid spell index"' failed.

Program received signal SIGABRT, Aborted.
0x00007ffff6de7a75 in raise () from /lib/libc.so.6
(gdb) backtrace
#0  0x00007ffff6de7a75 in raise () from /lib/libc.so.6
#1  0x00007ffff6deb5c0 in abort () from /lib/libc.so.6
#2  0x00007ffff6de0941 in __assert_fail () from /lib/libc.so.6
#3  0x000000000042e426 in SpellList::operator[] (this=[value optimised out>, idx=[value optimised out>)
    at game/magic.cpp:302
#4  0x000000000042e560 in get_spell_teleport (num=4025) at game/magic.cpp:324
#5  0x0000000000430f3d in thing_cast (num=4025, postava=0, sector=6, victim=0xffffffffffffffff, noanim=96 '`')
    at game/magic.cpp:2281
#6  0x0000000000429e36 in inv_quaf (id=[value optimised out>, xa=[value optimised out>, ya=161, 
    xr=[value optimised out>, yr=[value optimised out>) at game/inv.cpp:1107
#7  human_click (id=[value optimised out>, xa=[value optimised out>, ya=161, xr=[value optimised out>, 
    yr=[value optimised out>) at game/inv.cpp:2297
#8  0x000000000040a350 in find_in_click_map (ms=0x6c06c1, pt=0x66fb26, pocet=6, evtype=0x7fffffffde8c)
    at game/clk_map.cpp:557
#9  0x000000000040a633 in ms_clicker (msg=[value optimised out>, usr=[value optimised out>) at game/clk_map.cpp:598
#10 0x000000000044d24f in enter_event (tree=0x6c06e8, msg=0x7fffffffdef0) at libs/event.cpp:245
#11 0x000000000044d7df in send_message (message=[value optimised out>) at libs/event.cpp:426
#12 0x0000000000456631 in Sys_ProcessEvents () at sdl/input.cpp:109
#13 0x000000000044d8b0 in do_events () at libs/event.cpp:528
#14 0x000000000045894d in Task_WaitEvent (event=4025) at unix/task.cpp:46
#15 0x000000000043e37f in enter_game () at game/skeldal.cpp:1066
#16 0x000000000043f3a4 in game_big_circle (enforced=[value optimised out>) at game/skeldal.cpp:1424
#17 0x000000000043fb16 in load_saved_game (argc=[value optimised out>, argv=[value optimised out>)
    at game/skeldal.cpp:1537
#18 start (argc=[value optimised out>, argv=[value optimised out>) at game/skeldal.cpp:1581
#19 main (argc=[value optimised out>, argv=[value optimised out>) at game/skeldal.cpp:1681

[Martin Doucha]

Velikost tabulky kouzel už jsem opravil. Index 4025 je ale pořád mimo. Co za předmět jsi zkoušel použít když to spadlo?

[Drew]

Léčivý lektvar, který jsem nalezl v té chajdě hned na začátku. Poprvé jsem tu chybu spustil fireballem, ale lektvar to pak spouštěl rychleji.

[Drew]

A po poslednim commitu mi to nepadá už ani s jednim.

[Martin Doucha]

Fullscreen se plánuje, ale až hodně daleko v budoucnu. Na dnešních monitorech by 640x480 vypadalo příšerně a zatím mám důležitější věci na práci než strkat do SDL backendu nějaký přepočet obrazu na větší rozlišení. Až bude Skeldal bez problémů dohratelný a poběží i na big endian platformách, ještě jednou překopu renderovací jádro a s trochou štěstí udělám i OpenGL backend, který bude umět fullscreen.

[Drew]

No já nevím, teď jsem to zkusil ve wine (mimochodem to začalo prý od rc5 fungovat) a na fullscreen ve 1050x1680 to vypadá úplně v pohodě - ale nevím teda, jestli tam wine (respektive wine) nedělá nějaké nečisté triky. Samozřejmě nechci nijak naléhat, určitě jsou důležitější věci, jenom mi nepřijde, že by to vypadalo příšerně.