AGA Amiga näyttötilat vs. PC VGA/SuperVGA

NYT MINÄ POISTIN WINDOWSIN!

Olet oikeassa, OCS chipsetissä ei kaistanleveys riitä 640 resoluutioon ja 6 bittitasoon.

Mutta nyt on asia niin, että nuo fotorealistiset kuvat A500/A2000:lla ei tehtykään HAM6-tilassa, vaan tavallisessa 4 bittitason 640x400 resoluutiossa, ja copperia käytettiin vaihtamaan värejä jokaisella rivillä, niin että kuvassa on kuitenkin tuhansia värejä. Rajoitus tässä on että vain 16 eri väriä per jokainen rivi.

Eli Amigalla voi tehdä HAM6/HAM8-tilojen lisäksi copperin avulla fotorealistisia kuvia. HAM8-tila toimii AGA-Amigoissa kuitenkin niin hyvin, että copperin kanssa ei tarvitsee temppuilla, sillä sekin syö DMA-kaistanleveyttä paljon, jos värejä vaihtaa jokaisella rivillä paljon.

Anonyymi kirjoitti:

Olet oikeassa, OCS chipsetissä ei kaistanleveys riitä 640 resoluutioon ja 6 bittitasoon.

Mutta nyt on asia niin, että nuo fotorealistiset kuvat A500/A2000:lla ei tehtykään HAM6-tilassa, vaan tavallisessa 4 bittitason 640x400 resoluutiossa, ja copperia käytettiin vaihtamaan värejä jokaisella rivillä, niin että kuvassa on kuitenkin tuhansia värejä. Rajoitus tässä on että vain 16 eri väriä per jokainen rivi.

Eli Amigalla voi tehdä HAM6/HAM8-tilojen lisäksi copperin avulla fotorealistisia kuvia. HAM8-tila toimii AGA-Amigoissa kuitenkin niin hyvin, että copperin kanssa ei tarvitsee temppuilla, sillä sekin syö DMA-kaistanleveyttä paljon, jos värejä vaihtaa jokaisella rivillä paljon.

Lue lisää

Taisi olla nimellä Dynamic Hires. Tuo tosin kulutti melkoisesti prosessoritehoa, joten se taisi sopia lähinnä still-kuviin.

Anonyymi kirjoitti:

Taisi olla nimellä Dynamic Hires. Tuo tosin kulutti melkoisesti prosessoritehoa, joten se taisi sopia lähinnä still-kuviin.

Ei se kuluttanut lainkaan prosessoritehoa, mutta grafiikkamuisti meni kyllä jumiin tuollaisesta, eli prosessori ei saanut juuri aikajaksoja kirjoittaakseen tai lukeakseen chip ram muistiin jotain, mutta jos Amigassa oli FAST-laajennusmuistia, niin prosessori kyllä pyöri siellä täydellä nopeudella.

Rasterikeskeytykset prosessorilla on vanhanaikaista tekniikkaa, ja sitä käyttivät lähinnä C64 ja Atari ST, Amigassa copper hoitaa homman paremmin, ilman että prosessori kuormittuu.

Kannattaa huomata että nämä dynamic hires, sliced HAM-, ja sliced EHB-tekniikat eivät ole vain teoreettisia, vaan niitä voidaan käyttää peleihin myös. Vanhoissa Amigoissa oli ongelma seikkailupeleissä että 32/64 väriä ei riittänyt taustoihin, kun PC:llä vedettiin VGA:n 256 värillä, mutta esim. A500:lle tehty Universe (1994) pelissä käytettiin myös 256 väriä taustoihin samalla tyylillä kuin dynamic hires-moodissa.

Peleissä on kuitenkin lisäongelma: hahmojen värit sekoavat, kun hahmot liikkuvat ympäriinsä, ja värejä vaihdellaan joka rivillä ruudulla. Ratkaisuna tähän on pitää esim. puolet väreistä muuttumattomina, ja käyttää niitä ainoastaan hahmoihin. Tämä toimii esim. 32 tai 64 värin näyttötilassa varsin hyvin. Hardware spritet Amigoissa tietysti toimivat aina taustasta riippumatta, mutta ne eivät yleensä riittäneet peleihin, kun olivat OCS-Amigoissa vain 16 pikseliä leveitä ja niitä oli vain 8 kpl.

Anonyymi kirjoitti:

Ei se kuluttanut lainkaan prosessoritehoa, mutta grafiikkamuisti meni kyllä jumiin tuollaisesta, eli prosessori ei saanut juuri aikajaksoja kirjoittaakseen tai lukeakseen chip ram muistiin jotain, mutta jos Amigassa oli FAST-laajennusmuistia, niin prosessori kyllä pyöri siellä täydellä nopeudella.

Rasterikeskeytykset prosessorilla on vanhanaikaista tekniikkaa, ja sitä käyttivät lähinnä C64 ja Atari ST, Amigassa copper hoitaa homman paremmin, ilman että prosessori kuormittuu.

Kannattaa huomata että nämä dynamic hires, sliced HAM-, ja sliced EHB-tekniikat eivät ole vain teoreettisia, vaan niitä voidaan käyttää peleihin myös. Vanhoissa Amigoissa oli ongelma seikkailupeleissä että 32/64 väriä ei riittänyt taustoihin, kun PC:llä vedettiin VGA:n 256 värillä, mutta esim. A500:lle tehty Universe (1994) pelissä käytettiin myös 256 väriä taustoihin samalla tyylillä kuin dynamic hires-moodissa.

Peleissä on kuitenkin lisäongelma: hahmojen värit sekoavat, kun hahmot liikkuvat ympäriinsä, ja värejä vaihdellaan joka rivillä ruudulla. Ratkaisuna tähän on pitää esim. puolet väreistä muuttumattomina, ja käyttää niitä ainoastaan hahmoihin. Tämä toimii esim. 32 tai 64 värin näyttötilassa varsin hyvin. Hardware spritet Amigoissa tietysti toimivat aina taustasta riippumatta, mutta ne eivät yleensä riittäneet peleihin, kun olivat OCS-Amigoissa vain 16 pikseliä leveitä ja niitä oli vain 8 kpl.

Lue lisää

"Vanhoissa Amigoissa oli ongelma seikkailupeleissä että 32/64 väriä ei riittänyt taustoihin, kun PC:llä vedettiin VGA:n 256 värillä, mutta esim. A500:lle tehty Universe (1994) pelissä käytettiin myös 256 väriä taustoihin samalla tyylillä kuin dynamic hires-moodissa."

Ihme pelleilyä. A500:lla olisi ollut parasta tallentaa vaan 32 värisinä ne kuvat ja keskittyä siihen, että paletti ja kuvat ovat huolella optimoituna ja pakattuna datakompressiolla pieneksi.

Ei johtunut pelkästään siitä, että olisi säästynyt kikkailulta vaan A500:ssa oli myös pienemmät levykkeet. Olisi sopinut paljon enemmän grafiikkaa sinne vähemmällä kikkailulla.

Anonyymi kirjoitti:

"Vanhoissa Amigoissa oli ongelma seikkailupeleissä että 32/64 väriä ei riittänyt taustoihin, kun PC:llä vedettiin VGA:n 256 värillä, mutta esim. A500:lle tehty Universe (1994) pelissä käytettiin myös 256 väriä taustoihin samalla tyylillä kuin dynamic hires-moodissa."

Ihme pelleilyä. A500:lla olisi ollut parasta tallentaa vaan 32 värisinä ne kuvat ja keskittyä siihen, että paletti ja kuvat ovat huolella optimoituna ja pakattuna datakompressiolla pieneksi.

Ei johtunut pelkästään siitä, että olisi säästynyt kikkailulta vaan A500:ssa oli myös pienemmät levykkeet. Olisi sopinut paljon enemmän grafiikkaa sinne vähemmällä kikkailulla.

Lue lisää

Kannattaa huomata että dynamic hires tai muut vastaavat tekniikat vievät hyvin vähän lisätilaa.

Esim. 24-bittinen kuva esitetään vain 4 bitillä värilista, joka on erittäin pieni. Esim. NewTekin fotorealistiset kuvat (tai niin fotorealistisia kuin voivat olla 4096 värin paletilla), 640x400/4 bittiä vie 128 kt muistia värilista 12800 tavua (16 väriä vaihdetaan jokaisella rivillä 400 kertaa).

Näissä ei mitään kompressiota tai dekompressiota käytetä. Universen tapauksessa värivaihtolista olisi hyvin pieni, murto-osa itse pikselidatasta.

Pitää olla tietysti ohjelma joka konvertoi 24-bittiset kuvat, tai 16-bittiset kuvat dynamic hires kuviin. Mutta lopputuloksena on että tällaiset kuvat vievät hyvin vähän tilaa, kompressio voi olla jopa parempaa kuin jpegissä laatu huomioiden, paitsi että mitään dekompressiota ei tarvita.

Anonyymi kirjoitti:

Kannattaa huomata että dynamic hires tai muut vastaavat tekniikat vievät hyvin vähän lisätilaa.

Esim. 24-bittinen kuva esitetään vain 4 bitillä värilista, joka on erittäin pieni. Esim. NewTekin fotorealistiset kuvat (tai niin fotorealistisia kuin voivat olla 4096 värin paletilla), 640x400/4 bittiä vie 128 kt muistia värilista 12800 tavua (16 väriä vaihdetaan jokaisella rivillä 400 kertaa).

Näissä ei mitään kompressiota tai dekompressiota käytetä. Universen tapauksessa värivaihtolista olisi hyvin pieni, murto-osa itse pikselidatasta.

Pitää olla tietysti ohjelma joka konvertoi 24-bittiset kuvat, tai 16-bittiset kuvat dynamic hires kuviin. Mutta lopputuloksena on että tällaiset kuvat vievät hyvin vähän tilaa, kompressio voi olla jopa parempaa kuin jpegissä laatu huomioiden, paitsi että mitään dekompressiota ei tarvita.

Lue lisää

Älä nyt viitsi, 128kt on aika paljon jossain 800kt korpulta.

32 väriä 320x200 on 64000 5 bitin pikseliä, eli 40000 bittiä.

Paitsi että tähän kun yhdistää jonkun LZSS, RLE ja Huffman koodaukset niin vie helposti kolmanneksen, eli ruudullinen grafiikkaa olisikin 14kt.

Jpeg on kyllä miten päin vain parempi. Jpegillä menee 100kt kokoon joku 1280x720 24bit/pikseli.

Eli, Amiga 500:lla se 32 värinen palettikuva oli oikeasti paras seikkailupeleissä kun tallennustilaa oli niin vähän. Korppua ei oikein jaksanut vaihdella muuten kuin isommalta alueelta toiseen siirryttäessä tai jos tarinassa "luku 1" niin sitten kun vaihtaa lukua niin siinä yhteydessä, että ei tarvitse kokoaika vaihdella levykkeitä. Amiga 500:lle kiintolevy oli vain 20 megaa että se oli ennemminkin vain työtilaa ettei sitä mihinkään peleihin pahemmin haaskattu. Sen ajan Amiga peli oli hyvä saada sopimaan enintään seitsemälle levykkeelle. Jpegiä ei Amiga 500:n aikoina ollut ja sillä olisi joutunut odottaa purkua ikuisuuden ja olisi vain syönyt muistia. Lisäksi se grafiikka tietenkin olisi hyvä olla animoituna.

Nykypäivänä on vastaavia rajoitteita Android peleissä. Yksi "kartta", "luku", "scene", "alue" tms. pitäisi saada sopimaan pakattuna 150Mt lataukseen joita on enintään 50kpl. Eli vaikka tehoja riittää niin rajoite tulee siitä, että miten saa sopimaan kokoon jossa käyttö on mukavaa.

Anonyymi kirjoitti:

Älä nyt viitsi, 128kt on aika paljon jossain 800kt korpulta.

32 väriä 320x200 on 64000 5 bitin pikseliä, eli 40000 bittiä.

Paitsi että tähän kun yhdistää jonkun LZSS, RLE ja Huffman koodaukset niin vie helposti kolmanneksen, eli ruudullinen grafiikkaa olisikin 14kt.

Jpeg on kyllä miten päin vain parempi. Jpegillä menee 100kt kokoon joku 1280x720 24bit/pikseli.

Eli, Amiga 500:lla se 32 värinen palettikuva oli oikeasti paras seikkailupeleissä kun tallennustilaa oli niin vähän. Korppua ei oikein jaksanut vaihdella muuten kuin isommalta alueelta toiseen siirryttäessä tai jos tarinassa "luku 1" niin sitten kun vaihtaa lukua niin siinä yhteydessä, että ei tarvitse kokoaika vaihdella levykkeitä. Amiga 500:lle kiintolevy oli vain 20 megaa että se oli ennemminkin vain työtilaa ettei sitä mihinkään peleihin pahemmin haaskattu. Sen ajan Amiga peli oli hyvä saada sopimaan enintään seitsemälle levykkeelle. Jpegiä ei Amiga 500:n aikoina ollut ja sillä olisi joutunut odottaa purkua ikuisuuden ja olisi vain syönyt muistia. Lisäksi se grafiikka tietenkin olisi hyvä olla animoituna.

Nykypäivänä on vastaavia rajoitteita Android peleissä. Yksi "kartta", "luku", "scene", "alue" tms. pitäisi saada sopimaan pakattuna 150Mt lataukseen joita on enintään 50kpl. Eli vaikka tehoja riittää niin rajoite tulee siitä, että miten saa sopimaan kokoon jossa käyttö on mukavaa.

Lue lisää

En minä sanonut että 640x400 resoluutiossa pitäisi tehdä seikkailupelejä vanhoille Amigoille. Silloin nimittäin jokainen kuva vie 128 kt muistia. Dynamic hires toimii kaikissa näyttötiloissa, eikä se varsinkaan Universe-pelissä vie juuri yhtään sen enempää tilaa kuin vähävärisempi 32 värin kuva, mutta käytössä on silti 256 väriä, tai vaikka muutama tuhat väriä.

Mutta edellämainitussa resoluutiossa (640x400) kompressio olisi noin 6:1 dynamic hiresillä, jpeg:lla varmaan yleisesti ottaen pääsee 10:1 suhteeseen, ilman että kuvan laatu kärsii paljon. Mutta dynamic hiresissä ei tarvitse lainkaan aikaavievää dekompressiota, mikä on välttämätöntä vanhoissa koneissa, jossa jpegin dekompressio veisi kirjaimellisesti ikuisuuden. Jpeg dekompressio on todella tehosyöppö algoritmi, joka on hidas kuin etana vielä 68030/50 MHz prosessorilla.

Anonyymi kirjoitti:

En minä sanonut että 640x400 resoluutiossa pitäisi tehdä seikkailupelejä vanhoille Amigoille. Silloin nimittäin jokainen kuva vie 128 kt muistia. Dynamic hires toimii kaikissa näyttötiloissa, eikä se varsinkaan Universe-pelissä vie juuri yhtään sen enempää tilaa kuin vähävärisempi 32 värin kuva, mutta käytössä on silti 256 väriä, tai vaikka muutama tuhat väriä.

Mutta edellämainitussa resoluutiossa (640x400) kompressio olisi noin 6:1 dynamic hiresillä, jpeg:lla varmaan yleisesti ottaen pääsee 10:1 suhteeseen, ilman että kuvan laatu kärsii paljon. Mutta dynamic hiresissä ei tarvitse lainkaan aikaavievää dekompressiota, mikä on välttämätöntä vanhoissa koneissa, jossa jpegin dekompressio veisi kirjaimellisesti ikuisuuden. Jpeg dekompressio on todella tehosyöppö algoritmi, joka on hidas kuin etana vielä 68030/50 MHz prosessorilla.

Lue lisää

Niin AGA vehkeillä kyllä 640x400 olisi toiminut vähän staattisemmassa grafiikassa. Sopiva vaikka strategiapeleihin, luolastoseikkailuun, tekstiseikkailuun tai sellaiseen missä UI vie tilaa.

Jpegin sijasta joku LZSS, Huffman ja RLE koodauksia jolloin kuva olisi helposti <90k.

Korpuilla 640x400 oli vähän liikaa full screen grafiikalle kun ei sitten olisi sopinut mitään, että CD-ROM:ia tarvitsisi. Toiminnallisemmassa ja animoidummassa fullscreen grafiikassa 320x200 256 värillä olisi sitten toiminut hyvin. Siinä CD-ROM sitten mahdollistaisi tietenkin esirenderöidyn tai videokameralla kuvatun videon.

Anonyymi kirjoitti:

En minä sanonut että 640x400 resoluutiossa pitäisi tehdä seikkailupelejä vanhoille Amigoille. Silloin nimittäin jokainen kuva vie 128 kt muistia. Dynamic hires toimii kaikissa näyttötiloissa, eikä se varsinkaan Universe-pelissä vie juuri yhtään sen enempää tilaa kuin vähävärisempi 32 värin kuva, mutta käytössä on silti 256 väriä, tai vaikka muutama tuhat väriä.

Mutta edellämainitussa resoluutiossa (640x400) kompressio olisi noin 6:1 dynamic hiresillä, jpeg:lla varmaan yleisesti ottaen pääsee 10:1 suhteeseen, ilman että kuvan laatu kärsii paljon. Mutta dynamic hiresissä ei tarvitse lainkaan aikaavievää dekompressiota, mikä on välttämätöntä vanhoissa koneissa, jossa jpegin dekompressio veisi kirjaimellisesti ikuisuuden. Jpeg dekompressio on todella tehosyöppö algoritmi, joka on hidas kuin etana vielä 68030/50 MHz prosessorilla.

Lue lisää

Ei se jpeg oikeasti nykyään mikään tehosyöppö ole. Sitä vaan ei peleissä käytännössä tarvinnut aikoinaan kun grafiikka oli suorituskyky- ja muistisyistä 8-bit/pikseli. Siihen se sopi huonosti.

Joskus vuonna 1998 kun joku Celeron 300MHz alkoi olla normi niin sillä oli järkeä pakata osa grafiikasta mikä meni sellaisenaan ruudulle jos grafiikkaa oli niin paljon, että ei sopinut kunnolla CD-levyille. Oli itseasiassa helposti suorituskykyisempi kuin PNG kuvat. 3D-kiihdyttimissä suosittiin silloin 8-bit/pixel että ne meni eri tavalla.

Nykyään usein on niin, että on vaikka tekstuuripakkaus, että pakataan 4-bit/pikseli ja on pakattuna muistissa ja tuo sitten on pakattuna deflate pakkauksella kun ladataan verkosta tai SSD:ltä

Mainittakoon, että joskus 1992 tietokoneet olivat niin hitaita, että jos enemmänkin oli vilskettä ruudulla niin 320x200 resoluutio oli ideaalinen. Joku 640x480 256 värillä sopi ikkunointiympäristössä ajettaviin peleihin missä ruudulla ei ollut paljoa liikettä. 16-bit tai 24-bit väriavaruudet sitten mediahommissa.

A500:n HAM6-moodi on aika paska, sitä ei kyllä saa 640x400 resoon, taitaa 320x400 tai 320x512 olla maksimi.
Ja sen päällä ei voi juuri liikuttaa objekteja, kun värit sekoavat.

Mutta AGA:n HAM8-moodin käyttäminen peleissä on vielä aktiivisen tutkimuksen alla, miten värien sekoamista saisi hillittyä.

SVGA-näytönohjaimissa ei yleensä ollut kuin 2 megatavua muistia, joten 1280x1024 24 bitillä voi unohtaa. Itsellänikin oli vuonna 1997 hankittu SVGA-näytönohjain jossa 2 megaa muistia.

Anonyymi kirjoitti:

A500:n HAM6-moodi on aika paska, sitä ei kyllä saa 640x400 resoon, taitaa 320x400 tai 320x512 olla maksimi.
Ja sen päällä ei voi juuri liikuttaa objekteja, kun värit sekoavat.

Mutta AGA:n HAM8-moodin käyttäminen peleissä on vielä aktiivisen tutkimuksen alla, miten värien sekoamista saisi hillittyä.

SVGA-näytönohjaimissa ei yleensä ollut kuin 2 megatavua muistia, joten 1280x1024 24 bitillä voi unohtaa. Itsellänikin oli vuonna 1997 hankittu SVGA-näytönohjain jossa 2 megaa muistia.

Lue lisää

Ei siinä mitään tutkimista ole ollut. Edelleenkin sen ajan koneet olivat hitaita että AGA:lla toimi parhaiten 256 värinen tila. Ja tosiaankin sen ajan Amigassa sen verran vähän CPU tehoa että ei oikein pyörittänyt 3d grafiikkaa.

Eikä näillä tee enää mitään kun heikoin grafiikkasuorituskyky löytyy nykyään jostain Raspberry Pi koneista ja siinäkin on 4Gb/s muistikaista ja 3D-kiihdytys. Käytännössä pyörittelee 64Mb muistiin sopivaa sceneä ja videomuistia stencil bufferilla toteutuilla varjoilla ja per vertex varjostuksella.

Ei sitten tarvitse mennä kuin uuteen tablettiin niin on jo 64Gb/s muistikaista, OpenGL ES 3.0, per pixel varjostus. Lähinnä optimoidaan sitä että saisi scenen sopimaan pakattuna 150 megan lataukseen.

Pelikäytössä vuonna 1997 melko normi oli joku 640x480 16-bit/pikseli.

Anonyymi kirjoitti:

A500:n HAM6-moodi on aika paska, sitä ei kyllä saa 640x400 resoon, taitaa 320x400 tai 320x512 olla maksimi.
Ja sen päällä ei voi juuri liikuttaa objekteja, kun värit sekoavat.

Mutta AGA:n HAM8-moodin käyttäminen peleissä on vielä aktiivisen tutkimuksen alla, miten värien sekoamista saisi hillittyä.

SVGA-näytönohjaimissa ei yleensä ollut kuin 2 megatavua muistia, joten 1280x1024 24 bitillä voi unohtaa. Itsellänikin oli vuonna 1997 hankittu SVGA-näytönohjain jossa 2 megaa muistia.

Lue lisää

Niin ja mitä peleihin tulee niin AGA oli ilmestyessään parempi kuin vanha VGA ja lisäksi halpa tapa saada isoja resoluutioita ja värimääriä.

Tämä ei ollut Amigan ongelma peleissä. Ongelma oli heikko CPU-teho kun silloin kun Aga tuli, tuli myös 486DX2/66 CPU mille alettiin tehdä pelejä ja se riitti peleihin useita vuosia.

Anonyymi kirjoitti:

Ei siinä mitään tutkimista ole ollut. Edelleenkin sen ajan koneet olivat hitaita että AGA:lla toimi parhaiten 256 värinen tila. Ja tosiaankin sen ajan Amigassa sen verran vähän CPU tehoa että ei oikein pyörittänyt 3d grafiikkaa.

Eikä näillä tee enää mitään kun heikoin grafiikkasuorituskyky löytyy nykyään jostain Raspberry Pi koneista ja siinäkin on 4Gb/s muistikaista ja 3D-kiihdytys. Käytännössä pyörittelee 64Mb muistiin sopivaa sceneä ja videomuistia stencil bufferilla toteutuilla varjoilla ja per vertex varjostuksella.

Ei sitten tarvitse mennä kuin uuteen tablettiin niin on jo 64Gb/s muistikaista, OpenGL ES 3.0, per pixel varjostus. Lähinnä optimoidaan sitä että saisi scenen sopimaan pakattuna 150 megan lataukseen.

Pelikäytössä vuonna 1997 melko normi oli joku 640x480 16-bit/pikseli.

Lue lisää

Kyllä siinä tutkimista on, niin kauan kuin ei tiedetä.

Oman kokemukseni mukaan pelit ovat vain huonontuneet viime vuosina, mitä enemmän tehoja on tarjolla (esim PS5). Kun tehoa on tiettyyn pisteeseen asti, ei lisätehot enää auta. Ei ole mitään järkeä verrata Amigaa nykyajan laitteisiin. Jopa FPGA-Vampire Amigassa on niin paljon tehoja, että siinä menee vuosia ennenkuin sen kaikki salat ja potentiaali on tutkittu.

Amigan valtti on helppokäyttöisyys ja helposti ohjelmoitavuus assemblertasolla, mitä muut laitteet eivät voi tarjota. Ja tietysti reaaliaikaisuus, kun oma ohjelma vain pyörii muistissa, niin se pyörii aina niin hyvin kuin voi, ei ole käyttöjärjestelmää tai muita ohjelmia välissä. Ja Amigasta saa kaiken irti, kun ei ole softarajapintoja, jos ei halua käyttää. Eikä tarvitse prosessorituulettimia ja äänekästä sähkösyöppöä laitetta.

Uusi 64-bittinen FPGA-Vampire sen myös demonstroi: soitat musaa taustalla 5:llä assemblerkäskyllä, ja käytössä on 16 audiokanavaa, jossa 16-bittinen laatu.

Anonyymi kirjoitti:

Kyllä siinä tutkimista on, niin kauan kuin ei tiedetä.

Oman kokemukseni mukaan pelit ovat vain huonontuneet viime vuosina, mitä enemmän tehoja on tarjolla (esim PS5). Kun tehoa on tiettyyn pisteeseen asti, ei lisätehot enää auta. Ei ole mitään järkeä verrata Amigaa nykyajan laitteisiin. Jopa FPGA-Vampire Amigassa on niin paljon tehoja, että siinä menee vuosia ennenkuin sen kaikki salat ja potentiaali on tutkittu.

Amigan valtti on helppokäyttöisyys ja helposti ohjelmoitavuus assemblertasolla, mitä muut laitteet eivät voi tarjota. Ja tietysti reaaliaikaisuus, kun oma ohjelma vain pyörii muistissa, niin se pyörii aina niin hyvin kuin voi, ei ole käyttöjärjestelmää tai muita ohjelmia välissä. Ja Amigasta saa kaiken irti, kun ei ole softarajapintoja, jos ei halua käyttää. Eikä tarvitse prosessorituulettimia ja äänekästä sähkösyöppöä laitetta.

Uusi 64-bittinen FPGA-Vampire sen myös demonstroi: soitat musaa taustalla 5:llä assemblerkäskyllä, ja käytössä on 16 audiokanavaa, jossa 16-bittinen laatu.

Lue lisää

Jos on enemmän tehoja niin se mahdollistaa paremman pelin. Se on sitten eri asia onko peli tehty hyvin ja jos on enemmän tehoja niin ei niitä ole pakko käyttää. PS5:ssa tosin on niin paljon tehoja, että niiden hyödyntämisessä suurin haaste on grafiikan tuottamisessa niin, että saadaanko tuotettua kaikki assetit kunnon laadulla. Se näyttää paskalta jos ovat eri laatuisia joten helposti sitten tekee vähän karkeampana mikä toimisi vaikka tabletissa.

Tosiaankin nykyään tabletissa on 5 teraflopsia ja 64Gb/s muistikaista ilman tuulettimia, että se laittaa asiat perspektiiviin. Peliä tehtäessä aikoinaan peliä kehittävän firman piti ensiksi tehdä pelimoottori mille niitä pelejä tekee. Nyt niitä on iäisyyden saanut valmiina. Tämä on se asia mikä tekee pelihohjelmoinnin helpoksi, ei mikään assembler. Toki pelin saa sinne muistiin ja saa paremmin kuin vanhoilla Amigoilla kun muistia on enemmän.

Anonyymi kirjoitti:

Ei siinä mitään tutkimista ole ollut. Edelleenkin sen ajan koneet olivat hitaita että AGA:lla toimi parhaiten 256 värinen tila. Ja tosiaankin sen ajan Amigassa sen verran vähän CPU tehoa että ei oikein pyörittänyt 3d grafiikkaa.

Eikä näillä tee enää mitään kun heikoin grafiikkasuorituskyky löytyy nykyään jostain Raspberry Pi koneista ja siinäkin on 4Gb/s muistikaista ja 3D-kiihdytys. Käytännössä pyörittelee 64Mb muistiin sopivaa sceneä ja videomuistia stencil bufferilla toteutuilla varjoilla ja per vertex varjostuksella.

Ei sitten tarvitse mennä kuin uuteen tablettiin niin on jo 64Gb/s muistikaista, OpenGL ES 3.0, per pixel varjostus. Lähinnä optimoidaan sitä että saisi scenen sopimaan pakattuna 150 megan lataukseen.

Pelikäytössä vuonna 1997 melko normi oli joku 640x480 16-bit/pikseli.

Lue lisää

"Pelikäytössä vuonna 1997 melko normi oli joku 640x480 16-bit/pikseli."

Korjaan, 640x480 8-bit/pikseli

16-bit värit menivät normiksi 1998

Anonyymi kirjoitti:

A500:n HAM6-moodi on aika paska, sitä ei kyllä saa 640x400 resoon, taitaa 320x400 tai 320x512 olla maksimi.
Ja sen päällä ei voi juuri liikuttaa objekteja, kun värit sekoavat.

Mutta AGA:n HAM8-moodin käyttäminen peleissä on vielä aktiivisen tutkimuksen alla, miten värien sekoamista saisi hillittyä.

SVGA-näytönohjaimissa ei yleensä ollut kuin 2 megatavua muistia, joten 1280x1024 24 bitillä voi unohtaa. Itsellänikin oli vuonna 1997 hankittu SVGA-näytönohjain jossa 2 megaa muistia.

Lue lisää

Olihan noille vanhemman sukupolven Amigoille sellainen peli kun Pioneer Plague, joka käytti HAM-tilaa liikkuvien objektien kanssa. Ja ainakaan näkemässäni sinäputki-videossa ei näyttänyt värit menevän juurikaan sekaisin. Tuossa tosin oli ehkä käytetty taustoissa vain 16 ekaa palettiväriä ja suunniteltu liikkuvat objektit niin, ettei niissä mene värit sekaisin (tyyliin objektin jokaisen pisterivin vasemmanpuoleisin pikseli käyttää jotain 16 ensimmäisestä väristä).

Anonyymi kirjoitti:

Olihan noille vanhemman sukupolven Amigoille sellainen peli kun Pioneer Plague, joka käytti HAM-tilaa liikkuvien objektien kanssa. Ja ainakaan näkemässäni sinäputki-videossa ei näyttänyt värit menevän juurikaan sekaisin. Tuossa tosin oli ehkä käytetty taustoissa vain 16 ekaa palettiväriä ja suunniteltu liikkuvat objektit niin, ettei niissä mene värit sekaisin (tyyliin objektin jokaisen pisterivin vasemmanpuoleisin pikseli käyttää jotain 16 ensimmäisestä väristä).

Lue lisää

Tuollainen kikkailu juu onnistuu.

Itse jos suunnittelisin peliä Amiga 500:lle niin miettisin ennemmin sen 32 värin paletin jakamista alueisiin ja kuvassa olevan sisällön perusteella vaihtaisi paletin sisältöä.

On ihan tavallista graafisessa tuotannossa Kuvassa on käytössä 1-3 "väriä" eri sävyineen kerralla että ei näytä homoparaatilta, ja sisältö tietenkin vaihtelee. Elokuvissa näkyy vaikka niin, että mietitty minkäväriset vaatteet ihmisillä on, minkävärisiä autoja kuvassa on ja jne.

Todellisuus on yleensä kirjavampi että parempi olisi vain kikkailla niillä 32 värillä, vaihdella sisällön mukaan ja vaikka animoi palettia tai vaihtaa palettia animaatioframeissa.

Sen ajan teknologialla ongelma ei useinkaan ollut värimäärä vaan tallennustila ja resoluutio. Ja sitten vielä pienellä resoluutiolla usein näytettiin muutaman pikselin kokoisia asioita että ei oikein ollut detaljeja.

Commodore 64:llä ehkä liiankin usein huomattavan paljon kuvasta oli "puoliresoluutiota" 160x200 tarkkuudella. HAM tilan käyttö Amigalla johtaa vastaavaan tarkkuuden pudotukseen vaakaresoluutiossa.

Asiaan ehkä vaikutti se, että C64:n aikoihin "värit" oli yleensäkin uusi juttu ja sitten sitä kuvaa tehtiin homoparaatin näköiseksi laittamalla kaikki mahdolliset värit ruudulle eikä se välttämättä ole hyvännäköistä. Amigalla vielä kärsittiin samasta ilmiöstä.

Amiga 500/2000 oli tosiaankin ilmestyessään multimedioihin paras kone, ei tästä ole ollut epäselvyyttä. ISA väyläisillä koneilla oli toki myös keinonsa. 320x200 4bit/pikseli grafiikkatilassa,ei ollut kuin 16kt frame. Tai algoritmi joka pitää kirjaa päivitettävistä alueista että ei päivitetä framella kuin osaa ruudusta ja hyödynnetään vaikka RLE koodausta, että muistista ei tarvitse lukea niin paljoa. Tietenkin side scrollereihin Amiga sopi paremmin.

Vuonna 1992 tuli VLB väylä ja tämä yhdessä 486DX2/66 CPU:n kanssa oli sitten 1992 ylivoimainen kaikelle peligrafiikalle. Se kun riitti varjostettuihin, tekstuurimapattuihin polygoneihin z-sortilla.

640x480 resoluutio aikoinaan ollut sellaiseen käyttöön missä ei tarvittu nopeasti päivittää kuvaa. Jossain vuoropohjaisessa strategiassa näin ei tarvinnut tehdä. Tai vaikka jossain Legendin tekstiseikkailuissa. 640x480 256 värillä oli normi joskus 1996 kun oli se PCI väylä. 3D-grafiikka oli silloin vielä matalemmalla tarkkudella tavallista. 1998 16-bit värit tuli normiksi.

Resoluutiot alkoivat käytännön tasolla nousta vasta joskus Xbox 360 tasoisella raudalla vuonna 2005 ja tehtiin peliä vaikka jollain 1024x576 resolla. Oli täreämpää parantaa valaisua ja tekstuureja kuin pyrkiä piirtämään pelkistettyä kuvaa korkealla resoluutiolla.