Oznámení

**Noro** · 21.09.2026, 11:45:23

Tak budu muset zamakat na optimalizaci...

Tedy donutilo mě to přemýšlet. Na té emulaci jsem už překonal několik propadů výkonu když jsem tam něco přidal. Tak přemýšlím kde je problém. Rád bych se na 040 dostal na 25FPS na 060 aspoň na 35 a na 030 na 15. To by bylo pořád hratelné.

Budu se muset mrknout na smyčku rasterizace a taky na to jak je nastavená cache. Je dost možné, že se píše rovnou do FAST ram místo do Cache a pak teprve přesypat.
To by mohlo udělat klidně 6x větší zátěž.
Když bude nejhůř místo mapování textůr po pixelech udělám tabulky a po vzoru PS1 to budu sekat celočíselně to by na 060 mohlo zdvojnásobit fillrate.

**JPU** · 21.09.2026, 21:02:54

Autorem citovaného textu je Noro Přejít na původní příspěvek

Tak budu muset zamakat na optimalizaci...

Tedy donutilo mě to přemýšlet. Na té emulaci jsem už překonal několik propadů výkonu když jsem tam něco přidal. Tak přemýšlím kde je problém. Rád bych se na 040 dostal na 25FPS na 060 aspoň na 35 a na 030 na 15. To by bylo pořád hratelné.

Budu se muset mrknout na smyčku rasterizace a taky na to jak je nastavená cache. Je dost možné, že se píše rovnou do FAST ram místo do Cache a pak teprve přesypat.
To by mohlo udělat klidně 6x větší zátěž.
Když bude nejhůř místo mapování textůr po pixelech udělám tabulky a po vzoru PS1 to budu sekat celočíselně to by na 060 mohlo zdvojnásobit fillrate.

Ahoj,

ty FPS co zmiňuješ myslíš na Native chipsetu (ala AGA) nebo v RTG, nebo interní výpočet před posláním na "framebuffer"?

**TherioN** · 21.09.2026, 21:13:07

Optimalizácia 3D enginu pre klasickú Amigu (najmä pre procesory Motorola 68030 až 68060) je legendárne ťažká disciplína. Problém, ktorý opisujete — zapísanie priamo do RAM bez využitia cache, chýbajúci koordinovaný buffer či neefektívna rasterizácia — sú presne tie miesta, kde 3D enginy na Amige prichádzajú o väčšinu výkonu.

Ak chcete získať plynulých 25 FPS na 040 a 35+ FPS na 060, tu sú najúčinnejšie techniky, ako to dosiahnuť: 1. Práca s pamäťou a Cache (Najväčšia brzda)

Zápis po bajtoch alebo slovách priamo do Fast RAM zabil veľa projektov. Zbernica 68040/060 je najrýchlejšia pri celých 32-bitových / 128-bitových blokoch.

Zápis cez Line Push / Burst Mode (040/060): Namiesto zápisu po pixele do Fast RAM budujte obraz v reglistoch (pomocou MOVEM alebo zápisom do dátovej cache) a potom zapisujte celé riadky v 16-bajtových blokoch (Burst Mode).
Write-Allocate / Copy-Back Cache: Uistite sa, že framebuffer vo Fast RAM je nastavený ako Cacheable (Copy-Back). Kreslite kompletne v L1 Cache a až po dokončení riadku/bloku ju vyprázdnite (Data Cache Flush).
Zákaz čítania z Framebufferu: Do framebufferu sa iba píše. Akýkoľvek Read-Modify-Write (čítanie pixelu, úprava, zápis) zničí výkon zbernice.

2. Rasterizácia a Mapovanie Textúr

Ak mapujete textúry po pixele s presným (alebo aj skráteným) delení, 68060 aj 040 okamžite spomalia, pretože instrukcie delenia (DIVU/DIVS) sú drahé (a na 060 sa dokonca emulujú v kódovacom trape!).

Afínne mapovanie (Affine Texture Mapping): Rovnako ako PS1 robte interpoláciu len celočíselne po riadkoch (krok u, v je konštantný prírastok v fixed-point formáte). Pre väčšie polygóny stačí spraviť korekciu perspektívy len každých 8 alebo 16 pixelov (tzv. Sub-division).
Unrolled Loops (Rozbalené slučky): Vykresľovací cyklus pixelov pre daný riadok nesmie obsahovať žiadne podmienky (DBRA a skoky). Generujte dynamický kód (JIT/Self-modifying code) alebo použite rozbalené slučky prispôsobené dĺžke riadku.
Pre-calculated Look-Up Tables (LUT): Pre násobenie a skoky v textúrach majte všetko predpočítané v tabuľkách vo Fast RAM, aby sa zmestili do dátovej cache.

3. RTG vs. AGA (Cesta do obrazovky)

Otázka vo vašej správe je kľúčová: Ide o RTG (Chunky) alebo AGA (Planar)?

Ak RTG (Grafická karta / Chunky 8-bit / 16-bit):
- Kreslite priamo do 8-bitového Chunky buffera vo Fast RAM.
- Neposielajte dáta po pixele cez Zorro zbernicu do VRAM karty! Nakreslite celý frame vo Fast RAM a potom ho cez MoveMem / DMA preneste naraz do RTG framebufferu.
Ak AGA (Chunky-to-Planar / C2P):
- Ak kreslíte pre originálny chipset (AGA/CD32), konverzia z Chunky (8-bit) do Planar (bitprajny) je obrovská záťaž.
- Použite najrýchlejšie dostupné 040/060 C2P rutiny (napr. od Kalmsa / MGI), ktoré využívajú MOVEM a instrukčné kombinácie na konverziu priamo v cache.
- Zvážte Double-Buffering: zatiaľ čo Akiko/Blitter alebo CPU prevádza Rámec A do Chip RAM, CPU už rasterizuje Rámec B vo Fast RAM.

4. Optimalizácia rozlíšenia a rendera

Renderujte v nižšom rozlíšení (Double-Width / Low-Res): Hry ako Doom či Alien Breed 3D bežali v rozlíšeniach ako 160×100 alebo 320×100 (s zdvojovaním pixelov). Ak znížite počet vykresľovaných pixelov na polovicu (napr. 160×200 namiesto 320×200 roziahnuté cez Akiko/Copper), fillrate okamžite stúpne na dvojnásobok.
Bsp Trees & Portals: Využite striktné triedenie viditeľnosti zozadu dopredu alebo spredu dozadu (BSP stromy / Portály), aby ste nikdy nekreslili ten istý pixel dvakrát (nulový Overdraw).

Zhrnutie pre získanie 35+ FPS na 060:

Zmeňte mapovanie textúr na fixed-point afínne po riadkoch (štýl PS1).
Kreslite výhradne do Fast RAM s Copy-Back Cache.
Zápisy robte po 32-bitových / 128-bitových blokoch (vyhnite sa bajtovému zápisu do RAM).
Ak ste na AGA, použite 160×200 rozlíšenie s rýchlym C2P.

**tom127** · 21.09.2026, 21:59:03

Vyzkoušeno na TF1260 hrát by to šlo.

**Noro** · 21.09.2026, 23:47:48

Autorem citovaného textu je JPU Přejít na původní příspěvek

Ahoj,

ty FPS co zmiňuješ myslíš na Native chipsetu (ala AGA) nebo v RTG, nebo interní výpočet před posláním na "framebuffer"?

Bavím se o výstupu na AGA (rasterizace->C2P->chipRam->obraz)

**Noro** · 22.09.2026, 00:12:29

Autorem citovaného textu je TherioN Přejít na původní příspěvek

Optimalizácia 3D enginu pre klasickú Amigu (najmä pre procesory Motorola 68030 až 68060) je legendárne ťažká disciplína. Problém, ktorý opisujete — zapísanie[/LIST]

Ehh který model jsi použil, podle frázování bych řekl že ChatGPT.

Zkusil bych něco co nevím

je to trošku pain protože už jsem do toho napchal všechno co mě napadlo, poslední co mám na krku je změna práce s cache to ale znamená velký rozdíl v kodu pro 040 a 060 oproti 030.

Další věc je že fakt nechci na AGA používat 160x200 rander teď běží 320x 200 a tak taky poběží, Aktuálně to stínuje polygony, ta scéna kde jsou třil lodě a stanice má těch polygonů cca 300 to by měli zvládnout všechny C2P je na tom časově v pohodě v rozpočtu toho zase tak moc neudělá. 160x200 dává smysl tak u 020 s FAST RAM.

**Noro** · 22.09.2026, 00:25:00

Autorem citovaného textu je tom127 Přejít na původní příspěvek

Vyzkoušeno na TF1260 hrát by to šlo.

TO není blbé, ale rád bych lépe

. Mám problém otestovat MOVE16 a nemůžu pořádně nastavit FAST ram protože FS UAE dovede emulovat jen 8MB Fast, další paměť je v režimu Zorro III, jenže ta nejde takhle alokovat. Pokud bych chtěl zkusit jinou variantu, můžu ale musí to být na turbokartě a tu zase bez ROMky té turbokarty jako je třeba Blizzard 1260 nenaemuluju.

Takže jsem poněkud ve slepé uličce. Mám tu jen A1200 s Vampirem, jasně můžu to napsat jen pro Vampira s AMMX a čágo belo šílenci... ale to se mi nechce. Takže potřebuju testovat

.

**Noro** · 22.09.2026, 00:34:58

Takže další testovací sada pokud můžete, tak test na co nejvíc strojích a výsledky k tomu bych prosil díky.

Přiložené soubory

Frontier3_Flight_Variants.zip (280,9 KB, 1 zobrazení)

**Noro** · 22.09.2026, 09:18:18

Kdyby se někomu chtělo a bylo by super kdyby se chtělo potřeboval bych udělat náčrtky lodí.
Stačí na čtverečkovaný papír, z boku zezadu, zepředu, shora a pokud je potřeba tak i z dola. Okotovat tzn. dát tomu nějaký rozměr (můj osobní koncept je že malé lodi jsou do cca 30m, střední klem 60 a velké 150. Nákladní vnitrosystémové pak klidně 400 - 500m ale ty zase nemůžou dokovat všude.

Stanice pak mají rozměrově délka šířka cca 250 a víc (představte si jak tam musí nějak zaparkovat ta loď co měří 150m.

Lodě, stanice, rakety, torpéda, co Vás napadne sem s tím

jména tomu vymyslete jak chcete, ale aby to dávalo nějaký smysl.

**Falcon_11** · 22.09.2026, 09:40:58

Autorem citovaného textu je Noro Přejít na původní příspěvek

Takže další testovací sada pokud můžete, tak test na co nejvíc strojích a výsledky k tomu bych prosil díky.

Zdar Noro.

Vcera vecer som isiel testovat, ale ani jeden exac s cache mi nesiel, restartlo mi vzdy Amigu. Skusal som to aj z OS3.1 a shell. Ten 060 bez cache mi daval 5-6 FPS na zaciatku a ked sa objekt stracal, tak samozrejme to vyskocilo na 20 FPS

**Noro** · 22.09.2026, 10:16:17

Falcon_11 díky za test, uvidíme co ostatní to s tou chache mě štve z pohledu ptimalizace je to super krok může to hrozně pomoct. Ale je to zapeklitý problém, zvlášť když nemám pořádně jak testovat.

Napadlo mě že bych udělal něco jako přepínač stavu paměti cache a testovat ve stavu A a ve stavu B.

**Noro** · 22.09.2026, 11:58:50

Když koukám na ty výsledky tak mi z toho trčí dvě věci 1. Paměť tam to zjevně drhne, 2. OS nevypínám ho takže to může běžet na pozadí... 3. čekání na něco a asi tuším na co... pokud bude dneska čas tak to potůním

mám podezření že čtení klávesnice a myši skrz intuition je to na co se čeká došlo mi to když jsem si to tu rozkreslil

.

**tom127** · 22.09.2026, 12:55:19

Myslím si, že by měla 060 v pohodě dělat 40fps problém bude sběrnice. 060 musí spoustu úkonů emulovat na rozdíl od 030 kde to byl hardware a pokud zakážeš cash u 060 ztratí svůj potenciál výkonu.

**Noro** · 22.09.2026, 13:39:21

To není o zákazu Cache ale o ražimu, jestli je transparentní nebo jestli se nejprve naplní a pak se teprve přesune do paměti. To je rozdíl v některých případech i 4x většího výkonu, protože pokud se data a kód točí jen v té chache paměti tak je minimální komunikace po sběrnici a tím i minimální ztráta penalizace.

Vypnout cache je samozřejmě nesmysl.
060 oproti 040 a 030 emuluje především výpočty, které mají 64 bitový výsledek a práce s daty, tam kde se musí dorovnávat adresa. Všechno tohle vede k přechodu do privilegovaného režimu, ten ale na konci vypláchne cache paměti, celou pipeline a vráti CPU do čistého stavu a kód může pokračovat. Emulace sebere řekněme 2x až 3x proti neemulovaní instrukci.

MULU.L/MULS.L s 64bitovým výsledkem — muls.l d1,d3:d2
DIVU.L/DIVS.L 64/32 — divs.l d1,d3:d2
MOVEP, CHK2, CMP2, CAS2, CAS na nezarovnané adrese

Pak ale dojde na to vypláchnutí a to sebere klidně znovu 2x až 3x tolik. Pokud to použiješ někde kde je to exponované typicky při výpočtu hran polygonu... tak jsi lidově řečeno v pérdeli.

Oznámení

Without Frontier (Frontier 3 ;- )

Komentovat

Komentovat

Komentovat

Komentovat

Komentovat

Komentovat

Komentovat

Komentovat

Komentovat

Komentovat

Komentovat

Komentovat

Komentovat

Komentovat