Welcome, Guest. Please login or register.


Author Topic: Tesztelés (Read 43348 times)

Offline Zozosoft

  • Global Moderator
  • EP addict
  • *
  • Posts: 14723
  • Country: hu
    • http://enterprise.iko.hu/
Re: Tesztelés
« Reply #120 on: 2017.January.07. 17:11:34 »
Egyébként ha jól értem a dolgot, akkor a legnagyobb gond a párhuzamos memória elérések megoldása.
Amúgy meg csak egy nagy rakás számláló, tól/ig beállításokkal :-)

Offline balagesz

  • EP user
  • *
  • Posts: 277
  • Country: hu
Re: Tesztelés
« Reply #121 on: 2017.January.07. 18:24:02 »
Arról még nem írtam, hogy nekem milyen ötleteim vannak... :) Első körben én ezt viszonylag egyszerűnek képzeltem el, ezért is készült a jelenlegi teszthardver. Ami "alapjaiban" meghatározza a lehetséges megoldást, az az, hogy direkt "sprite-generátor"-t nem gondolnám, hogy lehet kapni... :)

Az elképzelés annyi volt, hogy van egy szép darab RAM, mint most, annak minden egyes BYTE-ja megfelel 1-1 nagy felbontású pixelnek a képen. Persze a 8 bitből csak 4 + 1 van használva, így 16 lehetséges "szín" van, illetve a "láthatóság" kapcsolható. Ez így tulajdonképpen egy sima "frame buffer". Magának a RAM-nak a buszrendszere úgy lenne felépítve, hogy a NICK Dot-Clock (ami 14.xxx MHz) dupláján futna, és 16 bites lenne, emiatt a sávszélesség a NICK felé szükséges adatmennyiség négyszerese. A fennmaradó RAM időben a Z80 dolgozhat, de ebből a sávszélességből csak néha-néha kell neki egy-egy ciklus, szóval marad szabadidő bőven. Ezt eddig egy nagyobb CPLD-vel meg lehet csinálni.

Na de hogy lesz ebből sprite? Ide lehet "csempészni" egy kis EP-s logikát. :mrgreen: Mivel a sprite pixel-adatait a bővítés memóriájába kell másolni, ebbe a memóriába létre lehetne hozni egy SPT-t. Ami SPB-kből állna. :) Azaz: lenne egy Sprite Parameter Table, amik Sprite Parameter Block-okat tartalmaznak. Ezek a blokkok egy-egy sprite adatait írnák le: hol van a "bitmap" a memóriában, milyen pozícióra kell kirakni a képen, milyen üzemmódban, stb. Ezt a SPT-t meg egy combosabb mikrovezérlő dolgozná fel, a RAM sávszélességének a fennmaradó idejében pakolgathatná az adatokat. Beolvasna egy-egy SPB-t, az alapján felszedné a memóriából a sprite "képét", majd a megfelelő helyre odamásolná a "frame buffer"-be. Ennek a felépítésnek van egy olyan előnye, hogy tulajdonképpen nincs maximálisan megjeleníthető sprite-szám, hanem mozgatható adatmennyiség-korlát van csak. Magyarán kis méretű sprite-okból sokat, nagyobbakból kevesebbet lehet egyszerre kezelni. Illetve a sprite-ok mérete dinamikusan változhat, az egyik lehet ekkora, a másik meg amakkora.

A sprite-ok megjelenítési prioritását én meglehetősen egyszerűnek képzelem el: ha több darab is egymásra kerül, az fog a végén látszani, amelyiket utoljára pakolt ki, azaz később következik az SPT-ben. :)

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.

Nagyjából ennyi volt az elképzelésem, és ekkor jött a teljesen önálló külső kép, mint kívánság... :) Azt nem mondom hogy borít mindent, de - mondjuk úgy - nem egyszerűsíti a helyzetet. :razz: A sprite-háttér ütközést ezzel már lehetne vizsgálni, csak vagy ott is olvasom a "háttér" adatait is, vagy ezt meg a megjelenítéskor tudom csak jelezni, immár real-time. Ami egy kicsit kilóg a logikából. :roll:

Ha ezt a µC-es feldolgozást csinálnánk, annyi előnye mindenképpen lenne, hogy tulajdonképpen csak program kérdése, hogy milyen lehetőségek vannak, lehet egy csomó fajta formátuma a sprite-oknak a 2 színűtől kezdve a nagyításon keresztül tulajdonképpen bármeddig.

Maga a hardver viszont a plusz "háttér" layer-rel kezd kilógni egy CPLD "komfort-zónájából", emiatt szóba jön ide egy valamilyen FPGA, csak azt még egyelőre nem "faragtam". :) De ha már FPGA, ott is van egy csomó lehetőség, akár külső µC felhasználása nélkül is. (Csak még alapabb eszközökkel kell megcsinálni a dolgot.) Jelen pillanatban nem tudom, hogy melyik verzió lenne a célravezető (Kombináltan mindkettő? :) ), van mit mérlegelni.

Egyébként ha jól értem a dolgot, akkor a legnagyobb gond a párhuzamos memória elérések megoldása.
Amúgy meg csak egy nagy rakás számláló, tól/ig beállításokkal :-)

A fenti megoldás "eliminálja" ezt a problémát, nincs szükség a párhuzamos elérésre. Cserébe persze van más... :)

Offline geco

  • EP addict
  • *
  • Posts: 7082
  • Country: hu
    • Támogató Támogató
Re: Tesztelés
« Reply #122 on: 2017.January.08. 09:32:23 »
Kösz az "összefoglalót", ezek szerint azért nem akkora varázslat a dolog, illetve ezt most nem érzem egy lehetetlen feladatnak. :)
A nagyja már meg is van :), legalábbis nekem úgy tűnik, és nem értek a HW-hez :D
Ami eltér majd a CPC-stől, hogy ott külön palettája van a sprite-oknak, de ez legyen a legkevesebb.

Offline geco

  • EP addict
  • *
  • Posts: 7082
  • Country: hu
    • Támogató Támogató
Re: Tesztelés
« Reply #123 on: 2017.January.08. 09:43:44 »
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.
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?
Én úgy gondoltam/nám a sprite-ot, mint full képet, hogy ilyenkor a sprite hw csak a képet adná, esetleg ha van még elég hely a sprite memóriában, akkor lehetne még sprite-okkal is foglalkoznia, és az ütközésvizsgálat ilyenkor a háttér sprite-ban kikapcsolható, ne vizsgálja a háttér és egy sprite ütközését, 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.

Offline IstvanV

  • EP addict
  • *
  • Posts: 4822
Re: Tesztelés
« Reply #124 on: 2017.January.08. 10:28:50 »
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.

A VIC-II (C64) tud ilyet. :) Természetesen a hardver teljesítménye korlátozza a soron belül megjeleníthető sprite számot, a 8 sprite adatának az olvasása a keret időtartama alatt történik.

Offline lgb

  • EP addict
  • *
  • Posts: 3563
  • Country: hu
  • æðsta yfirmaður
    • http://lgb.hu/
Re: Tesztelés
« Reply #125 on: 2017.January.08. 13:31:41 »
Azert ne felejtsuk el, hogy itt ez egy hardware :) Mig emulatornal nagy szivas a sprite utkozes vizsgalat (lassu ...), hardware-nel nem lassit, mivel nem egy emulator/software ugye, es megoldhato, hogy minden parhuzamosan menjen, teljesen mas gondolkodast igenyel :) Bar ettol eroforrast nyilvan kovetel, ami jelen esetben a komplexitast jelenti inkabb, talan nem veletlen, hogy C64 VIC-II-nel is a chip felulet jo 3/4-et a sprite kezeles viszi el :)

Offline Zozosoft

  • Global Moderator
  • EP addict
  • *
  • Posts: 14723
  • Country: hu
    • http://enterprise.iko.hu/
Re: Tesztelés
« Reply #126 on: 2017.January.08. 14:28:22 »
A priorítás/ütközés vizsgálat az egyszerű szerintem:
Sorba kell kötni őket az 5 bites adatukkal, az EXTC jelnél fogva az újabbik felülírja az eddigieket, ott ahol nem átlátszó. És ahol két EXTC találkozik, az már adja a jelet, hogy az aktuális sprite nekiment valaminek.

Offline endi

  • EP addict
  • *
  • Posts: 7298
  • Country: hu
  • grafikus, játékfejlesztõ, programozás, scifi, tudományok, vallás
    • Honlapom
Re: Tesztelés
« Reply #127 on: 2017.January.08. 16:01:01 »
Azert ne felejtsuk el, hogy itt ez egy hardware :) Mig emulatornal nagy szivas a sprite utkozes vizsgalat (lassu ...), hardware-nel nem lassit

egy mai pc-nek nem hiszem hogy akár több tízezer ilyen sprite ütközés vizsgálata gondot okozna :) (pixel pontosan természetesen)
Vigyázat! Szektás vagyok! :)

Offline lgb

  • EP addict
  • *
  • Posts: 3563
  • Country: hu
  • æðsta yfirmaður
    • http://lgb.hu/
Re: Tesztelés
« Reply #128 on: 2017.January.08. 17:01:42 »
egy mai pc-nek nem hiszem hogy akár több tízezer ilyen sprite ütközés vizsgálata gondot okozna :) (pixel pontosan természetesen)

Megis, probalj meg nagyon pontos C64 emulatort irni egyszer, es merd le milyen PC kell hozza :) Meglepo lesz az eredmeny :) Pedig az emulalando cucc nem tul 'tapos' egy valami egy modern PC-hez viszonyitva ... Persze ebben nem csak a sprite utkozes van epp benne, de hidd el, sokat elvisz egy gyors CPU-bol is egy olyan muvelet, amit valami megcsinal hw-bol, neked meg egy linearis kodfuttatasra tervezett CPU-n kell emulalni, ami a valodi hw-en tok parhuzamos mukodesu, es hw-bol van megoldva.

Offline endi

  • EP addict
  • *
  • Posts: 7298
  • Country: hu
  • grafikus, játékfejlesztõ, programozás, scifi, tudományok, vallás
    • Honlapom
Re: Tesztelés
« Reply #129 on: 2017.January.08. 17:23:41 »
Megis, probalj meg nagyon pontos C64 emulatort irni egyszer, es merd le milyen PC kell hozza :) Meglepo lesz az eredmeny :) Pedig az emulalando cucc nem tul 'tapos' egy valami egy modern PC-hez viszonyitva ... Persze ebben nem csak a sprite utkozes van epp benne, de hidd el, sokat elvisz egy gyors CPU-bol is egy olyan muvelet, amit valami megcsinal hw-bol, neked meg egy linearis kodfuttatasra tervezett CPU-n kell emulalni, ami a valodi hw-en tok parhuzamos mukodesu, es hw-bol van megoldva.

hát írtam elég sok játékot, pixelpontos ütközésvizsgálattal is... :)
a lineáris kódfuttatás sokat nem számít, hiszen brutálisan gyors egy mai pc egy magon is.
meg hát ügye van sok proci mag, meg gpu mag is :)
c64 emulátorok is régóta vannak, ha jól tudom 100%-osak
Vigyázat! Szektás vagyok! :)

Offline lgb

  • EP addict
  • *
  • Posts: 3563
  • Country: hu
  • æðsta yfirmaður
    • http://lgb.hu/
Re: Tesztelés
« Reply #130 on: 2017.January.08. 17:39:51 »
hát írtam elég sok játékot, pixelpontos ütközésvizsgálattal is... :)
a lineáris kódfuttatás sokat nem számít, hiszen brutálisan gyors egy mai pc egy magon is.
meg hát ügye van sok proci mag, meg gpu mag is :)
c64 emulátorok is régóta vannak, ha jól tudom 100%-osak

100%-os sosem lesz :) Olyan trukkok is vannak am mar, hogy par a dolog analog jellemzoit is emulalni kell, pl hogy a C64 serial IEC kabelen hiaba megy digitalis jel, a kabel induktiv es kapacitiv jellezoi alapjan a viselkedese elter attol, amit egy idealis digitalis emulacioban varnal. Es hasonlo agymenesek. Valoban, vannak jo C64 emulatorok, csak pont ezt mondom, hogy nezd mar meg mennyivel nagyobb teljesitmenyu gep kell a futtatasukhoz mint a hw amit emulal :) Nem mondom, hogy _csak_ ez (marmint a sprite utkozes vizsgalat) egy mai modern gepen lenne a szuk keresztmetszet, csak ugye azt mondottam, hogy egy FPGA-ban megvalositva ez teljesen mas, mint egy emulatorban.

Offline endi

  • EP addict
  • *
  • Posts: 7298
  • Country: hu
  • grafikus, játékfejlesztõ, programozás, scifi, tudományok, vallás
    • Honlapom
Re: Tesztelés
« Reply #131 on: 2017.January.08. 18:23:15 »
jó de remélem lesz emu támogatás :)
amúgy megint csak azt tudom mondani hogy a konvertálás lehetőségét kéne szem előtt tartani egy ilyen hw készítésekor, mert tuti hogy akkor legalább pár konverzió születne ami használja...
Vigyázat! Szektás vagyok! :)

Offline gflorez

  • EP addict
  • *
  • Posts: 3607
  • Country: es
    • Támogató Támogató
Re: Tesztelés
« Reply #132 on: 2017.January.08. 19:17:41 »
Ha egy gyors processzor esetén alkalmazható sprite, miért nem hajtják végre néhány egyszerű forma matematika koprocesszor? Persze lebegőpontos BCD ...

----------------

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

Offline lgb

  • EP addict
  • *
  • Posts: 3563
  • Country: hu
  • æðsta yfirmaður
    • http://lgb.hu/
Re: Tesztelés
« Reply #133 on: 2017.January.09. 02:47:04 »
Kicsit ott-topic, de: https://www.youtube.com/watch?v=h42neZVvoMY

A csavonak vannak erdekessegei, amikor pl egy MCU-val csinalt demot, real-time kodbol eloallitva a videojelet is (annyi RAM sincs, hogy frame buffere legyen), stb. Am itt most nem errol  van szo, hanem: vegulis egy Commodore One-bol kiszedte az egyik panelt (de most mindegy is persze, hogy az honnan van), ami lenyegeben magaban egy Cyclone III FPGA (ami nem is tul modern darab ma mar, mondhatni ...). Aztan abban implementalt maganak egy gepet szepen es irt ra demot :) Nekem tetszik. Persze a latottakbol kikovetkeztetheto, hogy valoszinu egy teljes erosen bovitgetett EP CPU-stul Nick-estul mindenestul is siman beleferne :) Bar ez mar megint egy masik project, nem epp "csak" a sprite/stb generalas kivulrol.

Offline Povi

  • EP addict
  • *
  • Posts: 2296
  • Country: hu
    • http://povi.fw.hu
Re: Tesztelés
« Reply #134 on: 2017.January.09. 10:15:00 »
A csavonak vannak erdekessegei, amikor pl egy MCU-val csinalt demot, real-time kodbol eloallitva a videojelet is (annyi RAM sincs, hogy frame buffere legyen), stb.
Beteg egy ember, de pont ezért szeretjük :-)
Régen nézegettem én is az alkotásait, de pár éve nem néztem felé, az MCU-s demo-t (Craft) ismertem, de az újabb cuccait nem láttam még. Ha már off topic-kodunk: :-) ezt a munkáját se ismertem (C64 demo): http://www.linusakesson.net/scene/lunatico/index.php kb. a felénél, miután megfordítod a lemezt, nagyon szép esőcsepp effektek vannak, és a legvégén a harnagjáték-szerű tune nagyon tetszik, hasonlót még nem hallottam SID-ből.
*** Speicherplatz zu klein