Vlákno názorů k článku Vývoj her pro herní konzoli NES: práce se sprity od Dushino - Díky moc za další nakládačku. Je moc fajn...
-
Díky moc za další nakládačku. Je moc fajn na Rootu zabřednout i do těchto hardcore technických vod.
Jen malinká drobnost k popisu obrázku 1, pro tento tutoriál nepodstatná: "..může se pohybovat v horizontálním i vertikálním směru bez nutnosti přesunů dat v obrazové paměti." To platí pouze pro horizontální směr (registry HPOSP/HPOSM), ale pro pohyb ve vertikálním směru je třeba posunovat data v paměti PMG objektu. V BASICu se to řeší třeba klopírováním stringů. Více např. v https://wearethemutants.com/2017/01/30/adventures-in-atari-basic-lesson-four-manipulating-memory-and-moving-players/ -
Pavel TišnovskýZlatý podporovatelDíky za upozornění. Já to myslel jinak a napsal to zbytečně zkratkovitě. Šlo mi o to, že Starquake běží například i na ZX Spectru a tam přesun hrdiny i NPC je nutné řešit reálnými přesuny v obrazové paměti (tj. v té jejich bitmapě 256x192 pixelů + v atributové paměti 32x24 atributů), a to je obecně pro ty osmibitové čipy peklo.
Na Atárku ta hra běží v módu F (GR.8 - což mě tedy překvapuje, čekal jsem textový mód :-), kde je každý přesun v rámci čistě obrazové paměti náročný na CPU. Ale sprity jsou uloženy mimo tuto paměť; jejich horizontální přesun je triviální (jeden INC/DEC, jednodušeji to prostě už nejde), vertikální posun je přenos nějakých deseti bajtů, podle výšky (to se snad ani nevyplatí psát do smyčky, ale přímo ji rozbalit :). Ale stále je to nic oproti tomu, jak složité by to bylo realizovt přímo v módu F - to realizuje snad jen Amourote.
-
Ano, rozumím, jasně.
S módem F jste mě dostal. Také jsem předpokládal, že hra běží v módu 2. Na https://youtu.be/FZi4EZqOvTI?t=192 je vidět, že NPC nejsou PMG, ale součást ram grafického režimu. PMG je použit snad jen pro hráče, i střely jsou v RAM grafického režimu - viz https://youtu.be/FZi4EZqOvTI?t=215 A to je tedy mazec, protože pak nefungují detekce kolizí a je třeba je počítat. Myslím si, že NPC a střely nejsou PMG proto, protože mají rozlišení módu F (resp. 2), což PMG nezvládne, pro PMG je minimální šířka pixelu 2 pixely módu F, ale to víte.
U Amaroute mě mód F nepřekvapuje - tam se řeší viditelnost a je vidět, že je to výpočetně náročné - chůze se zpomaluje v místnostech, kde je hráč částečně schován za něčím.
Omlouvám se za založení off-topic vlákna. -
Pavel TišnovskýZlatý podporovatel
Popravdě - až do dnešního rána jsem si myslel, že Starquake běží v textovém režimu, protože ta grafika vypadá definovaná pro bloky 8x8 atd. Akorát při první odpovědi jsem si říkal, že si to zjistím v emulátoru (ten má monitor a příkaz DLIST pro vytištění display listu) a docela jsem čuměl, že to má mód F.
Jinak teď už dává smysl, že ty NPC se při překryvu XORují - takto nemusí řešit ukládání, co je pod NPC, neboť se to samo vrátí při překreslení.
Takže díky - po XX letech jsem se zase něco nového dozvěděl o atárku :-)
-
"přesouvat grafiku v paměti je peklo" a "počítání kolizí je mazec" - tady je výborně vidět, kdo je rozmazlený atarista a kdo je opravdový programátor, kterému stačí bitmapa a Z80 :D
Ale vážně, je to o mindsetu, na hrách Zx Spectru vidíte jak v roce 1982/1983 se programátoři učili s hardwarem a pak si herní studia vybudovala know-how a hry jsou plné prakticky totožných řešení sprajtů a kolizí. S trochou praxe vám stačí kouknout na screenshot, rok vydání a autora/studio a víte jak budou vypadat low level grafické rutiny.
To jen tak na okra, seriál se mi samozřejmě moc a moc líbí. -
btw jsem nasel k te diskuzi:
https://www.retrogamer.net/retro_games80/the-making-of-starquake/...so with the Spectrum everything had to be done by your own program; it had to remove all the pixels of the sprite and then move it to the new position and then redraw every pixel back onto the screen. That took a lot of time. The sprite routine alone would probably take up a third of all the processing power while the game was running, and that routine was so important that I must have rewritten my sprite-drawing program a dozen times.
-
Pavel TišnovskýZlatý podporovatel
jj na atárku je to podobné - ten pokrok ve využívání HW ve hrách je tam taky vidět (a taky to, že prostě si mohli dovolit používat větší EPROM na cartridge, později i disketové hry typu Goonies atd.)
PS s tím rozmazlením - no prostě MOS 6502 ne všechno utáhl hrubým výpočetním výkonem, tak jsme měli koprocesory (ANTIC a GTIA) :-) Potom paradoxně (z vnějšího pohledu, interně to byl "swap" technologií) přišlo STčko, kde to zase čistě táhnul CPU a Blitter už přišel pozdě (už jen tím, že byl optional, tak se na něj nedalo spoléhat)
-
No jo, nechal jsem se unést. Posun dat opravdu peklo v assembleru není, ale proti pohodě zápisu do registru horizontální pozice je to nějaká ta práce navíc. Peklo je to možná v Basicu, ale i tam se to dá udělat rychle šikovnou manipulaci s řetězci.
Uznávám, že např. na ZX Spectru byly sprity opravu hardcore pro opravdové programátory a klobouk dolů před nimi. Také jsem slyšel, že šla sice použít i instrukce Z80 pro kopii paměti, ale že byla pomalejší, než když si ten cyklus programátor napsal sam. Podrobnosti ani CPU neznám, jen kulím oči a kroutím hlavou. Aniž bych chtěl zvednout rukavici k flame , složitost programování spritů na Spectru vysvětluje, proč často bylo vidět, jak ty sprity poblikávají. Na tohle jsme právě na Atari nebyli zvyklí, protože se posuny spritů s oblibou dělaly v době vertikálního zatmění paprsků obrazovky, takže pohyb byl pak krásné plynulý. Ten grafický koprocesor prostě měl něco do sebe. Na jednu stranu to bylo omezení, na druhou stranu velká pomoc. -
Pavel TišnovskýZlatý podporovatel
"počítání kolizí je mazec" - no toto už není úplná trivka, když se to má udělat dobře a rychle v SW. Atárko má detekci kolize s pixelovou přesností (proto taky je možné použít v Berzerku trik a nechat se střelit mezi hlavu a tělo do mezery, kde chybí nakreslený krk - jinak se nedá ve vyšších obtížnostech hrát). To udělat v SW je dost pomalé, tak to snad ani nikdo neřeší a jedou se nějaké bounding boxy.
