Enterprise Forever

:HUN => Programozás => Topic started by: Z80System on 2013.November.05. 21:19:40

Title: game00
Post by: Z80System on 2013.November.05. 21:19:40
Game00, avagy a galaga valaga.

Ez lesz az első (reméljük nem tart ki míg élek) készülő játékdemóm topikja. Azért kell ez, hogy a game00 specifikus kérdések itt legyenek tárgyalva, és az általános assembly és zeneprogramozás és satöbbi topikokba csak az általános kérdéseket írjam, minnél kevesebb legyen ott a game00 -ás off.
Title: Re: game00
Post by: Z80System on 2013.November.05. 21:31:32
Amiért pedig épp most indul, nem pedig máskor, az az, hogy feltegyek egy kezdő snapshot -ot, és kérném rá a legszubjektívabb véleményeket is.

Tehát pld. ilyeneket, hogy: "Nem olyan rossz ez, adjunk neki még egy kis esélyt", vagy "Hát ennél hatszor jobb lenne, ha beírnánk a 0xbx -re hogy tizennyóc", vagy "Hát ha ennyit lehet kihozni a 4K digiből, akkor vizesnyócas", meg ilyesmik. Vessük össze mindennel. Mint azt tapasztaltuk, az EP (-n elérhető) szoftverek nagy részét ugyan láttam, de emlékeim már igen homályosak.

Én pld. megnéztem pár játékot, pl. cauldron, sorcery (ajtónyitás!), exolon, miegymás és igazából nem lettem meggyőzve a digi mellett ...

(Ezt a snapshot dolgot még nem csináltam, kell valamire figyelni? Lehetnek benne olyan image hivatkozások, amik nyilván csak nálam lesznek, de abban reménykedek, hogy attól meg menni fog a dialógusok után a dolog.)

Szóval ez most nem csinál mást egyenlőre, mint hangokat játszik le. Szerintetek is sovány ?
Title: Re: game00
Post by: Zozosoft on 2013.November.05. 21:34:59
Szerintem tök poén hangok vannak benne.
Title: Re: game00
Post by: Z80System on 2013.November.05. 21:40:19
Quote
Szerintem tök poén hangok vannak benne.
Melyeket azonban egykönnyen lehetne szintetizálni jobb minőségben vajon ?

Vagy pedig ilyen hangzásokat nem volna valami könnyű előállítani Dave -vel ?
Title: Re: game00
Post by: endi on 2013.November.05. 21:53:08
Nekem is tetszenek a hangok. Ha más nem, egyedi mindenképpen lesz az EP programok között, és ez sokat számít nálam.

Amit viszont már írtam: nagyon sokat számít, hogy milyen hangokat használsz ilyen frekin. Kategóriákkal jobb lehet, ha megfelelőeket választasz ki, amik jobban ezen a frekin.
Szerintem szedj le a freesound.org-ról egy csomó hangot, rakd át EP-re és válaszd ki a jókat.

Amúgy lehetne mondjuk a zene chip, az effektek meg digi. Keresel valami kis proci igényű lejátszót, amihez van jó zene is, és kész.
Title: Re: game00
Post by: szipucsu on 2013.November.05. 21:55:13
Játék közben teljesen jó hangok lennének ezek. Még így elhallgatva sem rossz.
Title: Re: game00
Post by: Zozosoft on 2013.November.05. 22:20:40
Quote from: Z80System
Ezt a snapshot dolgot még nem csináltam, kell valamire figyelni?
Jelen esetben mindegy, ha majd olyan állapotban lesz, hogy töltene további fájlokat lemezről, akkor kell úgy csinálni, hogy Ramdiskben legyen a program, vagy mellékelni kell a disk image-t is.
Title: Re: game00
Post by: Zozosoft on 2013.November.05. 22:26:55
Quote from: Z80System
Vagy pedig ilyen hangzásokat nem volna valami könnyű előállítani Dave -vel ?
Ez kérdés engem is érdekelne, valami olyasmire vágynék, ami megmondaná egy WAV-ról, hogy ez mondjuk 568Hz-es hang 230ms-ig, majd 450ms alatt 2345Hz-re emelkedik, stb. Hasonlóan a hangerővel is.
Ezt utána már le lehetne programozni DAVE-re.
Title: Re: game00
Post by: endi on 2013.November.05. 23:27:23
Quote from: Zozosoft
Ez kérdés engem is érdekelne, valami olyasmire vágynék, ami megmondaná egy WAV-ról, hogy ez mondjuk 568Hz-es hang 230ms-ig, majd 450ms alatt 2345Hz-re emelkedik, stb. Hasonlóan a hangerővel is.
Ezt utána már le lehetne programozni DAVE-re.
ilyesmiről már beszélgettünk itt régebben
sőt találtam valami olyan programot is, ami x csatornás 4szögjelekre (frekik) bont egy wavot, és visszajátsza
de már nem emlékszem milyen topikban is volt
Title: Re: game00
Post by: Z80System on 2013.November.05. 23:31:35
Quote
sőt találtam valami olyan programot is, ami x csatornás 4szögjelekre (frekik) bont egy wavot, és visszajátsza
És ki is próbáltad, és működött is ?

Milyen komplex hangokra, hány csatornára ?

Beszédhangot is le lehet írni 2 csatornával ?
Title: Re: game00
Post by: endi on 2013.November.06. 00:20:36
Quote from: Z80System
És ki is próbáltad, és működött is ?

Milyen komplex hangokra, hány csatornára ?

Beszédhangot is le lehet írni 2 csatornával ?
nem, úgy emlékszem nem letölthető program volt, csak az eredményét lehetett meghallgatni
de lehet hogy csak lusta voltam kipróbálni
2 csatorna? neeeeem, pl egy beszédet 32 csatornára bontva kaptunk egy olyan beszédet aminél sejthető volt egy kicsit hogy mit is mond :)

de ott abban a beszélgetésben vetettem fel hogy az EP hang tudására kéne egy programot csinálnunk, olyat, mint ami grafikai szinten már létezik, az a tök jó konverterünk. nem csak frekikre meg hangerőkre bontana, hanem figyelembe venné a torzítási stb lehetőségeket is
de valszeg ezzel is inkább érdekes mint jó hangokat lehetne csinálni, és értelemszerűen nem beszédet, nem digi szintű hangot

na annyit írok, hogy már visszakereshettem volna
Title: Re: game00
Post by: endi on 2013.November.06. 00:23:49
na meg is van, innentől
http://enterpriseforever.com/sound/hanglejatszo-fejlesztese/msg20142/#msg20142

pár hozzászólás után ott a link a programra, ami java-s, úgyhogy nem tudom megnézni már
Title: Re: game00
Post by: endi on 2013.November.06. 00:29:12
hát ez nagyon vicces, mert ugyanabban a topikban a végén újra leírtam ugyanazt az ötletet
szóval most már én 2x, ti 1x írtátok le

ez évente elő fog jönni, mire 70 évesek leszünk, minden ötletet százszor leírunk :D

itt van:
http://enterpriseforever.com/sound/hanglejatszo-fejlesztese/msg25947/#msg25947
Title: Re: game00
Post by: endi on 2013.November.06. 00:35:47
esetleg ha ep-n akarsz hangokkal szórakozni, figyelmedbe ajánlanám szerény kis hangeditoromat :)

http://ep128.hu/Ep_Util/Sample_Editor.htm
Title: Re: game00
Post by: Z80System on 2013.November.06. 01:02:06
Na itt van egy olyan verzió, ahol nem egyben szólnak a hangok, mert úgy nem lehetett rendesen megfigyelni őket, a rövidek nem is hallatszottak.

Ebben van 9 darab 4KHz hang, ami gyakorlatilag egy teljes szegmenst elfoglal.

Az ABC betűire szólalnak meg, simán nyomva csak egyszer, shift -et is használva pedig loop -olva.

Én továbbra sem vagyok meggyőzve. Az tetszik hogy komondorosan mélyek a tónusok, "dögös" hangzása van, nem ciripelős fajta.

Viszont sokat esznek ramban és prociban is eléggé.

Szóval nem tudom ez a megfelelő ár/teljesítmény arány -e.
Title: Re: game00
Post by: IstvanV on 2013.November.06. 09:30:49
Quote from: Z80System
Viszont sokat esznek ramban és prociban is eléggé.
Ez ugyan csak 1% CPU időt takarítana meg, de a megszakítás kezelő rutint át lehetne másolni 0038h címre, és akkor megtakarítható lenne egy JP utasítás (10 ciklus / 0.00025 s).
Title: Re: game00
Post by: Z80System on 2013.November.06. 12:36:43
Hmmm ... azt továbbra sem tudom, hogy Dave -vel lehetne -e ilyen hangokat csinálni vagy sem,

de végülis így gombokat nyomogatva EP játéban gondolkodva abszolútértékben talán tényleg nem rosszak,

csak az ember ne akarja összehasonlítani az eredeti hanggal őket ...

Szóval én az eredetit választottam, azt hoztam át, azt akartam hallani, és persze nem azt hallom.

De azért nem olyan rosszak ezek ... már technikailag, nem a konkrét hangokra gondolok.
Title: Re: game00
Post by: Z80System on 2013.November.06. 12:47:27
Viszont azon gondolkodok, hogy lehet hogy tovább kéne rontani a minőséget. Ha 2KHz -en is lehetne (például az endi sample válogatós módszerével, és utána azokból annak kitalálásával, hogy vajon miért pont azok a hangok lettek jobbak, amik jobbak lettek) valami értelmes hangokat találni, akkor az ugye felezné a memóriaigényt, és ráadásul a CPU igényt is, ami úgy visszamenne 10% körülire, ami már a majdnem elfogadható szint lenne.

Ez esetben akár vissza is lehetne csempészni a két lapozó utasítást, és akkor lenne egy önálló cache szegmense a hangoknak, amelyen egyszerre kb. 20 hang is elhelyezhető lenne.

Az már úgy sztm. elég változatos hangokat eredményezhetne.
Title: Re: game00
Post by: endi on 2013.November.06. 12:58:48
Van pl egy robbanásod ami főleg mély és főleg magas frekiket tartalmaz. Ez nem lesz jó alacsony frekin, mert a magas és mély hang is igényli a magas frekit (persze hangtól is függ).
Ilyenkor a robbanás eredetijét egy hangeditorban át kell alakítani EQ-val. Fel kell húzni a középmagas hangokat és lehúzni a mély és magasakat. Ezután konvertálni.
Persze jobb eleve olyan robbanást keresni ami inkább középmagas frekiket tartalmaz. De még ezt is érdemes meggyúrni editorban.
EQ-n kívül van más effekt is ami ilyet csinál, most nem jut eszembe a neve.
Title: Re: game00
Post by: Z80System on 2013.November.06. 13:05:58
De azt hiszem, inkább nem is filózok tovább, hanem inkább haladok a lényeggel, végülis azt már kipróbáltnak lehet venni, hogy felfele nem fogok mozdulni, vagy 4KHz hang lesz, vagy pedig ennél kisebb.

Elkezdem így 4KHz hang mellett beletenni a funkciókat, és akkor majd ahogy azok viszik az időt meg a memóriát, majd vagy visszakényszerítenek kisebb frekik fele, vagy megmaradunk itt, esetleg kevesebb egyszerre cache -elt hanggal, szélsőséges esetben összesen kettővel, 1 lövés hang + 1 robbanás hang. Vagy jobbik legrosszabb esetben az előző kettő mellé kerül ellenségenként +1 ellenség lövés és +1 ellenség robbanás. És ha még ennél is kevésbé legrosszabb, akkor lehetne egy főhős sérülés és egy ellenségenkénti sérülés hang.

Vagyis 3 állandó és három ellenségenként másolt hang, azaz 6 kéne legyen cache -elve egy kényelmes minimumnál, azt meg össze tudnám hozni akár most is, ha a jelenlegi 3 -as lapomon a videó memóriám után lévő kb. 8K helyet erre áldoznám, és abba a mindenkori 6 hangot belepaszíroznám.

Ez esetben persze az érdekesebb, majd egy másodperces, 3K hosszú mintáknak, amikből vannak az előbbi teszt verziókban, azoknak fuccs lenne ...
Title: Re: game00
Post by: Z80System on 2013.November.06. 13:07:37
Quote
Ez nem lesz jó alacsony frekin, mert a magas és mély hang is igényli a magas frekit
Hmmm ... ez vajon miért lehet ? Az ember azt gondolná, hogy ha az ember kis frekire konvertál, az egy aluláteresztő szűrő, vagyis mély hangok megmaradnak, magasak meg magasságuk arányában pusztulnak kifele ... Miért igényelné a mély hang mégis a nagyfrekit ?
Title: Re: game00
Post by: endi on 2013.November.06. 13:17:48
Quote from: Z80System
Hmmm ... ez vajon miért lehet ? Az ember azt gondolná, hogy ha az ember kis frekire konvertál, az egy aluláteresztő szűrő, vagyis mély hangok megmaradnak, magasak meg magasságuk arányában pusztulnak kifele ... Miért igényelné a mély hang mégis a nagyfrekit ?
hát egy mély 4szögjel nem igényli pl
:)
de egy mély színusz kis mintavételezéssel elég gáz lesz
Title: Re: game00
Post by: endi on 2013.November.06. 13:20:32
amúgy itt egy online effekt generátor, ami azért lehet jó mert szintetizált egyszerű hangokat jobban lehet kis frekin lejátszani

a randomize gombot ajánlom figyelmedbe :)

http://www.bfxr.net/
Title: Re: game00
Post by: Z80System on 2013.November.06. 13:25:49
Quote
amúgy itt egy online effekt generátor, ami azért lehet jó mert szintetizált egyszerű hangokat jobban lehet kis frekin lejátszani

a randomize gombot ajánlom figyelmedbe (http://enterpriseforever.com/Smileys/phpbb/smiley.gif)

Megnézem, ha visszajöttem, de mi értelme van digivel játszani le egyszerű szintetizált hangmintákat ? Akkor egyszerűen szintetizálni kell őket a Dave -vel. Nem ?
Title: Re: game00
Post by: endi on 2013.November.06. 13:27:20
Quote from: Z80System
Megnézem, ha visszajöttem, de mi értelme van digivel játszani le egyszerű szintetizált hangmintákat ? Akkor egyszerűen szintetizálni kell őket a Dave -vel. Nem ?
hát ha van cpu időd rá...
Title: Re: game00
Post by: Z80System on 2013.November.06. 13:44:43
Quote
a randomize gombot ajánlom figyelmedbe (http://enterpriseforever.com/Smileys/phpbb/smiley.gif)

http://www.bfxr.net/ (http://www.bfxr.net/)
(http://www.bfxr.net/)
Hát appám, ezek között azért pikkpakk akadnak baromira meggyőzőek !

Oké többnyire a magashangos cicergős jött (nem szórakoztam sokat), de azért a 20 próbálkozásból pár nagyon frankót is bevágott a random !

Biztos hogy ezek a hangok sima ügyek a Dave -nek ? Mert ha igen, akkor eléggé Dave rúlz ...

Pld. vegyük az attach -ban lévő hangot (az oldalon simán be lehet tölteni), ezt szerinted a Dave így simán tudná ?
Title: Re: game00
Post by: endi on 2013.November.06. 13:47:01
félreértetted
ezeket digizve tudod használni
Title: Re: game00
Post by: szipucsu on 2013.November.06. 14:25:43
Quote from: Z80System
Miért igényelné a mély hang mégis a nagyfrekit ?
Szerintem azért, mert a mély hangoknak több a hallható felhangja mint a magas hangoknak. Ha kiírtjuk a felhangokat (a magas hangokat), a mély hang kevésbé lesz telt már.
Title: Re: game00
Post by: geco on 2013.November.06. 14:36:45
Szerintem hasonló hangokat Dave-vel is le lehetne szépen játszani 50Hz-es lejátszóval, csak ugye a progi nem Dave regiszterekre konvertál :lol: , ha az 50 Hz kevés lenne, akkor fel lehetne menni 300Hz-es megszakításban lejátszásra, tuti kevesebb időt enne a frekvencia, és a volume érték kiírása, mint a 4 KHz-es digi.
Title: Re: game00
Post by: endi on 2013.November.06. 15:23:10
Quote from: geco
Szerintem hasonló hangokat Dave-vel is le lehetne szépen játszani 50Hz-es lejátszóval, csak ugye a progi nem Dave regiszterekre konvertál :lol: , ha az 50 Hz kevés lenne, akkor fel lehetne menni 300Hz-es megszakításban lejátszásra, tuti kevesebb időt enne a frekvencia, és a volume érték kiírása, mint a 4 KHz-es digi.
amúgy igen. sokkal többet ki lehet hozni a daveből mint amit az exos hangrendszer mutat, úgy értem még 50Hz-n is. pl ha lenne envelope a torzításokhoz... egy jó editor amiben nagyon könnyen lehet dolgozni stb...
Title: Re: game00
Post by: Z80System on 2013.November.06. 20:49:47
Quote
félreértetted
ezeket digizve tudod használni
Lehet, hogy félreértettem, és lehet hogy nem voltál eléggé precíz, de azt hiszem ez lesz az igazság, hogy "ezeket csak digizve tudom használni".

És ezért nagyon is nem véletlen és nem elhanyagolható, hogy digi hanggal akartam próbálkozni, és hogy a Dave -ben nem bíztam.

Aki pedig azt mondta, hogy szerinte ilyeneket lehetne Dave -vel is, azzal most vitázni kezdenék. Persze nagyon örülnék, ha kiderülne, hogy tévedek, úgyhogy jó volna, ha valami hozzáértő ránézne.

Szóval azért gondolom, hogy nem menne ez Dave -vel, mert a Dave ugye csak négyszögjeleket tud. Namost ha betöltitek a weboldalra azt a korábban az attachment -ben megadott hangot, akkor azt fogjátok látni, hogy annak a szerintem jó hangzású effektnek a hullámformája "whistle" (legyen is az akármi). Namost ha átrakom "sin" -re (amivel tudtommal a komondorok is operálnak), akkor egy még mélyebb és nekem még jobban tetsző effektet kapunk eredményül. Nade ha áttesszük "square" -re, akkor meg egy olyan magasabb, szárazabb, keményebb hangzású (EP -s hangzású ... :() effekt lesz az eredmény ...

Ebből két dolog tűnik számomra megállapíthatónak:

1, Eddig mikor azt hallottam, hogy az milyen fontos, hogy a szintetikus hang hullámformája mi, azt nem tudtam elképzelni, hogy ennyire fontos ...

2, Akkor úgy tűnik, hogy nekem tetsző effektet az EP -nek esélye nincsen kelteni ... vagy a szitu nem ilyen 1Xu ? Jó lenne ha valami okos megszakértené ezt a kérdést ...

A hangot és a weboldalt megint ideteszem, hogy ne kelljen visszakeresni őket:

http://www.bfxr.net/ (http://www.bfxr.net/)
Title: Re: game00
Post by: Z80System on 2013.November.06. 21:18:09
Minthogyha a négyszögjel hang a színuszhanghoz képest olyan lenne, mintha teleraknánk a hangot egy csomó random hibával ...

Valószínűleg minnél nagyobb a frekvencia, a különbség a két jelforma között annál kevésbé lesz fontos a fül számára,

de minnél alacsonyabb (mélyebb hangok és tónusok) annál inkább a négyszögjel valami atombugos valaminek tűnik a színuszhoz képest ...

És valószínűnek tartom (ez is csak érzés, nincs semmi ráció mögötte) hogy ez globális ... tehát nem fogunk találni olyan hangot, vagy effektet, amire igaz lenne, hogy na, itt most jobb a négyszögjel mint a színusz ... a valóságban valószínűleg egy "négyszögjelhangon kívül" minden másra jobb a színusz, mint a négyszögjel ...
Title: Re: game00
Post by: endi on 2013.November.06. 21:27:44
Quote from: Z80System
És valószínűnek tartom (ez is csak érzés, nincs semmi ráció mögötte) hogy ez globális ... tehát nem fogunk találni olyan hangot, vagy effektet, amire igaz lenne, hogy na, itt most jobb a négyszögjel mint a színusz ... a valóságban valószínűleg egy "négyszögjelhangon kívül" minden másra jobb a színusz, mint a négyszögjel ...
Effektre ilyet nem lehet kijelenteni. De zenei hangra mondhatni "epic fail" a négyszögjel. :) De hát ennek is ügye költségcsökkentés oka volt...
Title: Re: game00
Post by: Z80System on 2013.November.06. 21:33:24
Quote
Effektre ilyet nem lehet kijelenteni.
Akkor dobje be egy effektet, amiben szerinted jobb a négyszög, mint más. (Kivévé hogy direkt egy rekedt medvén áthajtó traktor hangját akarod szimulálni direkt széjjeltorzítva.)

Igazából mostanáig vacakoltam a különböző típusú effektekkel, és mindegyiknél a nekem legjobban tetsző a színusz, és mindegyik hullámforma jobb gyakorlatilag mint a négyszög ... egyedül a "tan" ami pont ugyanolyan rossz sztm. ...
Title: Re: game00
Post by: Zozosoft on 2013.November.06. 21:39:22
De jó, hogy én botfülű vagyok :oops:
Title: Re: game00
Post by: Z80System on 2013.November.06. 21:45:28
Quote
De jó, hogy én botfülű vagyok (http://enterpriseforever.com/Smileys/phpbb/ds_icon_redface.gif)

De ennyire ? Tényleg nem hallod az óriási különbséget a színusz és a négyszög között ?
Title: Re: game00
Post by: Z80System on 2013.November.06. 21:47:29
Mindenesetre maga a generátor program nagyon jó ... Így lehet hangokat kikísérletezni, többé kevésbé intuitív módon ...

Azt hiányolom belőle csak, hogy beállíthassam a kimeneti wav frekijét ...
Title: Re: game00
Post by: Zozosoft on 2013.November.06. 22:10:01
Quote from: Z80System
De ennyire ? Tényleg nem hallod az óriási különbséget a színusz és a négyszög között ?
Óriásit nem, csak valami aprót, és nem tudnám azt mondani, hogy az egyik vagy másik sokkal jobb.
Title: Re: game00
Post by: Z80System on 2013.November.06. 22:29:35
Hopp, és most lehet azt is megtaláltam a gyakorlatban, amit IstvanV magyarázott a low-pass filterekről. (Azt az angol nyelvű filmet mire megértem, addigra sok víz lefolyik a Dunán ...)

Töltsétek be az attachment -ből a hangot, es nyomkodjátok a "sin" és "square" gombokat.
Azt fogjátok hallani, hogy az effekt mindkét hullámformával körülbelül ugyanazt az élményt nyújtja. Az én fülemnek legalábbis.

Ezt úgy értem el, hogy a "low pass filter cutoff" -ot lehúztam oda, ahol van. Ha felhúzzátok a jobb szélére a potinak, akkor hallani fogjátok, hogy míg a színusz ugyanolyan jó maradt addig a négyszögben megjelentek azok a zavaró "random pattogó zajok", amik a kemény hangzását adják a négyszöges verziónak ...

Tehát ebből valami olyasmire következtetnék, hogy ilyen low pass filterekkel lehet négyszögjel is a hullámforma, olyan lesz, mintha színusz lenne.

De akkor miért hagyták ki az EP -ből ?
Title: Re: game00
Post by: lgb on 2013.November.06. 22:36:42
Quote from: Z80System
Minthogyha a négyszögjel hang a színuszhanghoz képest olyan lenne, mintha teleraknánk a hangot egy csomó random hibával ...

Ugye ismerjuk a Fourier tetelt, ami azt mondja ki (na jo, regen tanultam, szoval csak kb - hiaba szigorlatoztam is belole ...), hogy barmilyen periodikus jel leirhato szinuszos es koszinuszos (tehat jellegeben szinuszos) jelek osszegekent. Azaz, ha fogsz egy negyszogjelet, es lenne olyan analog szurod pl, ami igen elesen kepes egyetlen frekvenciat atereszteni a tobbit meg semennyire nem, akkor egy szinuszos jellegu jel jonni ki belole, avagy, a negyszogjel tulajdonkeppen bazi sok (idealis esetben vegtelen szamu) szinuszos jelbol all ossze (http://cnx.org/content/m0041/latest/). Amugy egyes hangtomoritesi (veszteseges) algoritmusok is abbol indulnak ki, hogy pl FFT-t (Fast Fourier Transformation) hajtanak vegre, es "eldobjak" az emberi fulnek legkevesbe hianyzo komponenseket, ami ugyan nyilvan torzitast okoz, viszont kevesebb infot kell tarolni. Ha mar itt tartunk, periodikusan ismetlodo jel pl egy hosszan ejtett maganhangzo is, ezzel kiserleteztek is anno, hogy emberi hangot hogy lehet eloallidani olyan modon, hogy X db szinuszos jellegu jelet osszekeverunk, azaz nem digit allitunk elo vagy jatszunk le! (AdLib-nal is probaltak ezt imho, amikor az FM operatorokat kulon vezerlik az OPL chip-en vagy mi is volt).

Ha egy negyszogjel utjaba teszunk egy alulatereszto szurot, azzal kiszurjuk a nagyobb frekvenciaval megaldott komponenseket, igy nemikepp lasabb felfutasu jel lesz, es "legombojitett" (na meg kisse hullamzo itt-ott), ezert nyilvan ennek a hangzasa is mas.

Az mas kerdes, hogy digitalis aramkorokkel viszont pont negyszogjelet a legegyszerubb generalni, mert ugye kikapcs, bekapcs, stb :) Itt segitene amugy nagyon egy programozhato analog szuro szeruseg ami a kimenetre kapcsolhato, es igy programbol allithato, de sajnos Dave-ben ilyen nincs.
Title: Re: game00
Post by: Z80System on 2013.November.06. 22:41:07
Előbbire itt van +1 példa. Mindkét fajta hullámmal ugyanazt adja kb., de ha felhúzzátok a "low pass filter cutoff" -ot a jobb szélére, akkor csúnyán előjönnek a "négyszögjel hibák". Mintha direkt recsegtetés (zizegtetés) lenne építve a négyszögjelbe.
Title: Re: game00
Post by: Z80System on 2013.November.06. 22:44:50
Ok, és akkor az EP -ben semilyen szűrő nincs ? Tiszta négyszögjel és kész ?

Nem lehet, hogy valami "torzítóval" vagy akármilyen más funkcióval el lehet érni, hogy ne keletkezzenek azok a felharmónikusok, amik ezeket a zizegő pattogó hangokat adják ? Lehet, hogy símán tudnánk "normális" hangot kelteni a Dave -vel, csak nem tudjuk milyen funkciók rákeverésével kell csinálni ? Vagy ezen már túl vagyunk, és hanghoz értők sem tudják, hogy lehetne ilyet csinálni ?
Title: Re: game00
Post by: endi on 2013.November.06. 22:56:32
Quote from: Z80System
Ok, és akkor az EP -ben semilyen szűrő nincs ? Tiszta négyszögjel és kész ?

Nem lehet, hogy valami "torzítóval" vagy akármilyen más funkcióval el lehet érni, hogy ne keletkezzenek azok a felharmónikusok, amik ezeket a zizegő pattogó hangokat adják ? Lehet, hogy símán tudnánk "normális" hangot kelteni a Dave -vel, csak nem tudjuk milyen funkciók rákeverésével kell csinálni ? Vagy ezen már túl vagyunk, és hanghoz értők sem tudják, hogy lehetne ilyet csinálni ?
sajnos semmi ilyesmit nem tud az EP
gyakorlatilag semmi komolyabbat nem lehet kihozni belőle sajnos
ugyanez vonatkozik a specy128-ra is
sajnos ez volt legolcsóbb.. :)
Title: Re: game00
Post by: szipucsu on 2013.November.06. 23:31:52
Azért azt nem lehet mondani, hogy a szinuszjel a király, a négyszögjel meg semmi. Mindegyiknek van valami színezete, ami miatt jó valamire, csak mindkettő valami másra. Pl. a háromszögjel "érdesebb" (mint pl. a trombita vagy a hegedű), a négyszögjel ennél lágyabb (mint pl. a fuvola), a szinusz pedig önmagában túl lágy, túl tompa, önmagában nem is használják szerintem, csak nagyon ritkán, akkor is leginkább nem zenében.
Tehát hangeffektekhez inkább a háromszögjel és a négyszögjel jó.
Title: Re: game00
Post by: Z80System on 2013.November.06. 23:46:49
Quote
Tehát hangeffektekhez inkább a háromszögjel és a négyszögjel jó.
Akkor mér van, hogy nekem a fenti effekt generátornál a színusz tetszik, és a negyszögnél már csak a "tan" a rosszabb, zavaróbb, kissebb élményt nyújtóbb, ugyanannál az effektnél nézve ? Tetszik nekem a négyszög is, de csak akkor, ha a low pass filterrel ugyanolyanná alakítottam, mint a színuszos ... mikor már nincs különbség a színuszhoz képest, na akkor már jó a négyszög is ... :)
Title: Re: game00
Post by: endi on 2013.November.06. 23:59:07
egy másik generátor:
http://www.superflashbros.net/as3sfxr/
Title: Re: game00
Post by: Z80System on 2013.November.07. 09:27:10
Quote from: endi
egy másik generátor:
Olyasmi fílingem van, mintha ez az előbbinek a gyengébbik vagy korábbi verziója lenne ...
Title: Re: game00
Post by: geco on 2013.November.07. 10:06:04
EP-n is van alul/felüláteresztő szűrő, csak sajnos egy csatorna beáldozásával használható, sosem próbálkoztam vele, és sajnos a hangokhoz egyáltalán nem értek, de azért állítom, hogy négyszögjelekkel is tuti egész jó hangzás elérhető :D
Title: Re: game00
Post by: endi on 2013.November.07. 10:12:38
Quote from: geco
EP-n is van alul/felüláteresztő szűrő, csak sajnos egy csatorna beáldozásával használható, sosem próbálkoztam vele, és sajnos a hangokhoz egyáltalán nem értek, de azért állítom, hogy négyszögjelekkel is tuti egész jó hangzás elérhető :D
sajnos ezt eddig senkinek sem sikerült a gyakorlatban bebizonyítania...
ezek a szűrők, gyűrűmoduláció totál olyan hangzást ad mint a sima torzítások
Title: Re: game00
Post by: Z80System on 2013.November.07. 10:12:58
Quote
EP-n is van alul/felüláteresztő szűrő, csak sajnos egy csatorna beáldozásával használható, sosem próbálkoztam vele, és sajnos a hangokhoz egyáltalán nem értek, de azért állítom, hogy négyszögjelekkel is tuti egész jó hangzás elérhető (http://enterpriseforever.com/Smileys/phpbb/ds_icon_biggrin.gif)
Ha vannak, akkor miért kevesellte oket valyon IstvanV ?

Egész jo ... egész jó ... kipróbáltad a példákat amiket becsatoltam ? Azok szerintem egész jól mutatják, hogy aluláteresztő szűrő nélkül az egész jó nem egészen jó.
Title: Re: game00
Post by: geco on 2013.November.07. 10:25:17
Quote from: Z80System
Egész jo ... egész jó ... kipróbáltad a példákat amiket becsatoltam ? Azok szerintem egész jól mutatják, hogy aluláteresztő szűrő nélkül az egész jó nem egészen jó.
Nem :oops: , de az ay-s gépeken is voltak egész jó effektek játék közben, ezért mondom, hogy tuti lehetne négyszögjellel is egész jó effekteket csinálni, hozzáértő kezek kellenek hozzá , Szipucsu hol vagy? :D Ha az 50Hz kevés, akkor lehet emelni a tétet.
Title: Re: game00
Post by: endi on 2013.November.07. 10:33:52
Quote from: geco
Nem :oops: , de az ay-s gépeken is voltak egész jó effektek játék közben, ezért mondom, hogy tuti lehetne négyszögjellel is egész jó effekteket csinálni, hozzáértő kezek kellenek hozzá , Szipucsu hol vagy? :D Ha az 50Hz kevés, akkor lehet emelni a tétet.
én marha sokat próbálkoztam annak idején is meg azóta is emun
specy128 játékokban 99%-ban ugyanolyan effektek vannak mint amit az ep tud
de továbbra is hiszek abban hogy itt valami felfedezetlen van :)
Title: Re: game00
Post by: Z80System on 2013.November.07. 10:57:08
Quote
specy128 játékokban 99%-ban ugyanolyan effektek vannak mint amit az ep tud

Mostmár végig fogom nézni ezeket a s128 játékokat ... Méretükről lehet megismerni őket ?
Title: Re: game00
Post by: szipucsu on 2013.November.07. 11:04:34
Quote from: endi
egy másik generátor:
http://www.superflashbros.net/as3sfxr/
Az automatikus generálásnál itt is alig használja a szinuszhullámot, csak lézerhangoknál, ott se mindig.
Az FL Studio Toxic Biohazard pluginja lehet még jó, ott nem csak háromszög-, négyszög-, szinuszhullám van és egy zaj, hanem vagy húszféle hullámforma, bár azt inkább zenéhez tervezték, nem hangeffektekhez.
Title: Re: game00
Post by: szipucsu on 2013.November.07. 11:10:38
Quote from: geco
Szipucsu hol vagy?
Effektekben nem vagyok olyan jó. :D De pl. két csatornán gyűrűmodulációval egész félelmetes bombazuhanást lehet elérni, ha pl. 1 PITCH értékben tér el egymástól a két csatorna hangmagassága.
Ebben a videóban (http://www.youtube.com/watch?v=oPT-dcgIyKY) hallható ilyesmi, amikor zuhan a bomba, de itt véletlenszerűen adja meg a PITCH különbséget 0 és 1 között valahol.

De van 3 fajta torzítás, azért az nem kevés, és pl. a STYLE 16-ot is alig használták, pedig olyan hangzás tudtommal még C64-en sincs, de lehet, hogy tévedek.

Egyébként ha 0.1 PITCH értékkel tér el egymástól a két csatorna magassága és gyűrűmodulációval össze vannak kötve, az egészen újszerű hangzás, és picit még a háromszögjelre is emlékeztet, de az inkább zenénél lehet jó.
A zajcsatornához is megadható egy halom érték a STYLE-ben, azokat is alig használták, pl. a Sorcery-ben van ilyen.
Title: Re: game00
Post by: Z80System on 2013.November.07. 11:33:08
Hát jó ... lehet hogy most megsem, tehát egyszerűen a gyorsítás miatt mégis a digi lesz most a jó választás, de ha megvan a game00, akkor a game01 megkezdése előtt lehet mégis beleásom magam ebbe rendesen. És akkor a game01 már lehetne szinti hanggal, ha lehet jókat ...
Title: Re: game00
Post by: Z80System on 2013.November.09. 00:46:10
Na ... akadt egy kis probléma ... a 3 belapozot video szegmensemből a harmadik végén kemény 6144 byte szabad hely van ...

Ez lehetne a hang cache ... :)
Title: Re: game00
Post by: Z80System on 2013.November.09. 20:28:43
Na jól van, végülis akkor a "kényelmes legrosszabb eset" lesz maximum, a 3+3 hangos felállásban.

Úgyhogy továbbléptem, mostmár a háttér csillagmozgással bohóckodok újra. Egyrész többféle sebességgel akarom (magától értetődően), másrészt többféle színnel, és hát továbbra is maximum közeli sebességgel.

Jól el lehet molyolni itt mindennel ... és hát jó sok paraméter van.

Vajon úgy jövök -e ki jobban, ha csak kirajzolom a csillagokat, aztán rárajzolom a sprite -okat, és mindezt sima bájtos nullázással illetve másolással, és majd a bájtos kitakarások nem lesznek zavaróak ?

Vagy inkább a sprite -ok két szélét maszkoljam vagy xor -oljam ? Vagy inkább rajzoljam ki előre a sprite -okat és a csillagok kirajzolását maszkoljam be a sprite -ok alá ?

Annyi féle verziót kell kipróbálni ...
Title: Re: game00
Post by: endi on 2013.November.10. 00:34:13
löktyed az új verzsönöket inkább mint hogy ennyit írol :)
Title: Re: game00
Post by: geco on 2013.November.10. 07:21:14
Én a sima sprite rámásolást választanám, nem hinném, hogy annyira zavaró lesz 1-2 pötty pár pixellel korábban való eltűnése :D
Title: Re: game00
Post by: Z80System on 2013.November.10. 11:14:46
Quote
Én a sima sprite rámásolást választanám, nem hinném, hogy annyira zavaró lesz 1-2 pötty pár pixellel korábban való eltűnése (http://enterpriseforever.com/Smileys/phpbb/ds_icon_biggrin.gif)


Én is ebben gondolkodok először, azzal a kis módosítással, hogy ugye 4 pixel van egy bájtban, mikor nincs elcsúsztatva a sprite, akkor mondjuk egy 16 pixel széles sprite -hoz 4 bájtot fogok kimásolni, és a sprite meg jól ki van rajzolva a befoglalója széléig.

Mikor egy pixellel van jobbra tolva, akkor 5 bájtot fogok másolni de a jobb szélső bájtot, ahol most épp 3 üres pixel van, azt azért valamilyen módon maszkolni fogom. Aztán mikor kettővel van eltolva, akkor mindkét oldalon 2 pixel luk van, akkor csak simán kimásolom az 5 bájtot, amikor meg hárommal van eltolva, akkor bal oldalon van 3 pixel luk, akkor a bal oldali bájtot fogom maszkolni.

De nem tudom a gyakorlatban ez elég jó lesz -e, arról nem is beszélve, hogy az ellenség kódok is olyanok kelle legyenek így, hogy a sprite -ok egymással se kerüljenek fedésbe ...

Nem eccerű dolgok ezek.

Arról nem is beszélve, hogy még a csillagmozgás sincs készen ... csillagmozgast csinálni egyszerű, de gyorsat csinálni abból sem egyszerű ...
Title: Re: game00
Post by: endi on 2013.November.10. 11:29:30
Quote from: Z80System
Mikor egy pixellel van jobbra tolva, akkor 5 bájtot fogok másolni de a jobb szélső bájtot, ahol most épp 3 üres pixel van, azt azért valamilyen módon maszkolni fogom. Aztán mikor kettővel van eltolva, akkor mindkét oldalon 2 pixel luk van, akkor csak simán kimásolom az 5 bájtot, amikor meg hárommal van eltolva, akkor bal oldalon van 3 pixel luk, akkor a bal oldalt fogom maszkolni.
Ezt mindenki így csinálja (aki gyors kódot akar) az ősidőktől fogva. :)
Title: Re: game00
Post by: Z80System on 2013.November.10. 11:36:43
Quote
Ezt mindenki így csinálja (aki gyors kódot akar) az ősidőktől fogva. (http://enterpriseforever.com/Smileys/phpbb/smiley.gif)

Jajj, be hiányzott is már értékes kontribúcióid eme szép példánya ... érzem a pszichés támogatás erejét ... ahogy igyekszel biztosítani az utam helyességéről ... jajj, be szép is ez ... jajj, be szerencsés is vagyok ...
Title: Re: game00
Post by: endi on 2013.November.10. 11:37:54
Sőt, nagyon gyors kódhoz szoktak olyat is hogy kóddá konvertálják az adatot is. Azaz nem olvasgatják valahonnan a sprite adatokat meg másolgatják, hanem írnak egy kódot ami felépíti a sprite kirakó kódját úgy, hogy beleépíti a sprite adatokat brute force módszerrel.
Ezzel lehet a legnagyobb sebességet elérni, persze eszi a memóriát is. .)
Title: Re: game00
Post by: Z80System on 2013.November.13. 20:21:04
Minden különösebb magyarázat nélkül bemásolom az eddigi csillagmozgás ciklusmag elmélkedéseim eredményét. Lehet valakinek poen. Nincs itt mind, de a lényegi irányvonalak ezek :) :

;------------------------- 18.25 us
 ld d, (hl)
 ld e, #0x00

 xor a
 ld (de), a

 ld a, c
 add d
 cp b
 jr nc, Stars_Overflow
 ld d, a

 ld a, #0x00
 ld (de), a

 ld (hl), d
 inc l
;------------------------- 16.5 us
 ld d, (hl)
 ld e, #0x00

 xor a
 ld (de), a

 ld a, c
 add d
 and b
 ld d, a

 ld a, #0x00
 ld (de), a

 ld (hl), d
 inc l
;------------------------- 19 us
 ld e, (hl)
 ld a, (de)
 ld b, a
 ld c, #0x00

 xor a
 ld (bc), a

 inc e

 ld a, (de)
 ld b, a

 ld a, #0x00
 ld (bc), a

 ld (hl), e
 inc l
;------------------------- 19 us
 ld e, (hl)
 ex de, hl

 ld b, (hl)
 ld c, #0x00

 xor a
 ld (bc), a

 inc l

 ld b, (hl)

 ld a, #0x00
 ld (bc), a

 ex de, hl
 ld (hl), e
 inc l
;------------------------- 7.75 us
 ld hl, #0x0000
 ld (hl), a
 ld h, #0x00
 ld (hl), b
;------------------------- 8.5 us
 ld hl, #0x0000
 ld (hl), a
 ld hl, #0x0000
 ld (hl), a
;------------------------- 15 us
 ld a, (de)
 ld h, a
 ld (hl), b
 inc e
 inc e
 ld a, (de)
 ld h, a
 ld (hl), c
 dec e
 dec e
 inc d
 inc l
;------------------------- 9.5 us
 pop hl
 ld (hl), a
 pop de
 ld h, d
 ld (hl), e
;------------------------- 10 us
 pop hl
 ld e, l
 ld l, c
 ld (hl), d
 ld h, e
 ld (hl), b
 inc c
;------------------------- 10 us
 pop de
 ld h, d
 ld l, c
 ld (hl), a
 ld h, e
 ld (hl), b
 inc c
;------------------------- 8.5 us
 pop hl
 ld (hl), a

 pop hl
 ld (hl), a
;------------------------- 11 us
 ld d, (hl)
 ld (de), a
 inc l
 inc e

 ld d, (hl)
 ld (de), a
 inc l
 inc e
;------------------------- 10 us
 pop de
 ld h, d
 ld (hl), a
 inc l
 ld h, e
 ld (hl), a
 inc l
Title: Re: game00
Post by: Z80System on 2013.November.15. 22:36:20
Hát sajnálattal kell bejelentsem, hogy 64K gépet elvben is kizártam, tehát még opcionális feature -ök (pld. hang :)) nélkül sem fog menni a cucc 64K gépen.

128K alatt meg sem fog nyikkanni, és egyenlőre az LPT -m is az FF szegmens legelejétől van, és ha így marad (és egyenlőre úgy tűnik), akkor még EXOS kompatibilis sem lesz ... :(
Title: Re: game00
Post by: Mayer Gábor on 2013.November.16. 00:39:09
no problem
Title: Re: game00
Post by: Z80System on 2013.November.16. 15:56:03
Na az assembly topikban ergoGnomik (http://enterpriseforever.com/profile/?u=347) felvetései alapján elgondolkodtam pár dolgon,

és bár valszeg az IstvanV által megadott számítások megértéséhez szükséges időt nem fogom soha rászánni a EP alapú fejlesztésekre (így kb. soha nem lesznek olyan mély ismereteim a z80 és EP memória működéséről, amivel igazán optimális megoldásokat lehetne találni, de még az is lehet, hogy ez nem is akkora baj abból a szempontból, hogy ha ilyen szintű optimalizálásokat is figyelembe veszek, az még hatványozná a különböző verziók és lehetőségek számát, így a fejlesztési időt is.)

De mindenesetre (függetlenül attól, hogy a sprite kimásoló ciklusmagom mennyit lassul/gyorsul ha a forrása "fast" RAM -ban van, vagy nem) abból baj nem lehet, ha a sprite adatokat, és az őket kirajzoló kódot egy az assembly topikban már említett módon kölön szegmensre rakom, mely a nullás lapra lapozódik majd be.

Annál is inkább, mert ezt a gondolatot tovább vittem, és további jóságok (annak tűnő dolgok) derültek ki belőle.

Mi is a szitu:

Alap lapkiosztás:

F8 - általános kód és adat
FC - video ram 256 -os scanline- okkal, melyeknek első 104 byte -ja alkotja a scanline- t, és a második 152 byte -ja pedig szabad (ide kerültek volna eredetileg a sprite adatok).
FD - ugyanaz mint FC
FE - ugyanaz mint FC csak az utolsó 6KB már üres, jelenleg itt vannak a hangok, innen játsza le a 4KHz hangmegszak a mintákat, 4KHz -enként 2 byte kiolvasása a video RAM -ból.

Háttérben, nem állandóan belapozva:

FF - az elejét felülírtam az LPT adatokkal
F9 - csillagmozgatás kód + adat (csillagmozgatás fázisok). 50 Hz -enként belapozva a nullás lapra, kirajzolja a csillagokat.
FA - sprite kirajzolás kód + adat (sprite fázisok). 50 Hz -enként belapozva a nullás lapra, kirajzolja a sprite -okat.
FB - jelenleg még üres.

A sprite -oknak használ (nem tudni pontosan mennyit) ha "fast" RAM -ban vannak, és mivel egy sprite- jaim 16X16 pixelesek (duplázott méretű pixelek!), ezért eltolt fázisokhoz 5X16 byte kell, a szín keveréshez pedig fázisonként 2 db grafika, ezért 5X16X2 = 160 byte egy fázis. Egy lapra 102 fázis férne el, de lesz ott kód, és miegyéb, tehát mondjuk 64 fázis, ami akkor mondjuk 8 darab 8 fázisú, vagy 16 darab 4 fázisú, sprite grafika férne el, ami sztm. simán elég lehet. Vagyis a sprite -oknál veszíteni ezzel nem veszítünk semmit.

A plussz jó dolog meg az, hogy mivel a hangok úgyis a video RAM -ból vannak játszva, ezért ha már megy a csillagmozgás, meg a sprite- ok a jelenlegi kb. 6 hangos bufferrel,
akkor opcionálisan ki tudom terjeszteni egy módszerrel a hanglejátszást a kiűresedett scanline közökre.

Ugye 4Khz -en egy video "megszak" (50 Hz) alatt kb. 80X van hang megszakítás. Vagyis egy 80+pár byte -os puffer elég ahhoz, hogy 50 Hz -enként kelljen csak legyen a hang lejátszás ellenőrizve. Ez már most is így van a kódban.
Namost nekem 152 byte -om van a scanline -ok között üresen, ha lecsökkentem kicsit a hang frekijét 4KHz -ről pld. 3.5 KHz -re, akkor már elfér a 152 byte -on két 70 byte -os minta chunk (ami a 3.5KHz alatt kb. elegendő lesz 25 Hz -re), és 6 - 6 byte a két végén overhead, ami a minta korábbi ill. későbbi 6 -6 byte -ját fogja tartalmazni a minta chunk 2 végén.

Ezek a plussz 6-6 byte -ok arra kellenek csak, mivel nem tudjuk azt pontosan, hogy vajon a 3.5Khz -es megszakunk tényleg darabra megérkezik -e a videomegszakok ideje alatt.

Na ez még nekem is bonyolult volt, próbálom tisztábban:

A hangmegszak kicsit rosszabb kell legyen, mint 4KHz, mert 4KHz -en 80 byte kell egy 50 Hz -es intervallum alatt, és ha egy 50 Hz -es megszakításnyi időre csak 80 byte -ot tárolok bele a 152 byte -os területembe akkor sok memória pocséklódna el még mindíg. 2 db 50 Hz -es megszakításnyi idő meg már 160 byte lenne, nekünk meg csak 152 folyamatos byte -unk van.
Továbbá nem tudjuk az 50 Hz -es megszakjainkban pontosan elkapni darabra a hangmintákat, lehet hopgy 2 video megszak között egyszer 78 egyszer meg 83 minta játszódna le. Ezért kell kétoldalt egy kis ráhagyás, átfedés a minta chunk -ok között. Ami tovább növeli a byte -ok számát.

Tehát kicsit lejjebb megyek a hang frekivel úgy, hogy 152 byte -ba beférjen 2 50 Hz -es megszak idejéhez szükséges hangminta + az átfedések. Ez kb. úgy 3.5 Khz körül lesz.

Beállítom a hanglejátszást a hangmintám első darabkájának az elejére, és elindítom a lejátszást.
A hangmegszak az eddig megismert módon semmivel nem törődve, maximális sebességgel tolja a hangot.
Majd 2 50 Hz -es megszakításnyi idő múlva (mert tudom, hogy ennyi időre biztosan van elég hangmintám) , átírom a hangmegszak címét egy olyan rutin címére, ami elvégzi a csekkolást is, nem csak a hangot adja.
Ez a megszakítás megnézi (csak 25 Hz -es lefutással ugye), hogy a hangom pontosan melyik mintánál jár (nyilván az átfedő 6 byte -os részen kell legyen), és úgy állítja a következő scanline üres helyére elhelyezett hang chunk -ra, hogy ott meg a kezdő 6 byte -os tűrési zónán belül a megfelelő "folytatás" hangminta legyen.
Ezután a megszak címet persze visszaállítja a gyors lefutású hangmegszakra.

Igy akkor az össz sebesség szerintem növekedni fog, mert levettük a hangferit 3.5 KHz -re, és csak 1/25 Hz -enként nézzük meg részletesen a hangminta pozícióját.

És kapunk még 16K-18K hang memóriát a meglévő 6K -hoz ... lesz kb. 24K hang buffer ... az már akkor kb. 7 másodperc hang ... vagyis lehetne pár hosszabb is ...

És mindez opcionális, ráérek akkor ha már látszik valami, és a futáson csak gyorsítani fog.
Title: Re: game00
Post by: szipucsu on 2013.November.16. 21:13:35
Quote from: Z80System
lapkiosztás
Akkor ez valami kártyajáték demó lesz? :D
Title: Re: game00
Post by: Z80System on 2013.November.16. 22:35:29
Nem akar összejönni nekem ez a nulláslap váltás ...

A nulláslap első 100H -ját természetesen átmásoltam az összes olyan szegmensre, amiket be akarok lapozni a nulláslapra.

Megy ugyan egy aktív megszakítás (4KHz hang), de az gondolom elvégzi a dolgát annak a szegmensnek a 100H alatti területébe, ami be van épp lapozva, és mire visszatér, addigra minden ugyanaz mintha nem is lett volna megszakítás. (A megszak nem lapoz, meg semmi, és csak a hármas lapról olvas.)

Szóval lehet, hogy csak én bénázok el valamit, de elég érthetetlen jelenségek vannak egyenlőre a debuggerben, szóval lehet van itt valami elvi hiba, amiről nem tudok ?

A megszak úgy van bekapcsolva, hogy a 0x38 -ra van írva egy "JP megszakom". Olyan szegmenseket is használok, ami lehet, hogy az EXOS -nál van, de ha én nem hívok EXOS -t, akkor ezzel a megszak bekapcsolással az EXOS ki van zárva, igaz ?

Lehet itt valami elvi hiba ?
Title: Re: game00
Post by: Z80System on 2013.November.16. 23:26:01
Na meglett ... amikor átváltom a nullás lapot, akkor az IRQ rutin kódja nincs duplikálva az új lapon ... :oops:
Title: Re: game00
Post by: Z80System on 2013.November.16. 23:37:08
Quote
mér nem gyün?

Hát mer itt bénázok vele, látod ...

Napokig optimalizáltam itt a csillagokat, erre 3 sorral lett rövidebb ...

Most meg mikor kiderült, hogy sprite -okat is külön szegmensre teszem, ezért megcsináltam ezt a "DLL" funkciót általánosra, és így nem kell már kódokat írjak, ami összerak egy másik nulláslapra szánt szegmensen egy programot, hanem rendesen különálló forrásokból, egy teljesen önálló programot fordítok ezekre a funkciókra, és a programom képes betölteni őket és funkciókat hívni rajtuk.

Tehát mint a DLL -ek, vagy mint az EXOS bővítők úgy működnek most ezek a programok, így csak a rendelkezésre álló szegmensek limitálják, hogy hány szegmensen lehet a kód.

Persze a nulláslap lapozgatásának nehézségei miatt csak jó "nagy" feladatokra érdemes ilyet használni, mint pld. "csillagok" egyben, vagy "sprite -ok" szintén egyben ...
Title: Re: game00
Post by: Z80System on 2013.November.16. 23:37:41
Magyarul nem fícsőrt írok, hanem engine -t fejlesztek ... :)
Title: Re: game00
Post by: Z80System on 2013.November.16. 23:48:43
Megszakítás probléma megoldva. Fogtam a 18 bájtból álló hang megszakomat, és bemásoltam konkrétan a 0x0000 -ra, még azelőtt, mielőtt lemásolom a dinamikusan betöltött új kód szegmensekre az első 100H -t.

Magyarul az összes nulláslapon használt szegmensen ott lesz 0x0000 -tól a megszak kódja. Igy most fut.

Jól gondolom, hogy legális azt a területet használni ?
Title: Re: game00
Post by: IstvanV on 2013.November.17. 12:52:45
Quote from: Z80System
Magyarul az összes nulláslapon használt szegmensen ott lesz 0x0000 -tól a megszak kódja. Igy most fut.

Jól gondolom, hogy legális azt a területet használni ?
A 0-2Fh terület szabadon használható 5-ös fejlécű programban. De ha a játék futása közben már nem kellenek az EXOS hívások és az EXOS megszakítás kezelője, akkor célszerűbb 38h-ra másolni, és megtakarítani a JP utasítást. A RESET gomb lenyomásakor az EXOS visszamásolja az eredeti kódot a 30h-5Bh területre. De a játék is elmentheti és visszaállíthatja az EXOS 0. lap kódot, ha szükség van rá a játék közben is (általában nincs).
Title: Re: game00
Post by: Z80System on 2013.November.17. 12:55:23
Na az első működő csillagmozgás ki is mutatott pár marhaságot a tervezgetéseimben ...

Ugye 50FPS játékot és mozgást szeretnék, de szeretnék 50 FPS villogtatásos színkeverést is.

Az egy dolog, hogy azt mondtam, hogy az 50 FPS színkeveréssel majd 4X4=16 szín lesz lehetséges, ami mivel a színkeverésnek mindegy hogy az egyik frame lesz zöld és a másik frame lesz kék, vagy fordítva, ugyanaz a cián szín fog kijönni. Magyarul kidobálva a 4X4 -es mátrixból a duplikációkat, marad 10 szín. Ami végülis jóval több mint a 4, de nem 16.

Az viszont már gáz, hogy ez az 50 FPS színkeverés valójában egy 25 FPS játékhoz ideális. Vagy lehet, hogy máshoz egyáltalán nem is jó, majd kiderül a gyakorlatban.
Tehát ugye van a sprite valahol, kirajzolódik az egyik színkeverő fázis, következő frame -ben a másik színkeverő fázis, és a sprite csak mindkét frame után mozdulhat meg, ami 25 FPS mozgás lenne. Az új pozíciójában pedig szintén ki kell rajzolni mindkét fázist.

De én 50 FPS mozgást akarok, ekkor a sprite képes belemozdulni (nyilván) a két színkeverő fázisába. Namost nem sprite -okkal még, de a csillagmozgással kipróbáltam, és elég bénán néz ki. Változtatja a csillag formáját, bénán. Elképzelhető hogy sprite -oknál jobb hatás lesz, mert ott csak a színátmenetek határainak formáját fogja változtatni, de valszeg ott is nagyon zavaró lesz ...

Akkor pedig fuccs a 10 színnek ... marad a 4 ... :(
Title: Re: game00
Post by: Z80System on 2013.November.17. 15:38:27
Na, ha ez ilyen sebességgel fog folytatódni, akkor a jövő évre az EP programozási időm be van táblázva a galaga valagára ... :)

Itt vannak az első csillagmozgás verziók.

Az első a standard, a második effektes, a harmadik meg csak keret nélkül az első, hogy lehessen érezni a fílinget.

A hangok közül most csak az A,B,C megy, mert a többi nincs betöltve.
Title: Re: game00
Post by: Z80System on 2013.November.17. 15:40:50
Legközelebb még mindíg nem a sprite -okat fogom csinálni, mert a linker valamiért mindent linkel ami egy file -ban van, nem csak azt ami meg is van hívva,
így a rendszer file -omat szét kell szednem témakörönként kb. függvény szinten, hogy egy-egy programhoz csak az forduljon hozzá, ami oda épp kell.

Aztán végre jöhetnek a sprite -ok ...
Title: Re: game00
Post by: Z80System on 2013.November.17. 15:54:17
itt van még kettő verzió.
Title: Re: game00
Post by: Z80System on 2013.November.17. 18:13:57
Na jól van, megcsináltam a sys modul szétbontását is, mostmár akkor kis darabokban lehet a programokhoz linkeltetni a funkciókat, és nem kell a nagy méret miatt másolgatni őket.

Vagyis akkor most már jöhetnek a szpráááá ...

(Szprájtok, Szprájtok, Szprájtok, Szprájtok, Szprájtok, Szprájtok ... :))
Title: Re: game00
Post by: szipucsu on 2013.November.17. 18:37:38
A 04-es a legjobb. A 03-as rezgése pl. akkor jöhet jól, ha jó nagyot ütközünk egy csúnya szörnyikébe, vagy ha pl. varázstabletta hatása alatt vagyunk.
Még sosem láttam, hogy az emulátornak ennyire a szélén is volt kép. Ha így folytatod, akkor majd a tévé hangszóróján lesz a SCORE felirat?
Most nem lehet rád fogni, hogy annyit ittál, hogy csillagokat látsz, mert tényleg ott vannak. :D
Title: Re: game00
Post by: Z80System on 2013.November.17. 19:18:43
Franc ...

Még mindíg nem jó valami az átok framework -ömben.

2 képernyőm van ugye, 2 előre legenerált LPT -vel, képernyő (LPT is) legalján van a reload flag, kod valahol félképernyőnél beírja nick- be azt az LPT -t, ami a backbufferem (ami épp nincs beváltva), amire előzőleg kirajzolta a képet, aztán pedig vár videomegszakra, ami szintén a reload után jőn meg.

Aztán újra rajzol, az új "backbuffer" -be.

Elvileg ettől teljesen villogásmentes kéne legyen bármi, bárhol is rajzolom a képen.

A csillagokon nem is láttam különösebbet, de a sprite rámozgatva arra a képernyő függőleges pozícióra, ahol fut valami kirajzolas (csillag vagy sprite), akkor villog összevissza mint a bolond ...

Tehát nem működik a backbuffering rendesen ...

De nem látom mi lenne a hiba.
Title: Re: game00
Post by: szipucsu on 2013.November.17. 19:54:47
Amúgy sosem értettem, miért mindenki valami sziperhiper új programot akar írni EP-re, amibe majd' beletörik a bicskája. Egyszerűbb élvezetes játékot is lehetne írni, akár a meglévőket visszafejteni, beletenni ezt-azt, ami nem bicskatörő és egész jó játékokat kapnánk. Pl. a Dot Collectort vissza lehetne fejteni (8 kilobájtos, nem sok), lehetne beletenni más elv szerint mozgó ellenfeleket, digi effekteket, varázstablettát,stb. De ez csak egy példa. Mondjuk egy olyan játékot nulláról megírni se lehet nagy kunszt. Raknánk kígyót is a labirintusba, stb., fel lehetne dobni egyszerű témájú játékot is nagyon úgy, hogy nem törik bele a bicskánk. Vagy Dot Collector szerűt megcsinálni úgy, hogy át lehessen menni egyik képernyőből a másikba és el lehessen tévedni a labirintusban, stb.
Title: Re: game00
Post by: Z80System on 2013.November.17. 19:58:55
Quote
De nem látom mi lenne a hiba.
Mert nem is volt benne hiba. Egyszeruen a sprite X offset hozzáadást elrontottam, így az első képről átcsúszott a másodikra, a másodikról meg képernyőn kívüli területre.
Title: Re: game00
Post by: Z80System on 2013.November.17. 20:48:52
Na mára itt a vége, fusselvéle.

De legalább már mozog valami sprite is.

Persze ahhoz hogy valami értelmes dolog legyen majd a sprite -okkal (még a játékszerű mozgatásukról meg a tesztelésükről nem is beszélve), ahhoz először kell írjak valami grafika konvertáló, összepakoló, nyilvántartó, betöltő kódot is ... :(

Minnél többet megcsinál az ember, annál több meló lesz ... :)
Title: Re: game00
Post by: szipucsu on 2013.November.17. 21:39:07
Quote from: Z80System
Na mára itt a vége, fusselvéle.
Jó lesz ez, ígéretesnek tűnik. Szép színes!
Amúgy lebuktál, ugyanazok a csillagok jönnek végtelenítve. :D Amúgy jó ez is, de ha véletlenszerűen jönnének a csillagok, még jobb lenne.
Title: Re: game00
Post by: endi on 2013.November.17. 21:48:20
Quote from: szipucsu
Jó lesz ez, ígéretesnek tűnik. Szép színes!
Amúgy lebuktál, ugyanazok a csillagok jönnek végtelenítve. :D Amúgy jó ez is, de ha véletlenszerűen jönnének a csillagok, még jobb lenne.
Igen ezt én is néztem. Ugyanazok a csillagok jönnek. Nekem se tetszik. Én emiatt nem venném meg ezt a játékot. Mennék a boltban és látnám hogy ott megy a játék a monitoron, és meglátnám az ismétlődő csillagokat, és felkiáltanék "óóó, hát én ezt a játékot nem veszem meg!". És nem is venném meg.
:mrgreen:
Title: Re: game00
Post by: Z80System on 2013.November.17. 21:49:39
Quote
Jó lesz ez, ígéretesnek tűnik. 

Én ezt még messze nem merném kijelenteni. Ez a felezett felbontás ... meg a 4 szín ... lelkem háborog ... na de majd meglátjuk jó lesz -e bármire is.

Quote
Szép színes!
Ja. Kár, hogy standardba maradt akkor 2 szín az összes sprite -ra ... Talán akkor mégsem annyira színes ...


Quote
Amúgy jó ez is, de ha véletlenszerűen jönnének a csillagok, még jobb lenne.

Ennél többszörösen rosszabb a helyzet. Nem sorolva őket a főpont: én még azon is gondolkodtam, hogy leduplázom a csillagokat a fél képernyőn ... tehát hogy nemhogy ugyanazok, de a képernyőn egyszerre 2X látod ugyanazt ismételve ... egyfajta tile -ozással ...

De attól már én is féltem, hogy béna lesz. Ki kéne próbálni. Majd egyszer ...
Title: Re: game00
Post by: szipucsu on 2013.November.17. 21:52:09
Szerintem nem baj, ha nem lesz tökéletes.
Title: Re: game00
Post by: Z80System on 2013.November.17. 21:56:14
Hát ez nem egy termék ugye, hanem egy kísérlet ... hogy mit lehet, mit nem. Mit lehetett volna, ami nem történt meg.

Valóban nem baj, ha nem lesz tökéletes ... csak akkor szomorú leszek ... :) 

(Persze a tökéletesség feltételeit én súlyozom be.)
Title: Re: game00
Post by: Z80System on 2013.November.17. 22:00:54
Kicsit azon aggódom, hogy a frame beállíthatóság az idővel el fog sikkadni ...

Úgy értem, hogy a hangot pld. előrevettem, hogy nehogy amiatt kelljen újraírni az egészet.

De ahhoz már végképp nincs türelmem, hogy most a fejlesztés közben folyamatosan végiggondoljam a beállítható frame számokkal működő időzítéseket.

És biztosan fog kelleni csomó dolgot másképp csinálni a beállítható frame számhoz.

Szóval mikor majd kész lesz az egész, akkor lesz egy csomó plussz átírás, kód ... vagy legalábbis kéne. Ha akarnék beállítható frame számot ... márpedig akarnék.

De lehet lusta leszek.
Title: Re: game00
Post by: szipucsu on 2013.November.17. 22:26:55
Mióta megvan a Traffic játék, azóta nagyjából rendszeresen játszom vele a mai napig. A grafikája funkcionális ugyan, de a játék annyira ötletes, hogy a részletek egészen háttérbe szorulnak. Manapság inkább a csodálatos grafikára és hangokra mennek rá a játékokban, a játékmenetben meg semmi új nincs. De azért nem baj, ha jól meg van írva minden egy játékban, de a használhatósága nem ezen fog múlni. :)
Title: Re: game00
Post by: Z80System on 2013.November.17. 22:32:59
Fogj kezet az endivel, ő is mindig ezen vergődik.

De ez van. Nalam a tökéletes megjelenés, kivitel, az a beugró. Attól még valóban lehet teljesen rossz valami, hogy patent a külcsíny, de ANÉLKÜL lehet akármilyen jó is, engem nem érdekel.

Ízlések ...
Title: Re: game00
Post by: Z80System on 2013.November.18. 07:48:18
Hmmm ... most azon kezdtem morfondírozni, hogy ha felmennék HIRES -be, akkor tulajdonképp eddig az állapotig pont ugyanez lenne a futási időm.

Viszont lenne 16 szín ... egy álom válna valóra ...

Persze ha lenne dupla ennyi byte, akkor kár lenne nem duplázni a csillagok sűrűségét ... és akkor már duplázódna az idő.

Persze a lehetséges sprite -ok számát meg mindenképp felezné,

a scanline- jaim a mostani 104 byte -ról, 208 byte -ra mennének fel, és a maradék 50 byte - okra már nem férne el (csak nagyon rossz minőségű, 2KHz -es hang esetén lenne megoldható, akkor is csak 5K lenne) a hang buffer,

a sprite grafikák is egyből feleződnének darabszámban ...

De 16 szíííín ... az nagy mézesmadzag ... :)
Title: Re: game00
Post by: Z80System on 2013.November.18. 08:16:03
Közben egy másik ördög is bújkál bennem ... most hogy megcsináltam, hogy több szegmensen is lehet kód, felmerült bennem, hogy el kéne hagyni a 128K limitet is.

Ugye nekem ez a projekt arról szól, hogy miket lehett volna csinálni régen, és mivel a limiteket alapvetően a sebesség adta, nem a memória, lehet ezzel a memóriadologgal nem torzítanék sokat.

Úgy értem, hogy sokkal kényelmesebb lenne nekem most úgy dolgozni, hogy nincsenek memória limitek, mindennek van külön szegmense, oszt jónapot, de ami így működik, azt okos szervezéssel, időráfordítással, jó arányok megtalalásával, válogatással, stb. hasonló jóra meg lehetne csinálni 128K -n is, mint szabad memóriahasználattal. Csak én most megspórolnám az ezekre (memóriaoptimalizálas) szánt időket.

Vagy ez már nagyon nagy csalás lenne ? Ezzel értelmét veszítené már a dolog ? Nem tekinthetnénk többé relevánsnak ?

Egyébként meg a mostani memória bővítésekkel aki akarná tudná vas gépen is futtatni ... Sztm. akinek van vas gépe, az rendelt most magának bővítést ... nem ?
Title: Re: game00
Post by: Zozosoft on 2013.November.18. 08:50:40
Én a hangmintákat nem raknám a videó RAM-ba, másodpercenként több ezerszer akarsz hozzáférni, minden alkalommal várni a Nickre, ez tuti sokat lassít.
Title: Re: game00
Post by: Z80System on 2013.November.18. 09:03:59
Quote
Én a hangmintákat nem raknám a videó RAM-ba, másodpercenként több ezerszer akarsz hozzáférni, minden alkalommal várni a Nickre, ez tuti sokat lassít.
Hát most is onnan játszom le őket, eleve így lett az ideje tesztelve. Ha átraknám oket system RAM -ba, akkor szerinted jelentősen gyorsulna a futás ?

És ha nem onnan játszom le, akkor mire való a videó RAM ? Screen buffer, és kész ? Meg maximum háttér adat ? Háttértár ? Hisz grafikát nem tehetek bele, mert akkor lassítja a másolást, hangot sem, mert az is lassít, számításigényes pálya adatot sem (táblázatokat) mert az meg a számítást lassítja ... :)

A hangot a maga video megszakításonkénti 160 byte -jával (4KHz az 80 hangmegszak 50Hz -enként, és hangmegszakonként 2 byte -ot olvas be, ír ki portra),
egy sprite kimásoláshoz képest (ami ugye az össz idő 80% lesz kb.) egy kifejezetten nagy memóriaigényű, de kis memóriahozzáférési frekvenciájú feladatnak érzem a hangot ... ha még ezt sem lehet a video RAM -ba tenni, akkor mit ?


Most így utánaszámolva egy sprite -om 5*16=80 byte szintén (mekkora poén! :)), ami azért azt jelenti, hogy megszakonként 2 sprite -nyi memória azért valóban kimegy a hangra ...

Na de mégsem 8-10 ...
Title: Re: game00
Post by: Z80System on 2013.November.18. 09:21:27
És oké, video RAM -ban ne legyen semmi, csak screen buffer meg háttértár,

akkor marad ugye 4 szegmens a system RAM -ból,

1 kod
2 csillagok
3 sprite -ok
4 hangok

És már el is fogytam, ha szeretnék mondjuk a pályákhoz +1 szegmenst, akkor már nincs is ...

Arról nem is beszélve, hogy a hang szegmenst el kéne kezdeni lapozgatni akkor mégis, mert 3 videó szegmensre is atnyúlik a képernyő pufferem, és ha nem akarom megtanítani lapozgatva rajzolni a kódjaimat (és nem nagyon ...) akkor a kirajzolások ideje alatt 3 video szegmensnek belapozva kell lennie. Közben akkor a hang honnan menne ?

Persze ha szakítanék a 100H -nkénti scanline -okkal akkor ráférne 2 szegmensre a screen buffer.

De azért összességében az eléggé tetszik, hogy 100H scanline -ok, közöttük a hang (illetve hát kettőn), és ezek állandóan belapozva tartva, kivétel mikor 0- ás lapot váltok.
Title: Re: game00
Post by: Zozosoft on 2013.November.18. 09:28:05
Quote from: Z80System
És már el is fogytam, ha szeretnék mondjuk a pályákhoz +1 szegmenst, akkor már nincs is ...
De a pályák az kell folyamatosan egyszerre? Az lehetne lassú RAM-ban, és pályaváltáskor átmásolni az aktuálisat mondjuk a nullás lapon lévő pufferben.

A csillagok egy egész szegmenst fogyasztanak?
Title: Re: game00
Post by: Z80System on 2013.November.18. 09:36:57
Quote
De a pályák az kell folyamatosan egyszerre?
Még nem tudom mi alapján fognak mozogni az ellenségek, a példa csak teoretikus volt, hogy üresen hagyjuk a belapozott memória 50% -át, plussz kukázunk a tárunkból is ugyanennyit, ha nem használom ki a videomemória közöket.


Quote
A csillagok egy egész szegmenst fogyasztanak?

A csillagok le vannak tárolva. 46 (darab csillag) * egy 256 lépéses táblázat = 2e00H hosszú. Ha bármit számolgatok, visszatárolgatok, tesztelek, túlcsorgatok csillagonként, az duplázta a csillagok idejét.
A jelenlegi időt tovább lehetne 2/3 -olni, ha fenti memória dupláját áldoznám a csillagokra.

Azt hiszem meg az is másfélszerez vagy dupláz, ha 3 darab (különböző sebességű) 256 -os csillag táblán mozgattam minden csillaghoz egy saját indexet. Pedig a túlcsordulás már ott is automatikus.
Title: Re: game00
Post by: Zozosoft on 2013.November.18. 09:40:20
Quote from: Z80System
A csillagok le vannak tárolva. 46 (darab csillag) * egy 256 lépéses táblázat = 2e00H hosszú.
Akkor ott van még 1200h szabad bájt :-)
Title: Re: game00
Post by: Z80System on 2013.November.18. 09:50:51
Hááát ... ha elhagynám a 100H -s scanline -okat, akkor a teljes screen bufferem elférne 1 szegmensen ... még maradna is hely.

Vagyis lapozasi értelemben lehetne a

p0 - kód
p1 - üres!
p2 - screen
p3 - hang

A p1 -et meg fel lehetne használni bármire ami jön, vagy el lehetne hagyni a nulláslap csere körüli bonyodalmakat, és lehetne a p1 a cserélgetett kód lap.

Csak ehhez akkor a mostani csillagmozgás az kuka, kéne a dupla méretű adat hozzá,

és a sprite -ok kirajzolásánál is 16 bites összeadással lehetne csak lépegetni a sorok között ... azt volna jó tudni, hogy az vajon mennyit lassítana.

Mert ha nem félék ennyire a nem 100H scanline -októl, akkor azért lapozás szemppontjából bejjebb lennék.

És akkor a lapozást megtoldani kis extra RAM -mal ... :)
Title: Re: game00
Post by: Z80System on 2013.November.18. 10:02:44
Na, maradjunk annyiban,

hogy most így ahogy van megírok némi sprite mozgást majd,

és még ugyanerre a képre megírok olyan sprite kirajzolókat is, amik nem használják ki a 100H -s scanline -okat, hanem működnének normál képernyőn is,

és akkor ki tudom próbálni, hogy mi van ha azokat használom, de a hang system ramból szól,
vagy a 100H -sokat, de a hang videóból szól.

És ha jelentős a különbség, akkor érdemes elgondolkodni a csillagmozgáson mégegyszer. (Csillagmozgás ugye azért érzékenyebb a 100H -ra a sprite -oknál, mert ott egy "sprite" egy byte, és gyakorlatilag az egész csillagmozgás kód egy "cím számítás", míg a sprite -oknál azért kiraksz jó sok byte- ot egy címszámítás után.)
Title: Re: game00
Post by: Z80System on 2013.November.18. 10:13:09
Igazából a csillagokhoz már eszembe is jutott egy megoldás ...

Tehát tulajdonképp az a kérdés, hogy vajon jóval többet gyorsít -e a 100H scanline a sprite -oknál, mint amekkorát gyorsítana a system RAM -ból hanglejátszás.

Mert amennyiben nem gyorsítana sokkal többet, akkor érdemes lenne átállni még akkor is, ha a system RAM -ból hanglejátszás sem gyorsítana sokat. Ugyanis a csillagokon kívül egyszerűbb lenne az élet mindennel ...
Title: Re: game00
Post by: endi on 2013.November.18. 10:25:00
ha a csillagok mozgása le van tárolva akkor mozoghatnának kicsit térben is
vagy kacskaringósan, vagy mit tudom én
Title: Re: game00
Post by: szipucsu on 2013.November.18. 13:32:38
Quote from: endi
vagy kacskaringósan, vagy mit tudom én
Az már inkább hóesés lenne. :D És esetleg egy télapót kéne irányítani, és összegyűjteni a mikuláscsomagokat a levegőben?
Title: Re: game00
Post by: Z80System on 2013.November.18. 13:34:33
Quote
vagy kacskaringósan, vagy mit tudom én
Van a felrakott példák között effektes, annál is kacskaringósabban ?
Title: Re: game00
Post by: Z80System on 2013.November.18. 15:45:59
Ja, akit érdekel, színkód az előző példákban lévő raszteridőkhöz:

piros: billentyű mátrix beolvasása memóriába
zöld: egy C kód a hangok indításához, (pár IF szerkezet :)) csak átmenetileg van benne
sárga: csillagok
kék: sprite

és a többi szín a többi mócsing, LPT váltás, ilyesmik ...
Title: Re: game00
Post by: Z80System on 2013.November.19. 20:37:14
Kitaláltam hogy fogok színeket vinni a game00 -ba.

Annyi szín lesz benne, hogy azt fogjátok mondani, hogy túl csiricsáré, lehetne egy kicsit visszafogottabb, ízlésesebb ... :)

De nem lesz. Atomszínes lesz.

Zozo örülhet, ebben a játékban ki sem próbálom a villogtatásos színkeverést. Majd másikban. Ebben a játékban vétek lenne.

Lesz olyan, hogy 20 szín lesz a képen csak a sprite -okból + a csillagok színei (ami ugye már most is sok színű, grádiens) + egyéb sokszínű háttér effektek ... :)


Olyan effektek lesznek benne, hogy ilyen full konzol fíling lesz ... (http://enterpriseforever.com/Smileys/phpbb/smiley.gif)

(Persze ehhez előbb még túl kell jussak a sprite kezelés apró problémáján, de ha azon átvergődtem, akkor már síma ügy lesz, a szín és összhatáskérdésen nem kell tovább vergődjek, az sztm. ott lesz.)

Ja, és a színek persze úgy vannak értve, hogy sehol nem lesz zavaró "attributum" hatás (mikor a grafikát vágja valami színblokk). Teljesen minimális, vagy zéró attributum hatás lesz. Abszolút úgy fog tűnni, mintha normál pixel grafika lenne. (Persze ha valakinek már a mostani csillagmozgás is "attributum" hatás, azon nem fogok tudni segíteni. De annál erősebb "attributum" hatás nem lesz benne.)

(Ha nem képzelem el rosszul a dolgokat, persze.)


Na jó ... nem konzol ... ahhoz egy sprite -on belül még mindíg túl kevés szín lesz ...

De színes lesz. Az tutkó. Nagyon. És hibák nélkül.
Title: Re: game00
Post by: Zozosoft on 2013.November.19. 21:15:14
Quote from: Z80System
Zozo örülhet, ebben a játékban ki sem próbálom a villogtatásos színkeverést.
És ezért miért kéne örülnöm?  :oops:
Title: Re: game00
Post by: Z80System on 2013.November.19. 21:18:13
Quote
És ezért miért kéne örülnöm?  (http://enterpriseforever.com/Smileys/phpbb/ds_icon_redface.gif)

Nem te mondtad, hogy ne csináljam ?

Rád emlékeztem ...

Valaki mondta régebben, mikor a színek voltak terítéken, hogy ne legyen olyan.
Title: Re: game00
Post by: Zozosoft on 2013.November.19. 22:20:15
Quote from: Z80System
Nem te mondtad, hogy ne csináljam ?
Azt nem mondtam, hogy ne csináld, csak kérdeztem, hogy LORES 4 helyett nem lenne-e jobb a HIRES 16?
Lehet, hogy több* helyet foglal, cserébe egyszerűbb kód. Pixel méret ugyanaz.

* bár pontosan nem tudom hogyan villogtatnál, csak az LPT-t piszkálnád folyton? Az én módszeremben két LPT két videómemóriával van, tehát helytakarékosság ez esetben nem lenne.
Title: Re: game00
Post by: Z80System on 2013.November.19. 22:33:30
Quote
Azt nem mondtam, hogy ne csináld, csak kérdeztem, hogy LORES 4 helyett nem lenne-e jobb a HIRES 16?
Ja, én is megtaláltam végül.

De jól van, ha nem akarsz, nem kell örülj ... :)


Quote
Lehet, hogy több* helyet foglal, cserébe egyszerűbb kód. Pixel méret ugyanaz.

Hát a hely takarékossága nekem legelsősorban, nem memória takarékossági kérdés, hanem sebesség kérdés. LORES -ben fele akkora memória mozog, kétszer annyi sprite -ot lehet kirakni. Nagyjából.


Quote
* bár pontosan nem tudom hogyan villogtatnál, csak az LPT-t piszkálnád folyton? Az én módszeremben két LPT két videómemóriával van, tehát helytakarékosság ez esetben nem lenne.

Igazából ebben a játékban nem egész képeket akartam villogtatni (eleve dupla pufferrel megyek a 100% kirajzolási villogásmentességért, szal nem lenne hely többlet), hanem csak az egyes sprite -okat, mivel a játék 50 FPS -sel fog menni, ezért ilyen technikákat is meg lehetne engedni, hogy egy-egy képrészlet (sprite -oknak csak pixeleik, ahova kellene az új szín) villog csak.

De mondom, erre a játékra ez már nem vonatkozik, mert villogás nélkül is lessz annyi szín, hogy nincs is annyi a palettán.

Más játékra meg már más villogtatási szabályok fognak vonatkozni.

Pld. a game01 (ami egy oldalszkrollos HIRES dolog lenne, "sok" sprite -tal és sok nagyfelületű tile animációval), na az lehet hogy egész képernyő villogós lesz.

De nem kell úgy előre szaladni, ki tudja megérjük -e.
Title: Re: game00
Post by: Z80System on 2013.December.03. 12:05:39
Ha emlékeztek még rá, volt egy olyan tárgyalás game00 témakörben valahol, hogy mennyire lehet a hangmegszakba úgy cipőkanalazni valamit (itt a csillagmozgás kódjáról volt konkrétan szó), hogy ne legyenek ott komolyabb veszteségek abból fakadóan, hogy nem merjük teljesen kitölteni a megszakot kóddal, hogy nehogy kihagyjunk hang megszakítást azért, mert véletlenül a kódunk épp hosszabb idő alatt futott le.

Namost közben az jutott eszembe, hogy ha tudunk a megszakításban futó feladattal párhuzamosítható dolgot csináltatni a z80 -nal, akkor nem is kell kipumpálni a megszakot, akár "felesben" is járathatjuk, ha kell, hisz maga a megszak mindenképp lenne a hang miatt, a létezésének idejét nyilván nem tudjuk megspórolni, és mind megszakban mind a főprogramban a programunk fog valami értelmeset csinálni továbbra is.

Namost a csillagok esetében az elég gáz lehet, hogy pont azokat kell kirajzolni legelőször, de hála istennek nem tartanak túl sokáig (8-10 raszter lehet), es közben futhatnának a szprájtmozgató és tesztelő kódok.

Vagyis a főprogramom (jelenleg a konkrét hangkeltésen kívül mindent az csinál) úgy módosulhat, hogy nem a csillagok kirajzolásával kezdi a kört, hanem a sprite -ok, mozgatásával és tesztelésével, állapotváltozásokkal, szóval a játékkal, ami csak a háttérben zajlik, közben a megszakítás, szép szellősen, ahogy csak kényelmesen meg lehet valósítani kirajzolja a csillagokat, mikorra végez majd (minnél jobban ki van töltve a megszak, annál lassabb lesz a játékkezelés a főprogramban) a főprogram még úgyis a játékot fogja kezelni. mert nem hinném hogy a teljes gameplay tesztelése rövidebb idő lenne mint ami a 8-10 raszteres csillagkirajzolásból MEGMARAD a főprogram számára.

Vagyis gond nélkül (itt most a gond az időveszteség szinonímája akar lenni) interleave -elhető be a főprogram mellé bizonyos feladatok elvégzése, és jelen esetben hiába a nehezítő körülmény a csillagok sorrendjével, lehet találni mellé passzolo főprogram feladatot.

Majd ha a főprogram végzett a gameplay logikával, nyugodtan számíthat rá, hogy a megszakban a csillagok is kirajzolódtak közben, és folytathatja a sprite -ok kirajzolásával.
Title: Re: game00
Post by: Z80System on 2014.August.01. 13:43:10
Korábbi tárgyalások meg elmélkedések fonalát felvéve, következő döntésekre jutottam:



- Átlépek Assembler -re a C fordítóról. Ami persze az eddigi dolgok újraírását fogja jelenteni, de azokban igazából nem a begépelés, hanem a rengeteg irányvonal meg lehetőség közti választás volt a hosszú, szóval ez nem lesz túl nagy akadály.



- Szakítok azzal a gyakorlattal, hogy a scanline- ok 100H -val osztható címen kezdődnek. Ez mind a csillagmozgásnál, mind pedig a sprite kirakásnál elég komoly veszteség lesz sebességben, ez az egyszerű tényező a csillagmozgást akár duplázhatja időben, a sprite kirakást meg másfelezheti, viszont a video ram nem nyúlik szét 3 szegmensen, hogy aztán a scanline -ok közé kelljen egyéb értékes adatot fűzni be, vagy még rosszabb esetben üresen hagyni a közöket, hanem LPT- stől elfér 24K -n. Ami sajnos még mindíg 2 szegmens, de legalább nem három. 2 scanline- t fogok egy 256 -os blokkba tenni, így 128 -cal osztható címen fog kezdődni minden scanline. A scanline- ok közeinek vesztesége így nem egészen 4K lesz.



És akkor így választhatok a következő 2 lapozási stratégia közül, melyek közül az első:



p0: Fix kód+adat. A program olyan kódja és adatai melyeket mindenki minden körülmények között elérhet.

p1: Változtatható kód+adat. Ilyen pld. a csillagmozgás kód+adat, vagy a sprite -ok kód+adat területe. Többnyire saját magukban operáló kódok, maximum még a p0 -át használhatják, ha szükséges. Nyilván pld. a hívásukkor a paraméterek lehetnének a p0 -án pld.

p2: Video

p3: Video+8576 byte (összesen kb. 2 másodpercnyi) hang buffer.



Vagy méginkább a második:



p0: Változtatható kód+adat. Megoldva a 0 -ás lap váltást, a megszakkezelést és a lapozgatós hívást nincs igazi akadálya annak, hogy egy szegmensen tartsuk a kód+adat területeket. Mivel amúgy is kevés számú hívással hív majd bele a program a különböző kód+adat szegmensein eltárolt programokba, pld. "rajzold ki a csillagokat" vagy "torold le az osszes sprite -ot", stb. tehát mondjuk körönként maximum 10-20 darab (és akkor szerintem túllőttem nagyon) ilyen szegmensek közötti hívás lesz, vagyis sebességben nem fog meglátszani. Az igazi bénaság ezzel az, hogy mikor a 0 -ás lapon mondjuk a sprite kirajzoló szegmens van a sprite kód+adat -tal, akkor a sprite -ok pozíciói nem fognak direktben látszani, vagy legalábbis nem a 0 -ás szegmensen, vagyis azokat vagy még a váltás folyamata alatt (mikor még mindkét szegmens látszik) át kell másolni a sprite szegmensre, vagy pedig eleve olyan helyre kell rakni, ami a másik három lap -on van.

p1: Video

p2: Video+8576 byte (összesen kb. 2 másodpercnyi) hang buffer. És akkor ide lehetne annak a 8576 byte -nak egy kis darabkájába rakni azokat az állapotokat (pld. előbb említett sprite pozíciók), melyekkel a 0 -ás lapra lapozott kód szegmensek kommunikálnak.

p3: Hang buffer. (Még kb. 4 másodpercnyi.)



Tehát ha akarok 0 -ás lap váltogatást, akkor összesen 6 másodpercnyi, ha meg nem akarok, akkor 2 másodpercnyi hangbuffert tudnék címtérben tartani.
Title: Re: game00
Post by: Zozosoft on 2014.August.01. 14:06:24
Kimaradt a felsorolásból a verem! Ami nem árt ha mindig be van lapozva :-)
Title: Re: game00
Post by: Z80System on 2014.August.01. 14:31:40
Quote
Kimaradt a felsorolásból a verem! Ami nem árt ha mindig be van lapozva (http://enterpriseforever.com/Smileys/phpbb/ds_icon_smile.gif)
Nemtom kimaradt -e vagy sem, de az nálam (is ugye, korábbiakban megbeszéltek értelmében) 100h -n van,

ami teljesen jó a lapváltáskor is mert:

- letiltjuk a megszakokat
- belapozzuk p1 -re az új p0 szegmens jelöltet
- meghivjuk a cross-segment függvényünket a p1 -en (4000h -val növelt címen természetesen), ekkor eredeti p0 szegmens stack -jére pakolódik a visszatérési cím

- a cross-segment függvényünk úgy kezdi, hogy kiolvassa mi van p1 -en és belapozza p0 -ra
- ráugrik önmaga folytatására (ugrás utáni következő utasítás) a p0 -on
- visszalapozza p1 -re az eredetileg ott levő szegmenst (itt. video)
- engedélyezi a megszakokat



- elvégzi amit kell, pld. kirajzol sprite -okat


- letiltjuk a megszakokat
- berak p1 -re p0 -t
- ráugrik a 4000- rel növelt önmagára
- visszarak p0 -ra eredeti nullaslap szegmenst, melynek stack -jeben ott a visszateresi ertek
- ret -tel visszater

- es mi pedig visszarakjuk p1 -re az eredeti (video) szegmenst
- majd engedelyezzuk a megszakokat



mint látjuk, ez hivó oldalról annyi lesz, hogy:

- letilt megszak
- berakjuk p1 -re az uj p0 szegmensünket
- meghívjuk a függvenyunket a p1 -en
- visszatérés után visszarakjuk p1 -re az eredeti (video) szegmenst
- engedelyezzuk a megszakokat

a többit a hívott függvény végzi.


Mindehhez persze még az is kell, hogy a 100h elotti rendszerváltozók és maga a megszakítás kód is látszódjon minden 0 -ás lap szegmens esetén,
és hogy maga a megszak kód is tiltsa a megszakításokat. Ezek nálam adottak / megoldottak.
Title: Re: game00
Post by: Z80System on 2014.August.01. 14:39:30
Sőt mivel nekem a megszak csak zenét játszik le, és az nem nyúl a p1 -hez,
ezért a megszakítások tiltása/engedélyezése dologra nincs is szükség.
Title: Re: game00
Post by: geco on 2014.August.01. 18:15:55
Quote from: Z80System
Sőt mivel nekem a megszak csak zenét játszik le, és az nem nyúl a p1 -hez,
ezért a megszakítások tiltása/engedélyezése dologra nincs is szükség.
Azért van, mert az int meghívásakor, meg visszatéréskor a vermet használja (ha 0100h-n van a verem, és P0-t lapozod), okozhat elszállást.
Viszont a 0-ás lap lapozásához van egy egyszerűbb, és gyorsabb módszer, SPEMU-ban is ezt használom, átváltáshoz csak egy sima OUT (0b0h),a -t használok, úgy címezve a belapozandó lapon a kódot, hogy egyből az out utasítás utáni címen folytatódjon a lapozás utáni rész, vissza ugyanígy, csak a váltott lapon más címen az OUT (0b0h),a .és ennek címfolytonos következő utasítása hajtódik végre a visszalapozott lapon.
Title: Re: game00
Post by: Z80System on 2014.August.01. 18:24:31
Quote
Azért van, mert az int meghívásakor, meg visszatéréskor a vermet használja (ha 0100h-n van a verem, és P0-t lapozod), okozhat elszállást.
Nem feltétlen értem. Gondolom a port írás ilyen szempontból atomikus működésű, tehát csak akkor fogja elkezdeni a lapozó utasítást a z80, ha épp nincs megszakításban,
és amíg végre nem hajtotta a műveletet, addig nem is kezdődhet új megszakítás. Vagyis a megszakítás visszatérési címe vagy a régi vagy az új szegmensre fog kerülni, de olyan nem lesz, hogy még a régi szegmensre kerül, de a megszak futása közben érvényesül a lapváltas, és mire visszatérne a megszak, addigra már az új szegmens van a lapon ... nem ?
Title: Re: game00
Post by: geco on 2014.August.01. 18:26:49
Quote from: Z80System
Nem feltétlen értem. Gondolom a port írás ilyen szempontból atomikus működésű, tehát csak akkor fogja elkezdeni a lapozó utasítást a z80, ha épp nincs megszakításban,
és amíg végre nem hajtotta a műveletet, addig nem is kezdődhet új megszakítás. Vagyis a megszakítás visszatérési címe vagy a régi vagy az új szegmensre fog kerülni, de olyan nem lesz, hogy még a régi szegmensre kerül, de a megszak futása közben érvényesül a lapváltas, és mire visszatérne a megszak, addigra már az új szegmens van a lapon ... nem ?
Húú, igazad van, a megszakítás nem fogja maga alól kilapozni p0-át :oops:
Title: Re: game00
Post by: Z80System on 2014.August.01. 18:34:55
Quote
Viszont a 0-ás lap lapozásához van egy egyszerűbb, és gyorsabb módszer, SPEMU-ban is ezt használom, átváltáshoz csak egy sima OUT (0b0h),a -t használok, úgy címezve a belapozandó lapon a kódot, hogy egyből az out utasítás utáni címen folytatódjon a lapozás utáni rész,

Ezt meg még annyira sem értem ... persze hogy egszerűbb lenne simán csak átváltani a nullás lapon a szegmenst, és hagyni a kódot siman tovább futni, de hát ha van egy belépési címed a cél szegmensben, meg van mondjuk 3 helyről hívva a forrás szegmensből a függvény, akkor max. úgy lehetne megoldani amit mondasz, hogy a lapváltó utasítással felülírom a forrás szegmenst azon a részen, ami a cél szegmens belépési pontja előtt van ... aztán ráugrok, az ott "helyben" átvált, és akkor a cél szegmensen már a belépési pontnál leszek,
de aztán visszaváltáskor meg a cél szegmenst kéne felülírni ... de hát ezeket vissza kellene másolni ... nem értem ez miért lenne egyszerűbb ...

Ez az eset max. akkor lehet egyszerűbb, ha a forrás és cél meg a visszaút is csak 1:1 -es megfelelésű, és eleve úgy vannak a kódok befordítva, hogy az egyik "vége" passzoljon a másik "elejéhez", de nálam nem ez a szitu, én egy tetszőleges cross segment hívást valósítok meg, ahol a hívott kód ugyanazon a lapon (nullás) fog futni mint a hívó kód,
és csak átmenetileg van a p1 is átállítva, csupán a "vezérlésátadás" idejére.

Nem ?
Title: Re: game00
Post by: geco on 2014.August.01. 19:04:55
De, meg akkor, ha a HL, vagy IX, vagy IY regisztered szabadon felhasználható, lapváltás előtt megadod a regiszter értékét, majd lapváltás, és a lapváltás utáni utasítás pedig a egy JP (HL), vagy épp a megfelelő regiszter, ha a verem másik szegmensen lenne, akkor még azt lehetne használni az ugrásra.

Ezt a JP (HL)-es megoldást használom odaváltásra, vissza pedig úgy emléxem, hogy a verem tartalmát egy RET-tel, és a verem a 0-ás lapon van, 0-ás lapról 0-ás lapra ugrással.
Title: Re: game00
Post by: Z80System on 2014.August.01. 19:24:35
Hmmm ... hát hogy regiszter vagy nem regiszter, az tulajdonképp megint mindegy, lehet az egy másik lapokon lévő változó is, amiben átadsz címet,

de valóban így már csak egy helyen kell ( de ott továbbra is ) szinkronban lenni a 2 szegmens kódjának,
vagyis mindkét szegmensen egymáshoz passzoló helyeken kell legyen be és kiléptető kód,

és akkor mondjuk regiszterben vagy memóriaválzozóban meg lehet adni a cél címet,
call -lal meg lehet hivni a váltókódot,
mely váltókód átváltja a lapot,
és a célszegmensen lévő illesztett kód a kapott paraméterek szerint még mindíg szubrutinhivás szeruen meghivja a célfüggvényt,
célfüggvény visszatér a váltókódhoz ret -tel,
a váltókód visszaváltja eredeti szegmenst,
és az eredeti szegmensen szintén illesztve lévő kód kiad egy ret -et,
amivel visszatér a hívóhoz.

Igen ... elég szimpatikus ... Egyszerűbbnek épp nem mondanám,
sőt ez igényel egy helyen illesztett kódot, míg a p1 bevonásos módszer nem igényel,
de az olyan szimpi, hogy a p1 -et nem kell macerálni ...
Title: Re: game00
Post by: Z80System on 2014.August.01. 19:30:07
Sőt ... ha már memóriaváltozó, amit mindketten látnak ...

A váltókód is lehetne másik lapon ... és akkor nem kellene az illesztés sem ...

Pld. van nekem az a 8K hang bufferem az egyik video szegmensemen, amiből úgyis lecsípek majd egy pár bájtot ... Ott lehetne a váltókód is, és akkor triviális lenne ...
Title: Re: game00
Post by: geco on 2014.August.01. 19:30:47
Igen, annyival egyszerűbb, és gyorsabb, hogy nem kell pluszban lapozgatni, egy lapozás egy váltás, igen annyi a macera, hogy 2 helyen illeszteni kell a kódot mind a két lapon.

Valami ilyesmi a váltás:

Code: [Select]
      ld     hl,rutin1
       call   pagein


pagein out    (0b0h),a
és már az új lapon
       jp     (hl)

rutin1
       ...
       jp     pagebck

pagebck out   (0b0h),a
eredeti lapon:
       ret

és máris a call pagein után járunk

Title: Re: game00
Post by: geco on 2014.August.01. 19:32:31
Quote from: Z80System
Sőt ... ha már memóriaváltozó, amit mindketten látnak ...

A váltókód is lehetne másik lapon ... és akkor nem kellene az illesztés sem ...

Pld. van nekem az a 8K hang bufferem az egyik video szegmensemen, amiből úgyis lecsípek majd egy pár bájtot ... Ott lehetne a váltókód is, és akkor triviális lenne ...
Így még egyszerűbb, de mintha mondtad volna, hogy a videóramban is vannak kisebb lyukak, az is felhasználható, csak pár bájtra van szükség.
Nekem sajnos nem volt erre lehetőségem, csak a 0-ás lapon.
Title: Re: game00
Post by: Z80System on 2014.August.01. 19:47:50
Ja, kúlság,

bár a konkrét módszerben nekem nem tetszik hogy a rutin1 az jp     pagebck -kel tér vissza,
mert akkor ez már nem egy függvény, hanem egy kizárólag pagein -nel hívható függvény,
sokkal általánosabb, ha a függvények, mint a rutin1 nem tudja, hogy hogy hívták,
ret -tel térjenek vissza, de akkor pagein szubrutinkent kell hivjon nem sima jp (hl) -lel,
és akkor lehet a rutin1 -gyet hívni szegmensen belülről is, simán, meg másik szegmensről is.

abban viszont egyetértünk, hogy valszeg ez a legszebb módszer, ez az "egy helyen illesztett" módszer + regiszeterekben a hívási paraméterek dolog,
mert ezt az illesztett vezérlésátadó kódot ezt pár bajtból meg lehet írni, akár úgy hogy mentse el mi volt p0 -án (stack -re) és visszatérés után azt kapcsolja vissza,
így egyszer kell megírni a kódot, mindentől független lesz (szegmens értékek, függvény címek), és minden olyan szegmensre ami a 0 -ás lapra kerül, be lehet simán "másolni" a 100h előtti területre valahova ...

és akkor bármikor belehívhatnak egymásba úgy, hogy semelyik más lap nem kell elkapcsolódjon közben, semilyen más laptol nem függ a vezérlésátadás, és meg a megszakot sem kell továbbra sem lekapcsolni ...

szupi.
Title: Re: game00
Post by: geco on 2014.August.01. 20:24:12
mivel mindig a lapozó rutint hívom meg, és annak fix a pagebck része, ezért szerintem fölösleges időhúzás lenne CALL-ra cserélni a JP (HL)-t.

Amúgy annyit elírtam a kód példámban, hogy az OUT (0B0h)-k előtt fixen meg vannak adva nálam a szegmensek is, mivel csak két lap között váltok, de természetesen egyszerűen be lehet vonni több lapot is, és tök rugalmas, CPC-n néztem pl a North&South-nál is a memórialapozást, úgy oldották meg, hogy P1-re belapozza velamelyik alternatyív szegmenst (0* ,1* ,2*, 3*), azt átmásolja, majd visszalapozza az eredetit, ott sokkal kevesebb variációs lehetőség van, legfőképp csak a P1-re lehet mindent alternatív memórialapot belapozni, az eredeti 64Kb-s szettből csak az épp odavalót ( 1-est ), és a 3-ast.
Title: Re: game00
Post by: Z80System on 2014.August.01. 20:31:51
Ja és +1 "komolyabb" változás a dolgokban,

azt találtam ki, hogy ahhoz hogy demonstrálhassam a frame -es játék előnyeit a 2,3,X frame -es játékokhoz képest,
ahhoz tökéletesen elég, ha a képfrissítést lassítom be N frame -esre, a többi működés lassítása nem szükséges.

Elvben az még sokkal többet rontana a fílingen, ha a játék többi része is lassulna a kijelzési frekivel együtt,
hisz egy "síma" több frame -es játék a billentyűt is csak kissebb frekin olvassa, az összes léptetését is csak kissebb frekin végzi el,
de én ennyivel is "könnyítek" a sok frame -esség dolgán, hogy mivel a kód képes lesz frame -esen is futni,
ezért a kijelzést ugyan lassítani fogom a tetszőleges frame számra, de a léptetéseket, inputot, hangot mindent változatlanul játszok majd le.

Vagyis egy elvben mondjuk 50 frame -esre állítva, a játék képe majd csak másodpercenként fog frissülni, de a másodperces "slideshow" alatt a háttérben (vakon) a játék ugyanúgy 50FPS -sel játszható lesz majd. Szóval minden sebesség marad teljesen változatlan majd, a freki csökkenésével tisztán a képfrissítés sebessége fog csökkenni.

Ez lesz az ideális eset (ennél csak rosszabb lehet a helyzet általánosságban) hogy a kétkedők meglássák, hogy mit jelent valait 50FPS -sel játszani, vagy kisebb frekiken. Már a 8 bites korszakban ... ráadásul én még a felbontást is lefeleztem ugye, tehát még kisfreki barátabb lett így a játék. De sztm. még így is elsöprő lesz az 50 FPS hatása. (A kisebb frekikhez képest, ugyanazon játéknál.)

Remélem nem én lepődök majd meg ... :)
Title: Re: game00
Post by: geco on 2014.August.01. 20:35:22
Szerintem a játékot is lassítsd be, ne csak a kijelzést, mert pl 1 másodperces kijelzés késleltetlsnél 50Hz-es game speed mellett játszhatatlan lesz, játék belassításnál játszható , csak nagyon darabos, úgyis ez a lényeg szerintem.
Title: Re: game00
Post by: Z80System on 2014.August.01. 20:40:47
Ez iménti dolog a képfrekivel azért érdekes, mert van pár olyan dolog, ami egyrészt megköveteli a 50Hz -es működési frekit, ilyen pld. a hang, most nem magyarázgatom miért, és 25Hz -en már egyszerűen szétesne, és eddig izgultam hogy fogom összeegyeztetni ezeket az 50 Hz -es működésű dolgokat, a lassabb működésekkel,

de így, hogy csak a képfreki lassul majd, így csak azt kell mostantól következetesen megoldanom, hogy a szteppelés és a kirajzolás jól el legyen különítve,

és egyszerűen meg fogom tudni oldani az extrém lassításokat is, és nem fog elsikkadni ez a 50Hz proof funkció.
Title: Re: game00
Post by: geco on 2014.August.01. 20:44:54
Ja, én úgy gondoltam, hogy a hangot nem belassítva, az úgyis megszakításból fut, tehát minden, ami a megszakításban fut, azt eredeti sebességgel futtatni, csak az azon kívüli részt belassítani úgy, hogy x darab frame-et várjon, ha 0 várakozás van, akkor ennek a résznek az átugrásával.
Title: Re: game00
Post by: Z80System on 2014.August.01. 20:48:11
Quote
Szerintem a játékot is lassítsd be, ne csak a kijelzést, mert pl 1 másodperces kijelzés késleltetlsnél 50Hz-es game speed mellett játszhatatlan lesz, játék belassításnál játszható , csak nagyon darabos, úgyis ez a lényeg szerintem.
Egyrészt azért nem, mert ez lesz így az egyszerűbb, előbbi okokból.

Másrészt azért nem, mert eleve sem így akartam, hanem úgy hogy az eredeti sebesség ne változzon. A bizonyításnak pont az a lényege, hogy "mennyivel bénább vason ugyanzon 8 bites játék kisebb frekiken, mint 50 FPS -sel", és ehhez nagyon fontos az is, hogy minden sebesség ugyanolyan maradjon, minden frekin.

Tehát ha az űrhajó 50FPS mellett 1 másodperc alatt megy el bal szélről jobb szélre, mert a játékbeállítások azt igenylik,
akkor 25FPS frissítés mellett is pont 1 másodperc alatt menjen el.

És mennyivel randább lesz 25FPS -en mint 50FPS -en.

Ha nem úgy csinálnam mint írtam, pont azzal kellene vesződjek, hogy mindenki arányosan nagyobbakat lépjen a kisebb frekiken.

Az irdatlan lassú frissítések nem számítanak semilyen szempontból, senki nem fog 1 másodperc / pixellel játszani, és ha mégis játszana, akkor sem fog, mert nem ez a cél. Az egy másodperces frissítés példát csak magyarázatnak írtam.
Title: Re: game00
Post by: geco on 2014.August.01. 20:53:37
értem, én másképp közelítettem meg a bénaságot, azt hittem azt szeretnéd bizonyítani, hogy mennyivel bénább, ha 1 pixelt haladunk nem egy, hanem 2-3 frame alatt.
Title: Re: game00
Post by: Z80System on 2014.August.01. 20:59:16
Quote
értem, én másképp közelítettem meg a bénaságot, azt hittem azt szeretnéd bizonyítani, hogy mennyivel bénább, ha 1 pixelt haladunk nem egy, hanem 2-3 frame alatt.
Hát nem ... elismerem hogy kattant vagyok, de azért azt hogy ha valamit elrontunk az szarabb lesz, azt nem akarnám még én sem bizonyítani ... :)

Úgy is mondhatnám, hogy van egy létező X játék, ami 2 vagy 3 frame -esen X sebességgel működik (mert csak 2 frame -esre tudták megírni gépsebesség miatt),

akkor ha te azt 50FPS -re "kapcsolnád" (mert már elbírja egy turbós gép mondjuk) akkor a frame -enkénti léptetéseit nyilván felezni vagy harmadolni kéne, mint ahogy nmost van,

ekkor ugyanolyan (most se menjünk bele a görbeközelítések problémájába) sebességű és dinamikájú játékot kapnál, csak sokkal sűrűbb frissítéssel, finomabb frame -enkénti mozgásokkal.

És Zozó meg tudomismég kik ezt kérdőjelezték meg, hogy nem is lesz az 50FPS sokkal jobb, mint a 25 FPS vagy még kisebb. Hogy nem is kell az ...
Title: Re: game00
Post by: geco on 2014.August.01. 21:10:51
Mondjuk szerintem a 25Hz még fasza, elég folyamatosnak tűnik, de majd meglátjuk a teszten, mondjuk még annyi ronthat az összképen, hogy lorest-használsz, így nagyobb lesz az ugrás 25Hz-re váltásnál, természetesen arányaiban nem, mert ugyanúgy dupla pixel lesz, mint hiresben, csak nekem a fejemben mégis úgy áll össze a kép, hogy így mégis rosszabb lesz az összhatás, mint jobb felbontás mellett, de majd meglátjuk :)

No még annyi, hogy olyan korból származó gépről beszélünk, amikor nem nagyon volt 50 fps-es játék, nem az volt a cél, más volt fontos.
Title: Re: game00
Post by: Z80System on 2014.August.01. 21:21:47
Quote
Mondjuk szerintem a 25Hz még fasza, elég folyamatosnak tűnik,

Noooooooooooo ! :)


Quote
mondjuk még annyi ronthat az összképen, hogy lorest-használsz, így nagyobb lesz az ugrás 25Hz-re váltásnál, természetesen arányaiban nem, mert ugyanúgy dupla pixel lesz, mint hiresben, csak nekem a fejemben mégis úgy áll össze a kép, hogy így mégis rosszabb lesz az összhatás, mint jobb felbontás mellett, de majd meglátjuk (http://enterpriseforever.com/Smileys/phpbb/smiley.gif)

Ha jól értelek, akkor én pontosan ellenkezően gondolom.

Valóban rontani fog az összképen a lores, mert az átlag játek hires, és a lores sztm sokkal érzéketlenebb a frissítési frekire. Tehát nemhogy az lesz, hogy loresben szarabbul nez ki a 25Hz, mint hiresben nézne ki a 25 Hz,

hanem hogy a lores többet elrejt amjd a frekicsökkenésből. Mert mi nem a hires 50 FPS -hez hasonlíthuk majd a lores 25FPS -t,
hanem a lores 50 -hez a lores 25 -ot.

es ha a felbontás már konstans, akkor a hiába próbál az 50 Hz finomabban mozogni, ha a felbontás nem tudja megjeleníteni a finom mozgást ...

tehát a hireshez a lores persze h szarabb, de mi 2 lorest fogunk osszehasonlítani, ami sztm kevésbé frekiérzékeny,
mint ha 2 hirest hasonlítanánk össze frekiben ... nem ?
Title: Re: game00
Post by: Z80System on 2014.August.01. 21:32:57
Tehát ha van egy pixel loresben (függetlenül attól, hogy az milyen rondán tudna közelíteni bármit is, mert túl nagy pixel), azt loresben egy pixelesével tudod mozgatni,

míg hiresben ha veszel egy 2X2 pixeles blokkot, ami pont úgy néz ki mint a lores pixel, na ott már lesz értelme duplázni a frekit, mert ott 1 hires pixelesével (a 2X2 -es kockánk felével) is tudod mozgatni, ami a dupla frakivel pont ugyanaz a sebesség (fizikai méret/másodpercben) mint a lores fele freki.

Érted ?

Tehát sztm minnél nagyobb a felbontás, annál érzékenyebb lehet a frekire egy finom és lassú mozgás.
Title: Re: game00
Post by: Zozosoft on 2014.August.01. 21:33:56
Mozifilmek is csak 24 fps-sel készültek. Most a legújabb XBOX-on egy csomó játék csak 30 fps-sel fut.

Mindenesetre nagyon kíváncsi leszek ha lesz már egy játszható demó, hogy észrevenni bármit is :-)
Title: Re: game00
Post by: geco on 2014.August.01. 21:36:16
Nem tudom, szerintem, de ez tényleg csak szerintem a lores nem teszi frekiérzéketlenebbé a dolgot, de ezt tényleg meglátjuk majd, viszont az jutott eszembe, hogy programkód módosítása nélkül át lehetne váltani hiresbe is, csak annyi kell hozzá, hogy minden LPB-ben átváltunk hiresbe, és a bal, és jobb margót beállítjuk úgy, hogy a kettő különbsége fele legyen a lores beállításnak, így mindkét verzió letesztelhető egyszerre, ugyanazon játékon, csak pár sorral nőne a kód :)

Igaz, így nyújtott képernyőt kapnánk, az arányok beállításához egy picit több módosítás kéne az LPT-ben, de az is megoldható, és tényleg úgy, hogy a játék kódjához nem kell hozzányúlni a váltások miatt.
Title: Re: game00
Post by: endi on 2014.August.01. 21:36:59
Quote from: Zozosoft
Mozifilmek is csak 24 fps-sel készültek. Most a legújabb XBOX-on egy csomó játék csak 30 fps-sel fut.

Mindenesetre nagyon kíváncsi leszek ha lesz már egy játszható demó, hogy észrevenni bármit is :-)
mozifilmek és komolyabb játékok esetén azonban van motion blur, azaz a köztes frame-k ott vannak, csak elkenődve, de ez is információ az agynak
Title: Re: game00
Post by: Z80System on 2014.August.01. 21:44:54
Quote
Mozifilmek is csak 24 fps-sel készültek. Most a legújabb XBOX-on egy csomó játék csak 30 fps-sel fut.
Nem számít, sztm teljesen más dolog. Én is sokszor észrevettem, hogy 3D képnél, mikor pld. előre haladunk sokkal kevésbe zavaró a frekicsökkenés, de ha forgunk vagy oldalozunk, akkor zavaróbb. Egyébként is hangsúlyoztam végig a VASON (eredeti EP) és "8 bites cuccok" tehát egy scrollokkal és sprite -okkal, pontokkal operáló game.

De egyébként egy mai konzolos 30FPS -es játéktól is besírok a 60FPS -hez képest, de nem tartozik a 3D scene/mai hardverek az összehasonlításom tárgyába.

Mozifilmek totál nem számítanak, én sem értem, mert filmeknél meg a 60 FPS -es kamerás felvételeket utálom, és a 25 -öset meg szeretem, abszolút nem értem miért, itt nem is érdekes.
Title: Re: game00
Post by: Z80System on 2014.August.01. 21:45:47
Még lehet az is számít, hogy TV vagy monitor ... nem tudom, majd kiprobáljuk. :)
Title: Re: game00
Post by: Z80System on 2014.August.01. 21:49:09
Quote
Nem tudom, szerintem, de ez tényleg csak szerintem a lores nem teszi frekiérzéketlenebbé a dolgot, de ezt tényleg meglátjuk majd, viszont az jutott eszembe, hogy programkód módosítása nélkül át lehetne váltani hiresbe is, csak annyi kell hozzá, hogy minden LPB-ben átváltunk hiresbe, és a bal, és jobb margót beállítjuk úgy, hogy a kettő különbsége fele legyen a lores beállításnak, így mindkét verzió letesztelhető egyszerre, ugyanazon játékon, csak pár sorral nőne a kód (http://enterpriseforever.com/Smileys/phpbb/smiley.gif)

Na már előre látom ... ott lesz a cucc, ordít róla majd, hogy 50 FPS állat minden kisebb frekihez képest ...

És akkor majd azt mondjátok, hogy azért van így, mert lores ... :)

De akkó bammeg csinálok egy hirest is ... ott is sz** lesz ami nem 50 ...
Title: Re: game00
Post by: geco on 2014.August.01. 21:53:44
Quote from: Z80System
Na már előre látom ... ott lesz a cucc, ordít róla majd, hogy 50 FPS állat minden kisebb frekihez képest ...
És akkor majd azt mondjátok, hogy azért van így, mert lores ... :)
De akkó bammeg csinálok egy hirest is ... ott is sz** lesz ami nem 50 ...
:lol: :smt044
Azért hoztam fel, mert rövid kis addonnal megoldható lenne a váltás a két mód között, még úgyis, hogy mind vertikálisan, mind horizontálisan lecsökken a képméret a felére.
Ugye soronkénit LPT-t használsz, a fele akkora függőleges felbontás eléréséért 2 soros LPB-kkel?
Title: Re: game00
Post by: Z80System on 2014.August.01. 21:56:35
Igen, azt használok, szerintem is csökkenthető volna egyszerűen, de ez meg egy HARMADIK osszehasonlytás lenne, hisz csak méretben csökkentesz, felbontásban nem.

Ez kb. olyan, mintha azt mondanánk, hogy alljunk messzebb a monitortól, és nézzük meg úgy mennyit ront a freki csökkenés ... :)
Title: Re: game00
Post by: geco on 2014.August.01. 22:02:01
Quote from: Z80System
Igen, azt használok, szerintem is csökkenthető volna egyszerűen, de ez meg egy HARMADIK osszehasonlytás lenne, hisz csak méretben csökkentesz, felbontásban nem.

Ez kb. olyan, mintha azt mondanánk, hogy alljunk messzebb a monitortól, és nézzük meg úgy mennyit ront a freki csökkenés ... :)
Azért nem egészen, mert kisebbek lesznek a pixelek, és a mozgás összehasonlításhoz pont jó is, igaz minden kisebb is, végülis a második mondat áll, ha le akarom tesztelni abban a felbontásban, hátrálok pár lépést :D
Title: Re: game00
Post by: Z80System on 2015.October.11. 19:47:28
Na, talán úgy néz ki (ha isten is szeret) hogy következhet egy EP fejlesztősebb szakasz az év hátralévő részében.

Az elmúlt évek tapasztalataiból, és a pillanatnyi szituból mérlegelve úgy döntöttem, hogy "mégsem" a játék demó,
éppenhogycsak játszható játékmechanika irányába haladok majd a fejlesztésekkel,

hanem hozni fogok komoly áldozatokat, kötni fogok tényleges kompromisszumokat
a minnél tökéletesebb, optimálisabb mechanikák, kód, technikai megoldások rovására,
a minnél szélesebb körben értelmezhető eredmény javára.

Ami itt játékot jelent.

Természetesen nem jelenti ez, hogy mostantól majd minden pikpakk menne majd,
minden ugyanúgy csigabiga lesz, mint eddig, de a target módosul kissé,
amolyan "linuxos" játékfejlesztések irányába: sosincs kész, sosincs vége a fejlesztésnek,
mindíg csak aktuális verziója van a dolognak, nincsen végcél,
de attól még játszható a cucc, kompakt formája is létezik,
nem csak egy rutin vagy könyvtár.

Természetesen esetleges lesz a végeredmény, dizájn szempontból semmi jót nem jósolok,
de mindenképp használható (itt. játszható) lesz bárki számára.

Písz!
Title: Re: game00
Post by: Z80System on 2015.October.12. 19:13:54
Azon gondolkodok, hogy van EP -re (nagyjából az átiratoknak köszönhetően) mindenféle game,
gyenguszabbak, erősebbek, amit csak az ipar ki bírt izzadni magából annó.

Persze (megintcsak az átiratoknak köszönhetően) egyik nagy hiányosság hogy a játékok nincsenek az EP képességeire hangolva, kiélezve.
Alapvetően ezeken szándékoznék (pontosabban szándékoztam volna) faragni a játékdemó-fantáziálásaimban.

Azonban van egy másik aspektus, ami elképzelhető hogy a nagyérdemű számára még az előzőnél is sokkal fontosabb.
Korábban deklarált pálfordulásom ezt a (remélhetőleg) felismerést (is) célozza kiszolgálni.
Ez pedig a "Legkellemesebb EP játékok" témakörnél is taglalni próbált erővonal: hogy a játék játszassa magát.
Szórakoztasson, ne frusztráljon. Legyen benne valamiféle nehézségi fokozat állítás, és a szükségességig (játékfüggő)
precíz játékállásmentés (ha már egyik hardvermaszter sem képes rácuppanni a hw snapshot mentő funkcióra - úgy látszik túl nehéz ... :)),
és hát ezek akkor indukálni fognak egyféle szükséges kontent "mennyiséget" is, tehát pld. nem lehet a játékot összerakni mittomén
10 darab egyképernyős pályával, melyek marha szépen vannak ugyan kidolgozva, de űberveszett nehezek (Pld. Olli and Lissa).

Szóval ez érdekes lesz ... de most valahogy ehhez lett kedvem, ahogy így összeállt az EP konfigom ...
Mégse csak valami tech csillivilli, hanem valamire használni is lehessen ...

Lehet nem lesz X, csak egyetlen darab, de az kompakt és játszható legyen ... mégpedig fenti paraméterekkel ...

Simán lehet hogy nem is fog sikerálni ... :)
Title: Re: game00
Post by: Z80System on 2015.October.12. 19:19:17
Addig is az

Olli and Lissa 3

-mat CPC -ről nem akarja átírni senki ? :) :

https://www.youtube.com/watch?v=zVCc98RNKXY
Title: Re: game00
Post by: Z80System on 2015.October.12. 22:24:00
Szóval egy mondatban összefoglalva: retró játék (ráadásul EP tvíkelt) de mai ízléssel mérve is játszható, kazuárabb cucc, értelem szerűen anélkül hogy 42 óra renderelt animáció lenne benne, meg 172 emberév fejlesztés 127 millió dollárral támogatva ... :)

Gondolok itt olyanra, a galaga valaga témakörén belül, hogy mégha a grafika a 2 piros pötty kerget egy feketét kategóriás is,
akkor is az ellenségek mozgása, változatossága, a nehézség állíthatósága, és hogy nem kell mindíg elölről kezdeni, mert menti a játékállást,
és mert van elég "játékóra" ellenség haladni előre, ez talán élményszerűbbé, kevéssé frusztrálóvá tehet egy ilyen játékot kazuárok számára is ...
Title: Re: game00
Post by: Z80System on 2015.October.14. 22:06:32
Most nézem, a JOE MEGADEMO1 -ben van dual-plane -es grafika ... 2 képet mozgat és mixel össze "villogtatással" szerintem ...

És én valahogy úgy képzeltem, hogy az sokkal jobban villog majd .... de CRT TV -n alig villog ... na jó, nem alig, de azért nézhető ...

Mondjuk az emu -k szerintem megbuknak majd rajta, de elképzelhető hogy a dual-plane -es színkeverést már egyből elkezdem használni ...
Title: Re: game00
Post by: Zozosoft on 2015.October.14. 22:14:42
Ezt nézted már? (http://www.ep128.hu/Ep_Demo/Leiras/Zozolace.html)
Title: Re: game00
Post by: Z80System on 2015.October.14. 22:40:22
Quote
Ezt nézted már?

Eddig nem nagyon néztem,
most néztem (mindkét CRT monitorommal),
csak nem nagyon értem mit látok ...



Először is (minden csak akkor él ha jól látom) HIRES16 színű módban van (de legalábbis a pixelek nyújtottak, lehetne még LORES4 is de mér lenne az, ha csak nem tech kísérlet gyanánt, de ez egy kiadott demó, mér lenne abban ...) és ha jól látom összesen nincs a képeken legtöbbször 8 szín se, de 16 -nál meg tuti nincsen több ...

Másodszor vibrál mint a bolond, ha ennyire kell vibráljon (csak valahogy a MEGADEMO1 karakterisztikájából ez jobban jött ki), akkor inkább mégse fogom alkalmazni.

Harmadszor ez mintha nem "tiszta" dual-plane keverés lenne (két kép pontosan EGYMÁSON), hanem valós függőleges (interlace) elmozdulást is tartalmazó képváltogatás.

Negyedszer az egészen van valami olyan jelenség (a feliratoknál nagyon látszik) mintha így "össze vissza" mozogna a függőleg szinkron, és ez ilyen változó-vastagodó fekete scanline csíkokban meg "eltömődő betűkben" jelentkezne. Mintha afféle interferencia jelenség lenne ...


Szóval nem nagyon értem mit látok, de ha csak ilyet lehet a dual-plane -nel, akkor maradok a normál képnél.
A MEGADEMO1 sokkal meggyőzőbbnek tűnik, de az is igaz hogy ott mozgatják a képeket gyorsan, és egy szín árnyalatai csak a paletta ...
Title: Re: game00
Post by: Zozosoft on 2015.October.14. 22:52:44
Ez HIRES4, 7 színnel.
Két 4 színű kép van mixelve, a fekete közös szín mindkettőben, plusz 3-3 különböző. Az egyik LPT-ben az első kép páratlan sorai vannak, és a másik kép páros sorai, a másik LPT-ben az első kép páros sorai, és a második kép páratlan sorai.
Title: Re: game00
Post by: Z80System on 2015.October.14. 22:59:30
Quote
Ez HIRES4, 7 színnel.

Hmmm ... hát akkor ez a graf nem igényelte a "320" -as felbontást, vagy peniglen világtalan vok.

Quote
Az egyik LPT-ben az első kép páratlan sorai vannak, és a másik kép páros sorai, a másik LPT-ben az első kép páros sorai, és a második kép páratlan sorai.

Ez a kavarás a párossal meg páratlannal pedig elképzelésem nincs mire lehet jó ... interlace LPT ? van függőleges eltolás a két LPT között szinkronnal ?

Mindenesetre amiről én beszélek (és amit a MEGADEMO1 -ben is látni vélek) az 2 töknormál progresszív LPT ami 2 képet váltogatva egymásra vetíti azokat,
és intenzitás vibráción kívül más zavart nem tesz bele.
Title: Re: game00
Post by: geco on 2015.October.15. 08:59:29
Ez a kavarás a párossal meg páratlannal pedig elképzelésem nincs mire lehet jó ... interlace LPT ? van függőleges eltolás a két LPT között szinkronnal ?
Igen
Title: Re: game00
Post by: Z80System on 2015.October.15. 16:53:27
Quote
Igen

Azért találnám ezt teljesen feleslegesnek, amiért a 320 -as felbontást is.

Mert a képek felbontása (szemre, szerintem) ezt egyáltalán nem igényli.
Olyan értelemben, ahogy egy fekete/fehér sakktábla sem igényelné, mert túl kevés benne a szín és túl kevés benne a részlet,
tökéletesen megjeleníthető HIRES16 -ban, teljesen normális progresszív 50HZ -en,
nem kell vibráltatni sem intenzitásokban sem geometriailag.

Az interlace meg egy függőleges felbontást növelő (növelni igyekvő) technika ... ami ezeken a képeken csak ront, nem javít.
Title: Re: game00
Post by: geco on 2015.October.15. 18:33:16
Nem értek egyet, sokkal szebb képeket lehet csinálni, lásd EPIMGCONV-val készített attributum módú interlace képek, és nemcsak a függőleges felbontást lehet megduplázni, hanem a szem átverésével a színek számát is meg lehet növelni,
Zozó interlace Garfield-es képei legfőképp a színsokszorozás miatt készültek, nem a felbontás miatt, össze kéne hasonlítani egy ilyen képet interlace mód 7 szín (4 szín mód felbontásban), és egy sima 4 szín módú képet, meglátszik a különbség.
Amúgy speccyn a R G B 3 kép egymáson villogtatása is eredményez szép képeket, csak villog.
Title: Re: game00
Post by: Zozosoft on 2015.October.15. 18:57:43
Az egész nem ezekről a képekről szól! Volt ez a színlacés ötlet, és kellett hozzá valami amit az én egyszerű grafikához tök hülye agyammal is el tudtam készíteni.
A korábban már létező fekete fehér képekből (http://www.ep128.hu/Ep_Demo/Leiras/Garfield.htm) vettem párat, és paintboxban átszíneztem az egyes területeket. Ennyit még én is fejben tudtam tartani, hogy a 7 színből mit hova kell elszórni az egyes képeken.

A sor váltós villogtatás amúgy onnan jött, hogy így mindig van egyszerre mind a 7 színből a képen. Lehetne egyébként simán felváltva is villogtatni. Ott a forrás, lehet kísérletezni!

És ahogy írtam is anno, azzal is lehetne kísérletezni, hogy a két palettában különböző színeket összekeverve újabbakat létrehozni.

Az igazán érdekes az lenne, ha az imgconv tudna ilyet is, és aztán megnézni mi jön ki belőle...

Title: Re: game00
Post by: Z80System on 2015.October.16. 23:25:39
Na próbálom összerakni az új memóriatérképet az aktuális prioritásoknak megfelelően.

Következőnek tűnik egyenlőre:

b0:
 f8 - common (mindenféle kódok, kisebb méretű táblák, cache -ek, játéklogikák, ellenségmozgatások)

b1:
 f9 - stars (a csillagmozgás fázisai. úgy 4K üres hely maradt még itt.)
 fa - sprites (8-16 fázis. ez az éppen használatos, rendszer ram -ba kibontott, grafikus adatokat is inline tartalmazó sprite kirajzoló kódok szegmense. Nagyon sovi az a 8-16 fázis, ami egyszerre használható lesz. Ne is várjatok szép hosszú animokat. 2 fázisos villódzás, max. Mozgásokból kell tudni valami érdekeset összehekkelni.)

b2:
 fc - video ram + sprite graphics
 fd - video ram + sprite graphics (a három szegmensen összesen 100-300 fázis, ez a normál sprite grafika, ami jó sok, tehát magába a játékba jó sok beleférhet, csak egyszerre lehet majd belőlük keveset látni a képen.)
 fe - video ram + sprite graphics
 ff - lpt + system

b3:
 fb - audio buffer (8-16 sample, ami egyszerre úgy nagyjából elég lehet, csak itt meg tartalék nincs.)


Ahol tól-ig érték van, ott értelem szerűen a méret miatt nem lehet konkrét számot mondani, nagyobb sprite vagy hosszabb minta többet foglal.

Szóval lehetne még ezen finomítani, lehetne az audió buffer és a common szegmensekből valamennyit odatolni még a sprites szegmensnek, valamint a sprite grafiká helyekből áttolni vlaamit plussz hangmintáknak, amiket alkalomadtán az audio buffer -be rakhatnék, de ilyen finomhangolásokkal sztm nem akarok majd foglalkozni.

Inkább hagyom így tisztán 128K -s gépen, és ha lesz még anyag, amit bele kéne tolni, azt majd csak bővített gépeken fogom kezelni. Bővített gépeken viszont annyi hang meg sprite anim lehet majd, mint a tenger ... :)
Title: Re: game00
Post by: Z80System on 2015.October.17. 14:42:29
Á, szép álom volt, de a csillagmozgás beborította, szóval vissza a legkorábbi felálláshoz:



f8 - common

f9 - stars
fa - sprites

fb - samples

fc - video ram + sprite graphics
fd - video ram + sprite graphics
fe - video ram + sprite graphics + lpt

ff - exos (kenje a hajára)



b0:
 f8 - általában ez van itt, és csak ideiglenesen lapozzuk el

 f9 - ha meghívtuk a csillagkirajzolást
 fa - ha meghívtuk a sprite kirajzolást

b1:
 fc - általában ez van itt, és csak ideiglenesen lapozzuk el

 f9 - ha be akarunk valami paramétert állítani a csillagkirajzolónak hívás előtt
 fa - ha be akarunk valami paramétert állítani a sprite kirajzolónak hívás előtt
 fb - hangmegszaknál a megszak lapozza be magának hogy elérje a hangmintákat

b2:
 fd

b3:
 fe



Alapgép: 128K -s EP. 64K -s gépre nem csinálok verziót.
Bővített gép: minimum kb. 4-8 szegmenssel bővített memóriájú gép. Ha végül lesz ilyen verzió, akkor szerintem inkább 8.



common:

Általános kódok, bufferek, cache -ek, táblák, magas szintű játéklogika, ellenségmozgatások.
Ez a szegmens fog saját maga alól kilapozós cross-segment hívásokat kiadni és azok ide térnek majd vissza.
Természetesen ezek a hívott szegmensek is tartalmazni fogják az első 100H -át, ami tartalmazza magát a teljes hangmegszakot,
és a sajátmaga alól kilapozós cross segment hívási és visszatérési kódokat, valamint a stack -et is.
Ha a stack esetleg kicsi lesz valamiért akkor az első 200H lesz ismételve, vagy ilyesmi.
Ezek jelenleg a stars és sprites kódokat tartalmazó szegmensek lesznek.
Ezekből bővített gépen több is lehet persze, alapgépen mindegyikből csak egy lesz.

stars:

Egy 46* 256 bájt méretű csillagmozgatás táblázat (gyakorlatilag előre letárolt animáció) egy speciális formátumban,
melynél gyakorlatilag nem találtam jelentősen gyorsabban megjeleníthető formátumot, ami méretben ne lett volna
minimum dupla, de akár 3-4 szeres méretű.

sprites:

Grafikát is inline magába foglaló sprite fázis kirajzoló rutinok, köztük az eltolt fázisokkal és a törlő rutinokkal.
Ezeket a rutinokat ellenségváltás közben (bővített gép esetén, ahol lehetne hozzá háttérszegmens, esetleg konkrétan játék közben)
remélném generálni a raw grafikából.
Sajnos csak 8-16 (*4 eltolás) darab sprite fázis fog beleférni a szegmensbe, ami mondjuk azt jelentheti egy rosszabb esetben,
hogy ha a főhős karakternek van 4 fázisa, akkor mondjuk az ellenség csupán 1 darab 4 fázisú dolog lehet, vagy 4 db 1 fázisú, stb ...
Arról még lövésem nincs, hogy milyen gyorsan tudom majd generálni ezt a szegmenst a raw grafikából.
Remélem nem fogja a gameplay -t nagyon beszaggatni.

samples:

Hasonló mint az előző, csak nem sprite kódokat cache -el egy pillanatnyi játékhelyzethez, hanem hang mintákat.
Előzőhöz képest különbség, hogy alapgépen csak fel lesz töltve és kész, mert nem lesz honnan összemásolni másik készleteket.
Bővített gépen éppúgy ahogy a sprites kódokat, ezeket is ellenségváltáskor vagy menet közben tervezném összemásolni.
Olyan 8-16 hangminta fog beférni a szegmensre, amit random módon lejátszogathatok játék közben.

sprite graphics:

Raw sprite grafika, ami a 100h -ás sorok közeiben van elrejtve, 1-2 sprite fázis fér el egy közben. Leíró táblák a common szegmensen.
Innen generálom le a sprites szegmenst. Olyan 100-300 sprite fázis fér be még alapgépen is, szóval hely az lesz a grafikának, csak grafika is legyen ...

lpt:

Scanline -onkénti lpb -kből álló lpt, két végén annyi plussz lpb -vel, hogy azok a sprite -ok melyek lpt -t (színeket) is manipulálnak azok ne kelljen
figyeljenek a vágásra függőlegesen itt sem. Lesz jó sok szín ... :)

exos:

Mivel a legújabb erővonalak mentén haladva játékmentést is akarok, esetleg pálya adat betöltést is, ezért mégsem nyírhatom ki az exos -t.
Szóval a szegmensét egyszerűen kihagyom. További exos kompatibilitásra azonban továbbra sem törekszem.

video ram:

Sokat nyűglődtem, hogy megtartsam -e a 100h -ás scanline -okat vagy sem, illetve ha meg is tartom (és így a video RAM 3 szegmensre is szétnyúlik)
akkor megkövetelhessék -e a rajzoló kódok hogy mindhárom szegmens folyamatában be kell legyen lapozva miközben rajzolnak,
vagy tanítsam meg a kirajzolókódokat vágni függőlegesen és lapozzák be maguknak mindíg a szükséges szegmenst.

Különösen problémás a helyzet amiatt, hogy digi hangokat tervezek a játékhoz, aminek a 4K -s megszakítása folyamatosan működik (ami kb. 80 hívást jelent 50Hz -enként ugye),
és azt a megszakítást értelem szerűen a lehető leggyorsabbra kellene megírni, így árnyékregiszteresre lett megoldva, ami nem csinal mást mint beírja a két hangerőportot
(HL),(DE) -ről, majd növeli HL,DE -t. Namost ha a video ram 3 és a 0 -as lapon levo kirajzoló kód 1 lapot igényel, akkor hova rakom a hangmintás szegmenst kirajzolások közben.

Felmerült még bennem, hogy 50 Hz -en másolom a 0 -as lapra a 2* 80 körüli hangmintát, amit aztán a hangmegszak onnan játszhat a következő 80 hívódásakor,
de ez egyrészt nem tetszik, mert ez kb- mínusz 1-2 sprite lenne időben, amiből amúgy is kevés lesz, másrészt pedig ne felejtsük, hogy sajnos a 0 -ás lap sem fix,
az is változik 50 Hz -en belül N -szer ...

A sprite kirakó kódokat még viszonylag 0 időveszteséggel meg lehetett volna tanítani függőlegesen vágni a szegmenshatárokon, viszont a csillagmozgást képtelen voltam
kitalálni nem lassabbra, de lapozást kezelőre. Nem beszélve az esetlegesen közben felmerűlő egyéb rajzolókódokról, amiket még nem is tudom mik lesznek.

Szóval úgy döntöttem megmarad a 100h -ás scanline, sőt vágni sem tanítok meg semmit, a rajzolókódok igényelni fogják a 3+1 lapot,
és a hangmegszakba rakok mégis lapozást.

Remélem ezzel bukom a legkevesebbet, bár még nem mértem ...

Ez volt a régi hangmegszak:

Code: [Select]
void IRQ() __naked
{
__asm

IRQ_B:

ex af, af
exx

ld a, #D_Ints+ 0x2
out (0xb4), a

ld a, (de)
out (0xa8), a
inc de

ld a, (hl)
out (0xac), a
inc hl

exx
ex af, af

ei

ret

IRQ_E:

__endasm;
}

És ezt kell kibővíteni még a lapozással:

Code: [Select]
ld a,b //hangszegmens be
out (0b1h), a

ld a,c //video szegmens vissza
out (0b1h), a

Ez fog 80X meghívódni plusszban egy 50Hz -es időintervallumban ...
Title: Re: game00
Post by: Zozosoft on 2015.October.17. 15:29:07
Bővített gép: minimum kb. 4-8 szegmenssel bővített memóriájú gép. Ha végül lesz ilyen verzió, akkor szerintem inkább 8.
A legkisebb szokásos verzió a 320-as gép, azaz plusz 12 szegmens.
Title: Re: game00
Post by: Z80System on 2015.October.18. 11:52:41
Van valakinek tippje hol találok a neten ilyen 16X16 pixel körüli méretben 2 vagy 4 színnel megrajzolt ellenség sprite -okat,
amik jók lennének ilyen "űrben alulról lövöldözöm őket" játéba ?

Lehetnének szellemek, koponyák, mindenféle űrrovarok, devenérek, akármik,
szóval nyilván tematikában nem kell szorosan az űr koncepciójához tartozniuk,
csak nyilván ne földön futkosó karakterek legyenek, hisz itt minden "repülni" fog.

Mert azt mondjuk vehetjük készpénznek, hogy ha én rajzolom a játék karaktereit,
akkor az a nem jó értelemben lesz vicces :) :


Title: Re: game00
Post by: Z80System on 2015.October.18. 12:09:39
Olyasmikre gondolnék mint pld. ezen a bekarikázott 3 sprite,
csak ezek pld. olyan 20 pixeles körüli méretűek meg színben is olyan 6 színt használnak:
Title: Re: game00
Post by: Z80System on 2015.October.18. 12:21:51
Itt is lenne használható, a szürke fej pld. valszeg 1:1 -ben,
mert méretre is pont 16, meg színre is csak 4 van benne ha jól számolom.

De valami olyasmi tipp kéne, ami esetleg eleve ilyenre lett tervezve,
tehat nem egy "zelda" játék 2 sprite -ja, hanem van több használható egy helyen.
Title: Re: game00
Post by: geco on 2015.October.18. 12:45:18
Ebben van 2 sprite, ami esetleg jó lehetne (http://nestalgiawiki.com/images/7/7d/NEStalgia_Icons.dmi)
Title: Re: game00
Post by: szipucsu on 2015.October.18. 12:46:43
Van valakinek tippje hol találok a neten ilyen 16X16 pixel körüli méretben 2 vagy 4 színnel megrajzolt ellenség sprite -okat,
amik jók lennének ilyen "űrben alulról lövöldözöm őket" játéba ?
Ha te rajzolod, szerintem az is jó lehet. Rajzolhatsz neki nagy füleket, fura csápot, szigorú tekintetet. Vagy kicsit/nagyon be van nyomva a feje oldalról, felülről, furán áll a szeme, ilyesmik. A Nodes of Yesodba is nem tudom, honnan újították azokat a lényeket, eléggé érdekesek, főleg a "pulzáló köd", ami elkábít.
Esetleg ismert politikusok képeinek átkonvertálása? :D
Title: Re: game00
Post by: Z80System on 2015.October.18. 12:52:25
Hát, lehet hogy tényleg az lesz, hogy a meglévő játékokat kell nézegetni, és egyesével vadászni össze belőlük a tematikában passzoló pédányokat,
de jó lenne ezt elkerülni ...

Abban reménykedek hogy találok ilyeneket, mint pld ez a következő is, ami technikailag pont az ami kell,
csak épp figurálisan, ízlésre nem annyira jön be nekem:
Title: Re: game00
Post by: Z80System on 2015.October.18. 12:57:20
Bakker, attachment -ek szempontjából a fórum még mindíg nincs ott a toppon ...

Ez pld. egy gif, ami animál, de bárhogy szúrom be, nem működik ...
Title: Re: game00
Post by: Z80System on 2015.October.18. 12:58:17
Na mindegy, itt az URL -je, valameddig csak élni fog:

(https://38.media.tumblr.com/800f9754a9fa92d8ba800a58754df954/tumblr_ml7jkfpAct1qzizv5o1_500.gif)
Title: Re: game00
Post by: geco on 2015.October.18. 13:06:51
Nézd meg ezt : Galaxian Sprite-ok (http://www.spriters-resource.com/nes/galaxian/sheet/14344/)
Nézz körül ezen az oldalon a NES-t, és SMS-t érdemes sztem nézni, és nem baj, ha nem négyszínű a sprite paletta, meg lehet próbálni EPIMGCONV-val konvertálni, és megnézni a végeredményt.
Title: Re: game00
Post by: Z80System on 2015.October.18. 13:11:07
Quote
Nézd meg ezt : Galaxian Sprite-ok

Nem, galaxy sprite -okat sem akarok ... Még nem láttam olyan galaxy klónt, aminek tetszett volna a grafikája.

Valami ilyen (vagy még) komplexebbet keresek, mint az a "pikacsus" az előbb ...
Title: Re: game00
Post by: geco on 2015.October.18. 13:14:11
Lehet akkor is érdemes körülnézni az előbbi oldalon, rakat sprite van fent
Title: Re: game00
Post by: Z80System on 2015.October.18. 13:22:37
Quote
Lehet akkor is érdemes körülnézni az előbbi oldalon, rakat sprite van fent

Igen az igaz, de akár így, akár vmi emuban nézegetve a játékokat,
ezzel jó sok idő el fog menni ...
Title: Re: game00
Post by: geco on 2015.October.18. 13:29:50
Igen az igaz, de akár így, akár vmi emuban nézegetve a játékokat,
ezzel jó sok idő el fog menni ...
Sajnos ez ilyen, a gúgli nem mindig az ember barátja :( , kidob egy csomó szemetet.
Title: Re: game00
Post by: Z80System on 2015.October.18. 15:12:53
Megpróbáltam fekete háttér elé átrajzolni a cuccot, de nem túl nagy sikerrel egyenlőre ...

Azt kell mondjam nem állunk túl jól ...

Olyasmi vmi grafokat kell keresni, amit eleve fekete háttér elé rajzoltak, és nem fekete kontúrral képzelték el ...

Ráadásul nálam a 4 szín közül 1 a fekete (háttér), egy másik egy scanline -onként változó kékes/sárgás/fehéres átmenet, és csak kettőt lehet szabadon felhasználni, ezek meg 3 színt használnak szabadon ...

És akkor pld. ebben a sárkányban (véregér?) a fehér részek egy ilyen változó színátmenet lenne, aminek a tényleges színe attól függne, hogy hol van a képen függőlegesen éppen a sprite ...
Title: Re: game00
Post by: Z80System on 2015.October.18. 15:41:32
Igazából talán olyan nagyon-nagyon rosszul nem is mutat ... valami absztrakt háromszögnél, karikánál, nonfiguratív formánál legalábbis biztos jobban mutathat majd ...

Meg még 2 fázisból animál is majd ugye ...

Nemtom ... :)
Title: Re: game00
Post by: Z80System on 2015.October.18. 21:01:49
Upszi ... kéne valaki okos megszakértse a dolgot:

Az ep128emu2 -ben gond nélkül futtatok 368 X 272 pixel méretű LPT -vel rendelkező játékot.

Van arra esély hogy ezt nekem megjelenítik valós monitorok ? Vagy én ezt csak összefantáziáltam valahonnan, ill. az emuból ? :)
Title: Re: game00
Post by: geco on 2015.October.19. 09:05:11
Megpróbáltam fekete háttér elé átrajzolni a cuccot, de nem túl nagy sikerrel egyenlőre ...

Azt kell mondjam nem állunk túl jól ...

Olyasmi vmi grafokat kell keresni, amit eleve fekete háttér elé rajzoltak, és nem fekete kontúrral képzelték el ...

Ráadásul nálam a 4 szín közül 1 a fekete (háttér), egy másik egy scanline -onként változó kékes/sárgás/fehéres átmenet, és csak kettőt lehet szabadon felhasználni, ezek meg 3 színt használnak szabadon ...

És akkor pld. ebben a sárkányban (véregér?) a fehér részek egy ilyen változó színátmenet lenne, aminek a tényleges színe attól függne, hogy hol van a képen függőlegesen éppen a sprite ...
Nem kell olyat keresned, tedd fel a GIMP-et, és pár klattyintással le tudod cserélni a színeket. (select by volor, fill with fg color)
A Sprite világos színe helyett használhatod a kékes/sárgás/fehéres átmenetet, szerintem a legtöbb esetben nem lesz feltűnő.
Title: Re: game00
Post by: ergoGnomik on 2015.October.19. 12:13:46
Upszi ... kéne valaki okos megszakértse a dolgot:

Az ep128emu2 -ben gond nélkül futtatok 368 X 272 pixel méretű LPT -vel rendelkező játékot.

Van arra esély hogy ezt nekem megjelenítik valós monitorok ? Vagy én ezt csak összefantáziáltam valahonnan, ill. az emuból ? :)
Nem szakértés.

A PAL videosorban van 52us látható rész a 64us-os teljes sorból. Ez 81,25%. A plus/4-esen ez 370,5 képpont a 456 lehetségesből, és ebből a tényleges megjelenítő terült 320 pixel széles. Viszont van olyan billentyűparancs amivel ezt le lehet csökkenteni 304-re, hogy biztosan elférjen a korabeli monitorokon a megjelenítendő információ. Szóval én nem bizakodnék abban hogy tetszőleges megjelenítőn minden látszani fog széltében.

Függőlegesen fogalmam sincs, 240 (jó esetben 256) sort el tudok képzeni, mint biztosan látszó területet. De lehet esetleg számolgatni valamit a 4:3-as képarány alapján. Mondjuk az pont 240.

De csatlakoztasd fel a Commodore monitorodra amit egyszer említettél, annál jobb próba szerintem nem kell. Tudom, ezt akartad volna elkerülni.
Title: Re: game00
Post by: szipucsu on 2015.October.19. 18:54:40
Igazából talán olyan nagyon-nagyon rosszul nem is mutat
Persze, jó lesz az! Valamilyen figura, és animált is. Nem kell művészi grafikának lennie.
Title: Re: game00
Post by: Z80System on 2015.November.01. 17:42:19
Hmmm ...

Lehet hogy ez mindenkinek triviális rajtam kívül, de eszembe jutott egy lájvszéver dolog ...

Az "esett le" hogy tulajdonképp azon kódok 99% -a, melyek megengedik, megengednék hogy magasabb szintű nyelveken íródjanak,
és a közvetlen assembly optimalizálást nem igénylik ... azok valami futási időben nem változó, adatszerű dolgot írnak le,
adatszerű dolgot generálnak.

Tehát pld. eleddig egy LPT tábla generálást, egy csillagmozgás adattábla generálást, ilyesmiket ugye az SDCC -ben írtam le,
egyrészt azért hogy ne kelljen külső mondjuk C projektet felvenni, abban kimentegetni, a konstansokat duplán felvenni, nyilvántartani,
az egész olyan nehézkes ahhoz képest, mintha egyből a "játékba" írom ...

Aztán most hogy áttértem az assembly -re igyekeztem volna ugye azért az ilyen jellegű feladatokhoz nem elveszíteni a kényelmet és
a fejlesztési sebességet.

Ráadásnak most ráeszméltem, hogy pld. az LPT tábla (amit eddig eszembe nem jutott volna egy EP programnál nem "on the fly",
inicializálási időben generálni) ... az is milyen konstans egy dolog már ... gyakorlatilag az adott program konstansai teljesen leírják,
abból generálható, én még a memóriacímeket sem frissítem benne futási időben (mert lassú, még assembly -ben is), hanem vátogatok 2 előgenerált LPT táblát,
szóval az esetek 99% -ában minden ilyen dolog csupán az adott EP projekt konstansaitól függ, de valójában statikus dolog, fordítási időben leírható ...

És abban a fennmaradó részben ahol nem írható le fordítási időben ... na ott meg máris kell az assembly optimalizáció, ott nem megúszható ...

És csak a lehető legritkább (kockáztatom: a projektjeimnél zéró) esetben van az, hogy az adott kód futhat ugyan inicializálási időben, tehát nem kell
hozzá assembly optimalizálás, viszont nem írható le fordítási időben ... nem állítom hogy ilyen nincs, de nekem nem nagyon lesz ...



Szóval a következőt találtam ki:

Az EP projekt build -em egy komplexebb make "projekt" lett, több egymás után leforduló ÉS fordítási időben le is futó,
akár különböző nyelvi és technológiai megvalósítású komponensek összessége.
Ezek nálam nagyjából most úgy tűnik hogy a brass és a VC++ lesz,
de elvi szempontból tökmindegy, és változhat, bővülhet is.

A dolog úgy néz ki, hogy a programok konstansait pld. egy saját "makrónyelven" írom, melyet én rögtönöztem magamnak.
Attól lett "makrónyelv", hogy konkrétan C makrókkal dolgozom fel ezeket a konstansokat (majd szép lassan bővítem a makrókat, ahogy szükség lesz rá),
van olyan makró ami egy kommentet hoz létre a végső generált fájlokban (csak hogy ott is legyen komment, ne csak ebben az eredeti makró file -ban),
van amelyik ilyen vagy olyan típusú konstansot, satöbbit.

Valamint csináltam egy ilyen pársoros C++ programot, mely magába inklúdolja ezt a makró nyelven írt konstans file -t (rendesen compile time, #include -dal),
nyilván meg vannak írva benne a makrók, meg egyéb C++ progi, mely képes kimenteni a beinklúdolt file -okat a brass és a C++ (vagy ami még csak lesz később)
által inklúdolható formában.
Így akkor nem kell minden hülye nyelvhez és technológiához külön párhuzamosan nyilván tartanom egy adott EP projekt konstansait, közös adatait,
hanem generálódnak egy közös formából,
viszont nem is kellett normális programot írjak ami parszol valami saját formátumból,
vagy nem kell a konstansokhoz általános és bőlére eresztett formákat használjak mint pld. az XML,
valamint ki tudom használni a meglévő nyelvek makró funkcióit.

Persze a GNU világegyetemben ismert mindenféle texttranszformációs kütyükkel meg lehetne ezt oldani biztosan elegánsabban is,
melyben használhatnám a saját formát is, mégsem kéne parszereket hekkeljek, hanem egyszerű szabályokkal kifejezhető lenne ilyesmi átalakítás,
de részint nem ismerek ilyeneket, részint jó érezni, hogy a full C++ technológia ott van az ember háta mögött, és semmi nem tudja megakasztani ... :)

Miután ez a progi lefordult, mindjárt le is fut, és kiköpi magából a C++ és brass fordítók által megértett konstans file -okat.

Aztán a következő lépésben lefordul egy szintén kicsi, egy .cpp -s C++ progi (minden külön projektfile, meg ilyesmi nélkül, csak úgy commandline -ból),
mely inkúdolja előzőben generált konstans file -okat, és így meg lehet írni benne az LPT generáló kis C++ kódot, mely kimenti az LPT -ket egy file -ba.

Bármit változtatok a közös konstans file -okban, az tehát egyből egy módosult generált LPT file -t okozhat.

Aztán ugyanez a csillagok generálásával, majd ugyanez bármivel.

Az EP progi pedig mindent csak tölt és használ, semmit nem generál.

Így gyors is lesz a fejlesztés, kedvenc nyelve(i)men akármilyen kényelmesen írhatom őket,
az EP- n pedig még csak a helyet sem foglalják a generáló kódok, mindent oda töltök be,
ahol az valóban van az EP progi futása alatt.


Namost mindebben nincs semmi különösebb finesz,
azon az egy meglátáson kívül, hogy egy ilyen EP demo/game projektben kb. semmi nem olyan,
hogy inicializálási időben futhat, ezért nem kell mindenképp assembly optimalizálni,
viszont futási időben változtatni kéne a lefutást, és így nem lehet egyszerű adatfájlként betölteni.
Title: Re: game00
Post by: Z80System on 2015.November.01. 18:07:16
Persze az is igaz, hogy valahol elvben ez a háttértárigényt többszörözheti,
egy 4K-8K -s méretű LPT tábla assembly generáló kódjának mérete eltörpül az LPT mérete mellett,

így remek "tömörítő kodek" az assembly LPT generáló kód,

de mivel nem magnóról toljuk, és a háttértár mérete is gyakorlatilag korlátlan,
ezért a fejlesztési sebesség növekedése sztm. simán megéri ezt a háttértárméret növekedést ...

(LPT helyett odaképzelhető bármilyen tábla, adatszerkezet, kóddal generálható akármi ...)
Title: Re: game00
Post by: Zozosoft on 2015.November.01. 18:50:07
Nem mondom, hogy végig értem amiről beszélsz :oops: