Budeš to samplovat pak přímo na Amize?

Zatím to vypadá na Scorpion Engine. Tím bych se mohl soustředit hlavně na grafiku a zvuk. Bude záležet co umožní v herní mechanice, jelikož tam chci i maličké stroje, které si hráč bude moci postavit na vyrábění.
Hledám posledních pár dnů zvuky na 2 nových přístrojích, které pak zkusím přenést na Amigu, ale těžko říct co z těch jednotlivých nástrojů zbyde. Tohle bude výběr pro temnou část lesa, hrál jsem to vše najednou za letu a přehazoval nástroje za pochodu:

Tapeta tam již byla z doby, kdy tam byli únikové hry.

Tu krabičku jsem dostal před pár lety na praseti. Zatím jsem to nikde neviděl

Pěkný doupě... malba na zdi se mi taky líbí.

Je to standardně silnější než já a tak se musím zeptat, jestli se ještě dá sehnat ta falešná nálepka Amiga MIDI... 🙂

Doufám že to doděláš. Hlavní hrdina je perfektní. Vždycky když je ve hře na výběr rasa, beru si trpaslíky. Jsou prostě nejlepší.
A ta místnost je úžasná. Jak výbavou, tak těmi obrázky na zdi. To jsi znárodnil i s nimi, nebo jsi je tam maloval?

Něco se zas začíná dít. Znárodnil jsem místnost ve sklepě a tam je teď doslova vyvojové studio

Asi budeš používat nějakou standardní hudební rutinu, kdyby si s tím měl problém, můžu poskytnout tu mou. Má omezení po hudební stránce (třeba zatím k dispozici 1 nastavitelný druh vibrata), některé věci se musí více přizpůsobit. Ale zas můžu zkusit poradit v rámci mých možností, když už jsem ji vymyslel. Rutina je v assembleru, nesystémově naprogramovaná. Ještě se chci pokusit namyslet mechanizmus, který bude spouštět jednotlivé skladby v jednotlivých lokacích. Musí se ještě naprogramovat převodník z MODu na můj specifický formát, kterým má rutina hraje, aby se pak hudby skládali v klasickém trackeru pak převedli a doladili pro mou rutinu . Má rutina nemá propočet, kdy se má zvuk samplu ztlumit, to by ale právě měl mít převodník na můj formát a do mého formátu již jen zadat výsledek, aby se tím nezatěžovala samotná rutina při hraní skladby ve hře. Defor zde jednou ten výpočet uváděl. Já se taky pokusím nějaký převodník udělat, ale Ty si určitě šikovnější a rychlejší. Samozřejmě vše je jen návrh, klidně použij jiné hotové řešení, co hraje přímo MODy. Já jen, kdyby se ti to šiklo 🙂

Dualplayfield na AGA zvládá právě těch 15+15 barev. Další paralaxy už budou muset být nějakou "fintou". Třeba sprajty nebo nějakými předpočítanými animačními fázemi. To už záleží na situaci, fantazii a odvaze programátora
Blitz neznám, takže tady jsem ryba na suchu. Do toho raději pindat nebudu. Pokud bys potřeboval nějakou informaci na úrovni assembleru nebo řízení custom čipů, tak bych snad mohl byl nápomocný.
Ten trik s copperem a více barvami je o tom, že na daném řádku (úplně přesně řečeno se do určité míry dá definovat i horizontální pozice) je možno změnit postupně paletu barev. Tedy ano - od určitého řádku by se obraz kreslil jinou barvou. Určitě se tím dá dosáhnout barevné pestrosti, ale je třeba být opatrný a pečlivý při návrhu (aby se neměnily barvy vertikálně se pohybujících objektů). Nevím, jak se takové věci (copper-list) dělá v Blitz. V assembleru je to triviální záležitost.

Určitě to bude celé v AmiBlitz 3, AGA, tile scrolling do boku i šikmo a CPU tak 68030. Zvažoval jsem, zda použít dual playfield, protože bych rád měl 3 paralaxy. S tím, že ta třetí by byla animovaná v malých průhledech mezi stromy, takže by byla falešná . Dále bych chtěl zkusít více jak 15+15 barev. prý to jde pomocí copperu, ale zatím jsem to moc nepochopil jak na to. V podstatě to chápu tak, že když bude paprsek na místě kde chci, tak bych měl být schopen změnit na barvu která není v těch 15+15 a mít tam tak mnohem více barev, než je možné. Pokud by to ale znamenalo použít inline assembler, tak se obávám, že umřu na složitost

Ta cesta používat FAST ram je zajímavá, ale Blitz basic na to příkazy nemá a dělat se s rutinama, je pro mě na budku.

Pár dobře míněných rad. Ale klidně je v pohodě ignoruj, protože jsem na Amize žádnou hru nedodělal.
Nejdřív si ujasni, v čem budeš hru programovat. Grafika se dá nakreslit v ledačem, a klidně i na PC - důležitý je výsledek (jasně jasně i cesta může být cíl - chápu).
Pokud to bude nějaký vyšší programovací jazyk nebo celé prostředí (engine?), tak je třeba získat představu, jak bývá výsledný kód rychlý, co to dokáže, v čem je silný a kde jsou naopak jeho slabiny.
Ujasni si, pro jakou minimální konfiguraci to celé bude. OCS + 68000 + 512/512 RAM? A nebo AGA? A nebo AGA s hodně FAST RAM a lepším CPU? Nebo RTG?
Protože od toho se odvíjí v podstatě vše další.
Pokud OCS, tak máš max 32 barev. Ale pokud budeš chtít paralax, tak spíš jen 7 a 7 ve dvou playfieldech. Plus máš max osm sprajtů o šířce max 16 pixelů a třech barvách (nebo 4 sprajty s 15 barvami). To je dobré vědět, protože ty se můžou hodit pro nějaký další (ale jednoduchý) paralax (opakující se vzorek, stromy, kopce, mraky, ...).
Pokud to má být AGA, tak jsi na tom o něco líp. Například dva playfieldy mají hned každý 15 barev. Celkově máš k dispozici až osm bitplánů, takže se můžeš víc rozšoupnout a použít různé kombinace (např. 4 + 2 + 2). Problém ale pak bude s hardwareovým skrolováním. Sprajtů budeš mít sice stejný počet (i barevnost), ale jejich šířka může být až 64 pixelů. A to je dost k tomu, aby se daly využít jako další paralax pozadí. Pokud použiješ méně bitplánů (třeba jen těch pět), tak se ti hodně uvolní sběrnice do chip RAM, takže se k ní lépe dostane CPU (nebo Blitter, pokud neplánuješ rychlejší CPU). Na OCS (a navíc bez FAST) je 5 a více bitplanů spolehlivý zabiják výkonu a s tím je třeba počítat.
Je dobré si hru nejdřív víc naplánovat. Nekreslit hned postavičky a stromky. Spíše si nejdřive udělat rozvrh, jaké levely v ní budou. Co mají zobrazovat, jaké to bude prostředí. A nejdřív nakreslit jejich "tiles" (pokud bude hra založená na nich). Prostředí je nejdůležitější, protože musí být pro hráče přehledné a informativní.
Je třeba maximálně šetřit barvami. Vhodně si naplánovat paletu barev. Až pak podle ní (a případně ji modifikovat) kreslit postavy. Podle prostředí pak vyplyne i jejich velikost a detailnost. Pozadí (kopce v dálce, mraky apod.) se dodělává až podle toho, jaké barvy zbydou. S detaily šetřit, protože se to pak blbě animuje (a v pohybu se detaily stejně ztratí). Animace dělá strašně moc. Kvalitní hry z té doby mají často spíše víc políček animací než barevnější a detailnější postavičky.
Kolize se obvykle počítají pomocí bounding-boxů. Je možno využít i překryvu kolizních masek (Amiga to přímo podporuje hardwerově), ale v praxi to asi znamená spíše víc starostí než užitku.
Samozřejmě na všechno se můžeš vykašlat, pokud si stanovíš, že to celé má jet jen na AGA + 060 s bambilionem FAST RAM (a když to i tam bude pomalé, tak je tu vždy WinUAE ). Všechno se bude kreslit v chunky formátu do fast-RAM, c2p to pak na konci frejmu zkonvertuje do chip-RAM a nějaké optimalizace a velké plánování můžeš mít na háku.

Od září jsem začal znovu pokračovat na vývoji. Musel jsem si zopakovat naprosto vše. Tyhle věci se umí ztratit z hlavy jak pára nad hrncem. Takže teď jsem doinstaloval WB 3.1.4 opravil bug v Personal Paint 7.3v, kdy nejde kreslit jedním pixelem pomocí utility FBlit, která používa na rendering FAST ram (docela fuška, zjistit že tohle je potřeba )

Zvažuji jestli zběžně napsat o čem hra bude nebo zda je lepší to tajit? Co vy na to?

O: "Lost Forest", aneb hra kterou chystám

No já nevím, Red Pill (stejně jako backbone) má obrovské nároky a malý výkon. Určitě nejlepší je naprogramovat to přímo v jazyce. Podívej na tohle:





Aby se to vůbec hýbalo, potřebuje to minimálně 68020 a 8MB Fast!

O: "Lost Forest", aneb hra kterou chystám

Dám na tvou radu a půjdu touhle cestou. Wayne, mi říkal o enginu Red pills, tak zkusím jít paralelně i touhle cestou

O: "Lost Forest", aneb hra kterou chystám

Cyberiane, nechci ti do toho úplně moc kecat, ale příjde mi že na to jdeš od opačného konce. Pipláš se s grafikou, postavičkami, detaily a stínováním, ale nejdůležitější je scénář a engine. Většinou se to dělá tak, že se vytvoří engine, odladí, použije se v něm jen ta nejjednodušší grafika a animace typu rotující trojúhelník a teprve když všechno funguje, navěsí se na engine sprity, grafika, zvuky a hudba. Takhle Ti reálně hrozí, že ztratíš rok kreslením krásné grafiky a nakonec zjistíš, že jí nemáš čím pohánět. Docela často se to stává lidem, kteří si celou hru tvoří sami.