Welcome, Guest. Please login or register.


Author Topic: Tesztelés (Read 14471 times)

Offline balagesz

  • EP user
  • *
  • Posts: 265
  • Country: hu
  • OS:
  • Linux Linux
  • Browser:
  • Firefox 45.0 Firefox 45.0
    • View Profile
Re: Tesztelés
« Reply #135 on: 2017.January.09. 19:28:33 »
Ami eltér majd a CPC-stől, hogy ott külön palettája van a sprite-oknak, de ez legyen a legkevesebb.

Itt külön paletta - úgy tűnik - nem lesz sajnos, a NICK ezt nem teszi lehetővé. Ezért is lett volna szerencsés, ha az ECx bemenetek kikerülték volna a palettázó áramköröket, és "direkt" mentek volna ki a színkimenetre.

Ez az SPB, SPT ötlet nagyon tetszik, az, hogy meg lehet adni a sprite adat kezdetét, meg méretét főleg, sehol se láttam még ilyet, pl CPC-n fix címek vannak, és ha egy nagyobb sprite-ot akarsz, akkor több kisebből kell összepakolni, és gondolom az SPB tartalmazná a sprite x y pozícióját is.

Azt az "adat-kezdet" dolgot természetesen úgy kell érteni, hogy a bővítés memóriáján belül. Bár gondolom ez egyértelmű. :) Egy SPB tartalmazna az adott sprite-hoz minden szükséges adatot a képén kívül, az X/Y pozíciót is. Jut eszembe: ebből lehetne akár több is, ha ugyanazt több helyre is ki akarnád rakni. Így elég lenne csak 1× felolvasni, kirakni meg lehetne több helyre. :mrgreen:

A látható sprite-tal kapcsolatban, ha több sprite van ugyanazon a helyen ,vagy félig takarásban, kirajzolná az összeset, csak az utolsót jól rápakolná a többire, így lenne ami látható lenne a régebbiekből is?

Természetesen. Mivel egy-egy pixel egy BYTE-ot használ a "frame-buffer"-ből, így ehhez hardveres segítség is lehet: ha átlátszó a kirakandó pixel, nem történik memóriaírás. De ez már technikai részlet, az meg még odébb van.

ha az ütközés vizsgálat sprite pozíció alapján történik majd, ha pedig két sprite aktív pixelének találkozása alapján, akkor maradhat, de gondolom nem ez lesz, mert ehhez egy erőmű kéne.

Az esetleges ütközésvizsgálat mindenképpen kapcsolható kell hogy legyen, mert ebben a felépítésben rendesen viszi az erőforrást. :) De pixeles találkozás alapon gondolom a vizsgálatot, ahhoz viszonylag egyszerű és jól optimalizálható a matek. (Így, első végiggondolásra legalábbis... ;) )

Azert ne felejtsuk el, hogy itt ez egy hardware :) Mig emulatornal nagy szivas a sprite utkozes vizsgalat (lassu ...), hardware-nel nem lassit,

Ja, de itt pont nem hardver az ütközésvizsgálat. Bár... Most hogy mondod, DE! :) Csinálható ehhez "egyszerű" hardveres segítség, ismét egy megjegyzendő ötlet! :oops:

És ahol két EXTC találkozik, az már adja a jelet, hogy az aktuális sprite nekiment valaminek.

Ez igaz, ha a "világon eddig használt" "real-time" verzió van megvalósítva. Ha a "saját" verziómat nézem, ott nincs több párhuzamos EXTC jel, csak egy van.

If a fast processor is used for sprites, why not implement some simple form of maths coprocessor?  Of course in floating point BCD...

Ha van a külső µC, akkor azt lehet használni koprocesszornak is, persze. Mondjuk én nem biztos, hogy FPU-nak használnám elsősorban, hanem inkább blitter-nek. Persze a kettő nem zárja ki egymást. ;)

Kicsit ott-topic, de: https://www.youtube.com/watch?v=h42neZVvoMY

Hát igen, eléggé "félőrült" a jóember... (Persze a jó értelemben.)

Offline geco

  • EP addict
  • *
  • Posts: 5430
  • Country: hu
  • OS:
  • Linux Linux
  • Browser:
  • Firefox 45.0 Firefox 45.0
    • View Profile
Re: Tesztelés
« Reply #136 on: 2017.January.10. 08:40:31 »
Jut eszembe: ebből lehetne akár több is, ha ugyanazt több helyre is ki akarnád rakni. Így elég lenne csak 1× felolvasni, kirakni meg lehetne több helyre. :mrgreen:
Jó ötlet, viszont ez limitet szabna egy sprite kirakási számának, vagyis nem ,mert ha monsdjuk 8 xy pozíció lenne az SPB-ben, akkor egy újabb SPB-vel ugyanarra a spritre-ra még nyolc pozíció lenne lehetséges.

Offline lgb

  • EP addict
  • *
  • Posts: 3497
  • Country: hu
  • æðsta yfirmaður
  • OS:
  • Linux (Ubuntu) Linux (Ubuntu)
  • Browser:
  • Firefox 50.0 Firefox 50.0
    • View Profile
    • http://lgb.hu/
Re: Tesztelés
« Reply #137 on: 2017.January.10. 09:02:32 »
Ha meg nem volt rola szo (?), az is erdekes, hogy VSYNC ideje alatt mennyi adatot tudna beolvasni. Oke, akkor is osztoznia kell a Z80-al esetleg, de legalabb mas EXTCOL infot kozben nem kell kiadnia. Az FPGA a belso block RAM-jabol meg aztan eleg gyorsan elszorakozhat persze, ha mar ki kell rakni (az megint egy erdekes kerdes, de talan a dolgok tulbonyolitasa, hogy meg lehessen adni, hogy adott sprite mondjuk nem valtozik minden frame-ben, tehat nem kell mindig ujraolvasni feltetlen ...).

Offline ergoGnomik

  • EP lover
  • *
  • Posts: 840
  • Country: hu
  • Stray cat from Commodore alley
  • OS:
  • Windows NT 10.0 Windows NT 10.0
  • Browser:
  • Firefox 50.0 Firefox 50.0
    • View Profile
Re: Tesztelés
« Reply #138 on: 2017.January.10. 13:19:42 »
... hogy VSYNC ideje alatt mennyi adatot tudna beolvasni. Oke, akkor is osztoznia kell a Z80-al esetleg, de legalabb mas EXTCOL infot kozben nem kell kiadnia.
A VSYNC összesen 6 rasztersor. Soronként van 57 NICK ciklus. A videó órajel a NICK memória órajel 16-szorosa. balagesz kétszeres órajelet tervez 16 bites adatbusszal. Ebből 6*57*16*2*2=21888 bájt jön ki. Ha mindenre jól emlékszem.

Az azért nem hinném, hogy annyira tragikus lenne a Z80-nal osztozás. Végül is miért akarna olyan sokszor hozzáférni a bővítő memóriájához a processzor? Egyrészt visszaolvasgatni a sprite adatokat nem gyakran van sok értelme. Feltöltöd az adataidat, utána meg csak a pozíciókat meg az adatmutatókat módosítgatod az animációhoz és a mozgatáshoz. Másrészt az írást – szerintem, de majd akik ki tudják rendesen számolni pontosítanak – simán lehet pufferelni, a Z80 azért annyira még 10 MHz-en sem gyors, hogy szaturálni tudná a tervezett memóriabuszt.

Offline ergoGnomik

  • EP lover
  • *
  • Posts: 840
  • Country: hu
  • Stray cat from Commodore alley
  • OS:
  • Windows NT 6.3 Windows NT 6.3
  • Browser:
  • Firefox 50.0 Firefox 50.0
    • View Profile
Re: Tesztelés
« Reply #139 on: 2017.January.10. 19:58:50 »
Természetesen van a megoldásnak "árnyoldala" is. Egyrészt ha meg van jelenítve a kép, a következő frame-et "takarítással" kell kezdeni, illetve a sprite "megjelenítés" maga nem real-time: elindítod az SPT feldolgozását, aztán valamikor kész lesz. De ez tervezhető dolog. Aztán ha kell sprite-sprite ütözést is tudni vizsgálni, akkor az új sprite kipakolása előtt vissza kell olvasni az adott helyen levő adatot a frame-bufferből, ami a RAM sávszélességét fogyasztja.
Nem lehetne úgy szervezni a frame megjelenítését, hogy amint felolvasott egy szót, azt azonnal írja felül nullával? Ez megint csökkentené a szabad sávszélességet a megjelenítés ideje alatt, de nem torlódna fel a feladat a kép valamely részére, ráadásul nem kellene külön gondoskodni róla a programozónak (vagy a konstruktőrnek).

Az SPT feldolgozására lehetne olyan stratégiát bevetni, hogy a megjelenítő rész valahány rasztersoronként jelez a mikrokontrollernek, hogy itt már jártam, a megelőző sorokba már szabad rajzolni, a kontroller meg az SPT ismételt feldolgozásai során megjelöli a már feldolgozott SPB-ket például egy folytonosan futó framecounter beírásával, vagy ez feleslegesen elbonyolítaná a működést?

Offline balagesz

  • EP user
  • *
  • Posts: 265
  • Country: hu
  • OS:
  • Linux Linux
  • Browser:
  • Firefox 45.0 Firefox 45.0
    • View Profile
Re: Tesztelés
« Reply #140 on: 2017.January.12. 14:52:41 »
Jó ötlet, viszont ez limitet szabna egy sprite kirakási számának, vagyis nem ,mert ha monsdjuk 8 xy pozíció lenne az SPB-ben, akkor egy újabb SPB-vel ugyanarra a spritre-ra még nyolc pozíció lenne lehetséges.

Mondjuk senki nem mondta, hogy egy SPB-nek fix hosszúságúnak kell lennie. :-D (Persze logikailag jobban kezelhető az állandó méret.) Na de ez most mindegy, úgyis odébb van. Ami biztos: az FW-t egyszerűen "upgrade"-elhetőre kell csinálni, így az ilyen kiegészítések mehetnek majd később is, amikor már csak a polírozás folyik.

Ha meg nem volt rola szo (?), az is erdekes, hogy VSYNC ideje alatt mennyi adatot tudna beolvasni.

Nem szorítkoznék én csak erre, ráadásul a VSYNC pont "programozható" is EP-n, szóval nem is biztos hogy van. :) (Persze: ha nincs, nincs kép se, szóval ez csak elméleti dolog, de na. :oops:)

Az azért nem hinném, hogy annyira tragikus lenne a Z80-nal osztozás.

A Z80 azért ehhez képest "ritkán" használja a memóriát, még úgy is, ha direkt forszírozva van. :) Ami inkább "gáz", hogy a CPU 8 bites ciklusokat generál a 8 bites mivoltából kifolyólag, :) ha a bővítés busza meg 16 bites, akkor a processzor "dupla" sávszélességet visz el a többi résztől. Meggondolandó, hogy maradjon-e 8 bites a RAM, ezen még lesz mit gondolkodni.

Nem lehetne úgy szervezni a frame megjelenítését, hogy amint felolvasott egy szót, azt azonnal írja felül nullával?

Gondoltam erre is, de ennek valószínűleg több hátránya van mint előnye. Megduplázza a "frame-buffer" sávszélességigényét kapásból, cserébe minden kép kiírásakor újra kell másolni a sprite-okat akkor is, ha amúgy nem változott volna semmi. Illetve azért feltételezhető, hogy a képernyő teljes egészét nem teszik ki a sprite-ok (kivétel persze lehet...), takarításnál meg elég csak azokat a területeket törölni, ahol volt is valami.

Az SPT feldolgozáshoz a későbbiekben bőven lehet mindenféle optimalizációkat bevetni, de ez még a jövő feladata. ;)

(Amúgy eszembe jutott egy ötlet, amihez neki is álltam forrasztgatni, de egyelőre még nem tartok vele sehol. Ha lesz valami "fényképezhető", úgyis mutatom, csak egy kissé elhavaztam. Megint.)

Offline Zozosoft

  • EP addict
  • *
  • Posts: 13531
  • Country: hu
  • OS:
  • Windows XP Windows XP
  • Browser:
  • Firefox 50.0 Firefox 50.0
    • View Profile
    • http://enterprise.iko.hu/
Re: Tesztelés
« Reply #141 on: 2017.January.12. 15:00:51 »
Még egy meggondolandó dolog: maradjon-e ez a 8 bitben 5 bit memóriafelhasználás.
Lehetne esetleg, úgy, hogy a 0-ást színt nevezzük ki átlátszónak, amikor nincs EXTC. Így lehetne félbájtos adatokkal dolgozni, csökkenne a memória igény, ill. CPU igény átvitelnél.
Mondjuk így valamivel bonyolultabb lenne a hardver, a 4 bitnyi adatot OR-olva jönne ki az 5.

Offline endi

  • EP addict
  • *
  • Posts: 7305
  • Country: hu
  • grafikus, játékfejlesztõ, programozás, scifi, tudományok, vallás
  • OS:
  • Windows 7/Server 2008 R2 Windows 7/Server 2008 R2
  • Browser:
  • Chrome 55.0.2883.87 Chrome 55.0.2883.87
    • View Profile
    • Honlapom
Re: Tesztelés
« Reply #142 on: 2017.January.12. 15:01:50 »
mondjuk akkor már egy bias szín legyen a lyukasztó
(bocs ha hülyeséget írok és már tök máshol tart az egész :) )
Vigyázat! Szektás vagyok! :)

Offline Zozosoft

  • EP addict
  • *
  • Posts: 13531
  • Country: hu
  • OS:
  • Windows XP Windows XP
  • Browser:
  • Firefox 50.0 Firefox 50.0
    • View Profile
    • http://enterprise.iko.hu/
Re: Tesztelés
« Reply #143 on: 2017.January.12. 15:05:58 »
mondjuk akkor már egy bias szín legyen a lyukasztó
Igen ezen én is töprengtem, hogy talán jobb lenne azokból elveszteni egyet.

Offline balagesz

  • EP user
  • *
  • Posts: 265
  • Country: hu
  • OS:
  • Linux Linux
  • Browser:
  • Firefox 45.0 Firefox 45.0
    • View Profile
Re: Tesztelés
« Reply #144 on: 2017.January.12. 15:33:48 »
Még egy meggondolandó dolog: maradjon-e ez a 8 bitben 5 bit memóriafelhasználás.
Lehetne esetleg, úgy, hogy a 0-ást színt nevezzük ki átlátszónak, amikor nincs EXTC. Így lehetne félbájtos adatokkal dolgozni, csökkenne a memória igény, ill. CPU igény átvitelnél.

A témát itt két fele célszerű szedni:

A sprite "formátuma", hogy hogyan is néz ki a "sprite bitmap", ez az egyik. A jelenlegi elképzelésben ugye ezt a "sprite bitmap"-et felszedi a memóriából egy µC, majd kirakja a "frame-buffer" megfelelő helyére. Viszont a kirakáshoz simán át is lehet alakítani, a "sprite bitmap" emiatt lehet akármilyen formátumban. Lehet akár 2 színű is, ahol 1-1 bit jelenti az átlátszó / valamilyen szín esetet. Magyarán a Z80 által kezelt adat lehet olyan, hogy a lehető legkevesebb feladata legyen vele.

mondjuk akkor már egy bias szín legyen a lyukasztó

A másik rész meg az, ahogyan a hardver a "frame-buffer"-ből adatokat generál az ECx/EXTCOL bemenetekre. Jelen esetben itt gondolkozok az 1 BYTE-ból csak 5 bit használt / pixel verzión. Nekem is eszembe jutott az a verzió, hogy 4 bit legyen egy pixel, és a 16 variációból valamelyik (akár állítható...) kombináció legyen az átlátszó, de ez behoz egy adag problémát. :) Pl. az átlátszóság kezelése, amikor két sprite egymásra másolódik. Külön tesztelni kellene, hogy a BYTE-ban levő két pixel közül 0,1,2 vagy 3 átlátszó, az 1/2 változatban meg a "frame-buffer" tartalmát visszaolvasni+módosítani+beírni kellene egy sima beírás helyett. Aztán ott van a pozíció: ha 1 pixellel akarom vízszintesen eltolni a sprite-ot, akkor az egész sor-adatot fél BYTE-tal kell odébb pakolni, ami megint csak nem hatékony. (Ha lenne gyors és megfelelő méretű, 4 bites szélességű SRAM, az segítene a helyzeten, de szerintem nem van. :) )

Az 1 BYTE 2 pixel verziót viszont az esetleges "háttér", a plusz videolap esetén gondolom jónak, mivel az ismét olyan adathalmaz, amivel a Z80-nak is lehet dolga. Ott a kevesebb mindig jobb elv érvényesül, bár az is kérdés, hogy mi a gyorsabb: két pixelnyi adatot összerakni majd egy BYTE-ot kiírni, vagy két BYTE-ot kiírni. :oops:

Offline Zozosoft

  • EP addict
  • *
  • Posts: 13531
  • Country: hu
  • OS:
  • Windows XP Windows XP
  • Browser:
  • Firefox 50.0 Firefox 50.0
    • View Profile
    • http://enterprise.iko.hu/
Re: Tesztelés
« Reply #145 on: 2017.January.12. 15:47:27 »
az is kérdés, hogy mi a gyorsabb: két pixelnyi adatot összerakni majd egy BYTE-ot kiírni, vagy két BYTE-ot kiírni. :oops:
Igen, ez nekem is eszembe jutott.

Offline lgb

  • EP addict
  • *
  • Posts: 3497
  • Country: hu
  • æðsta yfirmaður
  • OS:
  • Linux (Ubuntu) Linux (Ubuntu)
  • Browser:
  • Firefox 50.0 Firefox 50.0
    • View Profile
    • http://lgb.hu/
Re: Tesztelés
« Reply #146 on: 2017.January.13. 15:26:20 »
Meg azt is vegyuk figyelembe szerintem, hogy 4 bit "elpzarlasa" (vagy 3, ha atlatszosagi bit is benne van) nagyban csokkenti a hw kepessegeit hogy adott idoegyseg alatt mennyi sprite pixel adatot kepes olvasni ... Ha pack-olva van jobb az arany. Plusz, en azon is elgondolkodnek, hogy valoban kell-e atlatszosagi info. Ha van egy I/O port amivel configolni lehet egy "colour key"-t (esetleg sprite-onkent kulon), akkor a 16 szinbol egyet felaldoztunk, hogy az lesz az atlatszo. Cserebe viszont nem kell kulon atlatszosagi bit az FPGA-nak kulon, es ha meg byte-ban ket pixel is van, akkor egyetlen byte ket teljes pixel atlatszosagi infoval egyutt ugymond (bar ezzel egy szin elveszett). Ha 16 biten eri el a RAM-jat az FPGA, akkor egyetlen memoriamuvelettel is ez mar 4db pixel. Ez sokkal rosszabb lenne, ha kulon van minden + atlatszosagi bit is. Ez akkor erdekes foleg, ha kozben ilyen "full screen" jellegu megjelenitest is kerunk tole + sprite-ok is kozben (es mondjuk nem is egy), akkor talan szamit ... Bar lehet en vagyok maximalista, es felesleges?

Ja, a masik meg: VSYNC mellett a HSYNC is kihasznalhato arra hogy 'prefetch-eljen' adatot, amikor nem kell Nick fele az EXTCOL labakon infot adni, nem tudom ez hasznos-e vagy nem.

Offline ergoGnomik

  • EP lover
  • *
  • Posts: 840
  • Country: hu
  • Stray cat from Commodore alley
  • OS:
  • Windows NT 6.3 Windows NT 6.3
  • Browser:
  • Firefox 50.0 Firefox 50.0
    • View Profile
Re: Tesztelés
« Reply #147 on: 2017.January.13. 15:58:12 »
Ja, a masik meg: VSYNC mellett a HSYNC is kihasznalhato arra hogy 'prefetch-eljen' adatot, amikor nem kell Nick fele az EXTCOL labakon infot adni, nem tudom ez hasznos-e vagy nem.
Nincs előbetöltés. A hardver előre generált adatfolyamot küld ki a külső szín bemenetekre. Ezt egy mikrovezérlő állítja elő a feltöltött sprite adatok és megjelenítésvezérlés alapján a képmegjelenítési adat-hozzáférések és a Z80 műveletek szüneteiben. Már ha jól értelmeztem az eddigieket.

Offline lgb

  • EP addict
  • *
  • Posts: 3497
  • Country: hu
  • æðsta yfirmaður
  • OS:
  • Linux (Ubuntu) Linux (Ubuntu)
  • Browser:
  • Firefox 50.0 Firefox 50.0
    • View Profile
    • http://lgb.hu/
Re: Tesztelés
« Reply #148 on: 2017.January.13. 16:13:11 »
Nincs előbetöltés. A hardver előre generált adatfolyamot küld ki a külső szín bemenetekre. Ezt egy mikrovezérlő állítja elő a feltöltött sprite adatok és megjelenítésvezérlés alapján a képmegjelenítési adat-hozzáférések és a Z80 műveletek szüneteiben. Már ha jól értelmeztem az eddigieket.

Hat nem tudom, de ennek nincs sok ertelme :) Miert ne lehetne kihasznalni? Ha tudod hogy adott sorban kell a sprite es hol van a memoriaban miert ne lehetne pre-fetch-elni, foleg akkor, ha amugy ott sok sprite van amire nem eleg "just-in-time" memoriasavszelesseg az FPGA szamara (ami aztan a sajat BRAM-jaban persze tarolhatja meg egy darabig). Mikrovezerlorol lemaradtam, vagy lehet nem olvastam el par uzenetet azota, en meg az FPGA-nal tartok :)

Offline balagesz

  • EP user
  • *
  • Posts: 265
  • Country: hu
  • OS:
  • Linux Linux
  • Browser:
  • Firefox 45.0 Firefox 45.0
    • View Profile
Re: Tesztelés
« Reply #149 on: 2017.January.13. 23:38:47 »
Meg azt is vegyuk figyelembe szerintem, hogy 4 bit "elpzarlasa" (vagy 3, ha atlatszosagi bit is benne van) nagyban csokkenti a hw kepessegeit hogy adott idoegyseg alatt mennyi sprite pixel adatot kepes olvasni ...

Egyelőre még annyira nincs lefixálva semmi, hogy bármi lehet. :) Az elképzelés most az, hogy lesz egy "frame-buffer", ami az egész képernyőhöz tartalmaz bit-információt. Itt lenne a 3 bitnyi pazarlás. :) Ebbe a "frame-buffer"-be meg egy µC "renderelné bele" a sprite-okat, amikor a Z80 mondja neki, hogy most csináld öcsém. Ezt a "frame-buffer"-t tulajdonképpen a Z80-nak nem is kell tudnia közvetlenül elérni! :)

Ha 16 biten eri el a RAM-jat az FPGA, akkor egyetlen memoriamuvelettel is ez mar 4db pixel. Ez sokkal rosszabb lenne, ha kulon van minden + atlatszosagi bit is. Ez akkor erdekes foleg, ha kozben ilyen "full screen" jellegu megjelenitest is kerunk tole + sprite-ok is kozben (es mondjuk nem is egy), akkor talan szamit ... Bar lehet en vagyok maximalista, es felesleges?

A "full screen" jellegű megjelenítés ettől teljesen független (legalábbis az eddigi elképzelések szerint), ott olyan üzemmódot csinálunk, ami éppen jól esik. Valójában a "sprite-frame-buffer" lehet akár külön buszon is, ez ismét egy eldöntendő dolog. (Persze ha külön busz, akkor külön RAM is, meg kell hozzá I/O láb az FPGA részéről, szóval itt is van előny / hátrány egyaránt, mint eddig mindig. :oops:)

Mikrovezerlorol lemaradtam, vagy lehet nem olvastam el par uzenetet azota, en meg az FPGA-nal tartok :)

Az egész ötletelésem onnan indult, de azóta a körítés elbonyolódott a CPLD-vel "kényelmesen" megvalósítható verziótól az FPGA-s megoldás fele. A µC-es lehetőség nekem ettől eltekintve szimpatikus maradt, mert az jó lehet még egy csomó egyéb dologra is.