| Zobrazit předchozí téma :: Zobrazit následující téma |
| Autor |
Zpráva |
frca
Založen: 28. 07. 2007
Příspěvky: 1561
|
 Zaslal: 7. leden 2024, 09:56:16 Předmět: |
 |
|
K mem*_fast:
S memcpy_fast to bylo trochu pomalejší. S memset_fast jsem nezaznamenal rozdíl.
_________________
www.FRANTICWARE.com |
|
| Návrat nahoru |
|
 |
mar
Založen: 16. 06. 2012
Příspěvky: 610
|
| Zaslal: 7. leden 2024, 10:16:21 Předmět: |
|
|
| frca napsal: |
Místo pro výměnu palety je těsně po novém framebuf_flip s vsync?
|
to si nejsem úplně jistý, nevím přesně který bit v 0x3da to je a co přesně znamená, ale hádám, že ano
| citace: |
Dále, hry časuji typicky s timerem konfigurovaným na 60 Hz, takže teď by to bylo 120 Hz - to by ještě s třístránkovou metodou fungovalo? Pak by byl limiter triviální:
timer_interrupt()
{
++timer_count;
}
...
// game loop
{
while (timer_count == prev_timer_count); // wait for timer
... // game step, rendering
framebuf_flip(VGA, 0);
}
Edit: Vlastně timer/limiter na 60 Hz bude podle mě stačit. Na rychlém HW se využijí všechny frejmy módu X bez artefaktů a na pomalém VSYNC nebude nic brzdit.
Tyhle dotazy píšu pro ujištění, protože to budu i nějak dokumentovat.
Edit2: 3stránkový page flip funguje na 486 bezvadně. Je to stejně rychlé jako ten původní, ale bez artefaktů. |
ano, se třemi stránkami to je safe dokud jsi pod 120Hz (resp. o něco míň, jinak si budeš koledovat o artefakty), proto jsem doporučoval 100Hz, ale může to být reálně cokoliv (ideál 90Hz, to je přesně mezi) - to je proto, že když poběžíš moc rychle, tak to předběhneš a začneš kopírovat do paměti stránky, která je aktivní. proto je ale taky 3-page flip super - s limiterem se toto nestane a můžeš svištět bez vsyncu
ad mem: díky za změření, tak pak zahodit. takže jsem to dělal zbytečně  proč ale není memset_fast rychlejší nechápu, pokud to vygeneruje rep stosb a ten 486 manuál s cykly nelže. takže |
|
| Návrat nahoru |
|
|
frca
Založen: 28. 07. 2007
Příspěvky: 1561
|
| Zaslal: 7. leden 2024, 10:36:00 Předmět: |
|
|
V praxi podle mě "fyzika" (a tedy i limiter) může běžet na 60 Hz, aby to odpovídalo reálnému framerate. Já jsem používal 60 Hz na fyziku i u klasického 70Hz módu 13h, protože je to takový zaužívaný standard 
Respektive nejsem si jistý, k čemu by byl vyšší limiter (90 Hz, 100 Hz, ...) dobrý...
Testy s paletou plánuji výhledově udělat.
_________________
www.FRANTICWARE.com |
|
| Návrat nahoru |
|
|
mar
Založen: 16. 06. 2012
Příspěvky: 610
|
| Zaslal: 7. leden 2024, 10:44:10 Předmět: |
|
|
| frca napsal: |
V praxi podle mě "fyzika" (a tedy i limiter) může běžet na 60 Hz, aby to odpovídalo reálnému framerate. Já jsem používal 60 Hz na fyziku i u klasického 70Hz módu 13h, protože je to takový zaužívaný standard
Respektive nejsem si jistý, k čemu by byl vyšší limiter (90 Hz, 100 Hz, ...) dobrý...
Testy s paletou plánuji výhledově udělat. |
jasně, to je v pohodě. trochu jsem se obával, že to nemusí přesně sedět a že by ti jednou za čas mohl vypadnout frame, pokud se blbě trefíš zrovna.
vyšší FPS je dobré třeba v dosboxu na 144Hz monitoru
ale to bys i vstup musel zpracovávat per frame a mít dyn. timestep
zároveň s fixním (min. pro interpolaci stavu, aby to bylo plynulé),
na 486ce myslím, že 60 možná tak v menu, takže to není až tak důležité )
dokonce i na desktopu některé hry to mají fixnuté na 60Hz, ale já jsem už tak zvyklý (=zmlsaný) na vyšší refresh, že mi to něpřijde plynulé
EDIT: pravda, ale dosbox bude stejně fixnutý na 60Hz, protože to tak bude mít i VGA v tom režimu, tak dobrá - mimo dosbox, pokud bude i native binárka |
|
| Návrat nahoru |
|
|
frca
Založen: 28. 07. 2007
Příspěvky: 1561
|
| Zaslal: 7. leden 2024, 11:55:13 Předmět: |
|
|
Teď mám chuť vyoptimalizovat pinball pro mode X. Žádný brzdící VSYNC a plany se dají s výhodou využít pro pixel doubling ze základního CGA módu. A kolečka budou kulatá!
_________________
www.FRANTICWARE.com |
|
| Návrat nahoru |
|
|
mar
Založen: 16. 06. 2012
Příspěvky: 610
|
| Zaslal: 7. leden 2024, 15:26:41 Předmět: |
|
|
ano, motivace mít 1:1 pixely (a 60Hz) je pro 320x240 velká
v robodovi jsem používal ještě takový trik: paleta byla udělaná tak, že index*16 mirroroval klasických 16 barev, tzn. paleta na indexu 0x1 měla stejnou hodnotu jako 0x10 a 0xf stejnou jako 0xf0 (protože 16 barev)
pak jak píšeš stačilo nastavit v bitplane 2 bity a jelo se
kopírovalo se přímo z bufferu do vram a to tak, že se vzaly 4 sousední bajty v pakované paměti (měl jsem to zabalené po nibblech, takže 1 bajt měl 2 pixely v sobě), vymaskovat 0xf0f0f0f0 a nahrnout to tam (plus ještě se samozřejmě v dalším movu kopírovalo ukládáním na další řádek protože doubling).
pak se bitplane maska zinvertovala a zkopírovalo se po 4ech bajtech s invertovanou and maskou (tj. 0x0f0f0f0f) |
|
| Návrat nahoru |
|
|
Ladis
Založen: 18. 09. 2007
Příspěvky: 1537
Bydliště: u Prahy
|
| Zaslal: 7. leden 2024, 15:43:57 Předmět: |
|
|
| mar napsal: |
| vyšší FPS je dobré třeba v dosboxu na 144Hz monitoru |
Brácha hraje DOSovské hry na běžném CRT 17" monitoru v 640x400 120 Hz. Hry jako Blood nebo Hexen. Např. na S3 Virge je skvělá podpora DOSu a vlastních Hz.
EDIT: 640x400 místo na 480, protože UI hry je přesně 2x2 pixely - podobně jako Retina na Macách.
| frca napsal: |
| A kolečka budou kulatá! |
Grafika do těch her se kreslila se započítáním nečtvercových pixelů, takže kulaté věci byly kulaté. Problém by byl, až když bys chtěl bitmapou otáčet (prot se použila jiná bitmapa).
| mar napsal: |
| ano, motivace mít 1:1 pixely (a 60Hz) je pro 320x240 velká |
Někteří lidé jsou na 60 Hz citliví, proto vyžadují ergonomických 70 Hz. Takže profesionální textové editory (např. MS Word) byly v textovém režimu 70 Hz a ne v grafickém. Grafický byl nutnost pro ne-anglické jazyky (např. u nás T602).
_________________
Award-winning game developer |
|
| Návrat nahoru |
|
|
mar
Založen: 16. 06. 2012
Příspěvky: 610
|
| Zaslal: 7. leden 2024, 16:19:53 Předmět: |
|
|
| Ladis napsal: |
| mar napsal: |
| ano, motivace mít 1:1 pixely (a 60Hz) je pro 320x240 velká |
Někteří lidé jsou na 60 Hz citliví, proto vyžadují ergonomických 70 Hz. Takže profesionální textové editory (např. MS Word) byly v textovém režimu 70 Hz a ne v grafickém. Grafický byl nutnost pro ne-anglické jazyky (např. u nás T602). |
1:1 je dobré v tom, že pak můžeš rovnou tu svoji věc vydat i pro moderní PC/jiné stroje a nemusíš nic řešit (proto třeba v defaultním nastavení Wolf3D vypadá v DosBoxu splácnutě, i když i to se dá nastavit)
60Hz je de facto standard, že by to někomu vadilo slyším poprvé, ale je to možné.
70Hz implikovalo "nečtveraté" pixely pokud vím
co jsem ochutnal 144Hz monitor na FPS hry (dokonce i tahání oken na desktopu je mnohem plynulejší), tak už bych na 60Hz zpátky nikdy nešel, radši 144 fullHD než 60 4k |
|
| Návrat nahoru |
|
|
frca
Založen: 28. 07. 2007
Příspěvky: 1561
|
| Zaslal: 7. leden 2024, 23:18:51 Předmět: |
|
|
60 Hz vadilo u CRT, to blikání bylo docela vidět a unavovalo oči. To už ale dnes málokdo pamatuje 
_________________
www.FRANTICWARE.com |
|
| Návrat nahoru |
|
|
mar
Založen: 16. 06. 2012
Příspěvky: 610
|
| Zaslal: 8. leden 2024, 02:08:20 Předmět: |
|
|
| pcha, já jsem začínal v 91ém na 8-bitovém atari s kazeťákem a pidi televizí (50Hz PAL) a nic mi nevadilo to byl úplně jiný hardcore |
|
| Návrat nahoru |
|
|
Ladis
Založen: 18. 09. 2007
Příspěvky: 1537
Bydliště: u Prahy
|
| Zaslal: 9. leden 2024, 00:23:58 Předmět: |
|
|
| mar napsal: |
| pcha, já jsem začínal v 91ém na 8-bitovém atari s kazeťákem a pidi televizí (50Hz PAL) a nic mi nevadilo to byl úplně jiný hardcore |
Ta TV ale měla velký dosvit.
_________________
Award-winning game developer |
|
| Návrat nahoru |
|
|
frca
Založen: 28. 07. 2007
Příspěvky: 1561
|
| Zaslal: 14. leden 2024, 10:59:05 Předmět: |
|
|
Když se pomocí
outp(SC_INDEX, MAP_MASK);
outp(SC_DATA, 1+2+4+8 );
vybere více planes, tak se můžou přepsat všechny najednou, případně jakákoliv kombinace. Výrazně to zrychlí pixel doubling / tripling / quadrupling.
_________________
www.FRANTICWARE.com |
|
| Návrat nahoru |
|
|
frca
Založen: 28. 07. 2007
Příspěvky: 1561
|
| Zaslal: 16. leden 2024, 23:51:32 Předmět: |
|
|
Zaimplementoval jsem to do CGPinballu. Hodně to pomohlo výkonu na 486 a kolečka jsou kulatá. Udělám pak nový release na svém webu. Díky za spolupráci
Tento náš-váš framework budu používat, kde jen to půjde.
Napadá mě například low detail mód ve stylu Dooma ve hře RCross.
_________________
www.FRANTICWARE.com |
|
| Návrat nahoru |
|
|
mar
Založen: 16. 06. 2012
Příspěvky: 610
|
| Zaslal: 5. srpen 2024, 21:13:04 Předmět: |
|
|
čau, omlouvám se za thread necromancy, ale mám dvě nové verze
uvědomil jsem si, že se de facto jedná o transpozici 4x4 bajtové matice, kde řádky se dají reprezentovat v registrech
první verze využívá bitových rotací (cca o 10% rychlejší oproti přechozí nejlepší na moderním CPU) a druhá má 2x víc movů na zápis (zapisuje 16 místo 32 bitů), ale má polovinu bitových operací plus nahrazuje rotace shifty - o 7% rychlejší na mém stroji než verze s rotacemi
je otázka, jestli by aspoň jedna z nich byla rychlejší na reálné 486ce, ale jsem optimista (už jenom na oko to vypadá zajímavěji).
jako bonus ušetří ještě esi registr, který se teď vůbec nepoužívá
na AT&T verzi dneska už nemám náladu, tak postnu jenom základní ideu:
| kód: |
void make_compact_asm4()
{
__asm
{
// dsti*4
xor edi, edi
_loop :
mov eax, [colors + 4*edi + 0 * 4]
mov ebx, [colors + 4*edi + 1 * 4]
mov ecx, [colors + 4*edi + 2 * 4]
mov edx, [colors + 4*edi + 3 * 4]
// transpose!
xchg ah, bl
ror eax, 16
xchg al, cl
xchg ah, dl
ror eax, 16
ror ebx, 16
xchg bl, ch
xchg bh, dh
ror ebx, 16
ror edx, 16
ror ecx, 16
xchg ch, dl
ror ecx, 16
ror edx, 16
// store packed0
mov[packed + 0 * 320 * 240 / 4 + edi], eax
// store packed1
mov[packed + 1 * 320 * 240 / 4 + edi], ebx
// store packed2
mov[packed + 2 * 320 * 240 / 4 + edi], ecx
// store packed3
mov[packed + 3 * 320 * 240 / 4 + edi], edx
add edi, 4
cmp edi, 320 * 240 / 4
jb _loop
}
}
|
| kód: |
void make_compact_asm4a()
{
__asm
{
// dsti*4
xor edi, edi
_loop :
mov eax, [colors + 4*edi + 0 * 4]
mov ebx, [colors + 4*edi + 1 * 4]
mov ecx, [colors + 4*edi + 2 * 4]
mov edx, [colors + 4*edi + 3 * 4]
// transpose!
xchg ah, bl
// store packed0, lo16
mov[packed + 0 * 320 * 240 / 4 + edi], ax
shr eax, 16
xchg al, cl
xchg ah, dl
// store packed0, hi16
mov[packed + 0 * 320 * 240 / 4 + edi+2], ax
// store packed1, lo16
mov[packed + 1 * 320 * 240 / 4 + edi], bx
shr ebx, 16
xchg bl, ch
xchg bh, dh
// store packed1, hi16
mov [packed + 1 * 320 * 240 / 4 + edi+2], bx
// store packed2, lo16
mov[packed + 2 * 320 * 240 / 4 + edi], cx
// store packed3, lo16
mov[packed + 3 * 320 * 240 / 4 + edi], dx
shr edx, 16
shr ecx, 16
xchg ch, dl
// store packed2, hi16
mov[packed + 2 * 320 * 240 / 4 + edi+2], cx
// store packed3, hi16
mov[packed + 3 * 320 * 240 / 4 + edi+2], dx
add edi, 4
cmp edi, 320 * 240 / 4
jb _loop
}
}
|
EDIT:
tak podle 486 manuálu rotace registrů o immed stojí stejně jako shifty, tj 2 cykly. bohužel xchg reg, reg je drahý - 3 cykly
mov reg,reg je jeden cyklus, mov do paměti může mít ale extra cykly (za určité konstelace dekódování effective address a 1 cycle "drahý" cache miss)
co jsem počítal, tak verze 4 by přesto měla být teoreticky o chlup rychlejší než verze 3, ale nijak dramaticky |
|
| Návrat nahoru |
|
|
Ladis
Založen: 18. 09. 2007
Příspěvky: 1537
Bydliště: u Prahy
|
| Zaslal: 6. srpen 2024, 10:22:40 Předmět: |
|
|
Existuje nějaký emulátor PC x86, který má přesné časování? PCem?
_________________
Award-winning game developer |
|
| Návrat nahoru |
|
|
|
Hlavní strana
FAQ
Test
Hledat
Seznam uživatelů
Uživatelské skupiny
Registrace
Ke Stažení
Nastavení
Přihlášení
Calendar
