Hírek | Archívum | Fórum | IRC | Amiga | AmigaOS | FAQ | RSS

 - Fórumok - Keresés - Statisztika - Szabályzat - Pegasos.hu fórum
forum.amigaspirit.hu / Fejlesztés / BSzili portok, fejlesztések (MOS/OS4)
<< . 1 . 2 . 3 . 4 . 5 . 6 . 7 . 8 . 9 . 10 . >>
Szerző Üzenet
BSzili
Tag

# Elküldve: 2016. Júl. 22. 11:25


charlie
Uhh, azért itt már vannak kételyeim :) Kérdés, hogy mi a lassabb, sorokat ugrálni, vagy C2P-ben visszaforgatni. Ez már kicsit mikro-optimalizációnak tűnik, szerintem az fog sokat dobni rajta, ha rendes raycaster-t csinálok belőle, ahogy fentebb javasoltad.

dino
Azért szeretném én azt a Doom portot látni :) A merítés ötlet szintjén már megtörtént, a falak/sprite-ok rajzolásán van bőven mit javítani.

Chain-Q
Divatamigás

# Elküldve: 2016. Júl. 22. 11:28 - Szerkesztve: charlie


@dino:
Barmit lehet, kerdes mennyit akarsz ujrairni a meglevo motorbol. :D

@BSzili:
Mikro-optimalizacio, de mivel minden pixel kirajzolasat erinti, ezert lehet hogy szamit. Ne felejtsuk el, hogy 020/030-on meg ilyen kulonbsegek is vannak (es jonehany orajel), hogy milyen cimzesmoddal ered el az adott memoriacimet. Ha pl. displacement van benne, vagy indirekt + offset, az joval lassabb mint egy sima (a0), vagy (a0)+.... Es hosszabban is van encodeolva, emiatt az utasitas beolvasasa/dekodolasa is lassabb. De abban valoszinuleg igazad van, hogy ezen kivul meg jo sok mindent lehet rajta gyorsitani, mielott ilyenekhez fordul az ember. :)

BSzili
Tag

# Elküldve: 2016. Júl. 22. 11:45


Igaz, a legkisebb is számít. Ha meglesz az új scaler, akkor szerintem minimális változtatással sor-rajzolót lehet majd csinálni belőle.

AliveMOon
Tag

# Elküldve: 2016. Júl. 22. 12:50 - Szerkesztve: alivemoon


Szerintem mindenképpen gyorsabb, ha külön van C2P!
Én kipróbálnék egy bináris fával kombináltat!
struct C2P_TREE
{
......U4 c;
......U2 left, right, pos;
};

C2P_TREE *p_tree = new C2P_TREE[WxH/4], *p_t, *p_te = p_tree, *p_tb;
U4 *p_c = p_chanky,
*p_planar;
I4 sub;
for( U2 i = 0; i < WxH/4; i++ )
{
......p_tb = p_t = p_tree;
......sub = 1;
......while( p_t < p_te )
......{
............p_tb = p_t;
............sub = p_c[i] - p_t->c;
............if( !sub )
...........{
.................// csak másolja
.................p_planar[f(i)] = p_planar[f(p_te->pos)];
.................break;
...........}
............p_t = p_tree + sub < 0 ? p_ts->left : p_ts->right;
......}

......if( !sub )
.................continue;

......// új elem
......// konvertál p_planar[f(i)]-re
......p_te->pos = i;
......p_te->c = p_c[i];
......if( p_te == p_tb )
......{
...........p_te->left = p_te->right = WxH;
.......}
.......else if( sub < 0 )
..................p_b->left = p_te-p_tree;
......else
..................p_b->right = p_te-p_tree;
......p_te++
}

Valami ilyesmire gondolok...
A találati arányt szerintem egy dupla/tripla bufferelésel tovább lehetne növelni.

Chain-Q
Divatamigás

# Elküldve: 2016. Júl. 22. 14:01


Az nagyon geci ha azt irom, hogy sajnos a feladathoz chunky2planar kell, nem chanky2planar? ...

dino
Kék troll

# Elküldve: 2016. Júl. 22. 14:32 - Szerkesztve: dino


Quoting: charlie
chanky2planar


Amugy ez a chanky2planar ez mi? Ez hol hasznaljak?
A chunky2planar al kabe kepbe vagyok, de szigoruan csak felhasznaloi szinten... :D

AliveMOon
Tag

# Elküldve: 2016. Júl. 22. 14:42 - Szerkesztve: alivemoon


Egyik englis másik hunglis?
Már külön életet él a kezünk gépelésnél és ha nem olvasom újra én is össze vissza ütök minden félét! A helyesírás ellenőrző is gyakran "segít", aztán igazi marhaság lesz belőle :)

Lazi
Mr. AmiCon

# Elküldve: 2016. Júl. 22. 15:42


Ha az egyik cel, hogy alap CD32-n menjen, az Akiko HW C2P nem hasznalhato?

Nem jo a teljesitmenye vagy rossz implementacio?

BSzili
Tag

# Elküldve: 2016. Júl. 22. 15:43 - Szerkesztve: BSzili


@AliveMOon
A C2P témáról egyelőre leakadtam, szóval ha csak nincs drop-in verzió belőle amit ki tudok próbálni, hogy gyorsabb-e, marad a Kalms féle.

@Chain-Q
Közben azt is észrevettem, hogy a falakhoz és sprite-okhoz textúrák még mindig a chip RAM-ba vannak tömve az EGA emuláció hagyatéka miatt. Gondolom ezeket praktikusabb lenne fast RAM-ban tárolni.

Van nekem még egy ilyen függvényem is:
https://github.com/BSzili/refkeen/blob/amiga/src/be_st_amiga_graphics.c#L479
Ezt egyedül a kéz kirajzolásához használja. Ami most van az a naiv C implementáció (hogy előtte hogy nézett ki, azt csak erősebb idegzetűeknek ajánlom: https://github.com/BSzili/refkeen/blob/amiga/src/id91_11/id_vw_ae.c#L294 ). A kérdés az, hogy ehhez 020-on és fölötte érdemes-e a blitterrel szórakozni, vagy inkább CPU-val toljam?

@Lazi
A CD32 egyelőre inkább lázálom, mint célplatform. Persze ott érdemes lenne akiko-t használni egy Doom benchmark tanulsága szerint:
http://www.amiga.org/forums/showpost.php?p=544232&postcount=8

Chain-Q
Divatamigás

# Elküldve: 2016. Júl. 22. 16:22 - Szerkesztve: charlie


@BSzili:
Ha valaki gyorsabb C2P-t ir, plane C-ben mint a Kalms fele... Hat az ugyes. :P Foleg hogy mar azt is a chipRAM sav fogja meg. Szoval benchmark or it didn't happen. :)

A fal/egyeb texturakat feltetlenul a Fast RAM-ba rakjad! Rengeteget szamithat. En nem szorakoznek a blitterrel, foleg nem 020+, akkor meg plane nem ha amugy az alatta levo teruletet minden korben felulirod egy C2P-vel... Vagy ez a kez kirendereles ez mar kozvetlenul a planar bufferedbe ir?

BSzili
Tag

# Elküldve: 2016. Júl. 22. 17:07


Igen, a kéz már a planar bufferbe megy miután megvolt a C2P.

AliveMOon
Tag

# Elküldve: 2016. Júl. 22. 18:00 - Szerkesztve: alivemoon


Hülyeséget kérdezek?
A kezet nem lenne egyszerűbb spriteok-ba rakni?

Chain-Q
Divatamigás

# Elküldve: 2016. Júl. 22. 18:17 - Szerkesztve: charlie


Na ez kivetelesen nem volt hulyeseg. :P En is gondoltam ra, de nekem folyton ilyen RTG maniam van, szoval en csak chunky-sitanam a kez irasat, aztan had csinalja a dolgat a C2P. :) De ha tenyleg csak annyi a dolga h. ott legyen, akkor lehet h. tenyleg spriteokkal jobban jarsz, mint rablittelni. Felteve ha rafer spriteokra persze.

AliveMOon
Tag

# Elküldve: 2016. Júl. 22. 18:19


RTG-n nem kell C2P...

Chain-Q
Divatamigás

# Elküldve: 2016. Júl. 22. 18:21


Tudom. Ugy ertettem, ha mindent a C2P csinal, akkor egyetlen pontban surusodik az osszes kod grafikai kimenete, es akkor nulla perc alatt lehet RTG verziot csinalni (masik fuggvenyt kell meghivni a C2P helyett, kesz).

BSzili
Tag

# Elküldve: 2016. Júl. 23. 08:24 - Szerkesztve: BSzili


A kéz csak előbukkan képernyő alján amikor a játékosnak puffogtatni támad kedve. A legelső játékban pluszban még cserélget rajta két textúrát. Szélességben ezek 73-79 pixel között vannak ezek, úgy hogy 5 sprite-ra férnének rá, de ahhoz sajnos egy kicsit sok színt használnak (5-7 + átlátszó). Ide már attached sprite kellene, abból meg csak 4 van, szóval ez nem igazán nyerő.
Chunky-t lehetne csinálni belőle, gondolom azt egy kicsit gyorsabban lehetne maszkolva másolni, de egyelőre nincs tervben RTG verzió. Ahhoz túl sok EGA szemetet kellene kitakarítani. Biztos vagyok benne, hogy a maszkolt planar blittelést lehet gyorsabbat írtni, mint amit én tákoltam C-ben pár perc alatt. Esetleg az FBlit forrásában lehet valami amit tudok hasznosítani?

szerk: Közben látom Kalms is írt egy CPU blittert. Ezt ha C-hez akarom illeszteni, akkor gondolom kell némi ragasztókód amivel a regisztereket lementem/visszaállítom.
https://github.com/Kalmalyzer/planar-cpu-blit

BSzili
Tag

# Elküldve: 2016. Júl. 30. 14:46 - Szerkesztve: BSzili


Ugyan az m68k assebly-hez és gépi kódhoz nem konyítok, a GCC átmeneti fájlok, egy hex editor és némi próbálkozás az IRA-val meghozta gyümölcsét. Az ötlet az volt, hogy az előre x86 kódra fordított scalereket kellene amigán életre kelteni. Azok már be vannak clippelve, és unrolled loop-okkal böfögik fix címekre a pixeleket. Egy délelőttnyi kísérletezés után megfejtettem a titkot:

MOVEA.L #destPtr,A1
MOVE.B (src,A0),(0,A1,D1.L)
RTS

A1-be kerül a destPtr, ami egy fix pointer a chunky buffer első oszlopának valamely pixeléhez. Ehhez hozzáadódik a D1-ben lévő képernyőoszlop száma. A0-ban van az oszlopfolytonosan tárolt textúra nekünk kellő oszlopa. Az src 0-64 között ennek a textúraoszlopnak valamelyik pixele. Az első két sor annyiszor ismétlődik ahány pixelt kell egy bizonyos magasságú felscale-elt falhoz kinyomni egy adott képernyőoszlopba. Ezek után csak végigmászok az összes képernyőoszlopon, kiválasztom a fal magasságának megfelelő scaler-t, beadom neki hogy hanyadik oszlop és a textúra címét és már megy is. Ezzel a C-s megoldáshoz képest sikerül kb megfelezni a falak rajzolását. Most ugyanezt meg kell csinálnom a sprite-okhoz is, és utána sínen leszek, mint József Attila.

szerk: Miután legeneráltam a scalereket a memóriába töröljem a cache-t? A sprite-ok elég undorító önmódosító kódot használnak, ami több szegmensből rak össze egy oszlopot, és ezek végén mindig belepatch-el egy egész oszlopot rajzoló scalerbe egy retf-et. Inkább előre át fogom másolni a kódot. Azon a pár száz bájton már ne múljon.

BSzili
Tag

# Elküldve: 2016. Aug. 06. 19:35


Mivel szinte minden megvolt hozzá a refkeen portban a scrollt leszámítva, nekiálltam faragni a Keen Dreams-t. Végül kb újra kellett írni az összes rajzoló függvényt, hogy a sebesség megüsse a kritikán aluli szintet :D Akit érdekel innen leszedhető:
https://drive.google.com/open?id=0Bz...GdfcjF3RElYNzA
ftp://ftp.3drealms.com/share/keendm.zip

WinUAE cycle exact A1200 módban szenved egy kissé, igazi gépen fogalmam sincs mit produkálhat. Lassan ideje lenne beszereznem egy A1200-est...

Peti
Tag
# Elküldve: 2016. Aug. 06. 23:29


Quoting: BSzili
Lassan ideje lenne beszereznem egy A1200-est...


Már fölajánlottam korábban, hogy jöhetsz hozzám tesztelni a kódot (ha még Miskolcon tartózkodsz), csak még nem sikerült találkoznunk. Ha megadsz valamilyen elérhetőséget, megbeszélhetjük a dolgot.

dh1
Mr. DTP

# Elküldve: 2016. Aug. 07. 00:28


Peti, az nem muxik, hogy valaki megy 1-2 orat tesztelni.
Huzamosabb ideig egy gepet kolcson kell adni ehhez.
Neki be kell lonie a rendszert ahogy o szereti stb.
Szal ez igy keves bar nagyon rendes felajanlas :)

BSzili
Tag

# Elküldve: 2016. Aug. 07. 07:58


Quoting: Peti
Már fölajánlottam korábban, hogy jöhetsz hozzám tesztelni a kódot (ha még Miskolcon tartózkodsz), csak még nem sikerült találkoznunk. Ha megadsz valamilyen elérhetőséget, megbeszélhetjük a dolgot.

Mailben bármikor elérsz, de sajnos nincs mostanában sok időm, és ahogy DH1 is írta, itt az hogy elmegyek és megnézem hogy hogy fut egy gépen nem sokat segít. Rengetegszer kell lejátszani módosítom, újrafordítom, kipróbálom hármast, ehhez kéz alatt kell lennie mindennek. Főleg az első necces, mert ahhoz kell a fejlesztőkörnyezet is. Ahogy ígértem, ha már lesz késztermék (a mostani még mindig nem az), élni fogok a lehetőséggel. A mostani állapotában még WinUAE-ben is röcög a scroll.

BSzili
Tag

# Elküldve: 2016. Aug. 20. 14:39


Újabb C2P kérdés, ebből hogy tudnék 4 bitplane-es verziót gyártani?
https://github.com/Kalmalyzer/kalms-c2p/blob/master/bitmap/c2p2x2_8_c5_bm.s

dh1
Mr. DTP

# Elküldve: 2016. Sze. 12. 03:14


Ugy latom sikerult urra lenni a C2P problemakon!
Meselnel picit a fejlesztesrol, mit fog tudni az Amiga verzo?
Gyorsabb CPU-n gyorsabb?
Audio cserelve lesz?
CD32 beharangozo video ... mit kiderult emu, ez valos sebesseg?
Teszt verziot lehet kerni, AM cikk okan?
thx

BSzili
Tag

# Elküldve: 2016. Sze. 12. 09:34


Bizonyos értelemben igen. a 2x1 C2P ötletét elvetettem, mert komoly módosításokat igényelt volna a játék motorjában (a látószög teljesen a kép szélességéhez van kötve), 2x2-ben meg szimplán túl pixeles a kép.
Gyorsabb procin természetesen gyorsabb, a felső határ a képfrissítési sebesség, mert a VBLANK-ot megvárja.
Az emulátor cycle exact CD32 módban fut, mivel igazi gépem (még) nincs, ezért ennél többet jelenleg én se tudok. A PC speaker hangok le lesznek cserélve, jelenleg az AdLib hangeffektek lettek átkonvertálva. Az még nem dőlt el, hogy teljesen új hangeffektek lesznek-e. A teszt verzió természetesen, megoldható, privátban tudok küldeni.

Yellow Dog
Tag

# Elküldve: 2016. Sze. 12. 10:57


Quoting: BSzili
felső határ a képfrissítési sebesség, mert a VBLANK-ot megvárja

Nem teljesen ide tartozik, de erről jutott eszembe: PC-s körökben mindenfelé olvasható, hogy így 100fps meg úgy 140, meg Úristen, leesett 38-ra, stb... Szóval a kérdésem, MI ÉRTELME VAN ENNEK? Miért nem elég a 25 fps vagy legyen 50, és azt fixen tarthatnák a programok? Teljesen felesleges a magasabb hiszen a szemünk úgysem tudta megkülönböztetni őket egymástól. Erre "okos" PC-s világban kitalálják inkább az Adaptive Sync technológiát, ahelyett, hogy a 30 éve tökéletesen működő VBLANK-ot használnák végre a sz.r videokártyáikon.

Lazi
Mr. AmiCon

# Elküldve: 2016. Sze. 12. 11:51


@Yellow Dog:
Hasonlo kerdes mar bennem is felmerult korabban.
Gondolj arra, hogy egy gyors scroll eseten a mondjuk 60Hz VBLANK meghatarozza hogy egyszerre hany pixelt kell eltolnod. Minel nagyobb meretu kepernyon nezed, a szemed annal jobban fogja ezt az ugrast erzekelni es adott meret es sebesseg eseten mar nem fogod folyamatos mozgaskent erzekelni.
320x200 felbontas es 14" kepatlohoz kivalo volt az, amit az Amiga chip set nyujtott.

Bocsi az offert es meginkabb ha hulyesege irtam.

BSzili
Tag

# Elküldve: 2016. Sze. 12. 12:38


Inkább nem kezdenék tudományos értekezésbe arról, hogy mit tud megkülönböztetni a szem és mit nem. A framerate nem lineáris, és minél alacsonyabb annál nagyobb a különbség két érték között. Nem mindenkinek egyforma a szeme, egy bizonyos szint fölött már csak az input lag-ban érzékelhető a különbség. Maradjunk annyiban, hogy én levágnám a kisujját azoknak a fejlesztőknek, akik PC-n 30fps-re korlátozzák a gyors reflexeket igénylő játékukat.

Yellow Dog
Tag

# Elküldve: 2016. Sze. 12. 14:20


Anatómia, 25 fps-t folyamatosnak lát a szem, persze villogást nagyobb frekin és érzékelünk, de pl. a 100fps tök felesleges. Olyan ez az fps hajsza mint mobilnál a kamera felbotás esztelen növelêse.

dh1
Mr. DTP

# Elküldve: 2016. Sze. 12. 16:38 - Szerkesztve: dh1


Lehet a szemed nem latja, de vannak akik pro jatekoskent halara gyilkolnak ha te framerate-ed 30 vagy az ala esik.
World of Tanks, mast nem jatszom, miota elloptak a videokartyam az integralt HD4000 lofaszt sem er a jo kis 7870 utan ... rendszeresen esik 12-15 fps-re a jatek (atlatszo vegetacio eseten). Mar a 30 is lassu elverzeshez segit, nincs eselyed ugy reagalni mint 60 fpsen ahol minden rohadt siman, lag nelkul fut. 60 fps felett mar en sem vennem eszre a kulonbseget de az uj monitorok (120, 144 frissites) es a VR technologiakhoz keves a 60 fps is ... elvaras a 120 minimum.
Amugy a kezem a WOT-al edzem, sokat segitett!!!

siz
Tag

# Elküldve: 2016. Sze. 13. 08:27


Quoting: yellowdog
Anatómia, 25 fps-t folyamatosnak lát a szem, persze villogást nagyobb frekin és érzékelünk, de pl. a 100fps tök felesleges.

Lehet, hogy 25FPS-t már folyamatosnak lát a szem, de ha a túl nagy mozgásokat 25FPS-sel rajzolja ki, akkor diavetítésnek érzékeled, mert az nem természetes, hogy a tárgyak 25FPS-sel "arrébb teleportálnak". A szemnek szüksége van a köztes állapotokra is, ezért szokták magasabb frame-rate-tel nyomni. Vagy pl. motion blur-ral kompenzálni, pótolni a kimaradt fázisokat.
Ha meg, mint BSzili is írta ráadásul a játék kontroljai a frissítéssel össze vannak kötve, akkor meg sokkal gyorsabb reakciót tesz lehetővé a magasabb frame rate.

<< . 1 . 2 . 3 . 4 . 5 . 6 . 7 . 8 . 9 . 10 . >>
forum.amigaspirit.hu / Fejlesztés / BSzili portok, fejlesztések (MOS/OS4)
 
 

Powered by community script miniBB™ © 2001-2024