Welcome, Guest. Please login or register.


Author Topic: game00 (Read 34584 times)

Offline szipucsu

  • Global Moderator
  • EP addict
  • *
  • Posts: 9888
  • Country: hu
    • Támogató Támogató
    • Webnyelv.hu - Tanuljunk nyelveket!
Re: game00
« Reply #105 on: 2013.November.18. 13:32:38 »
Quote from: endi
vagy kacskaringósan, vagy mit tudom én
Az már inkább hóesés lenne. :D És esetleg egy télapót kéne irányítani, és összegyűjteni a mikuláscsomagokat a levegőben?
100 SOUND SOURCE 2,STYLE 128,PITCH 25.2,SYNC 1
110 SOUND PITCH 25,SYNC 1
120 ! Videos

Offline Z80System

  • EP addict
  • *
  • Posts: 3848
  • Country: hu
Re: game00
« Reply #106 on: 2013.November.18. 13:34:33 »
Quote
vagy kacskaringósan, vagy mit tudom én
Van a felrakott példák között effektes, annál is kacskaringósabban ?
Z80 System

Offline Z80System

  • EP addict
  • *
  • Posts: 3848
  • Country: hu
Re: game00
« Reply #107 on: 2013.November.18. 15:45:59 »
Ja, akit érdekel, színkód az előző példákban lévő raszteridőkhöz:

piros: billentyű mátrix beolvasása memóriába
zöld: egy C kód a hangok indításához, (pár IF szerkezet :)) csak átmenetileg van benne
sárga: csillagok
kék: sprite

és a többi szín a többi mócsing, LPT váltás, ilyesmik ...
Z80 System

Offline Z80System

  • EP addict
  • *
  • Posts: 3848
  • Country: hu
Re: game00
« Reply #108 on: 2013.November.19. 20:37:14 »
Kitaláltam hogy fogok színeket vinni a game00 -ba.

Annyi szín lesz benne, hogy azt fogjátok mondani, hogy túl csiricsáré, lehetne egy kicsit visszafogottabb, ízlésesebb ... :)

De nem lesz. Atomszínes lesz.

Zozo örülhet, ebben a játékban ki sem próbálom a villogtatásos színkeverést. Majd másikban. Ebben a játékban vétek lenne.

Lesz olyan, hogy 20 szín lesz a képen csak a sprite -okból + a csillagok színei (ami ugye már most is sok színű, grádiens) + egyéb sokszínű háttér effektek ... :)


Olyan effektek lesznek benne, hogy ilyen full konzol fíling lesz ...

(Persze ehhez előbb még túl kell jussak a sprite kezelés apró problémáján, de ha azon átvergődtem, akkor már síma ügy lesz, a szín és összhatáskérdésen nem kell tovább vergődjek, az sztm. ott lesz.)

Ja, és a színek persze úgy vannak értve, hogy sehol nem lesz zavaró "attributum" hatás (mikor a grafikát vágja valami színblokk). Teljesen minimális, vagy zéró attributum hatás lesz. Abszolút úgy fog tűnni, mintha normál pixel grafika lenne. (Persze ha valakinek már a mostani csillagmozgás is "attributum" hatás, azon nem fogok tudni segíteni. De annál erősebb "attributum" hatás nem lesz benne.)

(Ha nem képzelem el rosszul a dolgokat, persze.)


Na jó ... nem konzol ... ahhoz egy sprite -on belül még mindíg túl kevés szín lesz ...

De színes lesz. Az tutkó. Nagyon. És hibák nélkül.
« Last Edit: 2013.November.20. 10:56:35 by szipucsu, Reason: Sok kis hozzászólás összevonása. »
Z80 System

Online Zozosoft

  • Global Moderator
  • EP addict
  • *
  • Posts: 14710
  • Country: hu
    • http://enterprise.iko.hu/
Re: game00
« Reply #109 on: 2013.November.19. 21:15:14 »
Quote from: Z80System
Zozo örülhet, ebben a játékban ki sem próbálom a villogtatásos színkeverést.
És ezért miért kéne örülnöm?  :oops:

Offline Z80System

  • EP addict
  • *
  • Posts: 3848
  • Country: hu
Re: game00
« Reply #110 on: 2013.November.19. 21:18:13 »
Quote
És ezért miért kéne örülnöm?  

Nem te mondtad, hogy ne csináljam ?

Rád emlékeztem ...

Valaki mondta régebben, mikor a színek voltak terítéken, hogy ne legyen olyan.
Z80 System

Online Zozosoft

  • Global Moderator
  • EP addict
  • *
  • Posts: 14710
  • Country: hu
    • http://enterprise.iko.hu/
Re: game00
« Reply #111 on: 2013.November.19. 22:20:15 »
Quote from: Z80System
Nem te mondtad, hogy ne csináljam ?
Azt nem mondtam, hogy ne csináld, csak kérdeztem, hogy LORES 4 helyett nem lenne-e jobb a HIRES 16?
Lehet, hogy több* helyet foglal, cserébe egyszerűbb kód. Pixel méret ugyanaz.

* bár pontosan nem tudom hogyan villogtatnál, csak az LPT-t piszkálnád folyton? Az én módszeremben két LPT két videómemóriával van, tehát helytakarékosság ez esetben nem lenne.

Offline Z80System

  • EP addict
  • *
  • Posts: 3848
  • Country: hu
Re: game00
« Reply #112 on: 2013.November.19. 22:33:30 »
Quote
Azt nem mondtam, hogy ne csináld, csak kérdeztem, hogy LORES 4 helyett nem lenne-e jobb a HIRES 16?
Ja, én is megtaláltam végül.

De jól van, ha nem akarsz, nem kell örülj ... :)


Quote
Lehet, hogy több* helyet foglal, cserébe egyszerűbb kód. Pixel méret ugyanaz.

Hát a hely takarékossága nekem legelsősorban, nem memória takarékossági kérdés, hanem sebesség kérdés. LORES -ben fele akkora memória mozog, kétszer annyi sprite -ot lehet kirakni. Nagyjából.


Quote
* bár pontosan nem tudom hogyan villogtatnál, csak az LPT-t piszkálnád folyton? Az én módszeremben két LPT két videómemóriával van, tehát helytakarékosság ez esetben nem lenne.

Igazából ebben a játékban nem egész képeket akartam villogtatni (eleve dupla pufferrel megyek a 100% kirajzolási villogásmentességért, szal nem lenne hely többlet), hanem csak az egyes sprite -okat, mivel a játék 50 FPS -sel fog menni, ezért ilyen technikákat is meg lehetne engedni, hogy egy-egy képrészlet (sprite -oknak csak pixeleik, ahova kellene az új szín) villog csak.

De mondom, erre a játékra ez már nem vonatkozik, mert villogás nélkül is lessz annyi szín, hogy nincs is annyi a palettán.

Más játékra meg már más villogtatási szabályok fognak vonatkozni.

Pld. a game01 (ami egy oldalszkrollos HIRES dolog lenne, "sok" sprite -tal és sok nagyfelületű tile animációval), na az lehet hogy egész képernyő villogós lesz.

De nem kell úgy előre szaladni, ki tudja megérjük -e.
Z80 System

Offline Z80System

  • EP addict
  • *
  • Posts: 3848
  • Country: hu
Re: game00
« Reply #113 on: 2013.December.03. 12:05:39 »
Ha emlékeztek még rá, volt egy olyan tárgyalás game00 témakörben valahol, hogy mennyire lehet a hangmegszakba úgy cipőkanalazni valamit (itt a csillagmozgás kódjáról volt konkrétan szó), hogy ne legyenek ott komolyabb veszteségek abból fakadóan, hogy nem merjük teljesen kitölteni a megszakot kóddal, hogy nehogy kihagyjunk hang megszakítást azért, mert véletlenül a kódunk épp hosszabb idő alatt futott le.

Namost közben az jutott eszembe, hogy ha tudunk a megszakításban futó feladattal párhuzamosítható dolgot csináltatni a z80 -nal, akkor nem is kell kipumpálni a megszakot, akár "felesben" is járathatjuk, ha kell, hisz maga a megszak mindenképp lenne a hang miatt, a létezésének idejét nyilván nem tudjuk megspórolni, és mind megszakban mind a főprogramban a programunk fog valami értelmeset csinálni továbbra is.

Namost a csillagok esetében az elég gáz lehet, hogy pont azokat kell kirajzolni legelőször, de hála istennek nem tartanak túl sokáig (8-10 raszter lehet), es közben futhatnának a szprájtmozgató és tesztelő kódok.

Vagyis a főprogramom (jelenleg a konkrét hangkeltésen kívül mindent az csinál) úgy módosulhat, hogy nem a csillagok kirajzolásával kezdi a kört, hanem a sprite -ok, mozgatásával és tesztelésével, állapotváltozásokkal, szóval a játékkal, ami csak a háttérben zajlik, közben a megszakítás, szép szellősen, ahogy csak kényelmesen meg lehet valósítani kirajzolja a csillagokat, mikorra végez majd (minnél jobban ki van töltve a megszak, annál lassabb lesz a játékkezelés a főprogramban) a főprogram még úgyis a játékot fogja kezelni. mert nem hinném hogy a teljes gameplay tesztelése rövidebb idő lenne mint ami a 8-10 raszteres csillagkirajzolásból MEGMARAD a főprogram számára.

Vagyis gond nélkül (itt most a gond az időveszteség szinonímája akar lenni) interleave -elhető be a főprogram mellé bizonyos feladatok elvégzése, és jelen esetben hiába a nehezítő körülmény a csillagok sorrendjével, lehet találni mellé passzolo főprogram feladatot.

Majd ha a főprogram végzett a gameplay logikával, nyugodtan számíthat rá, hogy a megszakban a csillagok is kirajzolódtak közben, és folytathatja a sprite -ok kirajzolásával.
Z80 System

Offline Z80System

  • EP addict
  • *
  • Posts: 3848
  • Country: hu
Re: game00
« Reply #114 on: 2014.August.01. 13:43:10 »
Korábbi tárgyalások meg elmélkedések fonalát felvéve, következő döntésekre jutottam:



- Átlépek Assembler -re a C fordítóról. Ami persze az eddigi dolgok újraírását fogja jelenteni, de azokban igazából nem a begépelés, hanem a rengeteg irányvonal meg lehetőség közti választás volt a hosszú, szóval ez nem lesz túl nagy akadály.



- Szakítok azzal a gyakorlattal, hogy a scanline- ok 100H -val osztható címen kezdődnek. Ez mind a csillagmozgásnál, mind pedig a sprite kirakásnál elég komoly veszteség lesz sebességben, ez az egyszerű tényező a csillagmozgást akár duplázhatja időben, a sprite kirakást meg másfelezheti, viszont a video ram nem nyúlik szét 3 szegmensen, hogy aztán a scanline -ok közé kelljen egyéb értékes adatot fűzni be, vagy még rosszabb esetben üresen hagyni a közöket, hanem LPT- stől elfér 24K -n. Ami sajnos még mindíg 2 szegmens, de legalább nem három. 2 scanline- t fogok egy 256 -os blokkba tenni, így 128 -cal osztható címen fog kezdődni minden scanline. A scanline- ok közeinek vesztesége így nem egészen 4K lesz.



És akkor így választhatok a következő 2 lapozási stratégia közül, melyek közül az első:



p0: Fix kód+adat. A program olyan kódja és adatai melyeket mindenki minden körülmények között elérhet.

p1: Változtatható kód+adat. Ilyen pld. a csillagmozgás kód+adat, vagy a sprite -ok kód+adat területe. Többnyire saját magukban operáló kódok, maximum még a p0 -át használhatják, ha szükséges. Nyilván pld. a hívásukkor a paraméterek lehetnének a p0 -án pld.

p2: Video

p3: Video+8576 byte (összesen kb. 2 másodpercnyi) hang buffer.



Vagy méginkább a második:



p0: Változtatható kód+adat. Megoldva a 0 -ás lap váltást, a megszakkezelést és a lapozgatós hívást nincs igazi akadálya annak, hogy egy szegmensen tartsuk a kód+adat területeket. Mivel amúgy is kevés számú hívással hív majd bele a program a különböző kód+adat szegmensein eltárolt programokba, pld. "rajzold ki a csillagokat" vagy "torold le az osszes sprite -ot", stb. tehát mondjuk körönként maximum 10-20 darab (és akkor szerintem túllőttem nagyon) ilyen szegmensek közötti hívás lesz, vagyis sebességben nem fog meglátszani. Az igazi bénaság ezzel az, hogy mikor a 0 -ás lapon mondjuk a sprite kirajzoló szegmens van a sprite kód+adat -tal, akkor a sprite -ok pozíciói nem fognak direktben látszani, vagy legalábbis nem a 0 -ás szegmensen, vagyis azokat vagy még a váltás folyamata alatt (mikor még mindkét szegmens látszik) át kell másolni a sprite szegmensre, vagy pedig eleve olyan helyre kell rakni, ami a másik három lap -on van.

p1: Video

p2: Video+8576 byte (összesen kb. 2 másodpercnyi) hang buffer. És akkor ide lehetne annak a 8576 byte -nak egy kis darabkájába rakni azokat az állapotokat (pld. előbb említett sprite pozíciók), melyekkel a 0 -ás lapra lapozott kód szegmensek kommunikálnak.

p3: Hang buffer. (Még kb. 4 másodpercnyi.)



Tehát ha akarok 0 -ás lap váltogatást, akkor összesen 6 másodpercnyi, ha meg nem akarok, akkor 2 másodpercnyi hangbuffert tudnék címtérben tartani.
Z80 System

Online Zozosoft

  • Global Moderator
  • EP addict
  • *
  • Posts: 14710
  • Country: hu
    • http://enterprise.iko.hu/
Re: game00
« Reply #115 on: 2014.August.01. 14:06:24 »
Kimaradt a felsorolásból a verem! Ami nem árt ha mindig be van lapozva :-)

Offline Z80System

  • EP addict
  • *
  • Posts: 3848
  • Country: hu
Re: game00
« Reply #116 on: 2014.August.01. 14:31:40 »
Quote
Kimaradt a felsorolásból a verem! Ami nem árt ha mindig be van lapozva
Nemtom kimaradt -e vagy sem, de az nálam (is ugye, korábbiakban megbeszéltek értelmében) 100h -n van,

ami teljesen jó a lapváltáskor is mert:

- letiltjuk a megszakokat
- belapozzuk p1 -re az új p0 szegmens jelöltet
- meghivjuk a cross-segment függvényünket a p1 -en (4000h -val növelt címen természetesen), ekkor eredeti p0 szegmens stack -jére pakolódik a visszatérési cím

- a cross-segment függvényünk úgy kezdi, hogy kiolvassa mi van p1 -en és belapozza p0 -ra
- ráugrik önmaga folytatására (ugrás utáni következő utasítás) a p0 -on
- visszalapozza p1 -re az eredetileg ott levő szegmenst (itt. video)
- engedélyezi a megszakokat



- elvégzi amit kell, pld. kirajzol sprite -okat


- letiltjuk a megszakokat
- berak p1 -re p0 -t
- ráugrik a 4000- rel növelt önmagára
- visszarak p0 -ra eredeti nullaslap szegmenst, melynek stack -jeben ott a visszateresi ertek
- ret -tel visszater

- es mi pedig visszarakjuk p1 -re az eredeti (video) szegmenst
- majd engedelyezzuk a megszakokat



mint látjuk, ez hivó oldalról annyi lesz, hogy:

- letilt megszak
- berakjuk p1 -re az uj p0 szegmensünket
- meghívjuk a függvenyunket a p1 -en
- visszatérés után visszarakjuk p1 -re az eredeti (video) szegmenst
- engedelyezzuk a megszakokat

a többit a hívott függvény végzi.


Mindehhez persze még az is kell, hogy a 100h elotti rendszerváltozók és maga a megszakítás kód is látszódjon minden 0 -ás lap szegmens esetén,
és hogy maga a megszak kód is tiltsa a megszakításokat. Ezek nálam adottak / megoldottak.
« Last Edit: 2014.August.01. 14:43:45 by Z80System »
Z80 System

Offline Z80System

  • EP addict
  • *
  • Posts: 3848
  • Country: hu
Re: game00
« Reply #117 on: 2014.August.01. 14:39:30 »
Sőt mivel nekem a megszak csak zenét játszik le, és az nem nyúl a p1 -hez,
ezért a megszakítások tiltása/engedélyezése dologra nincs is szükség.
Z80 System

Offline geco

  • EP addict
  • *
  • Posts: 7072
  • Country: hu
    • Támogató Támogató
Re: game00
« Reply #118 on: 2014.August.01. 18:15:55 »
Quote from: Z80System
Sőt mivel nekem a megszak csak zenét játszik le, és az nem nyúl a p1 -hez,
ezért a megszakítások tiltása/engedélyezése dologra nincs is szükség.
Azért van, mert az int meghívásakor, meg visszatéréskor a vermet használja (ha 0100h-n van a verem, és P0-t lapozod), okozhat elszállást.
Viszont a 0-ás lap lapozásához van egy egyszerűbb, és gyorsabb módszer, SPEMU-ban is ezt használom, átváltáshoz csak egy sima OUT (0b0h),a -t használok, úgy címezve a belapozandó lapon a kódot, hogy egyből az out utasítás utáni címen folytatódjon a lapozás utáni rész, vissza ugyanígy, csak a váltott lapon más címen az OUT (0b0h),a .és ennek címfolytonos következő utasítása hajtódik végre a visszalapozott lapon.

Offline Z80System

  • EP addict
  • *
  • Posts: 3848
  • Country: hu
Re: game00
« Reply #119 on: 2014.August.01. 18:24:31 »
Quote
Azért van, mert az int meghívásakor, meg visszatéréskor a vermet használja (ha 0100h-n van a verem, és P0-t lapozod), okozhat elszállást.
Nem feltétlen értem. Gondolom a port írás ilyen szempontból atomikus működésű, tehát csak akkor fogja elkezdeni a lapozó utasítást a z80, ha épp nincs megszakításban,
és amíg végre nem hajtotta a műveletet, addig nem is kezdődhet új megszakítás. Vagyis a megszakítás visszatérési címe vagy a régi vagy az új szegmensre fog kerülni, de olyan nem lesz, hogy még a régi szegmensre kerül, de a megszak futása közben érvényesül a lapváltas, és mire visszatérne a megszak, addigra már az új szegmens van a lapon ... nem ?
Z80 System