Vlákno názorů k článku Vykreslování spritů a animací na ZX Spectru (2. část) od _dw - Pred vice jak 6 lety jsem napsal demo...

Pred vice jak 6 lety jsem napsal demo EOB pro ZX 48kb a tam jsem resil atributy zvlast komplikovanym zpusobem, protoze je to uplne jiny zanr her (krokovy dungeon) a nemusim prekreslovat obrazovku x-krat za vterinu. Scena se vykresluje "malirskou" metodou. Postupne se vykresluji objekty od nevzdalenejsiho.

Kazdy sprite obsahuje hlavicku o sirce a vyssce v jednotkach znaku. Sprite se orezava, aby se nekreslilo mimo. Sprite jde i zrcadlit a usetrit si tak misto protoze temer polovina spritu sten je identickych.

;typedef struct
;{252
;    unsigned char  Offset na PIXel data;
;    unsigned char  Pocet_sloupcu_spritu;
;    unsigned char  Pocet_radku_spritu;
;} ZXHeader;

Kazdy znak se vykresluje samostatne a obsahuje vlastni atribut za nim je 0 nebo 8 nebo 16 bajtu dat.

Pokud atribut ma specialni hodnotu tak se to vykresluje odlisne.

Napriklad pokud je atribut 0x40 (jen BRIGHTNESS nastaveno na 1) tak je znak celopruhledny a nejsou tak ani ulozeny jeho data krome toho atributu.

Pokud ma atribut PAPER nastaven na nulu tak ma ten znak pruhledny PAPER, ale obsahuje nejaka data v INK. PAPER se prebira z puvodniho znaku co tam uz je nakreslen.

Pokud ma atribut nastaven FLASH (ten je smazan z vysledku) tak to znamena ze ma znak v sobe i data s maskou (1 v masce znaci pruhlednost = zachova puvodni hodnotu (pouzije se AND)). Nova data se nakresli pak pres OR.

Posledni dva body jdou kombinovat.

Vykreslovaci rutina je tady:
https://github.com/DW0RKiN/3D-Dungeon/blob/master/Source/sprite2buffer.asm

C zdrojak pro prevod bmp spritu (se specialni barvou na pruhlednost) na data co se ukladaji do asm jsem bohuzel ztratil.

Vysledek muze vypadat nejak takto: https://raw.githubusercontent.com/DW0RKiN/3D-Dungeon/master/screen.png

ty sprite se tedy posouvaji po "znacich" nebo tam je fine scrolling? (nebo jak se tomu rika na Spectru, proste posun po pixelech)

Cela scena se prekresluje. Je to "3D" pohled. Bud se tam neco zmeni, pohyb nepratel a nebo se pohnes ty (posun na dalsi ctverec nebo otoceni o 90 stupnu). Sprite maji tak vicemene pevnou pozici kam se kresli (nebo spis 2 pevne pozice). Zmeny muzou byt napriklad u vzdalenejsich sten, ze jsou jinde od stredni vertikaly pohledu. Nebo nejakych drobnosti jako pak, nebo dekoraci.

Spust si radsi demo a pochopis: https://github.com/DW0RKiN/3D-Dungeon/blob/master/dungeon_v7.z80

Kempston joystick:

up move
down move
left move
right move

up+left turning
up+right turning

down+left inventory
down+right inventory

fire action

fire+up first hand
fire+down second hand
fire+left another person
fire+right another person

15. 8. 2023, 17:47 editováno autorem komentáře

ah diky, proste klasickej Dungeon Master style :)

To vypada skvele, fakt jako EOB!

Ted me doslo, ze jsem otazku spatne pochopil a asi spravna odpoved je, ze ty sprity lze umistit (presouvat) po znacich (nasobcich 8 pixelu).

Ve skutecnosti je to trochu slozitejsi, protoze se muze kreslit jak do screenu tak do bufferu, a jeste to je bud uvnitr okna s orezanim a nebo vne.

Scena se kresli v bufferu a pak se to kopiruje na obrazovku tak aby se to nestretlo s "paprskem".

na to jsem se ptal, ale potom jsem si uvedomil, ze to asi neni v krokovacim dungeonu az tak potreba. Prisery jsou (predpokladam) vzdycky dve vedle sebe a kdyztak se posunou o celych osm pixelu stetjne jako v tom dungeon masterovi (EOB zase tak dobre neznam, ale DM jo). V DM to byly ukroky o cely ctverec a nebo kdyz jedna z priser zdechla, tak se zbytek posunul o pul ctverce do stredu.

akorat tedy nechapu, jak jsi to cely i s animacema priser a back bufferem narval do 48kB :)

To se mi na tvůrcích líbí, CPU architektura umí takových věcí, ale když není prostor, nastupuje magie :-)