Vzhledem k tomu, že se bude pravděpodobně jednat o rozsáhlý a dlouhodobý projekt, bude mít stránka k této hře povahu spíše úschovny vývojových řešení jednotlivých modulů. Teprve pokud se podaří hru dotáhnout do konce, bude stránka převedena na standardní informační stránku hry.
Vývoj bude postupovat po těchto modulech:
- statická grafika pozadí (kresba LEVELů) – dokončeno
- zobrazovač postavy hráče
- grafika ostatních pohyblivých objektů (pochodně, mříže, stráže, apod.)
Řešení každého z těchto dílčích modulů je na hraně možností PMD-85 i za předpokladu využití 64kB RAM. Pokud se hra nevejde do 64kB RAM, zveřejním knihovny ale hru nebudu uvolňovat. Spíše bych ještě vyzkoušel zásadní redukci animačních dat, neboť tam i desetiny procent ušetřeného prostoru mohou vzniklou situaci vyřešit.
Aktuální bilance využití RAM
| položka | délka [byte] |
| videoram/proměnné/bufer | 16384 |
| BG graphic | 7073 |
| data levelu | 2304 |
| zbývá | 39775 |
Oficiální startovní výstřel zazněl 1. 2. 2020
“ Houstone „, čekáme, jsme připraveni … 😆
Nejprve musím vyčistit stůl od The Magician’s Curse. Dotáhnout organizačně závěrečnou fázi této hry. Ale je pravda, že hlava už podvědomě upravuje knihovny pro PoP..
Návrh analýzy, případové studie použitelnosti modulu ( paměťové rozšíření 256kB RAM )
viz. “ https://pmd85.borik.net/wiki/Blog:Pamäťové_rozšírenie_256kB_RAM “
* zatim jen pro emulátor PMD-85 od RM-TEAMu ( verze PMD 85-2A a PMD 85-3 )
Nene. Já píšu hry pro PMD-85. Tím myslím to skutečné, fyzické PMD-85. To je stěžejní podmínka, ze které nemohu slevit. Takže bez 256kB RAM, tím pádem bez hardwarového přepínání stránek videoram a jiných vymožeností. Prostě to musí jet na skutečném železe. To je dost velká výzva.
Ale zrovna dělám animaci postavy Prince mezi pozadím a popředím statické scény a rychlost se jeví jako dostatečná a to posouvám postavu po dvou pixelech. Druhá věc je, nakolik rychlost postavy Prince zpomalí například animace padajících desek. To i na originálu viditelně hru zpomaluje. Originál má několik prioritních úrovní, ve kterých jsou bitmapy řazeny. Ale já si teď momentálně myslím, že by měly stačit roviny tři (pozadí, pohybující se objekty a popředí). Do tohoto systému se pokusím hru natlačit. Spíše teď řeším dilema, zda zvolit formát obrazovky 10×3 dlaždice (originál Apple) nebo 8×3 dlaždice (tuším konverze pro ZX Spectrum). Formát 8×3 ideálně vykrývá obrazovku PMD-85, vypadá proporčně lepší a systémově to řeší „zanoření se“ postavy hráče mimo obrazovku na levém a pravém okraji..
ok, ok…
Njn to dělají asi ty filmy, samá SCI-FI, to je jeden úplně zblblej…
tak to se teda ale snaž, ať to to zase k něčemu vypadá 🙈
Zatím to vypadá, že já si právě sám odpověděl na své dilema…
Tak zlom “ si “ vaz 😉
Tak pořád nic, pořád jsem nic nechytil. Nahazuji udici, ale nic se nechytá. Takže začnu asi tím, že metodou TOP-DOWN začnu (už jsem vlastně začal) přepisovat originál z procesoru 6502 na i8080. Tím se mi snad trochu blíže podaří zjistit systém, jakým do sebe jednotlivé knihovny zapadají a jaké datové struktury sdílí. Důvod proč se znovu zabývám variantou doslovného přepisu originálu je ten, že mám takový neodbytný pocit, že ten kód půjde výrazně zkrátit. Částečně kvůli nižší „hutnosti“ kódu procesoru 6502 obecně, a částečně kvůli tomu, že tam prostě některé věci nedám, či je vyřeším jinak (samozřejmě úsporněji). Tato varianta má totiž kouzlo v tom, že dané pojetí prostě přirozeně integruje všechny funkce hry a nemusím nic vyvíjet ve smyslu volby algoritmů „vyšších struktur“.
Souběžně s tím budu pracovat na alternativní verzi vykreslovacího jádra, které nepotřebuje řadit bitmapy objektů ve správném pořadí za sebe a pak výsledek hodit na obrazovku. Již zmíněná knihovna TriPlane (či jen její část TristatePixel) umožňuje totiž implicitně řadit pohyblivý objekt mezi popředí a pozadí a děje se tak téměř beze ztráty rychlosti až při vykreslování pohyblivého objektu přímo do videoram. Výsledek, jak již bylo řečeno, můžete posoudit ve hře The Magician’s Curse, kde je tato metoda použita při vykreslování postavy hráče. Ovšem rizikem je, že se dostanu do slepé uličky, pokud se v průběhu vývoje ukáže, že tento přístup není slučitelný s interními algoritmy hry.
Už jsem téměř rozhodnutý, že aby místnosti lépe vykryly plochu obrazovky, bude struktura obrazovky členěna na 8×3 modulů, tak jak to má ZX Spectrum. Je to trochu jiné než originál Apple, ale podle mne to není nějak moc násilná změna. Díky tomu bude využito všech 48 „textových“ sloupců na obrazovce. Opuštěná varianta „originál 10×3 moduly“ vykrývala pouze 40 „textových“ sloupců obrazovky a obraz místnosti působil příliš kostkatě (ne ve smyslu rozlišení ale ve smyslu poměru stran herní plochy).
Tolik tedy zpráva o aktuálním vývoji. Asi ještě dlouho nebude nic vidět. Ale neusnul jsem..
Zní TO a pravděpodobně TO i vypadá jako správná cesta správným směrem, aniž by se jednalo jen
o pouhou “ nudnou “ kopii toho co už tady bylo…
Jen tak dál …
PoP jménem Zdeněk
( bylo jménem středověkých šlechticů a rytířů ) 😎
Když budeš hodný, bude mít PoP pro PMD-85 na čele nápis „Zdeněk“.
„… no tak to mi teda nalaď mokrý dudy …“😆😉
To by byla teda velká pecka …
( Já, už budu hodný, “ dědečku “ ) ✌
Tak všechno nejlepší k jmeninám a ten jeden pixel na hlavě toho íránce Ti rezervuji. Snad bude z boku vidět..
Díky, díky…dneska mám navíc ještě narozeniny
😎😉
( Dle dřívějšího výkladu je jméno Zdeněk považováno za českou podobu latinského jména Sidonius. Jméno by se pak vykládalo jako „původem ze Sidonu”, „sidonský”. Sidonie bylo přitom antickým městem, které dnes pod názvem Saida najdeme na území Libanonu…. )
Dnes technologický průlom. Pokud hru nedokončím, určitě to nebude proto, že by se nevešla do 64kB RAM. Vejde. A začínám si myslet, že by to možná šlo vtěsnat i do 48kB. I když asi za cenu ořezání nějakých těch méně důležitých animačních dat. Pro 64kB verze PMD-85 by hra byla komplet, pro 48kB verze by mohla být ta ořezaná – alespoň něco.
Co se tedy dnes stalo?
1) Díky prvnímu stupni komprese to vypadá, že délka animací postavy hráče spadne z 30kB na cca 22kB (extrapolace z 1/16 převedených dat). Ještě mám připraven druhý stupeň komprese, který by měl ušetřit dalších cca 2-3 kB.
2) Hra zřejmě nebude potřebovat stínovou videoram o délce cca 12kB! Momentálně prováděné pokusy ukazují, že by snad mohl stačit lokální bufer, navíc umístěný v zápisníku „napravo“ od videoram, kterážto oblast paměti je jinak dost obtížně využitelná.
3) Mám (pravda, prozatím teoreticky) připraven systém komprese statické grafiky pozadí.
4) Dnes sestavené demo animuje běh postavy hráče na pozadí a odhadem to vytěžuje procesor tak na 10-15%. Nevěřím svým očím.
5) Hru zřejmě půjde synchronizovat UARTem v časovém rámci 100ms na jeden krok hry.
Takže další krok: udělat procedury pro sestavení místnosti a spojit se zárodkem animačního jádra.
Houstone, rozumíme a blahopřejeme, pokračujte dál v daších plánovaných i neplánovaných krocích, čekáme na další spojení a nové objevy …
konec …
Ta vykřesaná naděje pro PMD s 48Kb je úžasná zpráva :)
Díky
Existuje jedna animační varianta, která umožňuje vypustit některé mezilehlé animační fáze u méně častých pohybů, například „skok do dálky“ nebo šplhání a podobně. Jistě, ten pohyb pak nebude příliš plynulý, ale třeba se najde někdo, kdo to zrovna bude chtít pustit na starém železe se 48kB. Ale jsem teprve na začátku a je to spíše takový odhad. I když je realita, že jsem řádově na polovinu snížil předpokládané nároky na paměť RAM. A zase: je důležité slovo „předpokládané“. Teď to možná pojede i na 48kB ale později může některá funkcionalita vyžadovat zásadní předělávku a RAMky bude najednou málo. Takže to berme jako světlo na konci tunelu. Ale je to světlo.
…světlo je světlo a tma je tma …
chce to pochodeň nebo baterku 😉😎
Tak já vidím definici světla v tomto případě takto:
Momentálně se už PoP prochází po provizorní plošině (bez ovládání a v jednom směru). Velice pěkně střídá animační fáze běhu, to vše korektně na pozadí statické scény. Momentálně jsem rozšířil rozsah obnovovaného pozadí za postavou hráče a spotřeba výkonu CPU vzrostla na cca 33%, s dokreslováním různých pomocných textur bych neměl překročit spotřebu 50% výkonu CPU. Zbývá tedy dost na protivníky či padající stropnice. Stále je v platnosti fakt, že zřejmě ušetřím cca 12kB na pomocnou videoram, místo které poslouží zápisník ve fyzické videoram. Jak zrcadlově otáčet animační fáze postavy hráče přímo za běhu hry beze ztráty rychlosti mám taky vyřešeno (ještě aby to fungovalo..) A přišel další nápad na kompresi animačních dat Prince, což je klíčové. S těmi provizorně splácanými moduly bych od zítřka začal ladit řadič pohybových sekvencí a ovládání přes klávesnici a pak bych zpětně dodělal všechny animační fáze Prince, abych viděl, nakolik se ta hra vleze do 64kB a jestli zůstane aktuální ta šance na verzi 48kB.
No, tak ty si čaroděj … 😉😎
Opfavdu?
( … ju no boš, servus blonďak … )
Dobrý večer,
P (rinc) o P (rincezně): “ už se perou “ 😉😆 ( pravděpodobně již zítra )
Již teď se můžeme těšit na jejich skvělé příběhy z vězení s názvem PMD-85,
dobrou noc …
Jednu na dobrou noc bych měl. A není to z říše pohádek. Našel jsem systém pro velmi efektivní komprimaci statické grafiky pozadí. Právě to jdu přepsat do ASM. Snad ta online dekomprese nebude moc zpomalovat vlastní kreslení. Ale u téhle hry je to od začátku o tom „dostat to tam“. Bohužel, rychlost je až na druhém místě. Někde jsem vykopal, že originál jede na 11 FPS (frame per sec), já mám zatím synchronizaci na 10 FPS, což je kompatibilní i s jedničkovou verzí PMD-85. Pokud by se podařilo rozchodit PoP i na verzích se 48kB RAM, tak na jedničkové verzi by v nejhorším případě jela hra o 10-20% pomaleji. To z toho důvodu, že tam změnou předvolby T1 časovače 8253 nelze měnit vysílací rychlost UARTu. Ale to není nic zásadního. I ta 10 FPS rychlost vypadá celkem hratelně. Ne že by už ta hra jela, to bude tak za rok. Myslím tím, že pohyb postavy hráče má slušnou dynamiku.
Dnes první oficiální výstřel z “ AURORY “ na zimní palác … 😉😎
Tak to jsme z toho teda “ páv “
Budeme se zatím těšit na nějaké “ PoP preview “
pozn. redakce
LIBOR L.A. je “ pán „
… tož pěkně, kurňa, pěkně mu to šlape …ťap, ťap, ťap ✌
“ https://youtu.be/IZ5GJKapbzA „
Prozatím to vypadá tak, že tuhle animaci by člověk sesmolil i v BASICu :) Ale nespím na vavřínech! Mám kompletně ručně přepsaný seznam animačních sekvencí do assembleru i8080, dnes jsem udělal konvertor z binárních dat levelů rovněž do assemblerovského zápisu a zkouším již zmíněnou kompresi statické grafiky pozadí. S tou grafikou se musím pochlubit. Třeba takový obrázek o 240 bajtech jsem dostal do 61 bajtů. To vypadá nadějně. Daní za to je mírný pokles rychlosti kreslení. Ale opět: u této hry je to souboj o jednotky bajtů. Z této mantry nelze slevit.
Pokud vše, co mám momentálně rozdělané, do sebe zapadne, tak by měla postava hráče chodit v bludišti. Jen pomalu chodit směrem vlevo, bez interakce s okolím a bez všech těch ostatních prostocviků, které PoP umí. Tak tohle by se mělo vlézt cca do 8-10kB. Zhruba.
Momentálně mě okolnosti navádí k tomu, abych opět změnil směr vývoje, na chvíli opustil animace postav, a dokončil pozastavený vývoj vykreslovače pozadí. Přeci jen si musím vytvářet pomocné konstrukce, ve kterých se právě vyvíjený modul může uplatnit. A právě dnes mě napadlo, jak využít to geniální z originálu Mechner a efektivně to realizovat na hardware PMD-85.
Tak to jsou více než skvělé zprávy…
Důležité je, že Tě něco navádí :-) a jsou pořád nějaké nápady, jak to celé poskládat dohromady, aby to bylo životaschopný a všechno se to tam vlezlo …
Ty to určitě dokážeš 😎 👍
No díky za důvěru. Nějaké to rozpohybované demo se snad podaří slepit k termínu konání Foreveru 2020. S prázdnou tam nemohu jet.
Určitě to bude ta největší pecka z českých ( moravských, slezských ) luhů a hájů …
S důvěrou v Tebe vloženou, nezklameš 😆 😉 ✌( běda Ti )
… bude to s i rozsáhlou mezinárodní účastí
“ http://forever.zeroteam.sk/visitors.php “
( známé firmy jako solaris104, mborik …. )
Ty na Forever jezdíváš, nebo ses koukal na jejich stránky? Pokud bys letos jel, tak se asi potkáme. Já na 99% budu chtít přijet.
Jako reakci na oba Zdeňkovy podněty uvádí má tisková agentura následující stanovisko:
Nejen psaním programů zdarma živ je člověk. Momentálně jsem slíbil výpomoc s elektroinstalací v menším domku, pak se musím postarat o výbavu svého vlastního domu a tak to vidím na jedno- až dvoutýdenní výluku. Ale po večerech pracuji pravidelně na podpoře PMD-85, i když pravda pomalejším tempem. Některé věci holt musím řízeně a vědomě odsunout. Alespoň jsem si udělal radost a koupil v aukci PMD 85-2. V pátek dorazí. Alespoň bude další kus na testování vyvíjených her. Všechny mnou vlastněné jedničkové verze nejedou, trojku jsem koupil jako šrot, dvojku jsem doteď neměl (no vlastně měl, ale padla za oběť reverznímu inženýringu) a veškeré testy tak obstarávala PMD 85-2A. The Magician’s Curse bude tedy asi o týden zpožděn a u hry Prince of Persia prozatím ladím bitmapovou grafiku pozadí aby byla stoprocentní a nemusel se k ní později vracet. Pořád žije naděje na verzi POP48. Odhaduji, že do dvou tří týdnů by mělo být hotové demo, kde POP bude chodit regulérně na pozadí, ovšem bez koincidence s objekty. Tuž tela. (Ta poslední věta je pro místní :)
“ … za tela peniz, tuš buděm všeci zdravi …“ ✌ 😆 😉
Aktuální stav:
LEVEL 1 je korektně vykreslován, grafika statického pozadí prozatím zabírá 2,5kB. Ale nejsou tam sloupy, gilotiny a pár dalších bitmap, které tu sadu statických obrázků navýší. Finální délku celé grafické knihovny teď odhaduji na max. 3,5kB, což je vůči 13,5kB u originálu solidní úspora.
Z originálu jsem převzal systém technické kompozice obrazovky (rozklad obrázků na moduly A, B, C a D). Je to efektivní a systémově velice fikané řešení. A nějak moc to ani nezpomaluje úvodní vykreslení obrazovky. Trochu ano, ale pokud zbude místo, dají se některé věci vykreslovat rychleji jednoúčelovými procedurami. Takže ladění až nakonec.
Hra již má integrovaný detekční a překreslovací systém modulů 10×3 (ve skutečnosti 11×5). Takže když dojde ke změně stavu například pochodně nebo lahvičky, tak během následujícího obnovení obrazovky dojde k překreslení všech modulů, „postižených“ změnou stavu objektu. Postava Prince mi teď provizorně „běží“ na místě a testuje korektní a synchronní překreslování grafiky pozadí (například již zmíněné plápolání ohně pochodně se krásně zobrazuje za postavou pohybujícího se hráče).
Demo ještě vypouštět nebudu. Přes všechny zmíněné úspěchy je oproti demu z roku 2015/2016 jen málo viditelných změn. Jedinou změnou je vlastně ten klusající PoP na pozadí. To hlavní se prozatím odehrálo uvnitř.
Zásadní zprávou je fakt, že z fáze úvodního brainstormingu (souběžně jsem vyvíjel 3 verze hry PoP) jsem se dostal do fáze, kdy hra již má pevný základ, který se myslím měnit nebude. Jednotlivé komponenty, které ještě budu implementovat, již mají celkem jasné kontury a půjde jen o to, aby byly rychlé, krátké a funkční.
Naděje na PoP48 stále žije. U verze PoP64 bych chtěl udělat podporu MIF85. To by se líbilo i mi. Co implementovat zcela jistě nebudu, jsou ty úvodní kejkle s výběrem lahviček, otáčení obrazu, přeskakování levelů a nesmrtelnosti pomocí textových hesel. Zabírá to obrovské množství místa a je zapotřebí vybírat, co tam bude a co ne. Pokusím se rozšířit počet místností v levelu tak, aby level 12 (který je ve skutečnosti složen z levelů 12, 13 a 14) byl kompaktním útvarem, aby dohrávání jeho částí nezdržovalo hru. Hra by se pak skládala z hlavního bloku, následovaného sekvencí INTRO – LEVEL – INTRO – LEVEL – … dle řazení originálu. To pořadí by bylo zachováno i ve verzi pro MGF, přičemž INTRA by se dala přeskakovat. Dohrání nového levelu by bylo realizováno nahráním binárního bloku s definičními daty levelu, a pokud by se zrovna měnilo prostředí DUNGEON/PALACE, tak by se jako součást toho jednoho binárního bloku nahrála i potřebná grafická knihovna (zmíněných cca 3,5kB).
Momentálně zápasím s časem, nicméně po malých kouscích piluji grafiku pozadí na úrovni pixelů. Zdá se to jako malichernost, ale pokud dvě sousedící bitmapy (každá samozřejmě vyplněná odlišnou texturou!) do sebe nezapadnou jako správné dílky puzzle, působí ty grafické přechody mezi nimi velice rušivě. Zvláště proto, že řada bitmap má na výšku spíše jednotky rozsvícených pixelů a každý nesprávně umístěný tak křičí do světa: „Zde nepatřím!“ A pokud daná bitmapa může nabývat více poloh, je nutno sladit ty grafické přechody u všech polohových kombinací. Výsledek pak vypadá velice jednoduše a samozřejmě a člověk by řekl: „Cos na tom dělal, vždyť se ta podlaha propadne o 1 pixel – co je na tom?“ Je na tom řádově 100 pokusných kompilací pro každou odladěnou bitmapu, kdy zkoušíte upravovat grafickou vykreslovací masku například nášlapné desky a pilujete okrajové pixely zmíněných textur. Aby to na závěr vypadalo jednoduše a přirozeně.
Z nových věcných informací mám tak snad jen následující poznatek. Míra zatížení procesoru od animace statické grafiky pozadí je ve většině místností jako zázrakem někde kolem 60-80%. K tomu je ovšem třeba přičíst zatížení procesoru od obsluhy a vykreslování postavy hráče a jeho oponenta (nepřítele). To vše zatím bez nějakých zásadních rychlostních optimalizací. Nabízí se otázka: „A co když překročíme 100% zatížení CPU?“ No nestane se samozřejmě nic. Doba jednoho frame (cca 100msec, převrácená hodnota zobrazovací frekvence v jednotkách FPS) bude kolísat od jmenovité hodnoty zhruba 0 až +15%. Stejně to má i originál na Apple II. Koukněte se na youtube a tam viditelné časové disproporce budou viditelné i na PMD-85. Nejvíce je to vidět tam, kde nad postavou hráče začnou padat stropní desky. Tam odhaduji snížení FPS snad až na hodnotu 2-3 (z původních 11 FPS – snímků za vteřinu).
Jo,jo, jo…známa věc, co vypadá ve výsledku “ jednoduše a přirozeně „.
To je většinou ve skutečnosti ta největší “ dřina, pakárna, prasárna, piplárna “
na světe, kterou pak málo kdo ocení. Hlavně to “ žere “ neskutečné hodiny a hodiny času…
( … šmarjá, to byla fuška … )
Tak hlavně pevné nervy ( a když něco nejde, tak je nejlepší je jít se najíst ) 😆😉
Zlom (si) vaz ✌
Možná nakonec malé video s aktuálním stavem infrastruktury:
https://www.youtube.com/watch?v=upgok2V0JvM
Řekněme si to na rovinu, proč bychom to nepřiznali ..je to takové hezké “ preview “
Nakonci dokonce i pěkná interakce “ Prince “ s pozadím ✌
( … avšak po bližším prozkoumání, se tam objevil i takový malý nešvar viz. níže )
http://zkolar.sweb.cz/pmd85/PoP/PoP-dev-step2-issue1.png
http://zkolar.sweb.cz/pmd85/PoP/PoP-dev-step2-issue2.png
O tom nešvaru vím, postavu prince jsem tam přilepil jen tak do počtu kvůli průmětu jednotlivých vrstev obrazu. A protože se vykresluje jen modul o šířce 4 videobajtů (24 pixelů), tak je zobrazena i stejná šířka postavy (co je nad 24 pixelů, to už se nezobrazí). Vím o tom, ale to demo není o kompletní postavě ale o kompletní grafice pozadí. A vlastně ani tu to nezobrazuje v celém implementovaném rozsahu. Další demo asi vypustím ve stavu, kdy bude postava hráče alespoň chodit v obou směrech (a vždy bude zobrazena celá). A taky to video je trhané, myslím že jsem v roztržitosti nastavil při pořizování videa 11 FPS, což je samosebou chyba.
Teď dělám takové potěmkinovské demo, kdy stiskem kláves K0..K11 se přepínají jednotlivé levely, které jsou všechny součástí toho dema. A vždy se daný level dá kurzorovými šipkami celý projít kvůli kontroly grafiky pozadí. Pak ty levely zpátky odmažu a budu pokračovat na grafice postav. Tolik ediční plán na příští dva měsíce.
První demo, které ukazuje reálnou (no, momentálně spíše maximální) rychlost hry. On ten výkonový limit ale není v uvedeném demu moc poznat. Rychlost hry tam omezuje rámcové nastavení 10FPS. Pro verze PMD-85 2A a 3 bude rychlost větší nejenom tím, že lze nastavit větší hodnotu FPS, ale bude tam i prostor pro akceleraci vykreslovacích rutin. Prozatím tedy první komplexní ukázka, jakkoliv se jedná o potěmkina první kategorie.
https://www.youtube.com/watch?v=QvIU9D6S2_g
… to vypadá dost, dobře
👍 To se mi líbit 🐒
Jen tak dál …
“ zdar a sílu najdeš v sýru “ 😉😎😁
První odezvy jsou mírně negativní ve smyslu rychlosti. Ale tohle budu řešit až na konci. Buď zbude místo v RAM i u 48kB modelů a pak se najde nějaký softwarový mechanismus stabilizace rychlosti (nad jedním už přemýšlím – prostě se v každém frame překreslí konstantní počet modulů bez ohledu na to, kolik jich je nutno překreslit z důvodu jejich změny), a pokud bude jen 64kB verze, tak tam mohu jak výrazně zoptimalizovat rychlost vykreslování na úkor zabrané paměti RAM tak hlavně mohu změnou frekvence T1 časovače 8253 lineárně a spojitě řídit rychlost hry. I těch 11 FPS, které má údajně originál, se mi jeví celkem pomalé. 12 FPS už je podle mého gusta.
Tak to je super. Jsem to teď četl jedním dechem.
Mega se těším. Prince byl první hra na mé Amize 500+ , poctivě dohraná. :)
Každopádně určitě ji zapařím na PMDčku. :) ….Respekt !
jooo AMIGA ( ještě mám někde A500) to byla pecka, ale PMD85 je tak ňák víc jako RETRO ( byla to typická vůně plastu, cvakání kláves, beepání, typický hluboký zvuk při nahrávání z MG ) a hlavně to zavání jistou nostalgií … ✌😉 A PoP je prostě klasika…pamatuju, kde jsem tu hru viděl poprvé ( PC AT 286,
disk. mech 5.4 “ ) chroup, chroup ..to byl mazec
Začal jsem pracovat na kulturní integraci pohybu postavy hráče. Mnoho procedur bude společných pro ostatní „postavy“ ve hře. Nakonec tedy upustím od původního záměru napsat ovladače každé postavě na míru.
Nedávno vyvinutý systém pro odmazávání zbytků postavy při jejím pohybu funguje krásně a přitom je velmi jednoduchý a rychlý.
Co mi trochu vadí je fakt, že díky velice rychlé kreslicí proceduře jsou objekty při pohybu na obrazovce hřebenovitě rozmazané. Momentálně to tak nechám, ovšem při závěrečném ladění se kouknu, zda by pomalejší kreslení nebylo nakonec lepší. Bohužel na PMD-85 nelze kreslení synchronizovat s během paprsku na monitoru a tak je to problém neřešitelný. Tyto grafické defekty lze jen omezit, a to pouze částečně.
Momentální délka programu je cca 4900h a to ještě nemám připojeny všechny animační fáze postavy hráče. Ale na druhou stranu je tam plno vývojového balastu, který se vyčistí. Momentální meta je dodělat zobrazovač postavy hráče a propojit jej s řídicím modulem. Ten už „hotový“ je, ovšem není odladěn. Je pouze nahrubo přepsán z originálu. Takže to bude ta pravá zábava.
Aktuální verze podporuje jednobarevnou koloraci levelů. Animační fáze postavy teď upravuji z originálu Apple. Vypustil jsem číselný odpočet zbývajícího času. Odpočet udělám buď bargrafem nebo tam sice nechám číselnou časomíru, ovšem na bázi časování UARTem. Čtení 8253 na reálném stroji vykazuje takové šílené problémy, že tudy zcela jistě nepůjdu.
Ahoj, je to už viac ako 10 rokov, ale zápasil som si tým istým v Kvádrovi a nakoniec som odmazávanie „časovo natlačil“ čo najtesnejšie pred kreslenie novej pozície alebo nového spritu. Inak sa, bohužiaľ, nad tým paprskom na PMDčku vyhrať nedá.
Včera jsem ještě udělal alternativní kompilaci, kde se vykresluje obrázek po mikrořádcích, tak jak jdou lineárně za sebou. V tom nejhorším možném případě dojde během kreslení obrázku maximálně k jednomu „záseku“, kdy si oko může všimnout 20ms trvajícího řezu mezi dvěma animačními fázemi. Nutno říci, že je to mnohem, mnohem lepší, než když kreslím mikrořádky v pořadí 0,4,8,12,…,1,5,9,13,…2,6,10,14,…3,7,11,15… V tomto případě střih obrázku při přechodu paprsku TV obrazovky během vykreslování vytvoří hřebenovitý vzor, a ten je sakra vidět. Důvod pro to morbidní střídání mikrořádků je rychlost. Instrukci DAD pro posun na nový mikrořádek (doba vykonávání 10 T) lze ve třech čtvrtinách případů nahradit instrukcí INR H (6 T). Konkrétně u PoP dělá celkový dopad na rychlost hry odhadem 5% a to zase není tak málo.
Jo tak, aha, tak to máš pravdu. Tých 5% výkonu nie je niečo, čo by sa dalo pri POP oželieť. Je pravda, že Kvádro mal houby-sprajty oproti princovi.
Ešte som dávnejšie rozmýšľal, či by PMDčkovým hrám/demám nemohlo pomôcť „zafixovanie“ paprsku časovačom…
Hm, to není špatný nápad. Rozklad TV obrazu je přesně časovaný a neměnný, pokud by se do binárně čítajícího časovače taktovaného 2,048MHz dala konstanta odpovídající 20ms (konkrétně 40960 neboli A000h, což odpovídá celkem 320 TV mikrořádkům kompletního obrazu), tak by se čtením časovače modulo 128 dalo zjistit číslo právě zobrazovaného TV řádku. Jen by se na začátku hry asi muselo udělat nějaké grafické rozhraní typu „nastav dva videobajty nad sebou aby nebyly zarovnané“. Tím by se určil výchozí kalibrovaný mikrořádek TV rozkladu a od něj by se čítalo zbylých 320 mikrořádků rozkladu.
Vivat brainstorming! Nemáš ještě nějaký námět? Tohle vypadá fakt geniálně!
Tak aby som si neprisudzoval cudzie nápady, toto je Romanova idea, ktorú zo seba začal chŕliť počas brainstormingu po tom, čo som dokončil tie nekonečné sprity – https://www.youtube.com/watch?v=1T2HvgmodrA
Vtedy som prskal síru nad tým, že to bliká jak blázen.
Ohľadom konfigurácie, mne napadlo, že by sa pred spustením dema/hry objavil v spodných riadkoch obrazovky testovací obdĺžnik, ktorý by sa v každom frame prepínal z #AA na #55 (veľkosť asi taká, aby sa to stíhalo za frame, tj. 288px x 32px?) a cieľom užívateľa by bolo kurzorovými klávesami si nastaviť blikanie tak, aby bolo to blikalo tesne na konci… ale k realizácii nikdy nedošlo. :(
Dokončuji testovací program pro vizualizaci rozkladových obvodů obrazu u PMD-85. Pomocí tlačítek nahoru a dolů si mohu na obrazovce ustavit stabilní rozhraní, synchronní s rozkladem obrazu. Ostatně ještě dnes bych k tomu udělal samostatnou stránku. Jen co dokončím komentář toho testovacího programu..
… víc HLAV, víc ví … 🤪
a nebo neví, nikdo NIC … 🤓
Už aby bylo k dispozici nějaké to ALFA hratelné DEMO, pro zahnání začínajících abstinenčních příznaků …
… protože, kdo si hraje … NEZLOBÍ 😴😎✌️
Je k dispozici už nějaké hratelné DEMO v ALFA VERZI ? 😁😁😁
Ne, vůbec na tom nedělám. Abych byl upřímný, vyskytly se jiné výzvy, které jsou pro mne zajímavější. Poslední funkční stav PoP budu chtít pustit na OldComp párty 2020, ale nového není nic. A ještě nějaký čas nebude. Nejprve budu chtít dokončit ty rozdělané drobnosti (Miny, Treasure Island 2nd release) a zvažuji, že si postavím SAPI. Ale PoP neopustím. Jen k návratu k němu potřebuji hnací motor. Myslím, že s příchodem podzimu se situace výrazně zlepší a nejpozději do konce roku by snad měl Prince chodit na základě ovládacích kláves (tím myslím kompletní sestavu těch jeho prostocviků). Ale možná se něco změní. Třeba neseženu rám pro SAPI…
Takže, co máme nového ohledně PoP ?
😉😎✌️
Finišuji s animacemi v intru. Zbývá jich asi 10. Včera jsem se zdržel, protože jsem celé intro předělával na systém průběžného dohrávání z ROM modulu za chodu. Už to jinak nešlo, s ohledem na dostupnou RAM v PMD-85.
Vypuštění kompletního intra se dá očekávat v řádu nižších desítek hodin. Ale bude to takový první pokus, jak by to mohlo vypadat. Protože se na úkor rychlosti přechodu mezi jednotlivými obrazovkami uvolnilo dost paměti, je šance, že by se mohlo volit mezi hudbou na nativním BEEPru nebo na MIF-85. Otázkou ovšem je, jestli tento luxus bude možný i ve hře samotné.
Nakonec jsem zveřejnil aktuální stav intra, protože je na něm ještě práce jako na kostele…
https://www.youtube.com/watch?v=lK-x9by4n6c
… tak jsem to právě ZKOUKNUL a málem mi jako VYPADLI oči z důlků.
Musím říct jako, že dost DOBRÝ ✌️😎😉
Moc rád bych už neco OTESTOVAL.
Tak odyby bylo možno nějaké to HRATELNÉ DEMO,
třeba ?😉
Cca 8 měsíců – bez legrace. Dílčí části nemá smysl testovat. Celé se to skládá z drobných dílků a v nekonečně mnoha iteracích se pilují hrany všeho možného, aby to do sebe zapadlo. Není to sloučení hotových knihoven. Taková je realita.
Hmm, tak to bude teda MASO.
No a dá se udělat něco, co by tento šílený čas URYCHLILO ?
Ano. Kdyby se našel někdo, kdo by řekl, jak a z čeho to poskládat…. A to samozřejmě není možné.
A co oslovit slovenské bratr z RM-TEAMU ?
Možná, že by to pomohlo. Nebo by to mohlo přinést nějaké další nápady, cože ?
ZDAR A SÍLU 😎✌️🤟
Už se dávno stalo. Na Bytefestu 2022 jsme se bavili o možnosti, že by byl Prince of Persia vybaven ovladačem externí zvukové karty MIF-85. A kdo jiný by se toho nejlépe zhostil, když ne autoři…
Protože přišla celá řada dalších nápadů, jak ještě intro vylepšit, doplnit, zrychlit a spojit s jinými částmi hry, tak stále ještě probíhají na intru práce. Jen tak namátkou – průběžné dohrávání dat z ROM modulu během hry se podařilo zrychlit zhruba třikrát vůči původnímu řešení. Nyní se data mohou dohrávat rychlostí 10kB/0,3sec při současné animaci plápolání ohně v pochodních (to je nutné, aby si hráč nevšiml zamrzlého obrazu během nahrávání dat). To představuje v podmínkách PMD-85 natolik dostatečnou rychlost, že to otevírá úplně nové možnosti pro realizaci hry. Ale hra jako taková přijde na řadu odhadem tak za měsíc. Nyní budu chtít v jednom tahu dokončit ty animované mezihry, aby „nevychladl“ animační rukopis při resamplingu postaviček.
OKOK, tak fajn, tak hlavně když je to pěkné podchycený.
Tak kdyby jsi měl pro mě taky nějakou práci na projektu PoP tak se ozvi a dej vědět.
Jinak se do ničeho nebudu plést a prostě POČKÁM až řekneš UŽ 😎💁
Tak jaké jsou aktualní ZPRÁVY k dokončení vývojové fáze PoP ?
No, … žádné. Intro je hotové včetně podpory MIF-85, pracuje se na animovaných „mezihrách“. Celé to jede s podporou MEGAROM modulu s vlastním souborovým systémem. Nějaké demo na fyzickém PMD-85 (bez integrované vlastní hry) by MOHLO být na Foreveru. Ale člověk míní a všichni kolem mění. Dnes tři hodiny uklízení sněhu. Je to příjemná rozcvička, ale spolu s ostatními povinnostmi už nezbyl čas ani chuť na hračky. A tak je to den za dnem… Už několik týdnů.
Možná zajímavost: vývojový tým PoP pro PMD-85 zahrnuje čtyři lidi.
A bude se nějak vývojový tým PoP rozšiřovat ?
Tým se postupně rozšířil podle potřeb jednotlivých složek. Nejprve jsem „outsourcoval“ hudbu pro MIF-85, protože zde jsou povolanější. Následně jsem postoupil grafiku, protože toho je opravdu moc, a já bych to nutně musel udělat tak, abych to vůbec stihl (jinými slovy bych to odbyl). Momentálně nepředpokládám, že by bylo některou ze složek hry postoupit další straně k souběžné tvorbě.
Prozatím vznikají jednotlivé komponenty, které ještě neumí plně interagovat. Ale nějakou základní kostru bych na Forever přivezl. Ale hra nebude funkční, bude tam jen torzo s testem kláves. Nejprve musím rozchodit systém, kterým se volají jednotlivé fáze hry. To je něco, co sice není vidět, ale v MEGAROM modulu už se s nějakou kostrou musí počítat.
Diky za super informace o vývoji a pokroku
ve vývoji hry PoP.✌️😎
Držím PALCE, ke zdárnému běhu a dokončení …
Nějaký pokrok v oblasti PoP nebo tak nějak a podobně ?😉
Vidím, že v poslední době tady byl velký tah na branku s HW se SAPI. ✌️
PoP … tak nějak podobně. Udělalo se celkem dost, ale není to veřejně prezentováno. Ovšem mnohem více toho ještě zbývá. Konzultace produkčního týmu plánuji na letošním Bytefestu (2023).
Už se to nedá VYDRŽET.
asi to pustím …..
ÁÁÁÁCHCHCH, much bether 😎✌️
http://oldcomp.cz/viewtopic.php?f=48&t=8920&p=146941#p146941
JÁ, JÁ, JÁ UŽ DÁVNO SKÁČU ….
http://oldcomp.cz/viewtopic.php?f=48&t=8920&p=146991#p146991
POJĎ MI, HOPA…
ZADAR VOLANIČ
Tak jak to vypadá s PoP ?
Už dlouho nebyli žádné oficiální informace …
Bylo by možno něco dalšího veřejné pustit do světa
z vývoje ?
Ne.
Ale teď vážně. To málo času, co mi teď zbývá, věnuji na dokončení menších rozjetých věcí. Ale snad za měsíc, dva….
Tak tu máme o 3 měsíce později a logicky se tedy ptám, co máme nového ?
A NIC nebo NE neberu jako odpověď, rozmysli s to dobře “ Romane “ ? 😉😎
Ale něco jo, ale jsou to takové podprahové úpravy. To chce čas.
Kdy asi tak se začne testovat hra ?
No, …
Pořád je práce jako na kostele na dalších projektech. Ono v zásadě nechybí moc, jen ta vidina toho komplexního molochu způsobuje, že si Prince of Persia nechávám jako takovou třešničku na dortu. Jako stěžejní dílo předtím, než ohluchnu, oslepnu a definitivně vypnu počítač. Ale blíží se to.
A jak to tak bývá, zase mě někdo ukecal na další projekt, který po dvou týdnech končí a brzy bude zveřejněn.