Welcome, Guest. Please login or register.


Author Topic: game00 (Read 18813 times)

Offline geco

  • EP addict
  • *
  • Posts: 5431
  • Country: hu
  • OS:
  • Linux Linux
  • Browser:
  • Firefox 24.0 Firefox 24.0
    • View Profile
Re: game00
« Reply #120 on: 2014.August.01. 18:26:49 »
Quote from: Z80System
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 ?
Húú, igazad van, a megszakítás nem fogja maga alól kilapozni p0-át :oops:

Offline Z80System

  • EP addict
  • *
  • Posts: 3926
  • Country: hu
  • OS:
  • Windows 7/Server 2008 R2 Windows 7/Server 2008 R2
  • Browser:
  • Chrome 36.0.1985.125 Chrome 36.0.1985.125
    • View Profile
Re: game00
« Reply #121 on: 2014.August.01. 18:34:55 »
Quote
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,

Ezt meg még annyira sem értem ... persze hogy egszerűbb lenne simán csak átváltani a nullás lapon a szegmenst, és hagyni a kódot siman tovább futni, de hát ha van egy belépési címed a cél szegmensben, meg van mondjuk 3 helyről hívva a forrás szegmensből a függvény, akkor max. úgy lehetne megoldani amit mondasz, hogy a lapváltó utasítással felülírom a forrás szegmenst azon a részen, ami a cél szegmens belépési pontja előtt van ... aztán ráugrok, az ott "helyben" átvált, és akkor a cél szegmensen már a belépési pontnál leszek,
de aztán visszaváltáskor meg a cél szegmenst kéne felülírni ... de hát ezeket vissza kellene másolni ... nem értem ez miért lenne egyszerűbb ...

Ez az eset max. akkor lehet egyszerűbb, ha a forrás és cél meg a visszaút is csak 1:1 -es megfelelésű, és eleve úgy vannak a kódok befordítva, hogy az egyik "vége" passzoljon a másik "elejéhez", de nálam nem ez a szitu, én egy tetszőleges cross segment hívást valósítok meg, ahol a hívott kód ugyanazon a lapon (nullás) fog futni mint a hívó kód,
és csak átmenetileg van a p1 is átállítva, csupán a "vezérlésátadás" idejére.

Nem ?
Z80 System

Offline geco

  • EP addict
  • *
  • Posts: 5431
  • Country: hu
  • OS:
  • Linux Linux
  • Browser:
  • Firefox 24.0 Firefox 24.0
    • View Profile
Re: game00
« Reply #122 on: 2014.August.01. 19:04:55 »
De, meg akkor, ha a HL, vagy IX, vagy IY regisztered szabadon felhasználható, lapváltás előtt megadod a regiszter értékét, majd lapváltás, és a lapváltás utáni utasítás pedig a egy JP (HL), vagy épp a megfelelő regiszter, ha a verem másik szegmensen lenne, akkor még azt lehetne használni az ugrásra.

Ezt a JP (HL)-es megoldást használom odaváltásra, vissza pedig úgy emléxem, hogy a verem tartalmát egy RET-tel, és a verem a 0-ás lapon van, 0-ás lapról 0-ás lapra ugrással.
« Last Edit: 2014.August.01. 19:25:06 by geco »

Offline Z80System

  • EP addict
  • *
  • Posts: 3926
  • Country: hu
  • OS:
  • Windows 7/Server 2008 R2 Windows 7/Server 2008 R2
  • Browser:
  • Chrome 36.0.1985.125 Chrome 36.0.1985.125
    • View Profile
Re: game00
« Reply #123 on: 2014.August.01. 19:24:35 »
Hmmm ... hát hogy regiszter vagy nem regiszter, az tulajdonképp megint mindegy, lehet az egy másik lapokon lévő változó is, amiben átadsz címet,

de valóban így már csak egy helyen kell ( de ott továbbra is ) szinkronban lenni a 2 szegmens kódjának,
vagyis mindkét szegmensen egymáshoz passzoló helyeken kell legyen be és kiléptető kód,

és akkor mondjuk regiszterben vagy memóriaválzozóban meg lehet adni a cél címet,
call -lal meg lehet hivni a váltókódot,
mely váltókód átváltja a lapot,
és a célszegmensen lévő illesztett kód a kapott paraméterek szerint még mindíg szubrutinhivás szeruen meghivja a célfüggvényt,
célfüggvény visszatér a váltókódhoz ret -tel,
a váltókód visszaváltja eredeti szegmenst,
és az eredeti szegmensen szintén illesztve lévő kód kiad egy ret -et,
amivel visszatér a hívóhoz.

Igen ... elég szimpatikus ... Egyszerűbbnek épp nem mondanám,
sőt ez igényel egy helyen illesztett kódot, míg a p1 bevonásos módszer nem igényel,
de az olyan szimpi, hogy a p1 -et nem kell macerálni ...
Z80 System

Offline Z80System

  • EP addict
  • *
  • Posts: 3926
  • Country: hu
  • OS:
  • Windows 7/Server 2008 R2 Windows 7/Server 2008 R2
  • Browser:
  • Chrome 36.0.1985.125 Chrome 36.0.1985.125
    • View Profile
Re: game00
« Reply #124 on: 2014.August.01. 19:30:07 »
Sőt ... ha már memóriaváltozó, amit mindketten látnak ...

A váltókód is lehetne másik lapon ... és akkor nem kellene az illesztés sem ...

Pld. van nekem az a 8K hang bufferem az egyik video szegmensemen, amiből úgyis lecsípek majd egy pár bájtot ... Ott lehetne a váltókód is, és akkor triviális lenne ...
Z80 System

Offline geco

  • EP addict
  • *
  • Posts: 5431
  • Country: hu
  • OS:
  • Linux Linux
  • Browser:
  • Firefox 24.0 Firefox 24.0
    • View Profile
Re: game00
« Reply #125 on: 2014.August.01. 19:30:47 »
Igen, annyival egyszerűbb, és gyorsabb, hogy nem kell pluszban lapozgatni, egy lapozás egy váltás, igen annyi a macera, hogy 2 helyen illeszteni kell a kódot mind a két lapon.

Valami ilyesmi a váltás:

Code: [Select]
      ld     hl,rutin1
       call   pagein


pagein out    (0b0h),a
és már az új lapon
       jp     (hl)

rutin1
       ...
       jp     pagebck

pagebck out   (0b0h),a
eredeti lapon:
       ret

és máris a call pagein után járunk


Offline geco

  • EP addict
  • *
  • Posts: 5431
  • Country: hu
  • OS:
  • Linux Linux
  • Browser:
  • Firefox 24.0 Firefox 24.0
    • View Profile
Re: game00
« Reply #126 on: 2014.August.01. 19:32:31 »
Quote from: Z80System
Sőt ... ha már memóriaváltozó, amit mindketten látnak ...

A váltókód is lehetne másik lapon ... és akkor nem kellene az illesztés sem ...

Pld. van nekem az a 8K hang bufferem az egyik video szegmensemen, amiből úgyis lecsípek majd egy pár bájtot ... Ott lehetne a váltókód is, és akkor triviális lenne ...
Így még egyszerűbb, de mintha mondtad volna, hogy a videóramban is vannak kisebb lyukak, az is felhasználható, csak pár bájtra van szükség.
Nekem sajnos nem volt erre lehetőségem, csak a 0-ás lapon.

Offline Z80System

  • EP addict
  • *
  • Posts: 3926
  • Country: hu
  • OS:
  • Windows 7/Server 2008 R2 Windows 7/Server 2008 R2
  • Browser:
  • Chrome 36.0.1985.125 Chrome 36.0.1985.125
    • View Profile
Re: game00
« Reply #127 on: 2014.August.01. 19:47:50 »
Ja, kúlság,

bár a konkrét módszerben nekem nem tetszik hogy a rutin1 az jp     pagebck -kel tér vissza,
mert akkor ez már nem egy függvény, hanem egy kizárólag pagein -nel hívható függvény,
sokkal általánosabb, ha a függvények, mint a rutin1 nem tudja, hogy hogy hívták,
ret -tel térjenek vissza, de akkor pagein szubrutinkent kell hivjon nem sima jp (hl) -lel,
és akkor lehet a rutin1 -gyet hívni szegmensen belülről is, simán, meg másik szegmensről is.

abban viszont egyetértünk, hogy valszeg ez a legszebb módszer, ez az "egy helyen illesztett" módszer + regiszeterekben a hívási paraméterek dolog,
mert ezt az illesztett vezérlésátadó kódot ezt pár bajtból meg lehet írni, akár úgy hogy mentse el mi volt p0 -án (stack -re) és visszatérés után azt kapcsolja vissza,
így egyszer kell megírni a kódot, mindentől független lesz (szegmens értékek, függvény címek), és minden olyan szegmensre ami a 0 -ás lapra kerül, be lehet simán "másolni" a 100h előtti területre valahova ...

és akkor bármikor belehívhatnak egymásba úgy, hogy semelyik más lap nem kell elkapcsolódjon közben, semilyen más laptol nem függ a vezérlésátadás, és meg a megszakot sem kell továbbra sem lekapcsolni ...

szupi.
Z80 System

Offline geco

  • EP addict
  • *
  • Posts: 5431
  • Country: hu
  • OS:
  • Linux Linux
  • Browser:
  • Firefox 24.0 Firefox 24.0
    • View Profile
Re: game00
« Reply #128 on: 2014.August.01. 20:24:12 »
mivel mindig a lapozó rutint hívom meg, és annak fix a pagebck része, ezért szerintem fölösleges időhúzás lenne CALL-ra cserélni a JP (HL)-t.

Amúgy annyit elírtam a kód példámban, hogy az OUT (0B0h)-k előtt fixen meg vannak adva nálam a szegmensek is, mivel csak két lap között váltok, de természetesen egyszerűen be lehet vonni több lapot is, és tök rugalmas, CPC-n néztem pl a North&South-nál is a memórialapozást, úgy oldották meg, hogy P1-re belapozza velamelyik alternatyív szegmenst (0* ,1* ,2*, 3*), azt átmásolja, majd visszalapozza az eredetit, ott sokkal kevesebb variációs lehetőség van, legfőképp csak a P1-re lehet mindent alternatív memórialapot belapozni, az eredeti 64Kb-s szettből csak az épp odavalót ( 1-est ), és a 3-ast.

Offline Z80System

  • EP addict
  • *
  • Posts: 3926
  • Country: hu
  • OS:
  • Windows 7/Server 2008 R2 Windows 7/Server 2008 R2
  • Browser:
  • Chrome 36.0.1985.125 Chrome 36.0.1985.125
    • View Profile
Re: game00
« Reply #129 on: 2014.August.01. 20:31:51 »
Ja és +1 "komolyabb" változás a dolgokban,

azt találtam ki, hogy ahhoz hogy demonstrálhassam a frame -es játék előnyeit a 2,3,X frame -es játékokhoz képest,
ahhoz tökéletesen elég, ha a képfrissítést lassítom be N frame -esre, a többi működés lassítása nem szükséges.

Elvben az még sokkal többet rontana a fílingen, ha a játék többi része is lassulna a kijelzési frekivel együtt,
hisz egy "síma" több frame -es játék a billentyűt is csak kissebb frekin olvassa, az összes léptetését is csak kissebb frekin végzi el,
de én ennyivel is "könnyítek" a sok frame -esség dolgán, hogy mivel a kód képes lesz frame -esen is futni,
ezért a kijelzést ugyan lassítani fogom a tetszőleges frame számra, de a léptetéseket, inputot, hangot mindent változatlanul játszok majd le.

Vagyis egy elvben mondjuk 50 frame -esre állítva, a játék képe majd csak másodpercenként fog frissülni, de a másodperces "slideshow" alatt a háttérben (vakon) a játék ugyanúgy 50FPS -sel játszható lesz majd. Szóval minden sebesség marad teljesen változatlan majd, a freki csökkenésével tisztán a képfrissítés sebessége fog csökkenni.

Ez lesz az ideális eset (ennél csak rosszabb lehet a helyzet általánosságban) hogy a kétkedők meglássák, hogy mit jelent valait 50FPS -sel játszani, vagy kisebb frekiken. Már a 8 bites korszakban ... ráadásul én még a felbontást is lefeleztem ugye, tehát még kisfreki barátabb lett így a játék. De sztm. még így is elsöprő lesz az 50 FPS hatása. (A kisebb frekikhez képest, ugyanazon játéknál.)

Remélem nem én lepődök majd meg ... :)
Z80 System

Offline geco

  • EP addict
  • *
  • Posts: 5431
  • Country: hu
  • OS:
  • Linux Linux
  • Browser:
  • Firefox 24.0 Firefox 24.0
    • View Profile
Re: game00
« Reply #130 on: 2014.August.01. 20:35:22 »
Szerintem a játékot is lassítsd be, ne csak a kijelzést, mert pl 1 másodperces kijelzés késleltetlsnél 50Hz-es game speed mellett játszhatatlan lesz, játék belassításnál játszható , csak nagyon darabos, úgyis ez a lényeg szerintem.

Offline Z80System

  • EP addict
  • *
  • Posts: 3926
  • Country: hu
  • OS:
  • Windows 7/Server 2008 R2 Windows 7/Server 2008 R2
  • Browser:
  • Chrome 36.0.1985.125 Chrome 36.0.1985.125
    • View Profile
Re: game00
« Reply #131 on: 2014.August.01. 20:40:47 »
Ez iménti dolog a képfrekivel azért érdekes, mert van pár olyan dolog, ami egyrészt megköveteli a 50Hz -es működési frekit, ilyen pld. a hang, most nem magyarázgatom miért, és 25Hz -en már egyszerűen szétesne, és eddig izgultam hogy fogom összeegyeztetni ezeket az 50 Hz -es működésű dolgokat, a lassabb működésekkel,

de így, hogy csak a képfreki lassul majd, így csak azt kell mostantól következetesen megoldanom, hogy a szteppelés és a kirajzolás jól el legyen különítve,

és egyszerűen meg fogom tudni oldani az extrém lassításokat is, és nem fog elsikkadni ez a 50Hz proof funkció.
Z80 System

Offline geco

  • EP addict
  • *
  • Posts: 5431
  • Country: hu
  • OS:
  • Linux Linux
  • Browser:
  • Firefox 24.0 Firefox 24.0
    • View Profile
Re: game00
« Reply #132 on: 2014.August.01. 20:44:54 »
Ja, én úgy gondoltam, hogy a hangot nem belassítva, az úgyis megszakításból fut, tehát minden, ami a megszakításban fut, azt eredeti sebességgel futtatni, csak az azon kívüli részt belassítani úgy, hogy x darab frame-et várjon, ha 0 várakozás van, akkor ennek a résznek az átugrásával.

Offline Z80System

  • EP addict
  • *
  • Posts: 3926
  • Country: hu
  • OS:
  • Windows 7/Server 2008 R2 Windows 7/Server 2008 R2
  • Browser:
  • Chrome 36.0.1985.125 Chrome 36.0.1985.125
    • View Profile
Re: game00
« Reply #133 on: 2014.August.01. 20:48:11 »
Quote
Szerintem a játékot is lassítsd be, ne csak a kijelzést, mert pl 1 másodperces kijelzés késleltetlsnél 50Hz-es game speed mellett játszhatatlan lesz, játék belassításnál játszható , csak nagyon darabos, úgyis ez a lényeg szerintem.
Egyrészt azért nem, mert ez lesz így az egyszerűbb, előbbi okokból.

Másrészt azért nem, mert eleve sem így akartam, hanem úgy hogy az eredeti sebesség ne változzon. A bizonyításnak pont az a lényege, hogy "mennyivel bénább vason ugyanzon 8 bites játék kisebb frekiken, mint 50 FPS -sel", és ehhez nagyon fontos az is, hogy minden sebesség ugyanolyan maradjon, minden frekin.

Tehát ha az űrhajó 50FPS mellett 1 másodperc alatt megy el bal szélről jobb szélre, mert a játékbeállítások azt igenylik,
akkor 25FPS frissítés mellett is pont 1 másodperc alatt menjen el.

És mennyivel randább lesz 25FPS -en mint 50FPS -en.

Ha nem úgy csinálnam mint írtam, pont azzal kellene vesződjek, hogy mindenki arányosan nagyobbakat lépjen a kisebb frekiken.

Az irdatlan lassú frissítések nem számítanak semilyen szempontból, senki nem fog 1 másodperc / pixellel játszani, és ha mégis játszana, akkor sem fog, mert nem ez a cél. Az egy másodperces frissítés példát csak magyarázatnak írtam.
« Last Edit: 2014.August.01. 21:05:54 by Z80System »
Z80 System

Offline geco

  • EP addict
  • *
  • Posts: 5431
  • Country: hu
  • OS:
  • Linux Linux
  • Browser:
  • Firefox 24.0 Firefox 24.0
    • View Profile
Re: game00
« Reply #134 on: 2014.August.01. 20:53:37 »
értem, én másképp közelítettem meg a bénaságot, azt hittem azt szeretnéd bizonyítani, hogy mennyivel bénább, ha 1 pixelt haladunk nem egy, hanem 2-3 frame alatt.