Welcome, Guest. Please login or register.


Author Topic: Tesztelés (Read 43329 times)

Offline endi

  • EP addict
  • *
  • Posts: 7298
  • Country: hu
  • grafikus, játékfejlesztõ, programozás, scifi, tudományok, vallás
    • Honlapom
Re: Tesztelés
« Reply #60 on: 2016.December.29. 22:20:37 »
Nem értem, van több, mint 1000 :ds_icon_cheesygrin:

az imádott specy átíratok... :)
Vigyázat! Szektás vagyok! :)

Offline endi

  • EP addict
  • *
  • Posts: 7298
  • Country: hu
  • grafikus, játékfejlesztõ, programozás, scifi, tudományok, vallás
    • Honlapom
Re: Tesztelés
« Reply #61 on: 2016.December.29. 22:30:41 »
amúgy ez az external color input ez nem lassítja a rendszert?
ki-be lehet kapcsolni?
Vigyázat! Szektás vagyok! :)

Offline Zozosoft

  • Global Moderator
  • EP addict
  • *
  • Posts: 14722
  • Country: hu
    • http://enterprise.iko.hu/
Re: Tesztelés
« Reply #62 on: 2016.December.29. 22:35:47 »
amúgy ez az external color input ez nem lassítja a rendszert?
Nem.

Quote
ki-be lehet kapcsolni?
Ha úgy van megtervezve :-) Ami célszerű :-)

Offline balagesz

  • EP user
  • *
  • Posts: 277
  • Country: hu
Re: Tesztelés
« Reply #63 on: 2016.December.29. 22:56:41 »
Collision detection is megoldható, vagy ahhoz már durva hw kéne? És van-e értelme?

A bővítő porton nincs semmi, ami alapján el lehetne dönteni, hogy a NICK milyen pixeleket pakol ki a kimenetére. Így a háttérrel való ütközésdetektálás szerintem nem oldható meg.

csak mint érdekesség érdekel hogy mennyivel lassabb mint a belső mem?

Ahogy Zozo is írja, semmivel, de ez esetleg cél is kell majd, hogy legyen. De ahogy látom, azért beindult a fantázia rendesen... :-D

Offline Zozosoft

  • Global Moderator
  • EP addict
  • *
  • Posts: 14722
  • Country: hu
    • http://enterprise.iko.hu/
Re: Tesztelés
« Reply #64 on: 2016.December.29. 23:11:56 »
A bővítő porton nincs semmi, ami alapján el lehetne dönteni, hogy a NICK milyen pixeleket pakol ki a kimenetére. Így a háttérrel való ütközésdetektálás szerintem nem oldható meg.
Na és ha a háttér is kintröl jön?

Quote
De ahogy látom, azért beindult a fantázia rendesen... :-D
És még nem is írtam le mindent :-D

Elmélkedés: "ugyanilyen cucc csak kicsiben" azaz sprite méretben, a koordináta beírható módon. Ez idáig ha jól tippelem nem nagy ügy.
A probléma ott jön, hogy több is kéne ezekből. Egyrészt mi van ha egymáson vannak... adódik a priorítási sorrend. Ez tán úgy lenne legegyszerűbb, ha az EXTC jelével a magasabb priorítású az felülírni az alatta lévőket. Tán még ez se nagy gond.
A nagyobb gond az lenne, hogy a több sprite hogyan olvasná a memóriát egyszerre?
Ha jól sejtem ebből jön a kb az összes sprite rendszernél olvasható x sprite/scanline limit. Talán a keret ideje alatt olvassa be valami pufferbe a sprite adatokat, és aztán a képernyő idő alatt onnan dolgozik.
Esetleg egy rakás kicsi RAM chip mindnek külön-külön? :-)

Offline balagesz

  • EP user
  • *
  • Posts: 277
  • Country: hu
Re: Tesztelés
« Reply #65 on: 2016.December.29. 23:49:06 »
Na és ha a háttér is kintröl jön?

Hm... :) Mondjuk ezzel "bukod" az LPT-s sorrendezgetést, de persze lehet keverni a kettőt.

Elmélkedés: "ugyanilyen cucc csak kicsiben" azaz sprite méretben, a koordináta beírható módon. Ez idáig ha jól tippelem nem nagy ügy.

Nem, mert pont eddig van készen. :) (Ha a memóriát kitörlöd, csak egy "kicsi" részbe pakolsz képadatot, akkor oda is értünk. :) De azért ez így elég sovány lenne.)

A probléma ott jön, hogy több is kéne ezekből. Egyrészt mi van ha egymáson vannak... adódik a priorítási sorrend. Ez tán úgy lenne legegyszerűbb, ha az EXTC jelével a magasabb priorítású az felülírni az alatta lévőket. Tán még ez se nagy gond.

Itt csak fel kell állítani egy (célszerűen fix) sorrendet, aztán a "legutolsó" adata fog kikerülni a képre.

A nagyobb gond az lenne, hogy a több sprite hogyan olvasná a memóriát egyszerre?
Ha jól sejtem ebből jön a kb az összes sprite rendszernél olvasható x sprite/scanline limit. Talán a keret ideje alatt olvassa be valami pufferbe a sprite adatokat, és aztán a képernyő idő alatt onnan dolgozik.

Jól gondolod, a VIC-II pl. pontosan ezt csinálja, a keret alatt olvassa be előre a következő scanline adatait; ehhez egy (8...) akkora puffer kell, hogy a sprite-ok 1-1 rasztersora elférjen benne.

Esetleg egy rakás kicsi RAM chip mindnek külön-külön? :-)

Jaaa... :) Röhögni fogsz, nekem is eszembe jutott. Viszont nem túl alkatrészmennyiség-barát a megoldás. Meg nagy fogyasztás, felmelegedés, katasztrófa, mindmeghalunk™. :) Azt hiszem lassan le kellene írnom, hogy én mit tartok elképzelhetőnek. De előtte majd jól összeszedem a gondolataim, azt sem árt figyelembe venni, hogy ezt a valamit esetleg gyártani is lehessen... :razz:

Offline geco

  • EP addict
  • *
  • Posts: 7082
  • Country: hu
    • Támogató Támogató
Re: Tesztelés
« Reply #66 on: 2016.December.30. 09:41:14 »
A bővítő porton nincs semmi, ami alapján el lehetne dönteni, hogy a NICK milyen pixeleket pakol ki a kimenetére. Így a háttérrel való ütközésdetektálás szerintem nem oldható meg.
jaja, az tiszta, én a sprite-ok utkozesere gondoltam :-)
Ha már álmodozás, állítható méretű sprite-ok, akár pixelenkenként, határ a csillagos ég, a teljes képernyő,esetleg a számláló egyszerűségekét 4 pixelenkenként :-D
ja, és zoom lehetőség a col2 és col16 felbontás között :-)
egyelőre ennyi, és lassan kiveszem a biliből a kezem :-D

Offline ergoGnomik

  • EP addict
  • *
  • Posts: 1291
  • Country: hu
  • Stray cat from Commodore alley
Re: Tesztelés
« Reply #67 on: 2016.December.30. 10:51:21 »
Ebből teljes értékű 16 színű videókártya lesz még a végén. :smt043

Okleveles laikusként úgy érzem a prioritás vizsgálat melléktermékeként nagyjából automatikusan előáll az ütközés információ, ráadásul képpont szinten. Szóval ha csinálunk egy pepita mintát, amit két egymáshoz képest a pepita minta elemi szélességével vízszintesen eltolt sprite jelenít meg, akkor ezek nem generálnának ütközést. De ha csak egyetlen aktív képpontjuk is fedésbe kerül, akkor meg bejelez az ütközés figyelés.

Amit geco és talán endi pedzegetett, hogy kellene nagyítási lehetőség, az sem tűnik – mármint nekem kevéssé hozzáértőnek – bonyolultnak, inkább csak egy számláló kérdése, ami azt szabályozza mikor kezdje az adott sorban a sprite következő képpontját kitenni. Függőlegesen is hasonló lehet a helyzet, itt azt engedélyezi egy számláló lefutása, hogy a sprite adatainak következő sorára lépjen a motor.

Viszont ha a megvalósítás a kereten pufferbe beolvasással történik, akkor jó lesz valamilyen méretkorlátot vagy fix méretet felállítani. Azért is érdemes ezt figyelembe venni, mert abban a formában, amiben jelenleg meg van valósítva, a memória 3/8-a nincs kihasználva, noha így legalább egyszerű az alkalmazása. Ki lehet találni tömörebb formátumot, mint például 1 bájt átlátszósági maszk, amit követ 4 bájt képpont adat 8 darab 4 bites képpontként, illetőleg ennek valamilyen meghosszabbított változata (például a háromszorosa – 3 bájt átlátszóság, 12 bájt pixel – mivel az viszonylag jól illeszkedik egy szép 2n határra). Függőlegesen viszont nem biztos hogy kell limit, lehet az úgy is, mint az Amigánál (ha jól tudom, ott automatikusan nincs korlátozva a magasság, amíg nincs kikapcsolva, átparaméterezve vagy véget nem ér a képernyő, addig folyamatosan rakja ki a memóriából a kiolvasási szabály szerint következő sorokat).

Ezen kívül a pályarajzolás témakörében érdemes megfontolni egy karakteres képernyő jellegű megoldás bevezetését, természetesen nem feltétlenül ragaszkodva a 8 bites karakterkészlethez. És aki itt most felhorkan, hogy nehogy már csak karakteresen lehessen mozgatni a képernyőt, annak figyelmébe ajánlom a balagesz által készített szkrollozós videókat. Biztos vagyok benne, hogy semmi sem akadályozza meg őt abban, hogy ezt átültesse ilyen típusú képernyőszervezésre. Minden csak számlálók kérdése. :smt082

Offline Zozosoft

  • Global Moderator
  • EP addict
  • *
  • Posts: 14722
  • Country: hu
    • http://enterprise.iko.hu/
Re: Tesztelés
« Reply #68 on: 2016.December.31. 10:54:49 »
Jaaa... :) Röhögni fogsz, nekem is eszembe jutott. Viszont nem túl alkatrészmennyiség-barát a megoldás. Meg nagy fogyasztás, felmelegedés, katasztrófa, mindmeghalunk™. :)
Ha egy marék CMOS SRAM-ot odaszórunk, az nem hinném hogy jelentős fogyasztás lenne.

Quote
Azt hiszem lassan le kellene írnom, hogy én mit tartok elképzelhetőnek.
Ez tényleg célszerű lenne, mielött nagyon elszáll a fantáziánk :-)

Offline endi

  • EP addict
  • *
  • Posts: 7298
  • Country: hu
  • grafikus, játékfejlesztõ, programozás, scifi, tudományok, vallás
    • Honlapom
Re: Tesztelés
« Reply #69 on: 2016.December.31. 11:29:58 »
nem létezik olyan kész hardver ami ezt a feladatot ellátja?
vannak ezek a rapsberry pi és hasonló cuccok, vannak köztük olyanok ha jól tudom (bár tökre nem értek a témához) amik direkt különféle "barkácsolós" kimenetekkel rendelkeznek.
vagy már maga ez a hw is ilyesmikből lesz/van összerakva?
amúgy egy fotó is érdekes lenne :)
Vigyázat! Szektás vagyok! :)

Offline ergoGnomik

  • EP addict
  • *
  • Posts: 1291
  • Country: hu
  • Stray cat from Commodore alley
Re: Tesztelés
« Reply #70 on: 2016.December.31. 12:03:46 »
Ha egy marék CMOS SRAM-ot odaszórunk, az nem hinném hogy jelentős fogyasztás lenne.
Ez tényleg célszerű lenne, mielött nagyon elszáll a fantáziánk :-)
A fogyasztás talán a legkisebb baj. Nagyobb probléma, hogy feleslegesen elbonyolítja a NYÁK-ot meg a VHDL/Verilog (nem tudom balagesz melyikben nyomja) kódot. Ez meg a fejlesztési időt nyújthatja feleslegesen hosszúra, főleg mivel úgy nehezebb megkeresni ha valami esetleg félresiklik. Ha sávszélesség kell, akkor szélesebb adatbuszt és/vagy nagyobb órajelet kell használni.

A fantázia elszálláson meg már szerintem most is túl vagyunk. :D

nem létezik olyan kész hardver ami ezt a feladatot ellátja?
vannak ezek a rapsberry pi és hasonló cuccok, vannak köztük olyanok ha jól tudom (bár tökre nem értek a témához) amik direkt különféle "barkácsolós" kimenetekkel rendelkeznek.
vagy már maga ez a hw is ilyesmikből lesz/van összerakva?
amúgy egy fotó is érdekes lenne :)
A RPi és társai pont nem jók ide. Vannak a programozható logikákhoz – gyanúm szerint ezt a tesztet is ilyennel végezte a mester – fejlesztő kártyák, de végleges termékekben a legritkább esetben használnak olyanokat. Oda terveznek és gyártanak külön célhardvert.

Offline endi

  • EP addict
  • *
  • Posts: 7298
  • Country: hu
  • grafikus, játékfejlesztõ, programozás, scifi, tudományok, vallás
    • Honlapom
Re: Tesztelés
« Reply #71 on: 2016.December.31. 12:21:14 »
A RPi és társai pont nem jók ide. Vannak a programozható logikákhoz – gyanúm szerint ezt a tesztet is ilyennel végezte a mester – fejlesztő kártyák,

aha ilyesmire gondoltam én is.
Vigyázat! Szektás vagyok! :)

Offline balagesz

  • EP user
  • *
  • Posts: 277
  • Country: hu
Re: Tesztelés
« Reply #72 on: 2016.December.31. 22:00:11 »
jaja, az tiszta, én a sprite-ok utkozesere gondoltam :-)

Az mondjuk nem teljesen kizárt, hogy megoldható. Legfeljebb jár egy adag overheaddel. :)

Ebből teljes értékű 16 színű videókártya lesz még a végén. :smt043

Hehe... Mondjuk ezt pont el szerettem volna kerülni. :) Bár... :-D

Okleveles laikusként úgy érzem a prioritás vizsgálat melléktermékeként nagyjából automatikusan előáll az ütközés információ, ráadásul képpont szinten.

Ez megvalósítás kérdése, de szerintem nincs túl sok értelme "dinamikus" módon prioritást kezelni. Kell egy "felépítési sorrend", aztán az lesz a végén látható, amelyik utoljára marad. :)

Viszont ha a megvalósítás a kereten pufferbe beolvasással történik, akkor jó lesz valamilyen méretkorlátot vagy fix méretet felállítani.

Egyelőre itt még nem tartunk, de úgy érzem nem fogok én ragaszkodni a keret alatti felolvasáshoz...

Ki lehet találni tömörebb formátumot, mint például 1 bájt átlátszósági maszk, amit követ 4 bájt képpont adat 8 darab 4 bites képpontként, illetőleg ennek valamilyen meghosszabbított változata (például a háromszorosa – 3 bájt átlátszóság, 12 bájt pixel – mivel az viszonylag jól illeszkedik egy szép 2n határra).

Ez viszont jó ötlet is lehet, elrakom "későbbre".

Ezen kívül a pályarajzolás témakörében érdemes megfontolni egy karakteres képernyő jellegű megoldás bevezetését, természetesen nem feltétlenül ragaszkodva a 8 bites karakterkészlethez.

Toronyóra lánccal? :-D A karakteres képernyő egy meglehetősen bonyolult (az eddigi sima 16 színű grafikushoz képest...), persze hirtelen lett is egy-két ötletem. Ajjaj... :oops:

vagy már maga ez a hw is ilyesmikből lesz/van összerakva?
amúgy egy fotó is érdekes lenne :)

Fotót eddig azért nem csináltam, mert egy halom dróton kívül nincs túl sok látnivaló rajta:



Nyilván a "hanyatt" levő nyák lenne a lényeges, de azon egy 144 lábú CPLD-n meg egy 44 lábú SRAM-on kívül nincs semmi idevágó dolog.

Ha egy marék CMOS SRAM-ot odaszórunk, az nem hinném hogy jelentős fogyasztás lenne.

Persze, csak nehogy valami ilyesmi legyen a végeredmény! :razz:

Ez tényleg célszerű lenne, mielött nagyon elszáll a fantáziánk :-)

Ahogy nézem fantáziából azért tényleg nincs hiány! Ígérem, jövőre összeírom! ;) Az amúgy normális, hogy ez csak egy tesztnek indult, de szinte folyamatosan azon agyalok, hogy hova milyen alkatrészt kéne betervezni? :mrgreen:

Offline Zozosoft

  • Global Moderator
  • EP addict
  • *
  • Posts: 14722
  • Country: hu
    • http://enterprise.iko.hu/
Re: Tesztelés
« Reply #73 on: 2016.December.31. 22:03:45 »
Az amúgy normális, hogy ez csak egy tesztnek indult, de szinte folyamatosan azon agyalok, hogy hova milyen alkatrészt kéne betervezni? :mrgreen:
Teljesen! :ds_icon_cheesygrin:

Offline endi

  • EP addict
  • *
  • Posts: 7298
  • Country: hu
  • grafikus, játékfejlesztõ, programozás, scifi, tudományok, vallás
    • Honlapom
Re: Tesztelés
« Reply #74 on: 2016.December.31. 22:07:55 »
talán off, de emlékszem gameboy advanced-en csinált a kóderünk sprite tömörítést, amit realtime tömörített ki, és gyorsabb lett mintha nem lenne tömörítés, ugyanis csökkent az adatátvitel!
(természetesen hw sprite volt itt is, ennek a tömörítés dolognak az animációnál volt értelme, azaz amikor újra és újra fel kellett tölteni az új anim fázist)
Vigyázat! Szektás vagyok! :)