Tak toto budu sledovat.

Doplnil jsem celkem zásadní věc a to je ořezávání hran, myslím, že to je vidět střídavě se to zapíná a vypíná. Přes víkend zkusím udělat stínování nějak interaktivně aby se to dalo testovat... to bude asi solidní zásek do rychlosti je to halda počítání navíc.

----- UPDATE -----
Ale jakože vůbec . Dostal jsem geniální nápad. každá barva na screenu může mít řekněme 8 odstínů podle takže počítam z tabulek aloďe mají dva odstíny barvy a dva dstíny kovu max (to je 32 odstínů plus kabina a motory... ostatní to mají v zásadě stejně, plus textura s popisem a další věci znaky a tak.
Takže si kludně můžu ty odstíny předgenerovat a pak se jen posouvám v tabulce podle pozice dynamického světla. Takže to sice není uplně 100% stínování ale je to mnohem rychlejší a ve hře si toho nikdo nevšimne vypadá to líp než origoš Frontier .

Už to dovede korektní Z-buffer a stínování. Myslím že loď předstírající trysky a ukzuje jak to hezky stínuje.

Sleduji se zadrzenym dechem co bude dal

Obdivuji, ze ten kod pises rucne sam. To je v assembleru ci v C?

Blbinky jako loadery dělám v Cčku herní logiku v Cčku tam není moc co je to zbytečná drbačka dělat to v assembleru, rasterizér je v assembleru (a jo pujčil jsem si kus od Filipa D.) některé technikálie řeším, různým sháněním. Občas AI když je potřeba se na něco doptat Google stejně sime všechno přes gemini.

Jak máš jednou nějakou věc tak je to realativně snadné nejhorší je ten začátek. Původní myšlenka byla vykreslovat vektory... ale tam je problém s barvama a podle mě od určitého počtu to je pak jedno, jde spíš o velikost.

C2P rutinu mám z aminetu, ale pak bych rád použil RTGMaster.library to co mám dovede dokonce i delta kompresi (MMU na 030 počítá rozdáli mezi snímky a kopírují se jen změny.
To stínování nakonec není tak složité, daleko horší byl ten realistiký Z-buffer.

Jo a s Claudem jsem se domluvil, že mu nakreslím náčrtky lodí a on mi z toho udělá objekty v Blenderu .
Jo a Nechal jsem si vygenerovat reálné pozice a seznamy hvězd v okolí sluneční soustavy. Tak je tam přidám a kolem toho nebo spíš za jejich bublinou se bude generovat procedurální (fakt jakože zatím nemám tucha jak to udělám ) vesmír..

PS: Skutečný výhled bude ještě o něco menší... nahoře bude stavový bar (co má loď zapnuté a podobně) pak výhled z kabiny a pak dole ovládání a radar. Chtěl bych to udělat podobně jako to je tuším v Grindu tím ušetřím nahoře cca 20 pixelů a dole 56 možná víc ... a to znamená zase o něco méně překreslování v cz fast do chip.

No parada. Slusna prace.

Tu "oblohu" se statickymi hvezdami sem resil v Atari ST/Amiga Elite. Puvodne tam byl jen ubihajici starfield podle pohybu lodi, neco jako stardust. Ten sem potlacil a udelal ho tmave sedy a na pozadi bile staticke hvezdy a vypada to dobre. Aby to nezpomalovalo tak sem je predpocital do tabulky jako vektory na kouli kolem tebe (vzdalenost pro nepotrebujes, jen smer) A pak je rozdelil do stromu aby chudak 68000 na 8MHz to upocital a Elite se stale hybalo i na A500. Zkusim to zitra popsat a udelat dokument, jestli chces.

Realne hvezdy tam nemam, dal sem to nahodne. U prvni Elite je to jedno.

Vypada to moc zajimave

Tak jsem nechal haldu času an testování... a potřeboval bych dobrovolníka s 060tkou... nemám po ruce žádnou reálnou 060 a prostě nedává mi smysl aby hra měla na 040 25FPS na 060 i když prostě vešekré dělení upravím aby nepadalo do privilegovaného režimu tak jede 12 FPS takže potřebuju test na živém.

- 68030: ~14.4 fps
- 68040: ~24-25 fps
- 68060: ~13.5 fps
To vše v FS UAE podle mě ta 060 je prostě nějak na p... emulovaná. ručně jsem to přepsal, předělal jsem detekci hran, skrouhl jsem dělení na minimum a 060 nepoužívá ani jednu problematickou instrukci.​

README:
Spusteni:
- Rozbalit vsechny soubory do jedne slozky (musi zustat spolu:
amiga_flythrough_demo_<cpu>, hull.model, station.model).
- Podle sveho CPU spustit prislusny soubor, napr. na 060:
"amiga_flythrough_demo_68060 station.model hull.model"
(bez parametru to hleda DH1:station.model / DH1:hull.model - funguje
jen pokud mate prave takhle pojmenovany disk; s parametry to funguje
vzdy, kdekoliv soubory rozbalite).

Ukonceni:
- Klik levym tlacitkem mysi, nebo klavesa Escape.
- Po ukonceni se otevre okno "Frontier3 Report" se statistikami FPS
za jednotlive okruhy kamery (zustava otevrene, dokud v nem
nezmacknete klavesu). Behem letu bezi report i primo do konzole
(kazdych 220 snimku = 2 okruhy), takze FPS jde sledovat prubezne,
ne az na konci.

Co uvidite:
- Stanice se pomalu otaci kolem vlastni osy (nakloneni 40 stupnu).
- Mala oranzova lod (svetelny zdroj - "motory zapnute") pomalu obiha
stanici, v OPACNEM smeru nez stanice rotuje.
- Kamera rychle obleta cele okoli, ponoruje se blizko k rovine
prstence stanice a zase stoupa, porad dokola.
- Skutecne stinovani (smerove svetlo = ta oranzova lod) a skutecny
Z-buffer (spravne prekryvani mezi lodi a stanici, vcetne castecneho
prekryti).
- FPS pocitadlo vpravo dole (zive, aktualizuje se za behu).

Co je jinak oproti drivejsi verzi (2026-09-20):
- amiga_flythrough_demo_68060 uz NENI kompilovany jednotne -mcpu=68010
(bezpecne, ale zbytecne konzervativni kod pro vsechno) - ted je to
"smisene": core/fixmath a nacitani modelu bezi na bezpecnem 68010
(behem hry se nepocitaji vubec, na FPS to nema vliv), vsechno ostatni
(transformace, rasterizace, c2p) je prelozeno pro 68040 (realny 060
plne podporuje vsechny adresni mody a instrukce 68020-68040, chybi mu
jen 64bitove MULS.L/DIVS.L formy) - a rucne proverene rozborem
vysledneho strojoveho kodu (disasm cele slinkovane binarky), ze uz se
tam nikde tyhle nebezpecne instrukce nevyskytuji ani nepatrne (jedina
zbyvajici "podezrela" mista jsou rucne psany c2p prevod, ktery
nasobeni/deleni vubec nepouziva - overeno primo ve zdrojich).
- Pridana rucne psana 68k asm vnitrni smycka pro Z-buffer rasterizaci
(raster_pixel_68060.s) a odstranena zbytecna prepocitavana
transformace kamery/objektu (drive se pocitala znovu pro kazdy vrchol
kazdeho trojuhelniku, ted jen jednou za objekt za snimek - matematicky
presne stejny vysledek, jen bez zbytecne prace navic).

Ano, 68060 vychazi v FS-UAE HORE nez 68030, i kdyz je kod uplne bez
nebezpecnych instrukci a je overene rychlejsi na 68040. Nejpravdepodobnejsi
vysvetleni: samotne 68060 jadro v FS-UAE je znatelne min optimalizovane/
presne nez jeho 68020/030/040 jadra (dost bezna zkusenost v UAE komunite) -
ale bez testu na realnem 060 hardware se to od skutecne zbyvajici chyby v
kodu nedá se 100% jistotou odlisit. PROTO by bylo fajn dostat cislo z
realneho stroje - kdyz i tam vyjde 060 pomalejsi nez 030/040, je to jasny
dukaz problemu v emulatoru, ne v teto hre.

Pozadavky: AmigaOS 3.x, AGA (256 barev), 68020+ (testovano na
emulovanych 68030/68040/68060 pres FS-UAE).​