Enterprise Forever

:HUN => VIDEO: => Topic started by: Z80System on 2013.April.06. 10:22:23

Title: Grafikai trükkök
Post by: Z80System on 2013.April.06. 10:22:23
Tegnap egy nagy magyarazasban beugrott egy kerdes, azt sztm erdemes altalanositani, es nyitni egy ilyen grafikas topikot is.
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.April.06. 10:31:23
Az elso targyalni valo kerdes pedig az lenne ebben a topikban, hogy mi is van itt az interlace- szel ?

Ugye a TV- k ugy mukodtek, valami frekvenciaproblemak, meg korabeli alkatreszproblemak, pontossagok, mittudomenhogymik miatt, hogy 50Hz- el felkepeket nyomtak a TV kepernyojere. Ez azt jelenti hogy egy 25Hz- es (25 FPS) kepnek egy kepkockaja ugy kerult a TV kepere, hogy eloszor a kepkocka mondjuk minden paratlan sora, tehat minden masodik vizszintes sor kerult a kepre, majd ha az kesz volt, akkor jott egy olyan (fel)kep ami minden paros sort irt a TV kepernyore. Es mivel ezt viszont 50Hz- en csinaltak, ezert kijott a 25 Hz a teljes kepekhez. Ezt a 2 felkepet aztan "osszemosta" gondolom a katodsugarcso, meg a pontatlansagok, meg a CRT kioltasi ideje, meg ilyenek.

Tehat lehetne- e az, hogy en mindig csak azokat a scanline- okat frissitem a memoriaban, amit nick epp a TV -re fog kuldeni, tehat a mindenkori paros vagy paratlan sorokat ? Es persze mindezt a "normal" vertikalisan 300 koruli sorszamnal gondolom, ha e fole kell menni ehhez, akkor mar nem buli, hisz mondjuk dupla ennyi sor fele az pont annyi, mintha nem csinaltunk volna semmit ... :)
Title: Re: Grafikai trükkök
Post by: IstvanV on 2013.April.06. 11:12:27
Quote from: Z80System
Tehat lehetne- e az, hogy en mindig csak azokat a scanline- okat frissitem a memoriaban, amit nick epp a TV -re fog kuldeni, tehat a mindenkori paros vagy paratlan sorokat ? Es persze mindezt a "normal" vertikalisan 300 koruli sorszamnal gondolom, ha e fole kell menni ehhez, akkor mar nem buli, hisz mondjuk dupla ennyi sor fele az pont annyi, mintha nem csinaltunk volna semmit ... :)
Normál (nem interlace) módban a NICK minden sort elküld másodpercenként 50-szer. Megoldható a "kis felbontású" interlace is, de azzal természetesen láthatóan romlik a kép minősége.
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.April.06. 11:21:07
Es akkor a tv jelek altal "lefedett" fuggoleges felbontas valahol 600 sor korul van valojaban ? Es nekunk a 300 sorunkat "duplazza" ra a nick a kepre ?
Title: Re: Grafikai trükkök
Post by: IstvanV on 2013.April.06. 11:40:16
Nem duplázza. Az interlace valójában egyszerűen úgy működik, hogy a ~300 soros 50 Hz-es képet a függőleges szinkron időzítése fél sorral "remegteti" függőlegesen, és ez (a páros/páratlan sorok váltott megjelenítésével együtt) nagyobb felbontás illúzióját eredményezi. A normál mód csak annyiban különbözik, hogy nincs minden második képkocka eltolva függőlegesen. Commodore gépeken hasonló trükköt használnak a multicolor mód vízszintes felbontásának növelésére a hardware scroll használatával.

PC-s monitorokon van "double scan", amikor a video kimenet valóban duplázza a sorokat, de erre a nagy felbontás tartomány miatt van szükség, hogy a kisebb (pl. 320x240) felbontásoknál ne legyen látható "rés" a sorok között CRT monitoron, illetve azért, hogy a frissítési frekvenciák a "szabványos" tartományban maradjanak.
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.April.06. 12:09:26
Na, akkor lassuk ertem- e:

Quote
Nem duplázza. Az interlace valójában egyszerűen úgy működik, hogy a ~300 soros 50 Hz-es képet a függőleges szinkron időzítése fél sorral "remegteti" függőlegesen, és ez (a páros/páratlan sorok váltott megjelenítésével együtt) nagyobb felbontás illúzióját eredményezi.
Aham, tehat akkor egy TV film ( mert az ugye a regi katodsugaras TV- knel, jelbemenetknel mindig interlace volt ), vagy az EP interlace modja azert nem tekintheto igazi fuggoleges 600 soros kepnek kiterjedesben (az egyes kepek, felkepek frissitesi frekijeit most ne vegyuk szamitasba), mert a felkepek sorai kozott ( idozitesi ertelemben ) nem volt "kihagyva" minden masodik sor, es raadasul a 2 felkep egymashoz kepest nem egy, hanem csupan fel pixelsorral voltak eltolva fuggolegesen, igy a ket felkep pixelsorai fuggolegesen "egymasra logtak" ... vagyis ez egyfajta CRT kepcsovon megvalositott hardver felkep BLEND megoldas volt, tisztan sosem lattuk a 600 pixelunket, mindig volt benne a masik felkepbol is ... igaz ?

Quote
A normál mód csak annyiban különbözik, hogy nincs minden második képkocka eltolva függőlegesen.
Es akkor az EP nem interlace modban ezekszerint kepes olyan jelet kiadni (nem ismerem a jelek szerkezetet) ami egy alapvetoen interlace felhasznalasra tervezett TV- t NEM INTERLACE modon hajt meg, vagyis nincs az TV- k jeleben kikenyszeritve az interlace mukodes, belefer a jel szabvanyokba, hogy az EP INKABB MEGSE KERI a felkepek kozotti fel pixelsoros fuggoleges eltolast, vagyis nem normal interlace TV adaskent akar uzemelni, HANEM VALOS, IGAZI 50Hz- es 300 soros "progressziv szkennelesu" modban ? Vagyis TV es interlace ide vagy oda, az EP normal modban egy 50Hz, 300 fuggoleges sor, progressziv szkennelesu modban mukodik ?

Quote
Commodore gépeken hasonló trükköt használnak a többszínű mód vízszintes felbontásának növelésére a hardware scroll használatával.
Vagyis komondoron "szoftverbol" van megvalositva az interlace... amihez akkor az kell, hogy a hw fuggoleges scrolljuk a mindenkori interlace- esiteni kepes felbontasuk FELEVEL vagy annal kisebb lepesekben kepes legyen mozgatni a kepet ... igaz ?

Quote
PC-s CRT monitorokon volt "double scan", amikor a video kimenet valóban duplázta a sorokat, de erre a nagy felbontás tartomány miatt volt szükség, hogy a kisebb (pl. 320x240) felbontásoknál ne legyen látható "rés" a sorok között.
Hmmm... hat ez mar a 15Khz - 30Khz kerdeskor, nem ? Ez interlace- tol mar fuggetlen kerdes ...
Title: Re: Grafikai trükkök
Post by: endi on 2013.April.06. 12:49:21
Az interlace egy marha zseniális dolog amúgy. Lényegében fake motion blur-ra konvertálja az adatcsökkentést.
Title: Re: Grafikai trükkök
Post by: IstvanV on 2013.April.06. 12:53:04
Quote from: Z80System
Aham, tehat akkor egy TV film ( mert az ugye a regi katodsugaras TV- knel, jelbemenetknel mindig interlace volt ), vagy az EP interlace modja azert nem tekintheto igazi fuggoleges 600 soros kepnek kiterjedesben (az egyes kepek, felkepek frissitesi frekijeit most ne vegyuk szamitasba), mert a felkepek sorai kozott ( idozitesi ertelemben ) nem volt "kihagyva" minden masodik sor, es raadasul a 2 felkep egymashoz kepest nem egy, hanem csupan fel pixelsorral voltak eltolva fuggolegesen, igy a ket felkep pixelsorai fuggolegesen "egymasra logtak"
A fél sort a 300 soros felbontáshoz képest értettem, tehát 600 soros felbontáshoz viszonyítva egy sor. A felbontás 600 sornak tekinthető, de ennek csak a fele jelenik meg másodpercenként 50-szer, a másik felét a látás és/vagy a monitor tehetetlensége adja, vagy újabb TV-ken digitális de-interlace. Kifejezetten TV-re készült (pl. sport) műsorok egyébként kihasználhatják azt, hogy az egymást követő félképeknek nem kell feltétlenül ugyanahhoz a teljes képhez tartozniuk, azaz lehetséges másodpercenként 50 mozgás fázist megjeleníteni. A TV filmek azonban többnyire a mozi filmekhez hasonlóan csak 24 fps sebességűek, amit a TV adásban 25-re konvertálnak.

Quote from: Z80System
Es akkor az EP nem interlace modban ezekszerint kepes olyan jelet kiadni (nem ismerem a jelek szerkezetet) ami egy alapvetoen interlace felhasznalasra tervezett TV- t NEM INTERLACE modon hajt meg, vagyis nincs az TV- k jeleben kikenyszeritve az interlace mukodes, belefer a jel szabvanyokba, hogy az EP INKABB MEGSE KERI a felkepek kozotti fel pixelsoros fuggoleges eltolast, vagyis nem normal interlace TV adaskent akar uzemelni, HANEM VALOS, IGAZI 50Hz- es 300 soros "progressziv szkennelesu" modban ? Vagyis TV es interlace ide vagy oda, az EP normal modban egy 50Hz, 300 fuggoleges sor, progressziv szkennelesu modban mukodik ?
Igen. Ez a régebbi CRT TV-knél semmilyen problémát nem okozott (az interlace és progresszív módot nem kellett külön támogatni, az interlace egy egyszerű trükk a szinkron jelek időzítésében, amely kihasználja a CRT eltérítésének a tipikus megvalósítását), és a többi 8 bites gép is hasonló megoldást használt. Az újabb LCD TV-k azonban gyakran nem ismerik a progresszív módot - mivel 8 bites gépek már régen nincsenek a piacon - és hibásan azt is interlace-ként jelenítik meg, azaz vagy "remeg" a kép, vagy fésűszerű képhiba jelenik meg mozgásnál. Szintén problémákat okoz néha a 8 bites gépek gyakran nem egészen szabványos (nem pontosan 15.625 kHz) vízszintes frekvenciája, aminek a teljesen analóg CRT TV-knél nem volt különösebb jelentősége.

Quote from: Z80System
Vagyis komondoron "szoftverbol" van megvalositva az interlace... amihez akkor az kell, hogy a hw fuggoleges scrolljuk a mindenkori interlace- esiteni kepes felbontasuk FELEVEL vagy annal kisebb lepesekben kepes legyen mozgatni a kepet ... igaz ?
Nem, ez vízszintes interlace, ami a 160x200 felbontást növeli 320x200-ra.
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.April.06. 13:05:02
Quote
A fél sort a 300 soros felbontáshoz képest értettem, tehát 600 soros felbontáshoz viszonyítva egy sor. A felbontás 600 sornak tekinthető, de ennek csak a fele jelenik meg másodpercenként 50-szer, a másik felét a látás és/vagy a monitor tehetetlensége adja
Aham, en is igy ertettem ...

Quote
vagy újabb TV-ken digitális de-interlace. 
Fu, akkor elvileg egy modern tv- n a digitalis deinterlace funkcioval az EP igazi 600 fuggoleges soros kepet mutathat, mert gondolom ott frankon befogjak a 2 felkepet, es egyben teszik ki 600 sorosnak ... WOW

Vagyis szerezve egy ilyen digitalis deinterleszes kijelzot, 600X600- as iview- s kepek lehetnenek ... remeges nelkul ... (persze egy jo nick- kel)


Quote
Kifejezetten TV-re készült (pl. sport) műsorok egyébként kihasználhatják azt, hogy az egymást követő félképeknek nem kell feltétlenül ugyanahhoz a teljes képhez tartozniuk,

Na az ilyet viszont akkor a digitalis deinterlesz be kell zuzza... hiszen ket kulon kepet fog interleave- elni egy 600 sorosba ... :) Abbol maszatos valami lesz.
Title: Re: Grafikai trükkök
Post by: Zozosoft on 2013.April.06. 13:09:37
Vagyis szerezve egy ilyen digitalis deinterleszes kijelzot, 600X600- as iview- s kepek lehetnenek ... remeges nelkul ...
Ezt irtam is anno,hogy az LG-men tök jó állókép az interlaces iview!
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.April.06. 13:16:03
Na, akkor mostmar "mindent" ertunk interleszileg, mar csak az maradt hatra, az eredeti problemafelvetesbol, hogy sajnalattal vegyes szomorusaggal levonjuk a kovetkeztetest: az EP mind a 300 pixelsorat meg kell mozgatni sajna 50 FPS- sel, ha valaki igazan finom mozgast akar ...
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.April.06. 13:20:10
Ehes programozo blitterrel almodik ...
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.April.06. 13:34:15
Elvi csak a kerdes, de egy buszbovitore dugott kis DMA hardver (mondom, csak elvileg) megoldana ezt a kerdest ?

Tehat a memoriasebessegektol, ilyesmiktol meg lehetne gyorsitani sokat ?

Tehat mondjuk valami modern kis elektronika, ami kepes a memcsot masolni, logikai muveleteket vegezni, meg eltolni pixeleket az EP pixelformatumainak ismeretevel.

A z80 addig malmozhatna is, nem kellene parhuzamos mukodes, vagy ilyesmi, z80- nal elinditanank, 2 pixelsor raszterido alatt kepes lenne mondjuk memmozgatni mondjuk 64K- t, es ezzel megoldana minden sebessegkerdest ...

Szal elviekben ilyen lehetseges volna, vagy mar a ramok es mittudomenmi idoziteseitol sem lehetne ilyen alomcsippet kesziteni ?
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.April.06. 15:16:16
ill. +1 kerdes erejeig vissza az interlaci kerdesre is:

az ep128emuban (vagy barmelyikben) az interlaci kerdes vajon hogy kezelodik ? Ott is van valtogatva 2 darab felkep a fel EP pixelsor vastagsagu felkep eltolassal, es a tenyleges hardver megjelenito kioltasara van bizva a felkepek mixelese, ami gondolom regen nem ugyanaz a filing, mint a regi TV- ken, amik gondolom lassan hunytak ki, mint a terminator szeme, szal valami elesebben villogo dolgot kepzelnek el,

vagy pedig valami korabban emlitett deinterlace eljaras van hasznalva, esetleg raadasul olyan, ami nem feltetlen sorszamban 600- as, hanem marad haromszazas, de valami hardver trukkel blendeli a felkepeket ?
Title: Re: Grafikai trükkök
Post by: lgb on 2013.April.06. 15:36:01
Quote from: Z80System
A z80 addig malmozhatna is, nem kellene parhuzamos mukodes, vagy ilyesmi, z80- nal elinditanank, 2 pixelsor raszterido alatt kepes lenne mondjuk memmozgatni mondjuk 64K- t, es ezzel megoldana minden sebessegkerdest ...

Szerintem ilyen a vilagon nincs (marmint 8 bites vilagon hihi) ... Egyszeruen a hw nem alkalmas erre egyetlen 8 bites gepnel se, ez mar tul sok. Bar csak tippre mondom, nem ismerem a Z80 busz pontos idozitest, illetve hogy vmi letiltott Z80 (BUSRQ) mellett mi az az elmeleti max amit ki lehetne hozni egy DMA szeruseggel iras, olvasas ill iras+olvasas eseten savszelesseg ugyen. De gyanitom, hogy ilyen sebesseget amit irsz, azt nehezen ...

Csak viszonyitani tudok: C64-en pl 1MHz-re kerekeitve az orajelet, es ismerve a tenyt, hogy a 6502 (ill 6510, mind1) annyiban cool, hogy a CPU orajele es a memoriae meg az egesz mindensege tok ugyannyi (Z80-nal kisebb, igaz ott a CPU orajel viszont nagyobb, Z80-nal van kulon T es M cycles, 6502-nel nincs), ezert ott ugye kb 1megabyte-ot tudsz 1 masodperc alatt irni v olvasni (nyilvan ha egy byte-ot elobb irni majd olvasni kell, akkor a fele ...). Ez ugye azt jelenti, hogy 64K irasa vagy olvasasa az elmeleti max buszsegesseggel (amit CPU nem is kepes generalni!) az kb 1/15-od masodperc, ha olvasni es irni is kell, akkor a dupla annyi ido, tehat mar 1/7-ed masodperc kornyeken! Tehat az nagyon vad amit mondtal, hogy ket scanline alatt egy 8 bites gep 64K-t kepes lenne megmozgatni :) Ha half frame-eket nezunk es pl 300 sornak veszed a felkepet, akkor a 2 scanline az egy half frame 1/150-ed resze lenne idoben, azaz kb 1/7500-ed masodperc. ha jol fejszamlgatok kb nagysagrendileg csak, akkor az jon ki hogy amit te akarsz az 500-szor vagy 1000-szer (!) gyorsabb busz kene mint a C64-e. Felteve hogy Z80 meg M/T cycle 2 arany mellett is ketszer gyorsabb mondjuk a C64-nel, akkor is 500-szor gyorsabb gep kene az EP-nel (ami a buszrendszert illeti), hogy olyat lehessen csinalni amit te akarsz.

Ha vmit nagyon elszamoltam/felrebecsultem akkor bocs :)

Ezert mondtam hogy itt nem az EP a hibas vagy a Z80, ez egyszeruen mar nem 8 bites gep kategoria, ilyet meseben sem tudna egy 8 bites gep kb (meg a C64 DTV sem, ami ASIC-on reimplementalt C64 compatible joystick alaku cucc es belsoleg SDRAM van benne full 32 biten es 32MHz belso ASIC szintu orajellel se er a kozelebe annak amit te akarsz, mivel ott van DMA es Blitter is, es ezen en anno kiserletezgettem .... pedig az 32 bit es burst modban is tudja cimezni az SDRAM-ot pl !!!!)

Ha jol szamolom amit te akarsz az fel GIGABYTE per szekundum memoria savszelesseg lenne. Ez mar kb/majdnem a modern PC-k kategoriajaba esik .... nem egy 8 bites gepebe.
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.April.06. 15:54:15
Hat egy ilyen megvilagitasban valoban elegge mas a leanyzo fekvese ...

Akkor le kene cserelni a ramokat is gyorsabbakra ... ha az megoldana a dolgot.

De ha meg vagy 50 ic- t meg mittomenmiket is ki kene cserelni, akkor mar gyakorlatilag nem hozzatoldottunk vmit a dologhoz, hanem epitettunk egy masik gepet.
Title: Re: Grafikai trükkök
Post by: lgb on 2013.April.06. 16:25:44
Quote from: Z80System
Hat egy ilyen megvilagitasban valoban elegge mas a leanyzo fekvese ...

Akkor le kene cserelni a ramokat is gyorsabbakra ... ha az megoldana a dolgot.

De ha meg vagy 50 ic- t meg mittomenmiket is ki kene cserelni, akkor mar gyakorlatilag nem hozzatoldottunk vmit a dologhoz, hanem epitettunk egy masik gepet.

Na igen, de ez mar ugye messze nem egy atlagos 8 bites gep lenne, hanem valami tok mas, ami tobb nagysagrenddel gyorsabb annal. Itt kezdodik a filozofia, ahogy haverok is mondjak: "mi a fenenek szenvedsz ezekkel a regebbi gepekkel ha egy mai PC sokkal de sokkal gyorsabb?" ... azaz ha olyasmire vagysz ami total kivul esik a kerdeses technika lehetosegen, akkor azt vagy elfelejted (egyszeruen erre nem alkalmas ...) vagy pedig atnyergelsz egy masik kategoriara, de akkor pont a lenyeg veszik el, pl akkor hasznalhatsz PC-t EP helyett ami kepes ilyen memoria savszelessegre amit te akarsz. Egy EP atalakitva sem kepes erre imho, itt elvi szinten olyan igenyeket tamasztasz ami megoldhatatlan az adott technika keretein belul.

Szoval ez nem RAM kerdese, kb az egesz gepet le kene cserelni! Csak info keppen, imho a PCI Express x2 busz tudna azt amit te akarsz :) Ezt elvarni egy EP-tol azert kicsit durva :)
Title: Re: Grafikai trükkök
Post by: endi on 2013.April.07. 17:13:38
Amúgy egy oldalscrollos game EP-n is működhet, szerintem nem gond hogy félkarakteres a mozgás ha gyors a game.
De a felfele scrollal is lehetne egyszerű de jó játékokat csinálni.
Pl. mobilon totál sikerek a Nyan Cat, Doodle Jump meg hasonlók. :D
Title: Re: Grafikai trükkök
Post by: geco on 2013.April.07. 17:19:46
Quote from: endi
Amúgy egy oldalscrollos game EP-n is működhet, szerintem nem gond hogy félkarakteres a mozgás ha gyors a game.
De a felfele scrollal is lehetne egyszerű de jó játékokat csinálni.
Egyetértek :)
Title: Re: Grafikai trükkök
Post by: endi on 2013.April.07. 17:20:42
Mondjuk az igaz, hogy egy oldalscroll esetén 2x-es szélességű lap kell, ami marha sok memória...
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.April.11. 20:50:35
Ezt a cuccot 79- re datálja a wiki:

http://www.youtube.com/watch?v=GzitZv8Enmc (http://www.youtube.com/watch?v=GzitZv8Enmc)

Ebben 79- re benne volt a SOK-SOK sprite -os hardware ?
Title: Re: Grafikai trükkök
Post by: endi on 2013.April.11. 21:08:38
egy játékgép nem home computer árban van...
Title: Re: Grafikai trükkök
Post by: Zozosoft on 2013.April.11. 21:53:12
Ilyenekben volt legalább 2-3 proci...
Title: Re: Grafikai trükkök
Post by: lgb on 2013.April.11. 22:35:18
Quote from: Z80System
Ezt a cuccot 79- re datálja a wiki:

http://www.youtube.com/watch?v=GzitZv8Enmc (http://www.youtube.com/watch?v=GzitZv8Enmc)

Ebben 79- re benne volt a SOK-SOK sprite -os hardware ?

Most is megteheted: ott vannak a nick-en a bemenetek, EP-be is pakolhato annyi extra hw, hogy legyenek sprite-ok :) Igazabol ezzel is lehetne foglalkozni, az a "super nick" topic ami volt egyszer meg mindig bonyolultabb mint a meglevo nick-et hagyni, es megcsinalni vmi kulso "sprite egyseget" vagy hasonlot ... Bar ma mar ez hatareset: amugy sincs feltetlen ember tizezreinek EP-je, ha meg extra hw is kell hozza, kerdes, h milyen sw tamogatna egyaltalan ... Azert erdekes lenne legalabb :)
Title: Re: Grafikai trükkök
Post by: IstvanV on 2013.April.11. 23:21:09
Quote from: endi
Amúgy egy oldalscrollos game EP-n is működhet, szerintem nem gond hogy félkarakteres a mozgás ha gyors a game.
16 színű módban a pixelenkénti oldalra scrollozás is megoldható két képernyő puffert használva, és mindkettőt frissítve (fél karakterenként és LPT módosítással), de az egyiket egy pixel (negyed karakter) eltolással. Ez ugyan lassabb, mint a fél karakter felbontású scroll, de még mindig lényegesen gyorsabb, mint az egész képernyőt szoftveresen mozgatni.
Title: Re: Grafikai trükkök
Post by: endi on 2013.April.11. 23:22:09
Szerintem jóval egyszerűbb lenne írni pl. Androidra egy interfészt ami veszi az EP jeleit és renderel bármit. :D
Még olcsóbb is lenne. Egy ilyen tévére köthető full hd, hdmi kimenetes cucc 15ezer Ft. EP küldi a jeleket aztán mehet bármi.
Title: Re: Grafikai trükkök
Post by: endi on 2013.April.12. 09:16:53
na persze még ennél is egyszerűbb a 15 ezer ft-s android sticken egy emulátort futtatni és az emulátorba építeni sprite-ot :)
Title: Re: Grafikai trükkök
Post by: geco on 2013.April.12. 09:23:26
Quote from: IstvanV
16 színű módban a pixelenkénti oldalra scrollozás is megoldható két képernyő puffert használva, és mindkettőt frissítve (fél karakterenként és LPT módosítással), de az egyiket egy pixel (negyed karakter) eltolással. Ez ugyan lassabb, mint a fél karakter felbontású scroll, de még mindig lényegesen gyorsabb, mint az egész képernyőt szoftveresen mozgatni.
De ez már sokat lassít, nem, mert kellenek bit műveletek is a negyed karakter eltoláshoz?
Title: Re: Grafikai trükkök
Post by: endi on 2013.April.12. 09:36:06
Quote from: geco
De ez már sokat lassít, nem, mert kellenek bit műveletek is a negyed karakter eltoláshoz?
két bufferbe kell írni a sprite-okat, egyikre az eltoltakat. egész képernyő memóriamásolással totál lassú lenne, ilyet specyn se csináltak komolyabb játékban (azaz újra van rajzolva az egész pálya minden képkockában)

persze így megint csak 2x annyi memória kell a képernyőhőz, és ráadásul a sprite-okhoz is... :)
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.April.12. 12:16:45
Most akkor csak azt nem értem, hogy miért hagytok engem itt nyafogni, mikor ezek igenis léteznek:

http://www.youtube.com/watch?v=daQCjPB9gj4 (http://www.youtube.com/watch?v=daQCjPB9gj4)
http://www.youtube.com/watch?v=nn1nyXDo6Qg (http://www.youtube.com/watch?v=nn1nyXDo6Qg)
http://www.youtube.com/watch?v=YJQYb38PykI (http://www.youtube.com/watch?v=YJQYb38PykI)

Igy a youtube video alapján nincs gond a sebességgel se a villogással, remegéssel, a sub-huntert EP- n is megtudtam nézni, de most csak szoftver emum van, úgyhogy biztos nem lehetek benne, de vagy nem 25 FPS -esek ezek, vagy pedig akkor mégsem olyan nagy baj az a 25 FPS ... No mindegy, úgyis kiderítem saját tapasztalatból, de azért bedobálhatta volna ezeket valaki, amikor itt vernyogtam, hogy fú de lassú a z80. (No persze tegyük hozzá, hogy valszeg mindegyik scanline -t dupláz, úgy a memcsó is csak a fele, és egyik sem 320- as vizszintes scroll, csak 160- as ...)
Title: Re: Grafikai trükkök
Post by: geco on 2013.April.12. 13:56:04
Hát eddig az 50 FPS-ről beszéltél :D, és még sztem ezek a programok a 25 FPS-t se érik el, mégis szép a mozgásuk, a Sub Hunter 32x24-es screent használ, és nincs memóriafelezés, a képernyő mérete 12288 kb, ugye ebből kb 7 karakter magas a kijelző, de akár 8 is lehet, még 8 esetén is 8kb adatot kell kipakolni a képernyőre, szerencsére a dupla videolap segítségével ez ilyen lesz :)
Title: Re: Grafikai trükkök
Post by: IstvanV on 2013.April.12. 14:09:27
Quote from: geco
De ez már sokat lassít, nem, mert kellenek bit műveletek is a negyed karakter eltoláshoz?
Kellenek, de csak egy fél karakteres oszlopon (és az is csak az egyik képernyő pufferben, a másikat nem kell eltolni), és nem az egész képernyőn. Ehhez már elég gyors a Z80, 50 fps sebességnél is, de játéknál talán célszerűbb a 25 fps, mert akkor több idő marad sprite rajzolásra. A két képernyő puffer egyébként is hasznos, hogy villogás nélkül lehessen frissíteni a képet. 2*16K méretű puffer elég egy 40x25 karakteres képernyőhöz, és marad 384 byte (4.8 képernyő) az "ablak" mozgatására LPT módosítással. A sprite-okat egy képkockában csak az egyik képernyőn kell frissíteni.

"Spectrum méretű" 32x24 karakteres képernyőn talán megoldható a 4 színű, pixel felbontású scroll is, de az már nagyon sok memóriát pazarol (4 puffer), és másra nem nagyon marad idő vagy hely. Demónál azonban lehet értelme.
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.April.12. 14:09:43
Quote
Hát eddig az 50 FPS-ről beszéltél (http://enterpriseforever.com/Smileys/phpbb/ds_icon_biggrin.gif),
Hat ja, tesztelni fogom vas EP- n is, CRT- n meg TFT- n is, a saját stuffjaimmal, kicsit most összezavarodtam ... En játszottam azzal a sub hunter dologgal, és látványt és kontroll reszponzivitást tekintve alig emlékszek ilyen jóra ... Na majd kitesztelem saját kódokon mire emlékszek, mit kavarok ...

Quote
még 8 esetén is 8kb adatot kell kipakolni a képernyőre
Most ezt miért mondod, pont az a lényege ezeknek a scroll cuccoknak, hogy nem kell a teljes képernyőt kiírni ... biztos vagy benne, hogy írjak képről képre a teljes képernyő memóriát ?
Title: Re: Grafikai trükkök
Post by: geco on 2013.April.12. 14:52:57
Quote from: Z80System
Most ezt miért mondod, pont az a lényege ezeknek a scroll cuccoknak, hogy nem kell a teljes képernyőt kiírni ... biztos vagy benne, hogy írjak képről képre a teljes képernyő memóriát ?
A Sub Hunterben nincs hardveres scroll, ezért írja a majd full képernyőt.
Nekem úgy rémlik, hogy minden egyes frame-ben kirajzolja a parallax hátteret is.
Title: Re: Grafikai trükkök
Post by: geco on 2013.April.12. 15:04:57
Quote from: IstvanV
Kellenek, de csak egy fél karakteres oszlopon (és az is csak az egyik képernyő pufferben, a másikat nem kell eltolni), és nem az egész képernyőn. Ehhez már elég gyors a Z80, 50 fps sebességnél is, de játéknál talán célszerűbb a 25 fps, mert akkor több idő marad sprite rajzolásra. A két képernyő puffer egyébként is hasznos, hogy villogás nélkül lehessen frissíteni a képet. 2*16K méretű puffer elég egy 40x25 karakteres képernyőhöz, és marad 384 byte (4.8 képernyő) az "ablak" mozgatására LPT módosítással. A sprite-okat egy képkockában csak az egyik képernyőn kell frissíteni.

"Spectrum méretű" 32x24 karakteres képernyőn talán megoldható a 4 színű, pixel felbontású scroll is, de az már nagyon sok memóriát pazarol (4 puffer), és másra nem nagyon marad idő vagy hely. Demónál azonban lehet értelme.
Azt vágom ,hogy az egyik képen nem kell tolni, viszont azt nem értem, hogy miért csak fél karakteres oszlopon, vagyis mostmár sejtem. Azért mert fél karakteres oszlopokkal etetjük meg minden egyes frémben a képet? Tehát az egyik képet egy eltolatlan fél oszloppal, a másik képet egy eltolt fél oszloppal etetni minden egyes képváltás előtt?

Húúú, már nem emléxem, hogy melyik demóban, volt pixelenkénti hullámzás, onnan vettem ki a Sub Hunterhez is a pixelenkénti mozgatást, minden egyes pixellel eltolt változat le volt tárolva.
Title: Re: Grafikai trükkök
Post by: geco on 2013.April.12. 15:08:17
Megnéztem, a Megademo III (http://ep128.hu/Ep_Demo/Pic/Megademo3.gif) volt
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.April.12. 15:14:07
Én továbbra sem akarom elhinni, hogy képes ilyen FPS- sel a z80 kiirni teljes képernyőket ...

Ha így van, akkor meGa kulpa, mert akkor villamgyors ez a rendszer ...

De egyenlőre nem akarom elhinni ... A sprite- ok lehetnek kirajzolva minden frame- ben, a háttér sztm scroll, vagyis mindig csak a belépő rész van írva. Másképp nem lehet ...
Title: Re: Grafikai trükkök
Post by: IstvanV on 2013.April.12. 15:16:44
Quote from: geco
Tehát az egyik képet egy eltolatlan fél oszloppal, a másik képet egy eltolt fél oszloppal etetni minden egyes képváltás előtt?
Igen.
Title: Re: Grafikai trükkök
Post by: geco on 2013.April.12. 15:18:50
Quote from: Z80System
Én továbbra sem akarom elhinni, hogy képes ilyen FPS- sel a z80 kiirni teljes képernyőket ...

Ha így van, akkor meGa kulpa, mert akkor villamgyors ez a rendszer ...

De egyenlőre nem akarom elhinni ... A sprite- ok lehetnek kirajzolva minden frame- ben, a háttér sztm scroll, vagyis mindig csak a belépő rész van írva. Másképp nem lehet ...
Hát, pedig a Sub Hunterben tuti nem scroll, újrarajzolás. Két képernyőt használ ugyan, de nem az eltolás miatt, az egyik képernyő a munkás képernyő, a másik a megjelenített.
Az istván által említett 1 byte-os scrollal még gyorsabban lehetne scrollozni, akár 50 FPS-sel is
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.April.12. 15:20:42
Quote
Hát, pedig a Sub Hunterben tuti nem scroll, újrarajzolás. Két képernyőt használ ugyan, de nem az eltolás miatt, az egyik képernyő a munkás képernyő, a másik a megjelenített.
Az istván által említett 1 byte-os scrollal még gyorsabban lehetne scrollozni, akár 50 FPS-sel is
Juhúúúúúúúúúúú !!! :smt026
Title: Re: Grafikai trükkök
Post by: endi on 2013.April.12. 16:12:16
ne lelkesedj annyira azért...
Title: Re: Grafikai trükkök
Post by: endi on 2013.April.12. 17:32:39
amúgy meg Laci írt egy Scroll demót ügye... :) kérdezd őt
szerintem a legjobb EP demó
Title: Re: Grafikai trükkök
Post by: IstvanV on 2013.April.12. 21:37:35
16 színű, 928x200 méretű kép pixel felbontású vízszintes scrollozása 160x200 méretű ablakban, 50 fps sebességgel:

[attachurl=#]
[attachurl=#]

A Space billentyű 25 fps-re lassítja a scrollt, az Esc pedig kilép. 128K-s gépen nem EXOS kompatibilis a nagy memóriaigény miatt. Az eredeti kép itt (http://commons.wikimedia.org/wiki/File:Vancouver_Panorama.jpg) található.
Title: Re: Grafikai trükkök
Post by: Zozosoft on 2013.April.12. 21:53:39
Quote from: IstvanV
16 színű, 928x200 méretű kép pixel felbontású vízszintes scrollozása 160x200 méretű ablakban, 50 fps sebességgel:
Nem semmi! A CPU kb hány %-ra van leterhelve?
Title: Re: Grafikai trükkök
Post by: IstvanV on 2013.April.12. 23:32:04
Quote from: Zozosoft
Nem semmi! A CPU kb hány %-ra van leterhelve?
Kb. 37.5% ha a kép adat (a scroll.bin file-ból) nem a video RAM-ban van, egyébként ~38.8%. Ez 50 fps sebességnél az összes utasítás időtartama a HALT és a megszakítás kivételével, de minden második képkockánál csak LPT-t kell módosítani (puffer váltás), ezért az átlagos terhelés kisebb (~20%). Valószínűleg lehetne még javítani a kódon, és alacsonyabb CPU fogyasztást elérni. Elvileg van idő a 4 színű, 4 puffert használó megoldásra is, de ott problémát jelenthet a memória használat.
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.April.12. 23:47:24
Hát elég határeset ... IstvanV nem egy kókler, biztos nem lehet azt az oszlop hozzáadó+lpt hekkelő kódot nagyságrendileg csökkenteni időben (biztos nem teljesen rossz már az most sem), vagyis az bizony 40% ... Két vacak pixeloszlop frame -enként ... és ráadásul egy folyamatos memóriatérképről másolja, nem játékokhoz szükséges, karakterszerű blokkokból rakja össze. De még ha ez nem is számít, ez akkor is 30-40 % -a a rendelkezésre álló időnek.

Ez jelenleg frame -enként 400 pixel ( mindket képre egy plussz pixel oszlop ) megmozgatása ... ezt még duplázni lehet (vagy már lehet most is úgy van) azzal ha a forrás grafika is megvan eltoltan is letárolva, akkor 800 pixel per frame.

800 pixel tehát 40% processzoridő.

16 darab 16X16 pixeles sprite = 4096 pixel ... amit nem csak kirakni kell, hanem el is kell menteni ugyanennyi pixelt alóluk ... Naggyon - naggyon cipőkanalas dolog ez az 50 FPS -sel valami jatékgrafikat kirakni téma EP -n ...
Title: Re: Grafikai trükkök
Post by: Zozosoft on 2013.April.13. 00:06:39
Quote from: Z80System
Naggyon - naggyon cipőkanalas dolog ez az 50 FPS -sel valami jatékgrafikat kirakni téma EP -n ...
Mondjuk továbbra se értem az 50 FPS mániát, 25-nek is bőven örülni kéne :oops:
Title: Re: Grafikai trükkök
Post by: IstvanV on 2013.April.13. 00:09:15
Quote from: Z80System
Ez jelenleg frame -enként 400 pixel ( mindket képre egy plussz pixel oszlop ) megmozgatása ... ezt még duplázni lehet (vagy már lehet most is úgy van) azzal ha a forrás grafika is megvan eltoltan is letárolva, akkor 800 pixel per frame.
Nem pixel, hanem byte oszlopot kell mozgatni, tehát 400 pixelt beléptetni egyszerre két pufferbe, az egyikben egy pixellel eltolva (amihez szükség van a következő oszlopra is). Ezen kívül a jelenlegi kód először két byte oszlopot egy átmeneti pufferbe másol, és utána ezt használja a rajzoláshoz; itt lehetne optimalizálni kevesebb másolással.
Egyébként C64-en ennél valamivel több időt igényel egy teljes karakteres képernyő (de nem a szín memória) mozgatása, még ciklus nélkül 1000 LDA/STA utasítással is. EP-n a nagyobb probléma a hardveres sprite rajzolás hiánya, ezért célszerűbb játékoknál 25 fps-re korlátozni a sebességet.
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.April.13. 00:12:30
Quote
Mondjuk továbbra se értem az 50 FPS mániát, 25-nek is bőven örülni kéne
Amiket írni fogok, azokat úgy fogom készíteni, hogy (addig amíg az egy frame -be is beleférnek) lehessen egykönnyen változtatni, hogy hány frame -es legyen a működés.

Ha nem runtime paraméterként lesz bennük, akkor kapsz majd verziókat.

Es akkor majd te is kiprobálhatod, hogy milyen élménybeli különbség teljesen ugyanaz a dolog (sebességek megfelelően skálázva), de fele vagy harmada képfrissítéssel.

Akkor majd vagy te is megérted, vagy én fogok koppanni, hogy honnan is vettem én ezt az 50 FPS mániát ... Ha légből kapott (amit nem hiszek), akkor nagyon- nagyon régi fixációmat fogjuk orvosolni ... :)
Title: Re: Grafikai trükkök
Post by: nyuzga on 2013.April.13. 00:26:42
Quote from: IstvanV
16 színű, 928x200 méretű kép pixel felbontású vízszintes scrollozása 160x200 méretű ablakban, 50 fps sebességgel:
Nagyon jó. :smt023
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.April.13. 01:14:08
Csak azt nem értem, hogy

ha mondjuk 4 pixel oszlop a 30%,

akkor 12 pixel oszlop az 1 frame,

akkor 10 frame még mindíg csak 120 pixel oszlop, tehát úgy 12 frame (-nyi idő) a teljes képernyő kimásolása.

Akkor a sub hunter mennyi FPS -sel megy ?

És még sprite -okat is rajzol ...
Title: Re: Grafikai trükkök
Post by: geco on 2013.April.13. 08:32:39
Nagyon jóóó lett :)
Majd megnézem ,hogy mennyivel megy  a Sub Hunter.
Amúgy a 25fps-es mozgatás is folyamatos, egyáltalán nem darabos.
Title: Re: Grafikai trükkök
Post by: geco on 2013.April.13. 08:59:19
A Sub Hunter is 25 FPS-sel megy. :D
Title: Re: Grafikai trükkök
Post by: Povi on 2013.April.13. 10:08:51
Quote from: IstvanV
16 színű, 928x200 méretű kép pixel felbontású vízszintes scrollozása 160x200 méretű ablakban, 50 fps sebességgel:


Jó lett! :-)
Viszont azt nem értem, miért foglalja le az összes szegmenst, akár 640kB, akár 1024kB RAM van a gépben... .-)
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.April.13. 11:22:39
Quote
A Sub Hunter is 25 FPS-sel megy. (http://enterpriseforever.com/Smileys/phpbb/ds_icon_biggrin.gif)
Hát ez az ...

Hogy van az hogy 2 pixelsor kimásolása az 0.3 frame idő,
de egy teljes képernyő kimásolása meg belefér 2 frame időbe, sprite -okkal, mindennel ?

Nekkem itt valami büdös ...
Title: Re: Grafikai trükkök
Post by: IstvanV on 2013.April.13. 12:46:38
Quote from: Z80System
Hogy van az hogy 2 pixelsor kimásolása az 0.3 frame idő,
de egy teljes képernyő kimásolása meg belefér 2 frame időbe, sprite -okkal, mindennel ?
Ez így nem igazán hasonlítható össze, mert:
- a "2 pixelsor kimásolása" valójáben nem annyira egyszerű (egy byte feldolgozása viszonylag sok utasítás), és még lehetne rajta optimalizálni is
- a "teljes képernyő" a Sub Hunter esetében kis méretű
- a Sub Hunter valójában nem is scrollozza a képet, hanem csak egyszerű 1-4 karakteres ismétlődő animált mintát rajzol ki PUSH utasításokkal (C64-en ez egy fix háttér lenne karakters módban, a karakterkészlet animációjával)
Title: Re: Grafikai trükkök
Post by: IstvanV on 2013.April.13. 12:54:18
Quote from: Povi
Viszont azt nem értem, miért foglalja le az összes szegmenst, akár 640kB, akár 1024kB RAM van a gépben... .-)
Azért foglal le mindent, mert video szegmenseket csak így lehet foglalni. Természetesen utána a nem használt szegmenseket fel kellene szabadítani, de ez csak egy egyszerű és rövid idő alatt megírt demo, aminek nem az volt a célja, hogy "tökéletes" legyen, hanem csak az, hogy működjön. De a sok kritika miatt a forráskódot töröltem is. :oops: Majd ha lesz rá idő, feltöltök egy jobbban megírt változatot.
Title: Re: Grafikai trükkök
Post by: Lacika on 2013.April.13. 13:26:05
Képet hogy tudunk konvertálni a scroll-rutinhoz?
Title: Re: Grafikai trükkök
Post by: szipucsu on 2013.April.13. 16:30:29
Ez a scroll demó nagyon ász! :smt041
Olyat kéne még, hogy játékok screenshotos térképét etetni meg a scroll demóval, és azt görgetné jobbra-balra.
SPACE lenyomására nem éreztem különbséget.
Ha még a CPU 40%-át sem használja ez ki, akkor akár valami zene is szólhatna alatta? Esetleg lassabb scrollal, és némi zenével érdekes demó lehetne.
Title: Re: Grafikai trükkök
Post by: geco on 2013.April.13. 18:00:35
Quote from: Z80System
Hát ez az ...

Hogy van az hogy 2 pixelsor kimásolása az 0.3 frame idő,
de egy teljes képernyő kimásolása meg belefér 2 frame időbe, sprite -okkal, mindennel ?

Nekkem itt valami büdös ...
Hát valahogy úgy, hogy a hullámok nem másolva vannak, hanem fixen a kódba van ágyazva minden képernyőre kerülő bájt, a sprite-ok kicsik, és kb a 24x30-as kép 2/3-án zajlik a játék, és ott nincs bitművelet se 400 bájton, ja ,és azt nem néztem, hogy pixelenkénti scroll van benne, vagy byte-onkénti.
Title: Re: Grafikai trükkök
Post by: geco on 2013.April.13. 18:11:19
Ja, a bogyók is csak 25 Hz-enként mozdulnak a játék főmenüjében, és nem darabos a mozgásuk, sőt, amikor 50Hz-es mozgás volt belőve, azt túl gyorsnak éreztem.
Title: Re: Grafikai trükkök
Post by: geco on 2013.April.13. 18:16:35
Bocsi, tévedtem, a játékban nincs egyik részlet se fixen a kódban, minden hátteret PUSH-ol a képernyőre 4 regiszterpárt felhasználva hozzá: BC,DE,BC',DE'. Így, ha jól számoltam, kb 1 frame alatt teleírja a hátteret, és marad kb 1 frame a sprite-okra, és egyébre.
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.April.13. 18:22:53
Miért olyan fontos az a PUSH ? Akkor érteném, ha a grafika elférne regiszterekben, pár bájtból lenne kirakva, de hát az biztos nem úgy van, tehát nyilván van valami forrás memóriaterület is, akkor azt éppúgy növelni, olvasni kell, az egy dolog, hogy a célterületre megspórolnak egy növelést a PUSH -al, de miért olyan nagy szám az, hogy itt így többedszerre is kiemelitek ?
Title: Re: Grafikai trükkök
Post by: geco on 2013.April.13. 18:27:26
Azzal lehet a leggyorsabban adatot írni, 4x olyan gyorsan tesz be 2 byte-ot a memóriába, mint, az LDIR, sok időt lehet spórolni vele. ( utasítás idő: PUSH 11, POP 10, LDIR 21/16, LDI 16 , igaz ezek az értékek csak a NICK által nem használt RAM-ban lévő utasításokra érvényesek)
Jelen esetben a háttér 4 karakter széles területekből áll, és ez ismétlődik, ezért fontos a 4 regiszterpár, elég egyszer feltölteni a 4 regiszterpárt, aztán egy soron mindezt kiírni 8-szor, ez a megoldás kb 3x olyan gyors, mintha LDIR-rel ment volna a másolás, ugyanez érvényes a képernyőtörlésre is, csak ott a PUSH-sal majd 4-szer olyan gyorsan lehet törölni a képernyőt, mint LDIR-rel.
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.April.13. 18:34:36
aham ... tehat soronként igaz az, hogy csupán a regiszterekből fillezik a memóriát ... bámulatos ... soronként 8 byte -al érnek el ilyen hátteret ... eszméletlen ...

de akkor is ugye csak egy "halott" loop -olt anim, aminek a megrajzolása is veszettül kötött, nem pedig igazi scroll ...
Title: Re: Grafikai trükkök
Post by: Zozosoft on 2013.April.13. 18:34:52
A gyors RAM tesztek is PUSH-al nullázzák a RAM-ot.
Title: Re: Grafikai trükkök
Post by: geco on 2013.April.13. 18:39:15
Quote from: Z80System
aham ... tehat soronként igaz az, hogy csupán a regiszterekből fillezik a memóriát ... bámulatos ... soronként 8 byte -al érnek el ilyen hátteret ... eszméletlen ...

de akkor is ugye csak egy "halott" loop -olt anim, aminek a megrajzolása is veszettül kötött, nem pedig igazi scroll ...
Ez így van, ha pl R-type jellegű háttér lenne, akkor számolhatnánk ezzel a módszerrel elérhető sebességnek 12,5 frame/sec-et, ami még mindig nem biztos, hogy olyan lassú, viszont az István által elmagyarázott, és bemutatott módszerrel akár 25 frame/sec-kel is menne, ennek nagyobb a memória igénye, viszont nagyon gyors :)
Ja, és itt jön képbe, hogy meg lehet nézni azt is, hogy a 2pixelenkénti scroll mennyire csúnya, mert ha nem, akkor még lehetne sebességet nyerni, nem is keveset.
Title: Re: Grafikai trükkök
Post by: Zozosoft on 2013.April.13. 18:42:12
Itt (http://enterpriseforever.com/programozas/assembly-programozas/msg19643/#msg19643) már egyszer volt szó arról, hogy POP-PUSH módszer gyorsabb mint az LDIR, tehát még akkor is jobb, amikor memóriából memóriába kell másolni.
Title: Re: Grafikai trükkök
Post by: geco on 2013.April.13. 18:46:50
Quote from: Zozosoft
Itt (http://enterpriseforever.com/programozas/assembly-programozas/msg19643/#msg19643) már egyszer volt szó arról, hogy POP-PUSH módszer gyorsabb mint az LDIR, tehát még akkor is jobb, amikor memóriából memóriába kell másolni.
Erre nem is emlékeztem, de teccik, hogy az összes regiszter fel lett használva :D Én is gondolkoztam ezen, csak nem az összes regiszterrel, hát így lassabbra is vettem :oops:
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.April.13. 18:50:06
Quote
Ja, és itt jön képbe, hogy meg lehet nézni azt is, hogy a 2pixelenkénti scroll mennyire csúnya, mert ha nem, akkor még lehetne sebességet nyerni, nem is keveset.
Hát nézd meg a SOMB2 intrójában a scroll -t, az byte -os ( vagyis 2 (16 szinű) pixel ), kétképernyős, csak a belépő információt feltöltős ... :)

Es 50 Hz -es ... :)
Title: Re: Grafikai trükkök
Post by: geco on 2013.April.13. 19:02:45
Nem is lenne rossz, ha nem akadna meg néha, ha egyről beszélünk :D, mert én a scrollozó szöveget néztem, ami 4 színű, de az is úgy láttam, byte-onként megy.
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.April.13. 19:04:47
Hmmm ... :) Semilyen akadásra nem emlékszek ...
Title: Re: Grafikai trükkök
Post by: geco on 2013.April.13. 19:16:45
Pedig direkt a linuxos EP128emuval néztem, mert a virtuális XP alatt tapasztaltam ,hogy nem minden megy úgy, ahogy kéne :D Egy picit darabos volt a scroll, és nem csak azért, mert byte-onként mozog, hanem néha megakad egy picit, de megnézem újra :)
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.April.13. 19:19:50
HW EP -n én egy nagyon gyors, teljesen folyékony hatásra emlékszem ... ha nyomod a T gombot, na akkor szaggat ...
Title: Re: Grafikai trükkök
Post by: geco on 2013.April.13. 19:24:26
Megnéztem, szaggat. Lehet csak a képfrissítési különbségek miatt, mert ennek pont olyannak kéne lennie, mint ahogy leírtad :) Úgy fest 50Hz mellett a byte-onkénti scroll is jó, lehet 25 Hz-en se látszik darabosnak.
Title: Re: Grafikai trükkök
Post by: endi on 2013.April.13. 19:38:58
Valamit megnézhetnétek igazi EP-n. Van az Orkdemo3 és abban a DEMO3H.DAT, ami a valahányadik rész indítója. Na ebbe raktam bele asszem egy LPT trükköt, ami azt csinálja hogy a szöveg felső pár pixeljét eltolja pixelenként. Emu alatt sajna nem műxik, de gyanítom, hogy minden tévével se.
Nem tudom már mit csinál ez a trükk, de az biztos hogy csak véletlen jöttem rá ahogy próbálgattam az LPT értékeket.
Title: Re: Grafikai trükkök
Post by: endi on 2013.April.13. 19:39:51
Ja és az effekt csak akkor látszik amikor a fel-le mozgó szöveg fent van.
Title: Re: Grafikai trükkök
Post by: IstvanV on 2013.April.13. 19:41:24
Quote from: Lacika
Képet hogy tudunk konvertálni a scroll-rutinhoz?
epimgconv (232 karakter x 200 sor méretű kimeneti file, 16 színű PIXEL formátumban, fix palettával), és aztán egy rövid C programmal konvertáltam a scroll.bin file-t. Ennek a formátuma:
- keret szín (1 byte)
- FIXBIAS * 8 (1 byte)
- paletta (8 byte)
- a 464 byte oszlop, az egyes oszlopok felülről lefelé (200 byte), és aztán balról jobbra
Title: Re: Grafikai trükkök
Post by: IstvanV on 2013.April.13. 19:43:36
Quote from: geco
Pedig direkt a linuxos EP128emuval néztem, mert a virtuális XP alatt tapasztaltam ,hogy nem minden megy úgy, ahogy kéne :D Egy picit darabos volt a scroll, és nem csak azért, mert byte-onként mozog, hanem néha megakad egy picit, de megnézem újra :)
Emulátoron jobb minőségű scrollhoz érdemes "resample to monitor refresh rate" (OpenGL kell hozzá) módot beállítani.
Title: Re: Grafikai trükkök
Post by: IstvanV on 2013.April.13. 19:46:25
Quote from: geco
Úgy fest 50Hz mellett a byte-onkénti scroll is jó, lehet 25 Hz-en se látszik darabosnak.
Elsősorban a sebesség számít, a 25 fps még elfogadható (nem darabos), de byte-onként túl gyors lehet a scroll. A 12.5 fps-es byte-onkénti scroll pedig már kissé darabos a 12.5 fps miatt.
Title: Re: Grafikai trükkök
Post by: geco on 2013.April.13. 19:56:00
Quote from: IstvanV
Emulátoron jobb minőségű scrollhoz érdemes "resample to monitor refresh rate" (OpenGL kell hozzá) módot beállítani.
Köfiii :)
Title: Re: Grafikai trükkök
Post by: geco on 2013.April.13. 19:57:40
Quote from: IstvanV
Elsősorban a sebesség számít, a 25 fps még elfogadható (nem darabos), de byte-onként túl gyors lehet a scroll. A 12.5 fps-es byte-onkénti scroll pedig már kissé darabos a 12.5 fps miatt.
és tényleg :), a képkimozfató cuccomban karakterenként mozgatok ki, és mégse darabos :)
Title: Re: Grafikai trükkök
Post by: geco on 2013.April.13. 20:03:31
Csináltam egy kis tesztet: (16 push)

kód és nullázott terület FC szegmens alatt: ( byte / frame)
LDIR: 0d8fh byte
PUSH: 2f84h byte
kód FC alatt, nullázott terület FC fölött (csak push): 2f84h
Az LDIR is megegyezett az előző értékkel
kód FC felett, nullázott terület FC alatt (csak push): 291eh
kód is és nullázott terület is FC felett (csak push): 1fbch

Nem szúrtam el valamit? Mert ha a kód nem videólapon volt, akkor a törlés mindenhol ugyanolyan sebességgel futott.
Title: Re: Grafikai trükkök
Post by: IstvanV on 2013.April.13. 20:07:46
Csak érdekességként, a fenti scroll.com programban így történik a belépő oszlopok feltöltése (ez egy sor mindkét képernyő pufferbe):
Code: [Select]
       pop     bc
        ld      l, c
        ld      a, b
        ld      (de), a
        set     6, d
        and     55h
        rla
        or      (hl)
        ld      (de), a
        ex      de, hl
        ld      bc, 0c000h + 80
        add     hl, bc
        ex      de, hl

Az SP egy átmeneti pufferre mutat, amely két egymás melletti oszlopot tartalmaz (jobbról balra és felülről lefelé), a H pedig egy táblázat címének a felső byte-ja az egy pixel eltoláshoz. A DE a video memória cím, a 2. lapon található az egyik képernyő puffer, a 3. lapon pedig az egy pixellel balra eltolt verzió.

Az átmeneti puffer feltöltése így történik (két byte egy oszlopban):
Code: [Select]
       pop     de
        ld      (hl), e
        set     1, l
        ld      (hl), d
        inc     l
        inc     l
Ez a kód négyszer van "kiírva" a ciklusban, és az utolsó két INC L helyett INC HL-t használ (16 byte-os határra igazított puffert feltételezve). Az SP a kép adatra (scroll.bin tartalma) mutat, a HL pedig az átmeneti pufferre. A másolás pazarol némi CPU időt, és lehetne optimalizáni (pl. felváltva az egyik képkockában másolni, a másikban pedig rajzolni, így egyenletesebb és a legrosszabb esetben alacsonyabb lenne a CPU használat), bár a rajzoló ckilus (fent) CPU igénye nagyobb.
Title: Re: Grafikai trükkök
Post by: Povi on 2013.April.13. 20:08:54
Quote from: Zozosoft
A gyors RAM tesztek is PUSH-al nullázzák a RAM-ot.
Az ENTERPRESS-ben is volt egy rutin, amit Hsoft írt, ott képernyőtörlés volt megoldva PUSH-al
Title: Re: Grafikai trükkök
Post by: geco on 2013.April.13. 20:26:57
A pufferbe miért hagyod ki minden páratlan bájtot?
Ott még végzel minden egyes bájton egy eltolást, és oda csordul a kitolt bit?
Title: Re: Grafikai trükkök
Post by: IstvanV on 2013.April.13. 20:31:57
Quote from: geco
A pufferbe miért hagyod ki minden páratlan bájtot?
Oda a szomszédos oszlop kerül. A rajzolásnál minden sorban egy POP utasítás két byte-ot olvas a pufferből.
Title: Re: Grafikai trükkök
Post by: geco on 2013.April.13. 20:32:08
Ja,a BC'-t használod, mert ha nem, akkor még azzal lehetne gyorsítani, hogy BC'-nek értéket adsz az oszlopkiírás előtt, nem?

EXX
LD BC,0c000h+80h
EXX
Title: Re: Grafikai trükkök
Post by: IstvanV on 2013.April.13. 21:01:56
Quote from: geco
Ja,a BC'-t használod, mert ha nem, akkor még azzal lehetne gyorsítani, hogy BC'-nek értéket adsz az oszlopkiírás előtt, nem?
A BC' nem lenne jó, mert akkor nem tudom a DE-hez hozzáadni. Viszont van egy másik lehetőség a gyorsításra:
Code: [Select]
        ld      bc, 0c000h + 80
        ...
        pop     hl
        ld      a, h
        ld      h, high scrollTable
        ld      (de), a
        set     6, d
        and     55h
        rla
        or      (hl)
        ld      (de), a
        ex      de, hl
        add     hl, bc
        ex      de, hl
Title: Re: Grafikai trükkök
Post by: geco on 2013.April.13. 21:32:59
Quote from: IstvanV
A BC' nem lenne jó, mert akkor nem tudom a DE-hez hozzáadni. Viszont van egy másik lehetőség a gyorsításra:
Code: [Select]
       ld      bc, 0c000h + 80
        ...
        pop     hl
        ld      a, h
        ld      h, high scrollTable
        ld      (de), a
        set     6, d
        and     55h
        rla
        or      (hl)
        ld      (de), a
        ex      de, hl
        add     hl, bc
        ex      de, hl
bocs, tényleg :lol:
Title: Re: Grafikai trükkök
Post by: IstvanV on 2013.April.14. 15:39:57
Quote from: Lacika
Képet hogy tudunk konvertálni a scroll-rutinhoz?
Itt egy módosított epimgconv verzió, ami -outfmt 7 használata esetén a scroll.com formátumában menti a konvertált képet. Ez csak 16 színű nem interlace módú lehet 232x200 méretben, és automatikusan -palres 0-t (fix paletta az egész képen) állít be.

[attachurl=#]
Title: Re: Grafikai trükkök
Post by: IstvanV on 2013.April.14. 16:28:08
Gyorsabb verzió, ~20.5% CPU fogyasztás (a legrosszabb esetben, "eltolt" képkockánál és a video memóriából olvasva) 50 fps sebességnél:
[attachurl=#]
[attachurl=#]
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.April.14. 16:37:06
Hmmm ... most néztem a csillagos demómban olyan 15% -nyi időt visz el az LPT frissítése ...

Ezt futtatom le 136 -szor :

 ldi
 ldi
 ex de,hl
 add hl,sp
 ex de,hl

Elég durva ...



Egyébként hogy mérsz időt ? Emuban breakpoint- tal kiolvasod a raszter pozíciót, vagy szamolgatod a képen a sorokat kézzel, vagy hogy ?
Title: Re: Grafikai trükkök
Post by: IstvanV on 2013.April.14. 16:45:16
Quote from: Z80System
Egyébként hogy mérsz időt ?
Ezzel a Lua scripttel:
[attachurl=#]
Ezt a debuggerben futtatni kell (Run) és aztán Step módban folytatni az emulációt, hogy a script a futásidőt utasításonként mérni tudja.
Title: Re: Grafikai trükkök
Post by: IstvanV on 2013.April.14. 17:04:03
Quote from: Z80System
Hmmm ... most néztem a csillagos demómban olyan 15% -nyi időt visz el az LPT frissítése ...

Elég durva ...

Ez két sor beléptetése "eltolt" módban (az eltolás nélküli eset - minden második képkockánál - egyszerűbb és gyorsabb):
Code: [Select]
       exx ; 4
        pop     bc ; 14 (VV)
        ld      a, (de) ; 21 (V)
        inc     e ; 25
        and     0aah ; 32
        rra ; 36
        ld      l, c ; 40
        or      (hl) ; 47
        exx ; 51
        ld      (hl), a ; 58 (V)
        add     hl, de ; 69
        exx ; 73
        ld      a, (de) ; 80 (V)
        inc     de ; 86
        and     0aah ; 93
        rra ; 97
        ld      l, b ; 101
        or      (hl) ; 108
        exx ; 112
        ld      (hl), a ; 119 (V)
        add     hl, de ; 130
A megjegyzésekben a ciklusszámok láthatók, a "V" potenciális video memória hozzáférést jelöl. V=5-el számolva ez +30 ciklus, ami pesszimista számítás, de nem veszi figyelembe a 4 soronkénti DJNZ utasítást. 160 * 100 = 16000, ami valóban kb. 20%-a a 79942 Z80 ciklusnak két video megszakítás között.

Quote from: Z80System
Ezt futtatom le 136 -szor :

 ldi
 ldi
 ex de,hl
 add hl,sp
 ex de,hl
Valamivel gyorsabb megoldás:
Code: [Select]
        pop     de
        ld      (hl), e
        inc     l
        ld      (hl), d
        add     hl, bc
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.April.27. 18:19:30
Egy pixelsoronkénti ( vagy akár két pixelsoronkénti ) LPT frissítése (memóriacímek átírása bennük, hogy a másik képernyő buffer -re mutassanak) eszetlenül költségesnek tűnik nekem, el szeretném kerülni.

Ennek egyik módja az, ha az LPT -ket legenerálom egymás alá, pixelsoronként, mondjuk kettőt, ha két képet akarok váltogatni, és csak a másodikban állítom be a reload flag -et, ekkor az elsőről automatikusan átcsúszik a nick a másodikra.

Ha ugyanezt mondjuk nem 50 FPS -sel szeretném elvégezni, hanem mondjuk 25 FPS -sel, akkor már 4 LPT -t kell legeneráljak, ha 16,6 FPS -sel, akkor már 6 LPT -t, melyeknek az első felében (első 2, vagy első 3 LPT) az első képernyő pufferre mutató címek vannak beírva a sorokba, a második adag LPT -ben meg a második képernyőre.

Ennek 3 hátránya is van.

Egyrészt az FPS csökkenésével egyre nő az LPT -k száma,

másrészt az FPS az LPT -kbe lesz huzalozva, váltakozó FPS -ű megjelenítés nem lehet ilyen módon,

harmadrészt az LPT -im között szeretnék kihagyni helyet, amit nem tudok megtenni, ha a nick lép automatikusan egyik LPT -ről a másikra, a reload flag hijján.

Az lenne az igazi megoldás számomra, ha csak 2 darab előre legenerált LPT -m lenne, hiszen csak 2 képet akarok váltogatni, függetlenül a mindenkori FPS -től, így két LPT elég, amiben benne vannak a 2 képernyő bufferre vonatkozó címek, de ezek az LPT -k lehessenek akárhol a memóriában, legyen mindkettő LPT végén reload flag, amíg nem váltom át őket, addig ugyanaz az LPT legyen a képen, aztán ha letellett az X frame -em, amit akarok, akkor én váltsam át az egyikről a másikra az LPT -t.

A kérdés az lenne, hogy lehet -e ilyet tokéletesen villanás mentesen ? Tehát (legjobb esetben akár 50 FPS -sel) lehet -e baromi sűrűn LPT címet váltani a nick -ben úgy, hogy a képernyő természetesen rezzenéstelen maradjon. Időzítés, megszak, ilyesmi alkalmazható lenne ...

Van -e erre megoldás, tud -e ilyet a nick ?
Title: Re: Grafikai trükkök
Post by: Zozosoft on 2013.April.27. 18:35:04
Lehet ilyet, sőt 128-as Spectrum emulációhoz kell is, ha aktívan kapcsolgatnak a két kép között.
Az a kulcs, hogy csak a 83h portot kelljen átírni, azaz 1000H (vagy többszöröse) legyen a különbség a két egyforma (videócímekben eltérő) LPT között. Így bármikor lehet átkapcsolni.
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.April.27. 18:46:39
Quote
Az a kulcs, hogy csak a 83h portot kelljen átírni, azaz 1000H (vagy többszöröse) legyen a különbség a két egyforma (videócímekben eltérő) LPT között. Így bármikor lehet átkapcsolni.
Hogyhogy bármikor ? Fél képernyőkor is ? És a nick azonnal (mindenféle külön felszólítás nélkül) csak a 83h átírásától a következő LPB -t már a masik LPT -ből olvassa ?

Gondolom akkor a szerkezete az LPT -knek ugyanolyan kell legyen, nem ? Különben osszezavarodnak a sorszámok/ szinkron ... ?

Ha ez így van, akkor ez akár jó is lehet, de nekem jobban tetszene, hogyha rakhatnám az LPT -t teljesen szabadon, és akár a felépítésük se kéne pont ugyanolyan legyen, maximum ugyanannyi sorszámból kéne álljanak függőlegesen, vagy esetleg csak helyes szinkronjuk kéne legyen, és lenne valami, hogy mondjuk a mittudoménmelyik szinkron LPB -re beállítok egy videomegszakot, és ha akkor írom át a címet a nick- ben ilyen meg ilyen szabályokkal, akkor zizzenéstelen lesz ...
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.April.27. 18:53:56
És ez egyébként le van írva valahol az EXOS leírásban, vagy valahol, vagy pedig csak úgy ki lett kísérletezve ?
Title: Re: Grafikai trükkök
Post by: Zozosoft on 2013.April.27. 18:57:46
Quote from: Z80System
Hogyhogy bármikor ? Fél képernyőkor is ? És a nick azonnal (mindenféle külön felszólítás nélkül) csak a 83h átírásától a következő LPB -t már a masik LPT -ből olvassa ?
Igen.

Quote
Gondolom akkor a szerkezete az LPT -knek ugyanolyan kell legyen, nem ? Különben osszezavarodnak a sorszámok/ szinkron ... ?
Igen.
Quote
hogy mondjuk a mittudoménmelyik szinkron LPB -re beállítok egy videomegszakot, és ha akkor írom át a címet a nick- ben ilyen meg ilyen szabályokkal, akkor zizzenéstelen lesz ...
Elvileg ha jól rakod össze az lptket (a szinkron ugyanaz, és összesen ugyanannyi pixel sor van definiálva), akkor ha a force reload nélkül írod be az új címet, akkor jó lehet. Az IRQ generálást a szinkron elejére teszed, az IRQ rutin betölti az új címet, és amikor eléri a reload bites sort, már az újat fogja olvasni.
Title: Re: Grafikai trükkök
Post by: Zozosoft on 2013.April.27. 19:04:20
Quote from: Z80System
És ez egyébként le van írva valahol az EXOS leírásban, vagy valahol, vagy pedig csak úgy ki lett kísérletezve ?
Ki lett kísérletezve. Egy készülő Spectrum 128-as átírat (legyen majd meglepetés :-) ) használ ilyet, hogy a kép közepén kapcsolgat oda-vissza a két videó memória között, hogy a menüpontokat egy mozgó háttérrel mixelje.
Ehhez meg kellett találni, hogyan lehet nemcsak az LPT elején átkapcsolni.
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.April.27. 19:11:51
Quote
Az IRQ generálást a szinkron elejére teszed, az IRQ rutin betölti az új címet, és amikor eléri a reload bites sort, már az újat fogja olvasni.
Csak akkor nem értem most az 1000H -ra igazított, csak 83h -s verzió mit tesz hozzá a dologhoz ?

Mindkét regisztert átkapcsolni nincs idő egy pixelsor alatt, vagy mi ?

Tehát ha a fenti működik a szinkronnál, akkor működni fog az egyéb LPB -knél is, nem ?



Egyébkén ez a force reload flag (ez gondolom nem az LPB reload flag -je, hanem a 83h egyik bit -je) ez hogy működik ? A 83h az azonnal figyelembe van véve (hisz először azt írtad), a 82h viszont csak akkor, ha van force reload a 83h -n ? Vagy mi ? Nem mondom, hogy vágom ennek az értelmét, hogy mit akarhattak volna ilyen működéssel.
Title: Re: Grafikai trükkök
Post by: Zozosoft on 2013.April.27. 19:25:31
Quote from: Z80System
Csak akkor nem értem most az 1000H -ra igazított, csak 83h -s verzió mit tesz hozzá a dologhoz ?
Bármikor lehet átkapcsolni.
Quote
Mindkét regisztert átkapcsolni nincs idő egy pixelsor alatt, vagy mi ?
Idő az van, csak ha a 82h-t is átírod, akkor az új LPT-t az elejétől kezdi olvasni.

Tehát ha a fenti működik a szinkronnál, akkor működni fog az egyéb LPB -knél is, nem ?


Quote
Egyébkén ez a force reload flag (ez gondolom nem az LPB reload flag -je, hanem a 83h egyik bit -je) ez hogy működik ? A 83h az azonnal figyelembe van véve (hisz először azt írtad), a 82h viszont csak akkor, ha van force reload a 83h -n ? Vagy mi ? Nem mondom, hogy vágom ennek az értelmét, hogy mit akarhattak volna ilyen működéssel.
Ez be van kapcsolva a 83h írásos módszernél, ettől megy át a másik LPT-re.
De mivel a 82h nem volt írva, ezért az alsó bitek megmaradnak.
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.April.27. 19:26:43
Van valami mód arra, hogy egy video megszakítást kezelve megtudjuk melyik LPB váltotta ki azt a video megszakítást ? Valahogy visszaolvasni a függőleges raszterpozíciót, vagy aktuális LPB címet, vagy akármit ? Tehát hogy ha egy LPT -be több helyre is pakolok video megszakítást, akkor kitalálhassam melyiket kezelem éppen.

Persze kezelve az egyiket be lehet állítani valami flag -eket, de az bármikor elcsúszhat egy nem ismert működés, vagy akármi miatt. Valami direktebb infó kéne arról. melyik LPB megszakítását kezelem éppen.
Title: Re: Grafikai trükkök
Post by: Zozosoft on 2013.April.27. 19:28:44
Quote from: Z80System
Valahogy visszaolvasni a függőleges raszterpozíciót, vagy aktuális LPB címet, vagy akármit ?
Nincs ilyen :-(
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.April.27. 19:50:51
Quote
Idő az van, csak ha a 82h-t is átírod, akkor az új LPT-t az elejétől kezdi olvasni.
Hát ha az elejét írom bele ... nem ?





Na próbálom akkor összefoglalni a szabályokat:

Van a nick, annak a 2 LPT cim regisztere. 82h alacsony, 83h magas helyiérték. Ezek a regiszerek maguktól nem változnak egyáltalan. A szerepük csak annyi hogy egy LBP reload flag, vagy egy 83h reload bit (melyek tök ugyanazt a hatást érik el, csak első z80 független, második z80 függő módon) hatására ezekből a regiszterekből inicializálódik újra a nick LPT olvasása.

Tulajdonképp a nick JP utasítása a reload, és az operandusa meg ez a két regiszter, nem ?

Tehát magyarul ha ebbe a két regiszterbe barmit beleírunk, a prímszámokat akár, vagy a születési dátumunkat, az égvilágon semmi nem történik mindaddig, míg fenti két módszer valamelyike ki nem váltja a nick reload mechanizmusát, na ekkor ami épp benne van a fenti 2 regiszterben, az betöltődik a nick- be valahova belülre, és a következő lpb -t a nick onnan kezdi olvasni, és punktum.

Ebből akkor számomra valami olyan is következne, hogy a z80- nal 83h -n kezdeményezett force reload SEM AZONNAL-AZONNAL tölt újra, hanem igenis az aktuális LPB kirajzolásának be kell fejeződnie a nick által, ami ugye nagy is lehet, sok rasztersor, és csak utána fog megtörténni az a reload. Gondolom persze a z80 ettol nem fog blokkolódni, ő fut tovább, legrosszabb esetben valami 256 sor után majd tényleg bekovetkezik a reload a nick -ben. Ad abszurdum az is lehet, hogy ezen idő alatt akar módosíthatunk még a nick regiszterein ... :)

Namost akkor fentiekből az következik, hogy a két regiszerünkbe NEM KÖTELEZŐ az LPT kezdőcíme legyen, csak az "kötelező" hogy mikor a két okunk közül valamelyik kiváltja az LPT reload -ot, akkor "belepasszoljon" az új címen lévő LPB a szinkronunkba, és ha ez teljesül, akkor normál, rezzenéstelen képet fogunk kapni.






Ha mindez igaz, akkor viszont amit csinálsz azt nem csak 1000h- s váltogatással lehet elérni, hanem egy tetszőleges pixelsornál bekövetkező valamelyik forrásból származó reload -dal, a MEGFELELŐ LPB címével a regisztereinkben. Nem feltétlenül az LPT -nk elejével, és nem feltétlen 1000h -s határon, nem ?
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.April.27. 19:58:23
Viszont ha igazakat irkáltam, nem nagyon értem miért kéne a szinkronom elején váltanom át a videomegszakban az LPT- met, hisz épp hogy meg kell várjam míg a teljes lpt- m feldolgozódott, és a legutolsó LPB -m kirajzolása közben kell váltsak a megszakból, ez esetben a masik LPT -m legelejére, nem ?
Title: Re: Grafikai trükkök
Post by: Zozosoft on 2013.April.27. 20:34:53
Quote from: Z80System
Viszont ha igazakat irkáltam, nem nagyon értem miért kéne a szinkronom elején váltanom át a videomegszakban az LPT- met, hisz épp hogy meg kell várjam míg a teljes lpt- m feldolgozódott, és a legutolsó LPB -m kirajzolása közben kell váltsak a megszakból, ez esetben a masik LPT -m legelejére, nem ?
Azt ki kell próbálni, hogyha az utolsó reloados sorban van az INT, akkor még elég gyorsan beíródik az új cím, mielőtt reloadol a Nick.
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.April.27. 20:44:06
Quote
Azt ki kell próbálni, hogyha az utolsó reloados sorban van az INT, akkor még elég gyorsan beíródik az új cím, mielőtt reloadol a Nick.

Ja, hogy igazából te nem force reload -os váltásra gondoltál ...

Akkor viszont tulajdonképp tökmindegy hogy mikor írom át, nem ?

Tehát megy a kirajzolás, az LPT végén ott a reload, és közben tetszőleges időben átírhatom akkor force reload flag nélkül a regisztereket, majd a frame legvégén az LPB reload flag betolti a regiszterekből a nick -be, addig meg ott csücsül.

Tehát ha jól értettem/következtettem/fantáziáltam össze itt a dolgokat, akkor az én kiinduló problémám ilyen magától értetődően egyszerűen megoldható (hiszen én csak egesz LPT -ket akarok váltani, amik tetszoleges címen vannak), a te problémádra pedig az 1000H -s módszer meg egy nem kizárólagos, de nagyon elegáns megoldás ... nem ?
Title: Re: Grafikai trükkök
Post by: Zozosoft on 2013.April.27. 20:46:14
Quote from: Z80System
Ha mindez igaz, akkor viszont amit csinálsz azt nem csak 1000h- s váltogatással lehet elérni, hanem egy tetszőleges pixelsornál bekövetkező valamelyik forrásból származó reload -dal, a MEGFELELŐ LPB címével a regisztereinkben. Nem feltétlenül az LPT -nk elejével, és nem feltétlen 1000h -s határon, nem ?
Nem 1000h-s különbséggel nem működik. Ha a 82h-t is írod oda az LPT eleje kell, különben a következő reloadnál már csak csonka LPT-t fog olvasni. Ha meg az elejét írod, akkor ugrani fog a kép reloaddal. Reload nélküli írásnál meg csak az LPT végén lévő reloadnál vált át, így kép közben nem lehet többször váltani.

Eredetileg én is onnan indultam, hogy egymás mögött volt a két LPT :-)
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.April.27. 20:50:00
Quote
Nem 1000h-s különbséggel nem működik. Ha a 82h-t is írod oda az LPT eleje kell, különben a következő reloadnál már csak csonka LPT-t fog olvasni. Ha meg az elejét írod, akkor ugrani fog a kép reloaddal. Reload nélküli írásnál meg csak az LPT végén lévő reloadnál vált át, így kép közben nem lehet többször váltani.
Semmi nem akadályoz meg téged abban, hogy (akár tobb váltás után) az LPT vége- n elhelyezett reload flag aktivalodasa elott beállítsd végul a helyes kezdő LPT címet a regiszterekbe.

Ezért mondom, hogy az 1000H -s módszer csupan egy egyszerűsítés, egy elegáns megoldás, de nem KÖTELEZŐ megoldás. Nem ?
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.April.27. 20:53:02
Feltéve persze, hogy nincs olyan, hogy ha a 82- be írsz, akkor automatikus reload van, egy harmadik reload forrásként, vagy ilyesmi ...

Tehát ha igaz az összefoglalásom.
Title: Re: Grafikai trükkök
Post by: Zozosoft on 2013.April.27. 20:58:46
Quote from: Z80System
Semmi nem akadályoz meg téged abban, hogy (akár tobb váltás után) az LPT vége- n elhelyezett reload flag aktivalodasa elott beállítsd végul a helyes kezdő LPT címet a regiszterekbe.

Ezért mondom, hogy az 1000H -s módszer csupan egy egyszerűsítés, egy elegáns megoldás, de nem KÖTELEZŐ megoldás. Nem ?
Nem kötelező de ez esetben jönne a következő probléma, hogy mit is írjunk 82h-ra? Tudni kéne, hogy éppen melyik sorban jár a Nick, hogy a másik LPT következő LPB-jének a címét kiszámoljuk.
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.April.27. 21:04:28
Quote
Nem kötelező de ez esetben jönne a következő probléma, hogy mit is írjunk 82h-ra? Tudni kéne, hogy éppen melyik sorban jár a Nick, hogy a másik LPT következő LPB-jének a címét kiszámoljuk.
Igen, de természetesen ez is megoldható lenne, kombinálva a video megszakokat, reload flag -eket az LPB -kben, illetve a megszakkezelőkben a címátírásokat esetleg force reload- okat.

De pont attól olyan elegáns az 1000H -s módszered, mert az egy huszárvágással minden szinkront a nick -re bíz, neked csak azzal kell törődj, hogy hol akarod a másikra kapcsolni a képet, és azt egyetlen byte átírásával tetszőleges időpillanatban megteheted.
Title: Re: Grafikai trükkök
Post by: IstvanV on 2013.May.01. 19:51:15
Továbbfejlesztett scroll program:
[attachurlé=#]
[attachurlé=#]
[attachurlé=#]
Ez ugyan csak 24 karakter magas, viszont a kép adat tömörített, így 232 helyett 288 karakter a teljes szélesség, és 128K-s gépen is EXOS kompatibilis.
Title: Re: Grafikai trükkök
Post by: Zozosoft on 2013.May.01. 20:19:16
Poén a kép :-) kicsit ütősebb mint a demó kazettán lévő berepülünk a gépbe grafika! :-)
Title: Re: Grafikai trükkök
Post by: endi on 2013.May.01. 20:30:52
Quote from: Zozosoft
Poén a kép :-) kicsit ütősebb mint a demó kazettán lévő berepülünk a gépbe grafika! :-)
jaja, ütős lett volna ezt kazettáról betölteni :P
Title: Re: Grafikai trükkök
Post by: Zozosoft on 2013.May.01. 20:40:39
Quote from: endi
jaja, ütős lett volna ezt kazettáról betölteni :P
Nasa&Guy demók is voltak ekkorák (fájlméretre) , és azokat bőven töltögettük magnóról.
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.May.01. 22:04:54
István, szerinted is igaz az, hogy valószínűleg a nick bárhogyan kap reload flag -et, akár lpb -ből, akár 83h port bittől, előszor meg fogja várni az aktuálisan kirajzolt lpb végét, és csak utána tölt majd újra ?
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.May.01. 22:06:17
Az vajon miért van, hogy az exos leírásban az szerepel, hogy a 83h port -ra először írjuk ki simán az értéket, majd az értéket a b6 -tal megtolva, és utána előzőt b7 -tel megtoldva ?
Title: Re: Grafikai trükkök
Post by: geco on 2013.May.02. 11:03:43
Érdekes, én a 82h portot írom csak a képváltós programoknál, és az se villog, azt tapasztaltam, hogyha váltok, akkor szépen lefut az aktuális LPT, és csak a reload bitnél tér át az új LPT-re.
Title: Re: Grafikai trükkök
Post by: Zozosoft on 2013.May.02. 11:11:20
Quote from: geco
Érdekes, én a 82h portot írom csak a képváltós programoknál, és az se villog, azt tapasztaltam, hogyha váltok, akkor szépen lefut az aktuális LPT, és csak a reload bitnél tér át az új LPT-re.
Igen akkor kell erőszakoskodni, hogyha kép közben akarunk váltani.

Az Nick leírásban lévő módszer szerintem arra van, hogy bármilyen állapotban van a Nick (pl bekapcsolás utáni véletlenszerű adatokkal fut) biztosan átmenjen az új LPT-re.
Title: Re: Grafikai trükkök
Post by: Povi on 2013.May.02. 12:22:11
Zozo, elhozod ezt az új demo-t a klubba? Még nem láttam, ott nézném meg... :-)
Title: Re: Grafikai trükkök
Post by: IstvanV on 2013.May.02. 14:09:27
Saját scroll készítéséhez:
[attachurl=#]
[attachurl=#]
[attachurl=#]
Title: Re: Grafikai trükkök
Post by: IstvanV on 2013.May.02. 14:26:50
A konvertáláshoz a következő epimgconv paramétereket kell használni (a -mode 3 helyett természetesen lehet 2 vagy 4 is):

-mode 3 -outfmt 7 -size 288 192 -palres 0 -scalemode 1

Hatékonyabb tömörítés érhető el "egyszerűbb" dither használatával (például -dither 1 0.5, a második érték - amelynek az alapértelmezése 0.95 - csökkentése általában javítja a tömörítést, de rontja a kép minőségét). Ha így sem elég a memória 128K-s gépen, akkor még lehet próbálkozni a -mode 2 -dither 4 0, vagy esetleg -mode 2 -dither 0 0 használatával. A csökkentett (vagy kikapcsolt) dither mellett hasznos lehet a -chromaerr 1 a minőség javítására.

A kép mérete is módosítható a scroll2.s szerkesztésével és újrafordításával. A következő 3 változó állítható:
Code: [Select]
SCROLL_WIDTH    equ     576
VIDEO_HEIGHT    equ     192
VIDEO_WIDTH     equ     80
A VIDEO_HEIGHT a kép magassága, amely csak 16 egész számú többszöröse lehet, és legfeljebb 240. A VIDEO_WIDTH az ablak szélessége fél karakterekben, ennek természetesen párosnak kell lennie. A SCROLL_WIDTH pedig a scroll teljes szélessége fél karakterekben, ez is csak páros lehet. A scroll méretét korlátozza a memória, és a tömörítés hatásfoka. Konvertálásnál -size SCROLL_WIDTH/2 VIDEO_HEIGHT paramétert kell megadni. Egy további korlátozás, hogy az "ablak" csak 16K méretű területen mozgatható, ezért a következő feltételnek is teljesülnie kell:
VIDEO_WIDTH * VIDEO_HEIGHT + SCROLL_WIDTH - VIDEO_WIDTH <= 16384
Title: Re: Grafikai trükkök
Post by: Zozosoft on 2013.May.02. 14:35:16
Bővített gépen lehet sokkal szélesebb is a kép?
Title: Re: Grafikai trükkök
Post by: IstvanV on 2013.May.02. 14:45:30
Quote from: Zozosoft
Bővített gépen lehet sokkal szélesebb is a kép?
Elvileg igen, de kisebb módosításokra lehet szükség:
- az epimgconv fenti változata 511 karakterre (SCROLL_WIDTH = 1022) korlátozza a szélességet, illetve a bemeneti kép mérete legfeljebb 20480x8192 lehet; ezek az értékek valójában egyszerűen növelhetők a forráskódban :oops:
- a scroll2.s csak 8 szegmenst (ebből egy a 0. lap, tehát a tömörített méret kb. 124.4K lehet, 128K-s gépen pedig 76.4K + ami szabad hely van a rendszerszegmens elején) tud használni a file tárolására; ennek a növeléséhez a dataSegments táblázat méretét kell módosítani a forráskód végén
Title: Re: Grafikai trükkök
Post by: Zozosoft on 2013.May.02. 15:46:53
Quote from: Povi
Zozo, elhozod ezt az új demo-t a klubba? Még nem láttam, ott nézném meg... :-)
Találtam 720-as lemezt, viszem :-)
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.May.05. 17:26:43
Gondolkodtam itt a nick cím váltáson ... nem passzol ez össze nekem ...

Ha úgy lenne ahogy mondom, hogy mikor a nick -nek érkezik egy reload parancs bármelyik forrásból, akkor feltölti a 82/83 port tartalmát a belső regisztereibe, akkor Zozo módszere nem működne, hisz ő éppen azt csinálja, hogy csak a 83 -as portot írja, reload flag -gal.

Ha igaz lenne amit írok, akkor a reload flag hatására (83 -as porton) mind a 82 mind a 83 -as port tartalma feltöltődne a nick -be. De Zozo módszerében épp az volt a felfedezés, hogy ilyenkor csak a 83 -as port tartalma töltődik fel, és az alsó rész az marad a nick -ben, ami volt. (Zozo szerint.)

Szóval akkor én most nem értem, hogy a különböző (két) reload módszer esetén mi a pontos nick működés. Ki tudja ezt ?
Title: Re: Grafikai trükkök
Post by: Zozosoft on 2013.May.05. 17:34:11
Gyanítom, hogy tartozik egy belső flag a 82h-hoz, hogy írva lett, frissíteni kell a reloadnál.
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.May.05. 17:41:49
Használsz b6 -ot is a 83 -on, vagy csak b7 -et ? Nem lehet hogy a b6 jelenti a 82 reload -ot, b7 a 83 reload -ot, és az lpb reload flag meg mondjuk mindkettő újratöltését jelenti, implicit ?
Title: Re: Grafikai trükkök
Post by: Zozosoft on 2013.May.05. 17:46:02
Ha a b6 nem 1 akkor nem fut a Nick, nincs kép.
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.May.05. 18:09:46
Hmmm ... tehát akkor ha LPB reload flag van, akkor újratölti mindkettőt, hisz elejére ugrás, loop -olás van, függetlenül attól, hogy a portokon frissült -e valami, vagy már sok reload óta ugyanaz az érték van bennük.

Ha meg 83 -as reload flag -et kap, akkor amelyik írva lett a 2 port közül (és 83 mindenképp írva lett, mert abban van a reload bit aminek a hatását tárgyaljuk ), csak azt töltené fel ?

De mindkét esetben az aktuálisan már beolvasott és futó LPB tiszteletben lenne tartva ?

Ja ... ez így végülis elég valószínűnek látszik.
Title: Re: Grafikai trükkök
Post by: geco on 2013.May.06. 10:10:56
Az jutott eszembe, milyen jó lenne, ha lenne olyan beállítás, hogy a kép-et kimerevíti a Nick, tehát nem jelenik meg ezidő alatt semmilyen változás a képen, így ki lehetne kerülni a két kép használatát ezzel is picit gyorsítva a programot, és csökkenteni a memóriahasználatot. Nincs ilyen opciónk? Pl ha a 83-as port felső két bitje közül az egyiket nullázom, akkor nem frissül a kép, hanem ugyanaz marad a képernyőn?
Title: Re: Grafikai trükkök
Post by: Zozosoft on 2013.May.06. 10:17:12
Mitől maradna bármi a képernyőn? Eltekintve attól, ha radarhoz való CRT-t használsz, amin még ott van fél percig a kép :-)
Title: Re: Grafikai trükkök
Post by: lgb on 2013.May.06. 10:20:06
Quote from: geco
Az jutott eszembe, milyen jó lenne, ha lenne olyan beállítás, hogy a kép-et kimerevíti a Nick, tehát nem jelenik meg ezidő alatt semmilyen változás a képen, így ki lehetne kerülni a két kép használatát ezzel is picit gyorsítva a programot, és csökkenteni a memóriahasználatot. Nincs ilyen opciónk? Pl ha a 83-as port felső két bitje közül az egyiket nullázom, akkor nem frissül a kép, hanem ugyanaz marad a képernyőn?

Azt hogy? :) Nick-nek nincs sajat memoriaja (leszamitva par regiszter - gondolom) ahhoz hogy _valamit_ megjelenitsen, folyamatosan olvasnia kell a RAM-ot es az alapjan jeleniti meg a kepet. Ha nem akarod, hogy lassa a valtozast ugymond, akkor honnan venne az adatokat addig, amit meg kell jeleniteni?

Ami viszont eszembe jutott: RAM bovites stb, lehet fogyasztasnak is hasznalna miegymas ha megszabadulnek a DRAM-oktol illetve az egesz frissites RAS/CAS stb cucctol (esetleg kieshetne jo par IC) es az alaplapi memoriat is SRAM-ra cserelni valahogy a bovitessel egyutt? Ui akkor az az erdekes helyzet allhatna elo, hogy a 64K-s videoram-ra pl bepakolhatnek 128K-s SRAM-ot. Itt adodik a lehetoseg hogy pl mi van ha egy kis plusz logikaval azt mondom, hogy a Nick-nek meg lehetne mondani h a video RAM melyik felet lassa? Persze akkor mar uez lehetne CPU-ra is :) Es akkor lathatjak eltero feluket is! Ok, persze az "idealis" az lenne, ha a full RAM-ra lehetne nick-nek es cpu-nak ralatasa, nem ilyen "masodszintu lapozas" de imho ez mar tul mely beleturas lenne a gep lelkivalagaba, hisz a videoram-nal van h ott cpu/nick kozosen osztozik, mig a tobbi RAM-nal ez nincs, tehat itt a video ram es a "normal" RAM bovites ket kulon dolog lenne meg mindig.
Title: Re: Grafikai trükkök
Post by: endi on 2013.May.06. 10:46:01
zx81-en volt olyan hogy képrenyő kikapcs (hangyák megjelennek) és akkor kicsit gyorsabb lett :)
Title: Re: Grafikai trükkök
Post by: Zozosoft on 2013.May.06. 10:58:50
Quote from: endi
zx81-en volt olyan hogy képrenyő kikapcs (hangyák megjelennek) és akkor kicsit gyorsabb lett :)
Mivel ott a proci rajzolta a képet, lefoglalva a nagyja CPU időt.
Title: Re: Grafikai trükkök
Post by: geco on 2013.May.06. 11:28:12
Jogos, arról megfeledkeztem ,hogy folyamatosan frissíteni kell a képet lol.
Title: Re: Grafikai trükkök
Post by: lgb on 2013.May.06. 11:31:10
Quote from: Zozosoft
Mivel ott a proci rajzolta a képet, lefoglalva a nagyja CPU időt.

Nyilvan, de azert mas gepeken is okoz gyorsulast, ha a megjelenites tilthato, mivel akkor nem osztott a memoriahozzaferes a video subsystem es a CPU kozott es/vagy nagyobb orajellel is mehet a CPU ami nem lehetseges a video mellett. Ez utobbira jo pelda a Commodore 128 ahol a VIC-II nem megy 2MHz-en, bar a CPU atkapcsolhato arra (2MHz-en viszont VDC-vel megy!), vagy a Commodore +4, ahol a CPU orajele valtozik attol fuggoen hogy eppen hol tart a kepfelepites (tehat a kep kikapcsolasaval gyorsabb), de meg C64-en is valamivel gyorsabb kikapcsolt VIC mellett, preciz idozitesi rutinok/turobok stb ezert is kapcsoljak le a kepet. EP-n nem tudom lehetseges-e total megallitani a nick-et hogy ne is olvassa a memoriat, ezzel a video ram-ot is olyan sebesseggel erne el a CPU mint a "nem video RAM"-ot, nyilvan kep nem lesz kozben viszont :)
Title: Re: Grafikai trükkök
Post by: IstvanV on 2013.May.06. 11:43:37
Quote from: lgb
EP-n nem tudom lehetseges-e total megallitani a nick-et hogy ne is olvassa a memoriat, ezzel a video ram-ot is olyan sebesseggel erne el a CPU mint a "nem video RAM"-ot, nyilvan kep nem lesz kozben viszont :)
Nem lehetséges, vagy legalábbis nem sikerült eddig megoldást találni rá. A video RAM sebessége nem függ attól, hogy a képernyőn éppen keret van-e, és a 83h port felső bitjeinek sincs hatása a sebességre. A BFh porton van egy bit, amely állítólag a beépített memóriát 16K-ra korlátozza, de ez hibásan működik, és a gyakorlatban nem sok haszna van. Pedig egyes programoknál hasznos lehetett volna, ha csak az FFh vagy FCh szegmens számít video (lassú) RAM-nak.
Title: Re: Grafikai trükkök
Post by: Zozosoft on 2013.May.06. 11:58:24
Quote from: IstvanV
A BFh porton van egy bit, amely állítólag a beépített memóriát 16K-ra korlátozza, de ez hibásan működik
Szerintem csak nem frissítették a leírást :-)
Ha azt a bitet beállítjuk, akkor az alaplapi ROM és Cartridge kivételével minden VRAM-nak lesz dekódolva, azaz a 08-FFh szegmenseken mindenhol a FC-FFh szegmensek ismétlődnek.
Ennek egy esetleges fejlettebb Nick esetén lehetne értelme, ami 64K-nál többet tud kezelni, és maga oldaná meg a VRAM további dekódolását, mondjuk 256K-ra.
Vélhetőleg eredetileg tényleg a 64/16k lehetett a terv, de aztán rájöttek, hogy úgyse fognak a már akkor is borzalmasan elavult 4116-os RAM-okkal foglalkozni, viszont felmerült, hogy mi van ha majd egyszer több VRAM kéne... így lecserélték a 16K opciót, csak a leírás nem frissült hozzá.
Title: Re: Grafikai trükkök
Post by: lgb on 2013.May.06. 12:09:33
Quote from: IstvanV
Nem lehetséges, vagy legalábbis nem sikerült eddig megoldást találni rá. A video RAM sebessége nem függ attól, hogy a képernyőn éppen keret van-e, és a 83h port felső bitjeinek sincs hatása a sebességre. A BFh porton van egy bit, amely állítólag a beépített memóriát 16K-ra korlátozza, de ez hibásan működik, és a gyakorlatban nem sok haszna van. Pedig egyes programoknál hasznos lehetett volna, ha csak az FFh vagy FCh szegmens számít video (lassú) RAM-nak.

Mondjuk ertem, mert ugye az bal keretnel eppen lpb byte-okat olvas a nick, tehat ugyanugy kell neki a memoria. A jobb keretnel viszont igazan "elengedhetne" :) mert ugye ott elvileg nem csinal tul sokat. Ezek szerint amugy tenyleg nem lehet leallitani a nick-et sehogy sem, hogy ne jelentisen meg semmit, cserebe viszont ne is olvasson memoriat? :)
Title: Re: Grafikai trükkök
Post by: Zozosoft on 2013.May.06. 12:29:19
Quote from: IstvanV
83h port felső bitjeinek sincs hatása a sebességre.
Pedig a 6-os bitnek pont ez lenne az értelme...
Title: Re: Grafikai trükkök
Post by: endi on 2013.May.06. 12:31:50
Quote from: lgb
Mondjuk ertem, mert ugye az bal keretnel eppen lpb byte-okat olvas a nick, tehat ugyanugy kell neki a memoria. A jobb keretnel viszont igazan "elengedhetne" :) mert ugye ott elvileg nem csinal tul sokat. Ezek szerint amugy tenyleg nem lehet leallitani a nick-et sehogy sem, hogy ne jelentisen meg semmit, cserebe viszont ne is olvasson memoriat? :)
és ha minden 2. sorban nincs semmi? :)
Title: Re: Grafikai trükkök
Post by: IstvanV on 2013.May.06. 13:04:18
Quote from: Zozosoft
Pedig a 6-os bitnek pont ez lenne az értelme...
Ha a 6. bit ki van kapcsolva, akkor csak az aktuális LPB ismétlődik, de egyébként van kép.
Title: Re: Grafikai trükkök
Post by: Zozosoft on 2013.May.06. 13:22:26
Quote from: IstvanV
Ha a 6. bit ki van kapcsolva, akkor csak az aktuális LPB ismétlődik, de egyébként van kép.
Ennek vajon mire lenne jó?
Title: Re: Grafikai trükkök
Post by: IstvanV on 2013.May.06. 14:03:32
Quote from: Zozosoft
Ennek vajon mire lenne jó?
Nem én terveztem a NICK-et. :) Mindenesetre, amíg 0 a bit, addig az aktuális LPB címe nem változhat, de egyéb hatását nem találtam. Azonban a 0->1 átmenete a 7. bit 0 állapota mellett az új LPT cím betöltését eredményezi a sor végén, az LPB-n belüli sorszámlálótól függetlenül. A lényeg, hogy a video kimenetet és RAM időzítést egyik bit sem kapcsolja ki, és csak az LPB címre van hatásuk. De a 7. bit állítgatásával érdekes hardver "hibát" is sikerült előhozni, már nem emlékszem, pontosan hogyan, ami egy teljesen fehér sort eredményezett a képen.:???: Talán átmenetileg érvénytelen lett az LPB cím. Lehet, hogy a 6. bit funkciójának is ehhez van köze, például hogy ne történhessen véletlenül egyszerre növelés és újratöltés (aminek a két cím közötti AND művelet, vagy más hibás eredménye lehet).
Title: Re: Grafikai trükkök
Post by: endi on 2013.May.25. 22:20:16
írtam egy tök jó programot! random írja az lpt memóriát folyamatosan :)
ugrál, villog, csíkozódik, tök állat :)
asmban lenne jó persze, bár basic is látványos
Title: Re: Grafikai trükkök
Post by: Zozosoft on 2013.May.25. 22:37:21
És hol az a program? :oops:
Title: Re: Grafikai trükkök
Post by: lgb on 2013.May.25. 23:47:08
Quote from: endi
írtam egy tök jó programot! random írja az lpt memóriát folyamatosan :)
ugrál, villog, csíkozódik, tök állat :)
asmban lenne jó persze, bár basic is látványos

Nekem nem is kell hozza program, most a rosszalkodo EP-m ezt az effektet hw-bol implementalja :)
Title: Re: Grafikai trükkök
Post by: endi on 2013.May.26. 15:13:27
nem mentettem el...
2 sor basic volt:

10 c=nem jut eszembe az lpt címe
20 poke rnd(200),rnd(256)
30 goto 10

de lehetne értelmesebben is, hogy a szinkronok, sormagasságok ne romoljanak el, akkor bár nem fog látványosan ugrálni, de máshogy lesz látványos
Title: Re: Grafikai trükkök
Post by: szipucsu on 2013.May.26. 15:52:00
A "C" változóra miért van szükség? Később nem használjuk fel pl. a POKE utasítások után sem.
Title: Re: Grafikai trükkök
Post by: endi on 2013.May.26. 15:57:25
ja az kimaradt hogy poke c+
Title: Re: Grafikai trükkök
Post by: szipucsu on 2013.May.26. 22:02:20
Quote from: endi
c+
Ez C+ ? Én azt hittem, basic. :D :D
Title: Re: Grafikai trükkök
Post by: szipucsu on 2013.May.28. 09:37:29
Esetleg meg lehet próbálni megcsinálni ezt a képet is olyan scrollozósra:
[attach=1]

(Hogy letölteni hogy lehet innen az eredeti méretében, nem tudom, de biztos le lehet.)
Title: Re: Grafikai trükkök
Post by: lgb on 2013.May.28. 12:10:05
Quote from: szipucsu
Esetleg meg lehet próbálni megcsinálni ezt a képet is olyan scrollozósra:

(Hogy letölteni hogy lehet innen az eredeti méretében, nem tudom, de biztos le lehet.)

Ez igy mar tiszta google street view szeruseg lesz lassan :D Foleg ha tudja az ember kbd-rol jobbra/balra scrollozni pl. Vmi mars panoramakeppel is edekes  lehet, ott meg talan a szinek szama is kevesebb: egyszerubb konvertalni :)
Title: Re: Grafikai trükkök
Post by: szipucsu on 2013.May.28. 21:56:12
Quote from: lgb
Vmi mars panoramakeppel is edekes  lehet, ott meg talan a szinek szama is kevesebb: egyszerubb konvertalni :)
Esetleg csillagos égbolt ill. világűr képpel is lehet kísérletezni, ott überkevés szín kell. :D
Title: Re: Grafikai trükkök
Post by: lgb on 2013.May.28. 22:41:59
Quote from: szipucsu
Esetleg csillagos égbolt ill. világűr képpel is lehet kísérletezni, ott überkevés szín kell. :D

Hehe, de pixel adat se sok, hacsak nem egy planeta kozeleben van pl :) Amugy nem is rossz otlet. PC-n volt meg a regi idoben egy program (a nevere nem emlekszem) ahol egy gombre feszitve lehetett megnezni a csillagos egboltot, forgatni, nagyitani, csillagkepek osszekoto vonalait ki/be stb. Vmi hasonlo nincs EP-re? Amugy az is erdekes lehetne hogy sikban megcsinalni ezt, a csillagos egbolt eleg jol tomoritheto :) nem kene nyers pixel adatban minden, vagy epp a program allitana elo scrollozas kozben (fel/le/jobbra/balra) realtime, bar gyanitom, hogy itt mar lehet realtime rajzolas is ok, nem is kene kesz (akar csak idolegesen elore kiaszmolt) kepet gorgetni, ha egy fiktib morickaabra is eleg es/vagy csak par potty csillagoknak :)
Title: Re: Grafikai trükkök
Post by: endi on 2013.May.29. 00:26:25
poke 43800,255
:)
Title: Re: Grafikai trükkök
Post by: szipucsu on 2013.May.29. 21:36:02
Quote from: lgb
Vmi hasonlo nincs EP-re?
Szerintem van, de nem emlékszem a címére. Laci oldalán mintha fent lenne. Talán Pete Cooke a program szerzője (ő írta az Academy-t is.)
Title: Re: Grafikai trükkök
Post by: szipucsu on 2013.May.29. 21:37:36
Quote from: endi
poke 43800,255
Nálam ez nem csinál semmit...
Title: Re: Grafikai trükkök
Post by: endi on 2013.May.29. 21:47:41
ja gondolom configtól is függ
nálam tök látványos :)
kb mint minkor graphics módban beírod hogy look
(vagy text módban look hessmark102:"
Title: Re: Grafikai trükkök
Post by: szipucsu on 2013.May.29. 21:55:44
Quote from: endi
ja gondolom configtól is függ
Snapshotot vagy demót nem töltesz fel ide?
Title: Re: Grafikai trükkök
Post by: IstvanV on 2013.May.30. 15:29:50
Quote from: szipucsu
Esetleg meg lehet próbálni megcsinálni ezt a képet is olyan scrollozósra:
[attachurl=#]
[attachurl=#]

Másik változat:

[attachurl=#]
[attachurl=#]
Title: Re: Grafikai trükkök
Post by: Zozosoft on 2013.May.30. 15:36:07
:smt038
Title: Re: Grafikai trükkök
Post by: szipucsu on 2013.May.30. 16:40:54
Jó lett! Az első változat szerintem jobb.
Title: Re: Grafikai trükkök
Post by: endi on 2013.June.19. 11:32:16
marha jó c64 hullámzó scroll effekt, némi tech infóval

http://www.scene.hu/2013/05/31/a-legszebb-c64-es-scroller-hogyan-csinald-a-censor-design-utan/
Title: Re: Grafikai trükkök
Post by: Zozosoft on 2013.June.19. 11:42:37
Quote from: endi
némi tech infóval
Ezt valaki le tudná magyarra fordítani? :-) De erős a gyanúm, hogy EP-n nem megcsinálható dolgokról van szó :-(
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.June.19. 15:38:12
Ez vadallat ! Mondhatnam, hogy: ilyen nincs is ...

Kivancsi vagyok mi a trukk benne, de szemem szam elall ... ha ez egy sima c64 gep ... akkor le a kalappal annak aki kitalalta ...

Es 60 FPS -nek tunik ... :)
Title: Re: Grafikai trükkök
Post by: endi on 2013.June.19. 16:17:17
Most már tényleg utána kell néznem hogy is épül fel a c64 graf tudása, mert ilyeneket tényleg nem lehet EP-n csinálni.
Illetve talán a kb senki által használt színes-karakteres módban (amikor c16 felbontás van a karaktereken)? És a C64 is olyasmi módot tud úgy tudom.
Title: Re: Grafikai trükkök
Post by: lgb on 2013.June.19. 19:36:00
Quote from: Zozosoft
Ezt valaki le tudná magyarra fordítani? :-) De erős a gyanúm, hogy EP-n nem megcsinálható dolgokról van szó :-(

Hat ize :) A c64-ben a VIC-II erdekes joszag (elodje a VIC-I volt a VIC-20 nevu gepben - allitolag a c64 fejlesztoi neve vic-40 volt anno -, az meg nem tudott se sprite-ot, se bitmap grafikat, csak sima textet azt is joval kisebb felbontassal - okos emberek megis csinaltak mar vic-i-el is erdekes grafikakat, turkkozgetve). Peldaul EP-n ami engem kicsit "zavar", hogy hwtext uzemmodban nem lehet minden karakternek sajat szine szabadon. Ez ertheto amugy, egy nick slotban ugye kell olvasni a megjelenitendo karakter kodjat, az karakter-generator infot, es hopp nincs tobb, mivel egy slot-ban a nick 2 byte-ot tud olvasni. C64-en van meg egy dolog: a karakter szine. Ezt azonban a C64 eleg nyakatekerten csinalja: a 64K DRAM mellett a C64-ba van 1K 4 bites (!) SRAM. Na ebbol veszi a szineket. Amugy meg eleg nyakatekert mashol is, a VIC-II 16K ram-ot lat a 64-bol, valtoztathato melyiket, de a 4 bank kozul 2-ben fix helye van a karaktergenerator ROM-nak, ahol azon a cimeken csak azt kepes latni, stb, elegge atlathatatlan elsore, ha az ember nem assa bele magat :)

Node vissza az elejere: szoval - allitolag - a VIC-II fejlesztesekben fel akartak hasznalni a VIC-I dolgokat, es csak azt hozzaadni ami feltetlenul szukseges. Allitolag emiatt van (?) hogy a bitmap kep szervezese fura: normal HiRes (high-resolution) az 320*200 pixel, amde a cimszervezes a 40*25 karakteres semat koveti tovabbra is (azaz 8*8 egysegekben: 320/8=40, 200/8=25), pl bitmap-nal az elso byte nyilvan a kepernyo bal felso sarkanak 8 pixelet adja egymas mellett, a kovetkezo byte azonban az ez _alatti_ 8 pixelt, es igy tovabb, a 8 lefele utan meg ujra fenn vagyunk az elozo "karakternyi" hely mellett. Es igy tovabb. Viszont egy ilyen karakternyi helyen van olvasas arrol a helyrol is, ami karakter modban a video memoria lenne, ez hatarozza meg az adott 8*8 egysegen belul az eloter es hatter szint. Azaz erzesem szerint ez elegge EP attribute szeru mod talan? Hires bitmap modban az az SRAM nincs hasznalva ami karakteres modban kell a szinekhez, nem keverni! Tehat lathato, hogy bar a teljes kepernyon 16 szin lehet (annyit tud a VIC-II interlace es hasonlo trukkok nelkul), amde egy "karakternyi" helyen csak 2 lehet (background/foreground). Ezen eros limitacio ellenere neha meglepoen szep es szines kepeket rajzolnak hires modban (ekkor azonban ugye tudni kell, hogy a kepet ugy kell megkomponalni, hogy "karakter" hatarra essenek szin hatarok stb - habar ez is igazi muveszet, ha ugy fogjuk fel), ez pl allitolag hires (http://truechiptilldeath.com/wp-content/uploads/2010/10/04-01-Veto-25-Years-of-Yie-Ar-Kung-Fu.png) kep. Otletet adhatna arra, hogy EP-n is jobban meg kene nezni az attribute mode-ot? :)

Namost az un multicolor mod az ugyanaz mint a hires, am ket egymas melletti bit alkot egy pixelt, igy a felbontas tehat 160*200, illetve egy "karakter egyseg" 4*8 pixeles lesz, ezen belul azonban 1 pixelre 2 bit van, azaz egy karakter egysegen belul 4 kulonbozo szin lehet. Na itt mar bonyolodik a helyzet, ui a 4 lehetseges szin nem szabadon varialhato (minden extra trukk nelkul, lasd lentebb) hiaba lenne "szabad" adott egysegen belul, nincs memoriaforras ahol eltarolhato az info, hogy ott milyen legyen. Ezert - ha jol remlik, lusta vagyok utananezni bocsi -, 2 szin jon onnan ahonnan hires modban is ugye, egy az global hatterszen, egy meg az emlitett SRAM-bol (mivel az 4 bites memoria, ezert kellett - gondolom - egy szint globalissa tenni).

Megjegyzem: az hogy X szin lehet egy "karakter egysegnyi" helyen nem is teljesen igaz, trukkokkel (pl raster irq-bol vic register piszkalas stb) elerheto, hogy minden pixel sor utan ujraprogramozni, es akkor jonnek olyanok hogy 8*1 teruleten lehet pl ket szin, meg 4*1 teruleten (multicolor) 4, aztan jon hozza interlace, minden trukk, akar sprite-ok "elszorasa" hatterben, es azok is hozzatartoznak a kephez (ahol onallo sprite szinek lehetnek az is lehet hires v multicolor), es pl egyutt adjak ki a kepet. Azonban az "alap" hires es multicolor az a default modok amit "hw-bol" tud a vic-ii, kulonben mar trukkok kellenek amihez a cpu aktiv kozremukodese, preciz idozitese stb kell, tehat azt a vic-ii nem csak "magatol" csinalja.

Ezekrol imho jo/gyors osszefoglalot ad ez az oldal (http://www.studiostyle.sk/dmagic/gallery/gfxmodes.htm).

A sprite-ok meg kulon fejezet, 8db, 24*21 pixel (miert ez a fura meret? 24 pixel az hiresben eppen 3 byte, 21*3=63 byte egy sprite, es eppen 64 byte-onkent lehet a VIC-II bankba sprite-okat tenni, tehat igy majdnem ki is jon szepen egesz pontosan) lehet hires v multicolor (akkor persze X felbontas a fele), X es Y iranyban is hw-esen nagyitva (2x) vagy nem. Sprite-oknak sajat szinuk van, es amugy a gfx felbontastol fuggetlenul ott vannak, lehetnek felig/teljesen/egyaltalan nem a lathato kep dimenziojan kivul (keret mogott pl, onnan lassan bekusztatni). Ez az alap, de egesz light-osan 21 scanline-onkent ugye raster irq-bol lefedheto maris az egesz screen sprite-okkal (ha nagyitott x iranyban, kulonben nem eleg a 8 sprite ami 1 scanline-on belul kene), es kozben mehet a normal kijelzes is, itt-ott atlatszik a sprite v a grafika pl (valtoztathato a hatter/sprite prioritas, de a sprite-ok kozotti prioritas fix). Hw-esen detaktalhato (irq-t es kepes kivaltani) sprite-ok "utkozese". Itt is rakas trukk van, pl sprite "dinamikus" nagyitasa Y iranyban, stb.

Es akkor meg nem is volt szo egyeb trukkokrol, kepernyo gorgetese, scanline-ok koze szunetek "beeroltetese" valtoztathato hosszal, kepkerek trukkos kikapcsolasa h ott is lehesen grafika. Stb. Igazabol megdobbento, mert rengeteg minden mind trukk, ami akar a VIC-II bug-jainak is lehetne hivni, amit kreativan kihasznalnak :) Nekem ezert tetszik, az utolso tranzisztor erejet is preseljuk csak ki a masinabol, amit nem is arra terveztek be pedig :) Ha van truecolor HD keped, az nem olyan varazslat azon szepet mutatni ugye ...

Amugy, amit en szivesen latnek igazi EP mellett (nem helyett!) az a C64 es a C64DTV viszonya: legyen egy FPGA-ban implementalt EP (ahogy a DTV C64-nek) ami minnel jobban compatible de extra trukokkel. Ilyen C64DTV-n pl a 2Mbyte RAM, 320*200 felbontas pixelenkent (!) 256 szinnel, beepitett blitter es DMA funkcio, 2mbyte flash, es burst mod bekapcsolhato ahol a beepitett 32 bites memoriat ugy is hasznalja (32 bitre alignalt kodreszlet eleg gyors lesz, ha nincs mas memoriaeleres adott opcode-okon belul).

Remelem nem untatok nagyon. Ha igen, tegyuk at egy masik temaba, ne itt bosszantsa az embereket :) Nem tudom, ez segitett-e ... Vagy inkabb artott :D
Title: Re: Grafikai trükkök
Post by: endi on 2013.June.19. 20:04:28
aha, ez tök jó, köszi hogy leírtad

az attr hires mód kb az mint amit a specy tud, csak hát ügye a c64-nek szebb a színpalettája, meg specyn a brightness bit is megkötés

nem véletlen hogy az ilyen hires attr-es c64-es játékok nagy része specy átirat

amit meg "bugként" tud a c64, nos igen, ezek a legérdekesebbek

de ki tudja milyen ilyesmiket lehetne ep-ből kihozni? az általam említett "karakteres c16" mód pl szinte teljesen kihasználatlan, kb senki se használta soha
Title: Re: Grafikai trükkök
Post by: lgb on 2013.June.19. 20:43:01
Quote from: endi
amit meg "bugként" tud a c64, nos igen, ezek a legérdekesebbek

de ki tudja milyen ilyesmiket lehetne ep-ből kihozni? az általam említett "karakteres c16" mód pl szinte teljesen kihasználatlan, kb senki se használta soha

Mi az a karakteres c16 mod?

Igen, a bug-ok durvak, pl valaki rajott egyszer, hogy VIC-II mi alapjan tudja, hogy hol a keret. Nemi trukkos idozitessel at lehet verni, es nem fogja tudni a VIC-II hogy kell rajzolnia keretet :-P Az erdekes, hogy oda pl normal cuccot nem tudsz tenni (mivel videomemoria stb nem terjed ki a keretre) amde pl sprite-ok ott is latszanak! Sot okos emberek rajottek hogy az aktualis vic bank utolso byte-jat rendereli oda a vic-ii mint "idle mod" ilyenkor, es ilyesmikkel is lehe trukkozni. Vannak kozottuk olyan "elborzaszto" trukkok, amiket hiaba olvasok el akarhanyszor egyszeruen nem ertem, "ide mar keves vagyok" feeling ...

Azon elmelkedtem, hogy milyen durva lenne mar, ha a Nick 4 kulso szinbementet valahogy egy VIC-II-re kotnenk, es azt is a Z80 vezerlene :-P Elvileg a VIC-II pont 4 bitnyi (16) szint tud, bar a kimenete sajna mar analog, nem ugy mint nick ki-/bemenetek. Meg ugye az idozitest lehet ossze sem lehet pontosan passzitani (az mondjuk tuti h valahogy sajat ram kene neki). Pedig vicces lenne, a ViC-II kepes lenne karakteres kepernyot, eltero karakterszinekkel, a vazolt grafikus modokat stb, es sprite-okat megjeleniteni, es ehhez jonnek a Nick modok, illetve h Nick kepes megmondani hogy a szinbementein jovo adatokat hogy kezelje, akar LPB-nkent!

Pedig erdekes, a nick 4 szinbemenetere van barmi project? Elvileg egy mezei RAM-ot szamlaloval cimezve, az leptetve a nick orajelevel valahogy, maris valami stable kepet adna (ok, az aprosagok hogy vsync-re reset-elni a counter-t, meg igazabol 4 bit kell csak stb). Ha ebbe a RAM-ba valahogy irni is lehet CPU-nak, akkor maris van max EP felbontasunk pixelenkent 16 szinnel! Es akkor meg jonnek a kulonbozo keppen hozzakeverheto EP modok, ofkoz!

Eleve csak annyi is erdekes lehetne, hogy a busboviton is hozzaferheto ec0..3 meg extc (ha jol remlenek) vmi fix ertekre huzni, ha erre leglabb van egy latch ami z80 i/o irhato, mar azzal pluszban lehetne trukkozni, a fenti minden bonyadalom nelkul. Bar nem tudom igy mennyi ertelme lenne ....
Title: Re: Grafikai trükkök
Post by: endi on 2013.June.19. 21:09:05
A karakteres képet át lehet állítani olyanra hogy a c16 módnak megfelelő felbontása legyen, és 4 vagy 16 szín. De továbbra is karakterek maradnak. Régen szórakoztam ezzel, bár én se írtam benne se demót, se játékot, vagy legalábbis nem emlékszem.

Egy Zipp-el fordított basic játékra emlékszem csak ami így műxik, de az is csak ránézésre. A címére nem emlékszem.
Title: Re: Grafikai trükkök
Post by: lgb on 2013.June.19. 21:14:16
Quote from: endi
A karakteres képet át lehet állítani olyanra hogy a c16 módnak megfelelő felbontása legyen, és 4 vagy 16 szín. De továbbra is karakterek maradnak. Régen szórakoztam ezzel, bár én se írtam benne se demót, se játékot, vagy legalábbis nem emlékszem.

Marmint C64-en? Olyan van ott, hogy karakteres modban is van multicolor mod, igen. Ha arra gondolsz ...
Title: Re: Grafikai trükkök
Post by: endi on 2013.June.19. 21:16:47
neeeem, EP!
írtam is hogy van egy basic játék ami ilyen, de csak homályos emlék
de az tuti hogy a dolog létezik, és próbálkoztam vele
Title: Re: Grafikai trükkök
Post by: lgb on 2013.June.19. 21:24:17
Quote from: endi
neeeem, EP!
írtam is hogy van egy basic játék ami ilyen, de csak homályos emlék
de az tuti hogy a dolog létezik, és próbálkoztam vele

Jol van no :) Ertem akkor. Majd vmi Nick szakerto nyilatkozik :) Amugy termeszetesnek is tunhet, mivel ha beallitod Nick modnak mondjuk a ch128-at, attol a colour mode-ot tudod masra is allitani mint amire szokas ... Nem tudom akkor mi tortenik, de ha kicsit is logikus, akkor imho ugy "dekodolodnak" szinekke a karakter generator altal adott byte-ok (ami normal esetben ugye 8 horizontalis pixelje a karakternek), mintha a megfelelo grafikus mod eseten lenne. Max majd kijavit vki, ha nem igy van :)

Ilyen szempontbol ez hasonlit C64-en, mert ott is lehet grafikus es karakteres modban is multicolor-t kerni. Vegulis logikus is, ha a kimeno "bit stream" dekodolasa (ami aztan szinekke rakja ossze) a vegso egyseg kb, akkor tok mind1, hogy mivel eteted, karakteres, vagy grafikus stb felbontassal, max a hatas erdekes, es nem minden esetben hasznos :D
Title: Re: Grafikai trükkök
Post by: endi on 2013.June.19. 21:27:33
na itt egy gyors teszt ami átállítja a text mód első sorát valami olyamivé amiről beszéltem
csak próbálgattam úgyhogy én se tudom mi van pontosan :)
Title: Re: Grafikai trükkök
Post by: Zozosoft on 2013.June.19. 21:30:41
Diemonds (http://www.ep128.hu/Ep_Games/Leiras/Diamonds.htm) használ 4 színű karakter módot, ill. az István féle Boulder Dash verziók.
Title: Re: Grafikai trükkök
Post by: endi on 2013.June.19. 21:31:43
na akkor ezek szerint 4 szín csak :(
Title: Re: Grafikai trükkök
Post by: Lacika on 2013.June.20. 00:09:46
Quote from: lgb
 ez pl allitolag hires (http://truechiptilldeath.com/wp-content/uploads/2010/10/04-01-Veto-25-Years-of-Yie-Ar-Kung-Fu.png) kep. Otletet adhatna arra, hogy EP-n is jobban meg kene nezni az attribute mode-ot?
Ez nem hi-res kép, hanem "trükkös" (két fél-kép). A hi-res képeket pixel pontosan lehet konvertálni ep-s attribútummódba, ezeket a "trükkös" képeket már próba-szerencse.
Title: Re: Grafikai trükkök
Post by: lgb on 2013.June.20. 00:22:56
Quote from: Lacika
Ez nem hi-res kép, hanem "trükkös" (két fél-kép). A hi-res képeket pixel pontosan lehet konvertálni ep-s attribútummódba, ezeket a "trükkös" képeket már próba-szerencse.

Hat pedig a leirasaban azt irtak hogy ez az :) Szoval vagy ok hazudtak akkor vagy te (mivel akartam egy keppel demonstralni hogy mi hozhato ki a hires-bol, de nem volt keznel, gugliztam egyet hirtelen, erre azt irtak egy party eredmenyhirdetese alapjan hogy esz hires kep). Amugy nem tudom mit ertesz "trukkos" alatt, afaik MCI es IFLI pl olyan ahol ilyesmivel jatszanak, erre gondoltal? Masreszt akkor itt van egy masik, CSDb-ben megbizom ahhoz, hogy ez tenyleg hires (azaz ugye 320*200 es 8*8 blokkonket tenyleg csak 2 szin van benne, meg ha nehez is elhinni elso ranezesre - pont ez benne az igazi ertek szerintem):

http://csdb.dk/release/?id=101528 (http://csdb.dk/release/?id=101528)

Btw, azert azt fontos megjegyezni, hogy az ilyen PC-n nezett kepek lehetnek siman tenyleg pl hires-ek, attol hogy a mondjuk a png-t  (legyen peldanak az) nezve nem tunik annak, ui ezeket gyakran emulatorokrol screenshotoljak ahol pl be van kapcsolva hogy emulalja egy atlag TV altal hozzaadott effekteket. Aztan meg pl jpeg-rol vagy mas veszteseges tomoritesrol ne is beszeljunk, ahol eleve nem _teljesen_ ugyanaz az image data mint tomorites elott volt ... Mondjuk C64 a vice emulatorban tenyleg tok mas kepet ad, ha ki-be kapcsolom a PAL emulaciot :) Szetkenodik a kep, a szinekhatarok elmosodnak, befolyasolja a keptartalmat a nagy kontraszthatarok kornyekenek tartalma, meg ilyesmik. Tehat igy keszult "screenshot"-ot probalni konvertalni nem egeszen adodik az, amit az ember var ... Celszeru ilyenkor letolteni (csdb-n altalaban pl fenn van) a c64-es programot, emun kikapcsolni minden tv-s dolgok emulalni probalo effektet, aztan ugy csinalni a shot-ot.
Title: Re: Grafikai trükkök
Post by: endi on 2013.June.20. 09:33:21
ezek sima attr hires képek, csak azért jobbak mint a specy képek, mert a c64-nek sokkal jobb a színpalettája és nincs a brightness megkötés

ja meg nagyobb a felbontás egy kicsit, bár ez szerintem nem sokat számít

és igen, ha a specynek rendesen megválasztották volna a palettáját és nem lenne flash meg brightness dolog akkor ilyen képeket tudna!
Title: Re: Grafikai trükkök
Post by: endi on 2013.June.20. 11:51:28
Amúgy érdekes ez a 4szín karakteres mód. Itt is látszik hogy a régi emlékeket a vágyainknak megfelelően színezzük ki, mert én tökre úgy emlékeztem hogy minden mód elérhető karakteresben is. :)

Az viszont tény hogy nagy lehetőségek vannak benne.
Amúgy a Gameboy-okra nagyrészt ilyen karakteres üzemmódban csinálták a játékokat. Csak hát az ügye tud pixel scrollt, karakter tükrözést, több layert meg ilyesmiket.
Title: Re: Grafikai trükkök
Post by: endi on 2013.June.20. 12:24:54
Na persze most már könnyen megértem, hogy mi ennek az oka. a 4 szín üzemmód is lores itt, és ügye lores 16 esetén már használhatatlan lett volna. Attr meg eleve más, azt se kombinálhatták volna rendesen össze ezzel.
Title: Re: Grafikai trükkök
Post by: IstvanV on 2013.June.20. 13:37:30
Quote from: endi
marha jó c64 hullámzó scroll effekt, némi tech infóval

http://www.scene.hu/2013/05/31/a-legszebb-c64-es-scroller-hogyan-csinald-a-censor-design-utan/
Hasonló trükk megoldható az EP karakteres módjában is, de a scroll valószínűleg csak 2 színű lenne, mert nem lehet karakterenként állítani a színeket. Viszont a karakter kódjában 3 bit használható lenne 3 texel állapotának a tárolására a karakteren belül (mint a C64-es demóban, csak ott 3 4 bites szín állítható karakterenként), a maradék 5 bit pedig a karakter kódja lenne 32 oszlop méretű képernyőn a fix hullám grafikához. Viszont a scroll mögött lehetne színes háttér, vagy a scroll lehetne részlegesen átlátszó.
Title: Re: Grafikai trükkök
Post by: Lacika on 2013.June.20. 19:15:43
Quote from: lgb
Masreszt akkor itt van egy masik, CSDb-ben megbizom ahhoz, hogy ez tenyleg hires (azaz ugye 320*200 es 8*8 blokkonket tenyleg csak 2 szin van benne, meg ha nehez is elhinni elso ranezesre - pont ez benne az igazi ertek szerintem):

http://csdb.dk/release/?id=101528 (http://csdb.dk/release/?id=101528)


Ez valóban hi-res. Plus4-re (http://www.ep128.hu/Ep_Demo/Leiras/C-Plus4_Slideshow.htm) is van szebb színekkel.
Title: Re: Grafikai trükkök
Post by: lgb on 2013.June.20. 19:55:06
Quote from: Lacika
Ez valban hi-res. Plus4-re (http://www.ep128.hu/Ep_Demo/Leiras/C-Plus4_Slideshow.htm) is van szebb színekkel.

Persze, mert Plus/4-nek tobb szine van, mint a C64-nek, konkretan 128 (levonva belole azt, ami ugyanarra jon ki, igy valojaban "csak" 121). Viszont pl nincsenek sprite-ok. Maga a bitmap-es modjai amugy hasonloan mukodnek a C64-hez.

Amugy annak a kep kapcsan igazad volt, az tenyleg nem hires, valamilyen demo scene oldalon azt irtak (es peldanak hoztak), en meg elhittem, sorry. Itt van amugy: http://csdb.dk/release/?id=94452 (http://csdb.dk/release/?id=94452). Irjak is hogy egeszen pontosan nufli (tehat tenyleg nem hires).
Title: Re: Grafikai trükkök
Post by: endi on 2013.June.21. 11:33:13
Két demómban csináltam olyat hogy egy karakterben egy pont megy körbe, és több ilyen karakter volt eltolt anim fázissal. Ezekből aztán tök jókat lehetett rajzolni, hullámzás jellegű dolgokat persze. Egyik demómban editálható is ez a dolog.

De ezt tovább lehetne fejleszteni, és elég jókat ki lehetne hozni belőle.
Title: Re: Grafikai trükkök
Post by: endi on 2013.June.23. 20:15:43
Itt a két demóm amiről beszéltem.
Az elsőben csak az előre elkészített minták között lehet válogatni.
A másodikban a paraméterek állítgatásával tök jókat lehet kihozni belőle.
Na ezt továbbfejlesztve tök jót lehetne csinálni, picit olyat mint az a c64-es demó.
Title: Re: Grafikai trükkök
Post by: endi on 2013.June.23. 21:43:47
mondju most így nézve a másodikat, tök gáz hogy 1 pixel a pont
ha nagyobb pontot mozgatnék körbe, kategóriákkal látványosabb lett volna
Title: Re: Grafikai trükkök
Post by: Zozosoft on 2013.June.23. 21:55:28
Ez akkor karakteres módban van?
Title: Re: Grafikai trükkök
Post by: endi on 2013.June.23. 21:59:50
persze, ez a lényege :)
Title: Re: Grafikai trükkök
Post by: endi on 2013.June.23. 22:15:57
ja az elsőben 2x2 pixeles
de még lehetett volna 3x3 is
sőt, nem csak pixel hanem másféle dolog is, pl pattern
Title: Re: Grafikai trükkök
Post by: lgb on 2013.July.23. 16:33:08
Quote from: endi
Itt a két demóm amiről beszéltem.
Az elsőben csak az előre elkészített minták között lehet válogatni.
A másodikban a paraméterek állítgatásával tök jókat lehet kihozni belőle.
Na ezt továbbfejlesztve tök jót lehetne csinálni, picit olyat mint az a c64-es demó.

Ezt nem tudnad odaadni programban (nem ep128emu snapshotban)? Jo lenne tesztelni az emulatorom, karakteres modban ugyis vannak hianyossagai jelenleg (pl csak 2 szinu uzemmodot ismeri ra, bar altind az OK), es meg ki tudja milyen bugot talalhatnek :)
Title: Re: Grafikai trükkök
Post by: endi on 2013.July.23. 18:25:46
az orkdemo3-ban van, de most hirtelen nem tudom hányas rész
külön is indíthatók a részek, de nem .com-ra vannak nevezve
demo3a, demo3b stb nevek az indíthatók asszem

de az orkdemo1-ben ugyanez az effekt a part2-ben van
Title: Re: Grafikai trükkök
Post by: IstvanV on 2013.July.23. 18:57:09
A Boulder Dash (http://www.ep128.hu/Ep_Games/Leiras/Boulder_Dash.htm) 4 színű karakteres módot használ, a "CPC" változat pedig ALTIND0-t is.
Title: Re: Grafikai trükkök
Post by: lgb on 2013.July.24. 16:34:06
Quote from: IstvanV
A Boulder Dash (http://www.ep128.hu/Ep_Games/Leiras/Boulder_Dash.htm) 4 színű karakteres módot használ, a "CPC" változat pedig ALTIND0-t is.

Ok, nezem, erdekes. Az OK, hogy nincs ertelmezheto kepem normalis (mivel csak "2 szinu" karakteres mod van jelenleg), amde az LPT-je is igen fura, valami ~100ezer (vagy hasonlo) scanline van benne :D Legalabbis nalam ez jon ki belole, bar ha ez normalisan megy amugy (megnezem mindjart ep128emu-val) akkor persze biztos, hogy valamit en szurok el, bar fura, hogy ilyen meg nem jott elo nekem mas tesztelt programmal eddig.

Aha, ez nekem ep128emu alatt sem megy, szoval itt vmi mas gixer lesz :(
Title: Re: Grafikai trükkök
Post by: IstvanV on 2013.July.25. 10:26:20
Biztos, hogy jó verziót töltöttél le (például nem Spectrum átiratot) ? Én teszteltem ep128emu-n és igazi gépen is, és mindkettőn működik. EP64-en is futnia kell.

[attachurl=#]
Title: Re: Grafikai trükkök
Post by: lgb on 2013.July.25. 21:37:16
Quote from: IstvanV
Biztos, hogy jó verziót töltöttél le (például nem Spectrum átiratot) ? Én teszteltem ep128emu-n és igazi gépen is, és mindkettőn működik. EP64-en is futnia kell.

Jot. Bar ep128emu-nal en hibaztam: fileio-val toltottem be es nem az aktualis konyvtarbol, mert ha ugy csinaltam akkor mukodik vele. Amugy fura, most normalis az LPT az JSep-ben is, akarhanyszor probalom pedig semmit nem modositottam amire ennek hatassal kene lennie. Illetve kozben implementaltam a 4, 16 es 256 szinu karakteres modot is, amde ertelmezheto kepet nem ad tovabbra sem (de legalabb stable az LPT). Az nem lehet, hogy undocumented Z80 opcode-ot hasznal a boulder dash es azon hasal el? Lehet, ideje lesz atnezni/modositani az JSspeccy Z80 "magjat" is, most neztem: televan spectrum-os maradvanyokkal pl tape trap rom point meg ilyesmik.
Title: Re: Grafikai trükkök
Post by: IstvanV on 2013.July.26. 09:03:10
Quote from: lgb
Az nem lehet, hogy undocumented Z80 opcode-ot hasznal a boulder dash es azon hasal el?
Az IXL, IXH, IYL, és IYH regisztereket használtam, ezeket támogatja a jsep ?
Title: Re: Grafikai trükkök
Post by: IstvanV on 2013.July.26. 12:14:09
Mindenesetre valószínűnek tűnik, hogy Z80 probléma lehet, mert a Z80 regiszterekből úgy látszik, lefagy a program.
Title: Re: Grafikai trükkök
Post by: lgb on 2013.July.26. 12:24:02
Quote from: IstvanV
Mindenesetre valószínűnek tűnik, hogy Z80 probléma lehet, mert a Z80 regiszterekből úgy látszik, lefagy a program.

No igen. Amugy mint irtam, ez ugye az jsspeccy z80-a valojaban, ami meg a fuse-bol kerult oda, szoval kisse kusza :) Mindenesetre biztos nem tamogat minden nem dokumentalt cuccot, eleve az EXOS2.4-bol is az indult el rajta csak, ahol Zozo kigyomlalta a nem dokumentalt opcode-okat a Z180-as kiserlete miatt. Arra nem erzek egykonnyen lelkierot, hogy kivagjam az egesz Z80-at es irjak ujat helyette, de ahogy elnezem lehet, hogy kene ... :-/
Title: Re: Grafikai trükkök
Post by: IstvanV on 2013.July.26. 12:48:53
Ha jól látom, a kód elvileg támogatja a nem dokumentált Z80 utasításokat. Talán egyszerűen csak hibás valahol ?
Title: Re: Grafikai trükkök
Post by: lgb on 2013.July.26. 13:26:36
Quote from: IstvanV
Ha jól látom, a kód elvileg támogatja a nem dokumentált Z80 utasításokat. Talán egyszerűen csak hibás valahol ?

Igen, ugy altalaban ranezesre tenyleg, ezt mar regebben is neztem. Amde mondjuk fura, mert ugye ahogy irtam, EXOS2.4-an is itt bukik el, legalabbis a Z180 miatt megtisztitott verzioval pl megy, ahogy irtam is. Akkor viszont eleg "nagy" hiba lehet.

http://ep.lgb.hu/jsep/demo/test/README

Ez alapjan pedig szepen tesztelgetve is volt (marmint nem altalam ...), bar kerdeses mennyire atfogo a teszt erre nezve is.
Title: Re: Grafikai trükkök
Post by: Zozosoft on 2013.July.26. 14:00:12
Valamikor az emulátorok ősidejében csináltam egy ilyen tesztet.
Title: Re: Grafikai trükkök
Post by: lgb on 2013.July.26. 15:11:37
Quote from: Zozosoft
Valamikor az emulátorok ősidejében csináltam egy ilyen tesztet.

Hasznos, epp ilyet kezdtem volna keresni :) Belepakoltam a default disk image-be. Ja, meg rajottem hogy nincs HOLD/STOP gomb, home/end-et bevetettem erre a celra a pc billencsen, mar ha firefox is ugy akarja ... Ja, meg feltunt, hogy ez a tesztprogram kicsit nagyobb lathato kepernyot feltetelez mint ami nalam van :D En kb abbol indultam ki h leirasok szerint tv-n nem erdemes 256 lathato scanline-nal tobbet feltetelezni, hogy lathato. Vagy vmi hasonlo az overscan miatt. Bar gondolom mivel emulatorhoz irtad, itt ez kevesbe volt szempont :)
Title: Re: Grafikai trükkök
Post by: Zozosoft on 2013.July.26. 15:40:18
Quote from: lgb
Ja, meg feltunt, hogy ez a tesztprogram kicsit nagyobb lathato kepernyot feltetelez mint ami nalam van :D
Ez csak a simán EXOS-ból (és így BASIC-ből is) elérhető 27 karaktersoros videólap.
Title: Re: Grafikai trükkök
Post by: lgb on 2013.July.26. 15:53:25
Quote from: Zozosoft
Ez csak a simán EXOS-ból (és így BASIC-ből is) elérhető 27 karaktersoros videólap.
Lehet, az idokijelzos jatekkal egyutt mar kicsit sok? :) Ha jol tippelek h egy karakter 9 soros szokott lenni, akkor 27*9=243, es akkor meg ugye statusz sor, vagy pluszba a ZT-s idokijelzes, az imho tobb lesz mint 256. Lehet meg kene emelnem kicsit az emulalat kepernyo fuggoleges meretet? Azert nem akartam, mert ugye sebessegben sokat szamit par sor is. Mondjuk nem nagy szam atirnom, csak jo lenne tudni mennyi az idealis ertek, es persze minnel kevesebb legyen az az idealis :D Mondjuk en csak a hasamra utottem hogy milyen magas legyen, es hol kezdodjon az aktiv kijelzes, nem biztos (a jelek szerint biztos nem ...), hogy jo ez igy :)

Btw, te lattal vmi rendelleneset az undoc opcode testered futasa soran, vagy probaltad az emuban? Nekem nem tunt fel semmi. Az viszont teny, hogy mar az EXOS2.4 sem ment ahol nem a "Z180-asitott" verzio volt, szoval akkor esetleg tudnal kuldeni nekem ket EXOS2.4 rom image-et, ami lehetoleg semmilyen mas letezo kulonbseget nem tartalmaz, csak az "undoc-opcode-talanitast?" :) Akkor osszehasonlitassal talan kiderulne, hogy ott min akad el, aztan talan egyszer a boulder dash-ra is kiderul ekeppen :)
Title: Re: Grafikai trükkök
Post by: IstvanV on 2013.July.27. 13:13:32
Spectrum 48-ra van z80tests.tap (http://homepage.ntlworld.com/mark.woodmass/z80tests.tap), de EP-re át kellene írni. :)
Title: Re: Grafikai trükkök
Post by: endi on 2013.August.05. 16:13:18
Amúgy az jutott eszembe, hogy karakteres vagy karakteres-grafikus módban lehetne olyan függőleges hw scrollt csinálni, ahol a pálya mellett oldalt nem scrollozós rész van, pl. a hud. Vagy több függőleges sávban egymástól független scrollokat. Nem emlékszem hogy ilyet demóban vagy játékban csináltak volna.
Title: Re: Grafikai trükkök
Post by: IstvanV on 2013.September.05. 20:07:46
Quote from: endi
Nem emlékszem hogy ilyet demóban vagy játékban csináltak volna.
Azért, mert a NICK nem teszi lehetővé, legalábbis hardveresen nem. Az LPT-ből olvasott paramétereket nem lehet a soron belül módosítani, mert a NICK csak egyszer olvassa ezeket a sor elején, és a soron belüli pozíció nem módosítható.
Title: Re: Grafikai trükkök
Post by: endi on 2013.September.05. 21:16:03
félreértesz, én katakteres trükkre gondoltam, tehát:
-a képernyő bal felére felépítesz karakterekből egy "memóriatérképet", azaz pl 20 darab karakter egymás mellett, amelyek képernyő magasságúak
-a képernyő jobb felére ugyanez

aztán ezután lehet scrollozni vagy bármit csinálni ezen a két részen
Title: Re: Grafikai trükkök
Post by: endi on 2013.September.06. 12:17:00
most hogy gondolkodtam rajta, valami tényleg nem oké azzal amit írtam :)
de valami van itt mégis ami kihasználatlan szerintem
Title: Re: Grafikai trükkök
Post by: szipucsu on 2013.September.12. 19:24:32
Ezt a képet esetleg meg lehet próbálni scrollozósra betenni. Bár van a neten kb. 20-szor ekkora felbontásban is ez, talán EP-hez ez is elég itt.
(Egyébként a Wikipédiáról érhető el a hatalmas felbontású.) (http://commons.wikimedia.org/wiki/File:Louvre_2007_02_24_c.jpg)
Title: Re: Grafikai trükkök
Post by: IstvanV on 2013.September.13. 13:03:39
A konvertáláson (http://enterpriseforever.com/programozas/grafikai-trukkok/msg32534/#msg32534) még lehetne javítani, de első próbálkozásra ilyen lett:

[attachurl=#]
[attachurl=#]    (epimgconv_sse2.exe -mode 4 -dither 1 0.9 -quality 9 -size 164 224 -ymax 1.25 -gamma 0.85 -palres 0 -scalemode 1 -outfmt 7 Louvre.png louvre.bin)
[attachurl=#]    (epimgconv_sse2.exe -mode 2 -dither 4 0 -quality 9 -size 164 224 -palres 0 -scalemode 1 -outfmt 7 Louvre.png louvre.bin)

[attachurl=#]

Louvre.png (3048x524):
[attachurl=#]
Title: Re: Grafikai trükkök
Post by: Zozosoft on 2013.September.13. 13:12:18
Szerintem elég jó lett!
Title: Re: Grafikai trükkök
Post by: IstvanV on 2013.September.13. 19:13:08
Találtam egy hibát, a program Esc billentyűre lép ki 00:0000h címre ugrással, de EXOS 2.3 esetén az Esc billentyű lenyomva tartása kihagyja a BFF8h címen beállított reset rutint, és így nem szabadul fel a lefoglalt memória. :oops: Más billentyűt kellene használni. A reset gombbal történő kilépésnél nincs ilyen probléma.
Title: Re: Grafikai trükkök
Post by: szipucsu on 2013.September.13. 21:11:54
Jó lett! A -mode 4-gyel szerintem jobb!
Tényleg, most kipróbáltam, ESC hosszan nyomva tartása után az INFO kevés szabad memóriát ír ki.
Title: Re: Grafikai trükkök
Post by: IstvanV on 2013.September.15. 12:22:26
Egy továbbfejlesztett verzió soronként változó palettával talán jobban nézne ki. Természetesen így már nem férne el az LPT az EXOS veremben, és több CPU időt igényelne a scrollozás, de valószínűleg megoldható.
Title: Re: Grafikai trükkök
Post by: endi on 2013.September.19. 20:53:30
nemrég volt ilyen demó party, a nyertes 256byte demó web verziója, durva:

http://www.p01.org/releases/tea_storm/tea_storm.htm

view source :)
Title: Re: Grafikai trükkök
Post by: lgb on 2013.September.20. 06:46:05
Quote from: endi
nemrég volt ilyen demó party, a nyertes 256byte demó web verziója, durva:

http://www.p01.org/releases/tea_storm/tea_storm.htm

view source :)

EH-eh-eh :) Canvas 2D context, ilyen JSep-ben is van nem meglepo modon, csak ott van par "felesleges" cucc meg, mint peldaul az EP emulalasa is kozben [vagyhat legalabbis annak kiserlete ...] :)
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.October.21. 19:28:02
Hmmm ... lehet, hogy csak a spanyolviaszt találtam fel, de ha így van, én akkor is csak most világosodtam meg. Ugyan régebben is hallottam, hogy vízszintes scroll -t lehet csinálni EP -n karakteres módban, de én ezt sosem találtam igaznak, de most mégis bekattant nekem is, hogy lehetne megcsinálni, és miért is lenne jó.

A dolog előnye egy standard grafikus módban elkövetett vizszintes scroll -hoz képest (egy olyanhoz képest pld. amit IstvanV csinált legutóbb), hogy a tile -ozottan tömörített grafika megjelenítése hardverből támogatott lenne, és hogy a dupla képernyő nem a pixel információt duplázná, hanem csak a karakteres (index) memóriát.

Vagyis igaz rá, hogy egy diszkrét karakterszettből aztán hatalmas nagy pályákat lehetne a memóriában tartani, és a maga a scroll ideje egy a maximum képernyőre csak kiférő (tehát fullos méretű) képernyőnél szerintem nem lenne több 6-10 pixelsor  raszteridőnél. Vizszintes scroll -hoz ez pedig marha jó EP -n.

A dolog egyik hátránya hogy igen erősen kéne tile -ozni, ráadásul igen erősen szögletes tile -ozni, mert csak nagyon kevés számú tile (karakter) állna a rendelkezésre a pálya összerakásához.

A dolog másik hátránya pedig, hogy a karakteres módokban a grafika LORES, vagyis a megszokott felbontásunk feleződne az adott színüzemmódokban. Ami azt jelenti, hogy normál "320 -as" felbontásunkkal nem 4 hanem csak 2 színnel a "160 -as, téglás" felbontásunkban pedig nem 16 hanem csak 4 színnel rajzolhatnánk.
Ugyan a grafikus módokkal szemben a karakteres módoknál bizonyos karakterhatárok és karakterszámhatárok betartásával ki lehet használni a palettánknak mind a 16 színét, ezeknek felhasználása csak egesz extrém körülmények között lenne lehetséges akkor, ha az atributum jellegű sprite átszíneződéseket ki akarjuk zárni. Részemről az attributum hibák a létező legocsmányabb dolgok a világon, csak a lehető legkevesebb játéknál tudták ugy használni őket, hogy az ne legyen iszonyat gány. Szóval én inkább a kevesebb, akár 2 szín mellett vagyok, ha az attributum hibák megjelenéséről lenne szó.

Egyszóval vizszintes scroll, karakteres módban, hatalmas de durván tile- os pályák jól tömörítve, nagyon gyorsan, de kevesebb színnel és/vagy rosszabb felbontással mint a megszokott grafikus hires mód:


S= space karakter kód (üres karakter, csupa 0 a grafikus területe)
A,B,C,D= négy különböző karakter kód
X,Y=még két különböző karakter kód

Egyszerűség kedvéért legyünk "320 pixeles" két színű karakteres módban (hozzáértőknek: LORES 2 szín), de igaz minden színüzemmódban.

SSSSSSSSSSSSSSSS
SSSSSABSSSSSSSSS
SSSSSCDSSSSSSSSS
SSSSSSSSSSSSSSSS

Ezzel a sormintával a karakteres képernyő memória kis darabkáját ábrázoltam ahol sok space közé be van rakva négy karakter.
Képzeljük el, hogy az A,B,C,D karakterek 4 olyan karakter, ami egy 2X2 karakteres blokkot alkot, vagyis ugye itt most 16X16 pixelt, és ebbe a 16X16 -os blokkba bele van rajzolva egy láda (vagy barmi más tile).
Vagyis a nagy semmi kozepén van egy 16X16 pixeles tile- unk.

( Namost ha ezt az A,B,C,D -t a kepre több helyre is felraknánk, akkor ugye az összes helyen megjelenne a 16X16 pixeles grafikánk, de ezt most nem tesszük, csak simán egy marad.)

Namost azt akarjuk, hogy a képernyőnk kezdjen el scrollozni. (Egyenlőre csak jobbról jöjjön a pálya és balra menjen, de lehet 2 irányba is, dupla karakterkészlettel mint egy irányba.)

Ehhez végigmegyünk a pályán egy preprocesszáló kóddal (vagy kézel, ha űber kevés tile -lal dolgozunk) és balról jobbra megnézzük, hogy hány olyan kombinációt tudunk találni, úgy, hogy egy karakter mellett egy másik karakter van. Ezeknek a kombinációinknak a száma nem szabad meghaladja majd a teljes pályaelemkre szánt karakterkódjainknak a számát. Mivel a karekterkészletünk 64,128,256 darab karakterből allhat mindössze, és a mozgó elemek megjelenítéséhez is igen sokat kell majd fenntartani, ezért igen szűkre szabott ez a szám.

A fenti példánál ez a kombinációkeresés azt fogja eredményezni, hogy ugye ezeket a kombinációkat találjuk:

- olyan kombináció, ahol S mellett S van, vagyis ha scroll -ozási irányt is nézzük: S<-S, és mivel tudjuk hogy ez üres teljesen, ezért ezt a kombinációt továbbra is S karakterkóddal fogjuk ábrázolni.

- aztan lesz olyan kombináció, ahol S mellett A van, vagyis: S<-A, itt már A -nak van mintája, ezért erre a kombinációra felveszünk egy új X karakterkódot

- aztan előbbi mellett: A<-B, itt meghagyjuk az eredeti A karakterkódot, hogy a példa egyszerű legyen, valójában ezt A vesszővel kéne jelölni, mert ez már nem az eredeti A karakter kód lesz, hanem ugye az A<-B átmenetet jelképező karakter kód.

- aztan a: B<-S, ami B marad.

- aztan lesz még: S<-C, amire felvesszük Y karakterkódot.

- meg: C<-D, ami C lesz.

- es az utcsó: D<-S, ami D lesz.

mindezek után módosítjuk a karakteres memóriánkat így:

SSSSSSSSSSSSSSSS
SSSSXABSSSSSSSSS
SSSSYCDSSSSSSSSS
SSSSSSSSSSSSSSSS


És csinálunk 8 teljes karakterkészletet, amelyekben az X,A,B és Y,C,D karakterek (tehát vegyük észre hogy nőtt a tile -unk helyigénye 4 -ről 6 karakterre!) scrollozása előre ki van számolva, minden karakterkészletben egy pixellel balra vannak tolva a dolgok.

Ha ezután nem nyúlunk egyáltalán semilyen memóriához, tehát meg a karakterkód memóriához sem, csak valtogatjuk az LPT -ben (vagy akár előre generált 8 LPT -vel, abszolút csak LPT portváltással) a karakterkészletet, akkor a tile 7 pixellel el fog scroll -ozódi hardverből. Ha a most már 6 karakteres (X,A,B,Y,C,D) tile -unkat több helyre felteszük a képre, akkor természetesen minden példány el fog scrollozódni.

Természetesen a nyolcadik pixelhez visszaváltjuk a normál karakterkészletre az LPT -t, és a karakter kód memória címét állítjuk egy karakterrel arrébb. Ehhez kell már memória írás, de mivel karakteresek (8 pixelsor) az LPB -jeink magasságban is, ezért csak nagyon kevés címet kell arrébb állítanunk. Természetesen a bejövő karakterkódokat pótolnunk kell a jobb oldalon, és hogy ne kelljen egy teljes képernyőnyi karakter kód memóriát másolgatni, ezért a karakterkód memóriánal ugyanazt a duplázást lehet használni mint a pixeles vizszintes scroll- nál, vagyis inkabb minden (nyolcadik pixel után) esetben 2 helyre másoljuk ki a belépő karakter kód oszlopot, így két képernyőt építünk, melyre egy teljes képnyi scrollozás után visszaválthatunk.

Ezek után a mozgó dolgokat már valós karakterkód és karakterkészlet memória manipulációval ki kell rakjuk, kicsit még bonyolultaban is, mint a grafikus mód esetében, de nagyságrendileg ugyanannyi idő alatt, mint a grafikus módnál.

Így viszont maga a vízszintes scroll sztm 10 rasztersor alatt tartható, vagyis szinte a teljes idő a sprite -ok kirakására és minden másra fordítható ...
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.October.21. 19:41:26
Javítottam a karakteres scroll leírásban pár elírást, amik eléggé megkeverhették a megértését. Remélem így már valamennyire érthető lesz.
Title: Re: Grafikai trükkök
Post by: endi on 2013.October.21. 19:49:48
hát igen, leírtad szépen hogy miért is nem csinált ilyet soha senki :)
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.October.21. 19:56:29
Quote
hát igen, leírtad szépen hogy miért is nem csinált ilyet soha senki (http://enterpriseforever.com/Smileys/phpbb/smiley.gif)
Klaff -klaff ... ( klaffogott endi ... )

Konkrétan tudok olyan grafikát, amit ily módon ki lehetne használni, és berosálnál olyan jó lenne.

És nem konkrétan arról az űberminimál dologról beszélve, ilyen típusú grafot meg lehetne vele csinálni, frame -esen:

[attachimg=1]
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.October.21. 20:08:54
És minden fáklya loboghatna, akár zéró közeli időből ... Meg vizek hullámozhatnának, nagyobb területek animálódhatnának alig időből,

nem sprite kirakáshoz mérhető időből ...
Title: Re: Grafikai trükkök
Post by: endi on 2013.October.21. 20:11:11
hát ez a kép nem épp azt mutatja, hogy érdemes lenne ezzel foglalkozni :)
plusz itt mindjárt nem 2 szín van
Title: Re: Grafikai trükkök
Post by: szipucsu on 2013.October.21. 20:13:10
Quote from: Z80System
És minden fáklya loboghatna, akár zéró közeli időből ... Meg vizek hullámozhatnának, nagyobb területek animálódhatnának alig időből,
Én inkább egy falbontó labdás játéknak gondolnám ezt, csak nem ütő van ott lent, hanem a krapek dobálja majd a lasztit. Ha meg megunja, fogja magát és kimegy az ajtón, ami úgy nyikoroghat, mint a Sorcery-ben. Gond csak akkor van, ha a fal magától visszaépül, amikor újra a szobába téved a krapek.
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.October.21. 20:15:27
Quote
hát ez a kép nem épp azt mutatja, hogy érdemes lenne ezzel foglalkozni (http://enterpriseforever.com/Smileys/phpbb/smiley.gif)
plusz itt mindjárt nem 2 szín van
Nekem nagyon is azt mutatja, hogy érdemes lenne ...

És választhatnánk, hogy két színnel toljuk (ami volójában 4X2 szín, ha jól rajzolunk), vagy pedig 160 -as felbontással 4 szín (4X4 vagy 2X4 nem tom pontosan).

Kínnal és verítékkel, de meg lehetne közelíteni egy frame -es C64 játék szintjét ... ami sztm egy igen nagy előrelépés lenne ahhoz képest, ami van. Már akit egyáltalán érdekel a frame -esség és a játékélménynek a tech tulajdonságokból fakadó része.
Title: Re: Grafikai trükkök
Post by: szipucsu on 2013.October.21. 20:22:56
Nekem az tetszene nagyon, ha a Cauldron játékban nem képernyőváltások lennének, hanem a kép scrollozna, ahogy C64-en.
Nem tudom, ott csak a felszínen van-e scrollozás vagy a föld alatt az ajtók mögötti részeken is.
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.October.21. 20:34:08
Hát ezzel a módszerrel kb. ugyanilyen ( vagyis lassú ... :) ) sebességgel meg lehetne csinalni sztm. a Cauldron -t, mint amilyen sebességgel most fut, csak scroll -os lehetne a pálya.

Viszont sokkal kevesbé lenne szép színes ...
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.October.21. 20:36:17
Na jó, ezt vissza kell vonjam ... a Cauldron felső pályáján a grafika sokkal kevésbé tile -ozható valószínűleg, mintsem hogy beleférjen ... Sokkal "kockább" grafika is kéne ... és akkor végképp nem lenne Cauldron ... :)
Title: Re: Grafikai trükkök
Post by: geco on 2013.October.22. 10:11:59
Ehhez hasonló dolog jutott nekem is eszembe, amikor a karakteres módot mondtam, még az is beleférne, ha a full 40x25-ös képernyő karakterkód tábláját módosítjuk és a karaktermemóriához nem nyúlunk, 1000 byte-os területet is gyorsan felül lehet írni.
A lejjebb mutatott képen szereplő játékot szerintem majdnem olyan szépre meg lehetne csinálni, egy színnel kevesebb a téglában, és a sprite lenne csúnyább, felbontás ugyanígy. Ennél a játéknál lehet gyorsabb lenne, ha csak a tégla , és az alsó két sor karaktereinek 8 byte-ja lenne felülírva,  a többi esetben meg a karakterek 8 byte-ja, és a karakterkód tábla is, ez sem enne sok időt.
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.October.24. 13:44:05
Igen, azt hiszem ezt a karakteres módos vergődést én múltkori megvilágosodásomig nagyon alábecsültem ...

Pedig már a nyolcvanas évek elején a sprite -ok nélküli C16 -on is ez volt a válasz szinte "mindenre". Persze a megfelelő kompromisszumokkal a játékokban.

Valahogy úgy voltam vele, hogy ugye LORES graf, eleve kuka, hisz van HIRES, nyilván abban kéne. A szupergyors vizszintes scroll működés csak most esett le a minap, az meg hogy tudunk nagyobb képernyőterületeket animálni valahogy sosem fogott meg, egyébként meg ha pixelhelyes sprite -okban gondolkodunk, akkor ugyanakkora (LORES) memória bizergálást kéne csinálni karakteres módban is, ráadásul egy plussz bonyolító indirekciós memória layout -on keresztül.

Tehát a fő irányvonal, a megoldási képlet valami olyasmi lehet az EP grafikai performanciájára a játékokban, ami már a C16 -nál is volt, hogy karakteres mód + karakteres módhoz kitalált játék, mint megjelenítés mind a gameplay vonatkozásában ...

Tehát pld. egy 50 FPS topikban linkelt exorcist -nél fontos paraméter, hogy a sprite -oknak nem kell tudnia fedésbe kerülni sem a falakkal, sem egymással, maximum mondjuk az elkapásnál egyetlen sprite karaktersornyit a főhősnél, az ellenségprogramokat lehetne olyanra írni, hogy elkerüljék egymást ... a többi mehet HW -ból, karakter kód animációval. És ilyenek ...

Most épp már az is felmerült bennem akkor, hogy egy galaga -t nem lehetne -e karakteres mód -osítani ...
Title: Re: Grafikai trükkök
Post by: IstvanV on 2013.October.24. 13:57:20
Quote from: Z80System
Igen, azt hiszem ezt a karakteres módos vergődést én múltkori megvilágosodásomig nagyon alábecsültem ...

Pedig már a nyolcvanas évek elején a sprite -ok nélküli C16 -on is ez volt a válasz szinte "mindenre". Persze a megfelelő kompromisszumokkal a játékokban.
Karakteres módot (sprite-okkal) szerintem C64-en is gyakran használtak, különösen a "scrollozós" játékoknál (1 MHz-es 6510 processzorral könnyebben megoldható az 1 KB méretű karakteres képernyő mozgatása). 256 karakter általában elég a pályák rajzolásához, és a sprite-ok - a C16-al és EP-vel ellentétben - nem "fogyasztják" a karakterkészletet, és a színeik is függetlenek lehetnek a háttértől. A karakteres grafika további előnye, hogy kevés CPU idő használatával animálható (hullámzó víz, stb.), és kevesebb memóriát is fogyaszt, ami hasznos, ha összesen csak 64 KB van. :)

Quote from: Z80System
egyébként meg ha pixelhelyes sprite -okban gondolkodunk, akkor ugyanakkora (LORES) memória bizergálást kéne csinálni karakteres módban is, ráadásul egy plussz bonyolító indirekciós memória layout -on keresztül.
A háttér mentésénél és a sprite törlésénél van némi előnye a karakteres módnak, mert csak az eredeti karaktereket kell menteni és visszaírni pixelek helyett (8-szor kevesebb adat).
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.October.24. 14:00:49
Quote
A háttér mentésénél és a sprite törlésénél van némi előnye a karakteres módnak, mert csak az eredeti karaktereket kell menteni és visszaírni pixelek helyett (8-szor kevesebb adat).


Újabb megvilágosodás ... :)

Ez egyre jobb ...
Title: Re: Grafikai trükkök
Post by: geco on 2013.October.24. 15:16:08
Quote from: Z80System
Újabb megvilágosodás ... :)

Ez egyre jobb ...
Megnéztem pár linket az 50fps-es postodból, azok is mind karakteres módnak tűnnek, pl a centipede animált háttérmozgása tök gyors, csak egy karaktert kell minden frame-ben felülírni. A sub hunterbe betett bogyóknál meg ha jól emléxem, akkor 8 karaktert változtatok, és csak minden 2. frame-ben, amúgy túl gyorsan bogyóztak volna :D , ez volt a C64 sebesség is (25 fps)
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.October.24. 15:28:47
Quote
Megnéztem pár linket az 50fps-es postodból, azok is mind karakteres módnak tűnnek, pl a centipede animált háttérmozgása tök gyors, csak egy karaktert kell minden frame-ben felülírni. A sub hunterbe betett bogyóknál meg ha jól emléxem, akkor 8 karaktert változtatok, és csak minden 2. frame-ben, amúgy túl gyorsan bogyóztak volna (http://enterpriseforever.com/Smileys/phpbb/ds_icon_biggrin.gif) , ez volt a C64 sebesség is (25 fps)
Az 50 FPS topikba másolt cuccok alapvetően nem olyan cuccok, hogy lám azt a CXX 50 FPS -sel csinálja,
hanem olyanok, amiket talán vagy jóeséllyel lehetne megcsinálni EP -n 50 FPS -sel.

Korábban is elhangzott már több helyről hogy C64 -en is kevesebb lesz az 50 FPS cuccok aránya, mint hinni vélem. De ez már a másik topic témája lenne.
Title: Re: Grafikai trükkök
Post by: geco on 2013.October.24. 16:10:48
Quote from: Z80System
Az 50 FPS topikba másolt cuccok alapvetően nem olyan cuccok, hogy lám azt a CXX 50 FPS -sel csinálja,
hanem olyanok, amiket talán vagy jóeséllyel lehetne megcsinálni EP -n 50 FPS -sel.

Korábban is elhangzott már több helyről hogy C64 -en is kevesebb lesz az 50 FPS cuccok aránya, mint hinni vélem. De ez már a másik topic témája lenne.
Én is úgy értettem, ahogy itt írtad, hogy azokat meg lehetne csinálni :) , a centipede-t csak azért írtam le, hogy annak a hátérmozgatása frame-enként 8 byte másolásával megoldható, és ekkor jutott eszembe a sub hunterbe betett bogyózó képernyő, ott midnen képen látható mozgás bekerülhetett volna egy frame-be.
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.October.24. 16:18:14
Quote
Én is úgy értettem, ahogy itt írtad, hogy azokat meg lehetne csinálni :) 

Hát akkor csak siman: ja.

Bár megmondom őszintén én sorba megyek: a galaga az első ... :)

Szóval először azon gondolkodom, aztán majd egy vizszintes scroll -os cucc fog jönni, először csak 2 színnel valószínűleg, aztán jönnek majd a "ziccer" -ek ...

De ezekből bármi is valósul meg, hétköznapi halandónak nem sok öröme lesz, mert épp csak látszódni fog belőlük valami. Pontosabban az tisztán fog látszódni, hogy mire lehetne kihozni a végén, de értelmesen játszani nem lehet majd velük.

De ez meg már megint egy másik topik lenne ...
Title: Re: Grafikai trükkök
Post by: geco on 2013.October.24. 16:28:38
A galaga tűnik a legbonyolultabbnak, átvinni az űrhajókat egyik karakterből a másikba...
Szerintem a centipede, vagy az óriáspacman :D sokkal könnyebben kivitelezhető. Bár lehet fullon megírni nem is tudnám :lol: Az ellenség mozgatása okozhat nálam problémát.

Lehet később nekiállok az egyiknek.
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.October.24. 16:33:13
Quote
A galaga tűnik a legbonyolultabbnak,


Hát igazából sztm az oldal scroll -os dolog még a galagánál is nehezebb talán, de ha mégsem, akkor valóban ezek vannak holtversenyben az első helyen nálam is.


De hát pont ezért kezdek ezekkel és nem a "ziccerekkel". Először a nehezet, aztán jöhet az élvezet ... :)
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.October.24. 16:47:17
Quote
Lehet később nekiállok az egyiknek.
Minnél többen állnak neki, annál inkább sülhet ki belőle valami eredmény is.
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.October.24. 20:39:49
Ki tudja, hogy karakteres üzemmódokban a karakterkódok legfelső 2 bitje minden színüzemmódban használható ?

Úgy értem azt irta az EXOS leírás, hogy 2 színűnél a felső két bit a paletta első 8 színét engedi kiválasztani kettesével,

De 4 színű módban akkor csak egy bit van, és azzal lehet kihasználni a 8 színt, négyesével,

vagy ott is két bit van, és a teljes 16 -os paletta kihasználható 4 -esével ?

És akkor 16 meg 256 színben meg színek szempontjából nincs semmi extra, a felső két bitnek semmi hatása ?

Természetesen végig feltételezve a 64 karakteres módot ...
Title: Re: Grafikai trükkök
Post by: IstvanV on 2013.October.24. 20:45:05
256 színű módban a biteknek nincs hatása (az LSBALT/MSBALT kivételével, amelyek továbbra is levágják a megfelelő bitet, de a színekre ezeknek sincs hatásuk ilyenkor).

Paletta alapú módokban (2, 4, és 16 színű) OR 2 és/vagy OR 4 művelet történik a paletta színnel. Ezek mindhárom módban működnek (és még a normál esetben grafikus módokban használt LSBALT/MSBALT bitek is), de nem mindig van értelme a használatuknak. 2 és 4 színű módban nincs lehetőség a felső 8 paletta szín használatára.
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.October.26. 23:27:18
Ez szinte nem is programozási kérdés, de attól még nem tudom.

Szóval a normál PC -s rendszereknél van egy fix frekvencia amin megy a monitor, pontosabban amire (vagy amikre) képes a monitor, ezt meghajtja egy videokartya kimenet azon a frekin, ami épp választva van a monitor által ismert frekikből.

A képfrissítésre az alkalmazói szoftver a grafikus API -kon keresztül eldöntheti hogy vár rá, vagy nem vár rá, és joccakát.

( Mondjuk épp ezzel kapcsolatban várható nagy változás most, az nvidia a "napokban" találta fel a spanyolviaszt, és bemutatnak olyan monitor és videókártya (persze csak nvidia kari ...) kombókat, amikkel meg lehet valósítani akár dinamikus képfrissítéseket is. Technikailag nemtom ez mekkora kunszt, de a lényeg hogy már nem csak a szokásos képfrissítési frekik lesznek, és ha valami épp kiesik (lassabb) a beállított frekiből, akkor a várakozás miatt egyből duplájára lassúl, vagy várakozás nélkül jön a frame tearing, hanem ha a cucc 54 vagy 37 FPS -sel tudja lökni a frame -eket, akkor a monitor azt szépen le fogja követni. Ez olyan mintha végtelen mennyiségű frekit ismerne a monitor, és még ráadásul frame -ről frame -re változhatna is az érték.)

De vissza az EP -re. Szóval EP -n ennél nagyobb befolyásunk lehet a videó jelre, ha jól értem ? Tehát van az LPB -kben az LPT reload flag, amit ha bekapcsolunk, akkor újratöltődik az LPT címe. De ez az újratöltés közvetlen befolyással lesz a kimeneten a video jelekre (RGB+szinkronok), nem ? A monitoroknál hogy van ez, lekövetik a videójelet szolgamód ? Tehát feltételezzük, hogy van egy LPT -m ami nem korrektül (az összes függőleges sorra) van összerakva, hanem mondjuk 200 sort tartalmaz. Akkor mi lesz ? Ki fog rakni képet a monitor ?Megjelenik a monitoron a kép tetejétől a 200 sor, es a monitor többi része fekete lesz ?

Ugyanez a hatás lesz akkor is, ha nem az LPB -ből, hanem a z80 forced LPT port írással váltom a címet, mondjuk minden frame -ben ?

Mert én úgy emlékszem, hogy a monitorok (TV -k) ennyire azért nem követik le a video jelet, hanem szétesik a kép ... nem is értem mi értelme van egyáltalán a forced reload -nak akkor ?

Tehát ugye ha villanásmentesen akarok LPT -t váltani, akkor a nem forced verziót kell alkalmazzam, és akkor a kép végén automatikusan fogja majd betölteni a nick a címet a (mostmár) új LPT -re. Így csak azzal kell már szívni majd, hogy mielőtt nekiállok szétbarmolni az előző LPT -t, vagy a videómemóriáját, azelőtt megbizonyosodjak róla, hogy a váltás a NICK részéről már végbement. Oké, hogy kicsi az az idő, hisz 50 Hz a frissítés, de akkor is, elvileg gondolkozva.

Ha forced módon váltok, akkor meg villanik (villanhat) egy nagyot, attól függően, hogy az előző LPT épp hol tartott mikor ráváltottam forced módon az új címet. De sztm ha mondjuk 50 fuggőleges pixelsor után forced módon LPT -t váltok, abból csak csúnyaság lesz, nem pedig a felső 50 sor ... vagy mégis ? Leköveti a monitor a jel változását ? Vagy eleve nem is lesz mit lekövessen, hisz a szinkron jelekig nem jut el az LPT így soha ...

Vagy lehet hogy forced reload- nál a NICK generál gyorsan valami szinkron jeleket a monitornak az LPB -k nélkül is ?

Szóval ...

1 Monitorok mit tudnak lekövetni ?
2 Van -e bármi értelme a forced LPT cím váltásnak ?
3 Hogyan tudom detektálni azt, hogy a nem forced LPT váltás ténylegesen betöltésre került már a NICK által (ok, persze csinálok egy tizedmásodperces várakozást, és kész, de nincs is rá hivatalos módszer) ?
Title: Re: Grafikai trükkök
Post by: Zozosoft on 2013.October.26. 23:41:52
A forced-nek leginkább bekapcsoláskor van szerepe, de akár resetnél is (pl pont LPT készítés közben lett resetelve), hogy mindenképpen hagyja abba a Nick amit csinál, és váltson az újra. Mert a nem meghatározott régi adatokkal lehet, hogy éppen olyan LPT-n fut, aminek sosincs vége...

Ha nem megfelelő számú sort raksz az LPT-be akkor futni fog a kép, bizonyos eltérést tolerálnak a monitorok, de pl nekünk volt olyan Junosztyunk ami kb 2 sor eltérésnél már elindult a kép lefele vagy felfele...

A detektálásra az a módszer, hogy a VINT is ott van RELOAD mellett az LPT végén, így akkor van videó megszakítás, amikor újra kezdi az LPT-t, ha nem forcos-os új volt, akkor azt.
Vagyis ha két képernyőt akarsz használni, akkor beírod az új címet, aztán várni a videómegszakításra, ha az megjött lehet törölni a régit.
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.October.27. 00:00:11
És akkor egy már szétcsúszott videójel kimenet/TV bemenet hogy talál össze ? Mitől lesznek újra szinkronban ?

Mikor forszoltan beváltom az LPT -t, lehet hogy először elpörög az LPT végén a szinkronig, ott egymásra talál a video jel és a TV, és onnantól lesz jó a kép ?

Tehát forszolt beváltásnál az is lehet, hogy célszerű az első szinkron LPB -vel váltani be, aminek a végén meg úgyis ott van a reload megint ?

De akkor tehát csak van valami "lekövetés", ha más nem a kép kezdésére, mert különben sosem találnának már egymásra, ha egyszer elcsúsztak, nem ?
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.October.27. 00:02:09
De akkor meg hogy jönnének létre ezek a futások, a kép tetejéhez húzott képhez képest ?
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.October.27. 00:04:26
Quote
A detektálásra az a módszer, hogy a VINT is ott van RELOAD mellett az LPT végén, így akkor van videó megszakítás, amikor újra kezdi az LPT-t, ha nem forcos-os új volt, akkor azt.
Hát ... ez inkább "egy" módszer, nem pedig "a" módszer ... mi van, ha én a videomegszakot nem oda akarom ? Mi van ha a leváltandó LPT -ben nem ott volt.
Title: Re: Grafikai trükkök
Post by: Zozosoft on 2013.October.27. 00:16:21
Quote from: Z80System
Hát ... ez inkább "egy" módszer, nem pedig "a" módszer ... mi van, ha én a videomegszakot nem oda akarom ?
Hova máshova akarod? :-)
Amúgy a kép végének nem kötelező az LPT végén lenni. Lehetséges, hogy mondjuk az utolsó érdemi képtartalmat jelző sor legyen az utolsó ami reloadol meg megszakít, a kép (mondjuk játéktér) alatti üres keretet, meg szinkron részt az LPT eleje tartalmazza.

Lehet több megszakítás is, de akkor neked kell nyilvántartani, hogy éppen melyik jött.
Quote
Mi van ha a leváltandó LPT -ben nem ott volt.
Ha nem tudod mi volt az előző LPT-dben az baj :-) ha meg tudod, akkor ahhoz képest kell gondolkodni.
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.October.27. 00:25:04
Quote
Amúgy a kép végének nem kötelező az LPT végén lenni.
Na ez tök érdekes ... tehát az LPT egy "kört" képez, és nincs eleje meg vége ... ami azért érdekes mert úgy "tanítják" hogy

1 kezdő szinkron lpb
értelemes sorok lpb -i
5 vég szinkron lpb

de akkor eszerint ez is jó:

5 vég lpb
1 kezdő lpb
értelmes sorok lpb -i

vagy:

értelmes sorok lpb -i
5 vég lpb
1 kezdő lpb

És lássuk be ez tök röhej ...



És akkor mitől talál egymásra a videojel és a monitor ?
Title: Re: Grafikai trükkök
Post by: Zozosoft on 2013.October.27. 00:27:46
Quote from: Z80System
És akkor egy már szétcsúszott videójel kimenet/TV bemenet hogy talál össze ? Mitől lesznek újra szinkronban ?
A szinkronáramköröktől. De azt passzolom, hogy ezek pontosan hogyan is működnek.
De a lényege az, hogy a szabvány szerinti (pluszminusz némi tűrés) ütemben érkező szinkronjeleket felismeri, és belövi a képet a helyére.
A kezdetek kezdetén a hálózati áram adta a szinkront, ezért 50 félképes a PAL, míg 60 az NTSC, mert az amcsiknál 60Hz-es áram van (ott 60FPS-es játékot akarnál látni :-D )
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.October.27. 00:32:20
Quote
De a lényege az, hogy a szabvány szerinti (pluszminusz némi tűrés) ütemben érkező szinkronjeleket felismeri, és belövi a képet a helyére.
Szupi ... de hát épp az van, hogy nem vagyunk már szinkronban ... tehát nem vagyunk tűrésen belül ...


Quote
A kezdetek kezdetén a hálózati áram adta a szinkront, ezért 50 félképes a PAL, míg 60 az NTSC, mert az amcsiknál 60Hz-es áram van

Hmmm ... hát akkor az endit én áttettem a palánkon a másik fórumon ... :)


Quote
(ott 60FPS-es játékot akarnál látni (http://enterpriseforever.com/Smileys/phpbb/ds_icon_biggrin.gif)

Há még vili ... mint ahogy bizonyos gépeken úgy is mennek ...
Title: Re: Grafikai trükkök
Post by: Zozosoft on 2013.October.27. 00:37:12
Quote from: Z80System
de akkor eszerint ez is jó:
Így van, így kerül pl a Zozotools óra a rögzített helyen lévő status sor fölé.
Vagy a Z&A demóban így tettem a status sort működő magnó szintjelzővel a képernyő közepére.

És ott van még az LPT animáció lehetősége, amikor a végén még nincs újratöltés, hanem folytatódik egy másik kép kocka adataival. Lásd Nasa&Guy demók nagyrésze.


Quote
És akkor mitől talál egymásra a videojel és a monitor ?
Az a lényeg, hogy a két megfelelő szinkronszakasz között megfelelő mennyiségű sor legyen. Erre számít a monitor/tv szinkronáramköre, erre próbálja belőni magát.
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.October.27. 00:38:14
Quote
Ha nem tudod mi volt az előző LPT-dben az baj 


De tudom mi volt benne, egy video megszak, ami már rég lefutott, mire a reload megérkezett. A reloadnál meg nincs megszak.


Ekkor én az új LPT video megszakjánál fogom csak érzékelni a váltást ...


Ami olyankor mikor ezt nem frame -enként akarom csinálni, hanem csak úgy átváltotam A- ról B -re, akkor nem is baj végülis,


ha meg frame -enként akarom, akkor muszály lesz a vegére tegyem a megszakot ...


Az EXOS LPT egyébként hova teszi a megszakot ? Reload -hoz ?
Title: Re: Grafikai trükkök
Post by: Zozosoft on 2013.October.27. 00:44:17
Quote from: Z80System
Szupi ... de hát épp az van, hogy nem vagyunk már szinkronban ... tehát nem vagyunk tűrésen belül ...
Ilyenkor le kell mennie pár normál körnek, hogy beálljon a dolog. Ez az amit úgy látunk, hogy ugrik egyet a kép LPT váltáskor.

Quote
Há még vili ... mint ahogy bizonyos gépeken úgy is mennek ...
C64 van ilyen is meg olyan is, és mivel ott minden mindennel összefügg, ezért más lett a CPU órajele is.

Arra nagyon kíváncsi vagyok, hogy ha belépett volna az amerikai piacra az EP (Las Vegasban ugye kiállítottak egy shown), akkor hogyan készült volna az NTSC verzió?
Title: Re: Grafikai trükkök
Post by: Zozosoft on 2013.October.27. 00:47:21
Quote from: Z80System
Az EXOS LPT egyébként hova teszi a megszakot ? Reload -hoz ?
Igen, meg úgy általában a programok 99%-a. Geco CPC átirataiban van olyan, hogy kellett a 300Hz-es CPC megszakítás is, így több videó megszakítás lett egy LPT-n belül.
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.October.27. 00:53:40
Quote
Arra nagyon kíváncsi vagyok, hogy ha belépett volna az amerikai piacra az EP (Las Vegasban ugye kiállítottak egy shown), akkor hogyan készült volna az NTSC verzió?

Hát ez az ... ennek az eszetlen szabadságnak akár ára is lehet ...

Amigán is van copper, ott is vághatsz soronként képet, mégsem kell szinkronizációval tökörésszél ... (remélem jól emlékszem ... :)).

Az még egy dolog, hogy az EXOS -t át kellett volna írni olyanra hogy 200 sornál többet ne használjon soha,

de az összes programot is át kellett volna írni, mivel a fene nagy szabadság jegyében mindennek rossz lenne a szinkronja ... nem ?

Jó hogy a szinkront nem az ENTER gombra vezették már ki, hogy a júzer nyomogassa 50 vagy 60 herccel ... :)

A NICK -en kéne legyen egy PAL/NTSC kapcsoló, vagy freki kapcsoló, lehetne N-M freki range, és az értelmes sorokhoz neki kéne hozzácsapni a szinkront hardverből. Nem ?
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.October.27. 00:57:26
A szegény alkalmazás programozót zaklatni ilyenekkel ... van annak elég más baja ... ( pld. nincsenek szprá ... )
Title: Re: Grafikai trükkök
Post by: ergoGnomik on 2013.October.27. 11:14:07
Quote from: Z80System
Hát ez az ... ennek az eszetlen szabadságnak akár ára is lehet ...

Amigán is van copper, ott is vághatsz soronként képet, mégsem kell szinkronizációval tökörésszél ... (remélem jól emlékszem ... :)).

Az még egy dolog, hogy az EXOS -t át kellett volna írni olyanra hogy 200 sornál többet ne használjon soha,

de az összes programot is át kellett volna írni, mivel a fene nagy szabadság jegyében mindennek rossz lenne a szinkronja ... nem ?

Jó hogy a szinkront nem az ENTER gombra vezették már ki, hogy a júzer nyomogassa 50 vagy 60 herccel ... :)

A NICK -en kéne legyen egy PAL/NTSC kapcsoló, vagy freki kapcsoló, lehetne N-M freki range, és az értelmes sorokhoz neki kéne hozzácsapni a szinkront hardverből. Nem ?
A szabadság árához csak annyit, hogy mindennek van ára. Azon múlik az egész, hogy hajlandó vagy-e megfizetni vagy sem? Senki sem kötelez arra, hogy saját LPT-t használj. Csak lehetőség.

Amigában nem vagyok képben, de ott talán nem tudsz közvetlenül a videoszinkronhoz hozzáférni, ami a te szempontodból legfeljebb kényelmi funkciónak tudható be. EP-n egy kicsit figyelni kell, de ha egyszer elfogadtad a rendszert, hogy ezzel akarsz dolgozni, akkor sajnos implicit módon a szabályokat és korlátokat is elfogadtad.

Egyébként nagyjából pont annyi történt volna az EP NTSC piacra bevezetése után, mint az a Commodore számítógépeknél is. Lett volna belőle PAL és NTSC változat. Képzeld, Latin-amerikába PAL-60-as gépeket gyártott a CBM, mert ott is próbálkoztak. Valószínűleg a hardver különbözősége szoftverben így vagy úgy, de érzékelhető lett volna, és a program a megfelelő időzítéseket és LPT-t használta volna, vagy a két TV szabványú piacra külön változatot készítenek.

A szabványváltó kapcsoló önmagában kevés, mert az alap vivőfrekvenciák is mások. Egyébként meg a sorszinkront most is saját maga csapja hozzá hardverből. Sőt, a függőleges szinkront is hardverből csapa hozzá, csak szólni kell neki mikor tegye azt. (Egyébként sizecoding versenyeken a szinkronjelek bizergetésével létrehozott effekteknek azért szokott sikere lenni.)
Title: Re: Grafikai trükkök
Post by: Zozosoft on 2013.October.27. 11:20:40
A szinkron jelek birizgálása teszi lehetővé az interlace-t is.
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.October.27. 11:44:20
Quote
Egyébként nagyjából pont annyi történt volna az EP NTSC piacra bevezetése után, mint az a Commodore számítógépeknél is. Lett volna belőle PAL és NTSC változat. Képzeld, Latin-amerikába PAL-60-as gépeket gyártott a CBM, mert ott is próbálkoztak. Valószínűleg a hardver különbözősége szoftverben így vagy úgy, de érzékelhető lett volna, és a program a megfelelő időzítéseket és LPT-t használta volna, vagy a két TV szabványú piacra külön változatot készítenek.
Tehát módosítani kellett volna minden addig kiadott játékot (hisz mindenki LPT -t használt) és/vagy az új szabványú gépen a módosításokig nem ment volna egyetlen cucc sem ? Hat ... nekem ez azért elég nagy árnak tűnik, ha jól értem.


Quote
A szinkron jelek birizgálása teszi lehetővé az interlace-t is.

Ami szintén lehetne síma flag is a NICK -nek.

Az egy alkalmazói döntés hogy interlace vagy nem interlace, eztán felállítja a döntésének megfelelő LPT értelmes sorainak adatbázisát, kódját,

és a NICK meg az alkalmazás döntésének eredménye képpen megkapott interlace vagy nem interlace adatokat tolja PAL vagy NTSC formában kifele ...

Feltéve hogy a kisebb sorszám (mert ha jól tudom, NTSC -n kisebb sorszám van) nem avatkozik be magába az alkalmazásba is ...

Tényleg, hogy van ez, a világ összes játéka más NTSC -ken mint PAL -on ? Azn NTSC egy képarány változtatás is, vagy csak függőleges felbontás változtatás, vagy csak képfreki változtatás, a színek kezelésének változtatása mellett ?

Ha egy játék kihasznál minden sort amit a PAL enged, akkor ott gamplay változtatásokat kell eszközölni (pld. pálya áttervezése) azért hogy a kisebb NTSC képről ne lógjon ki ? Mert ha így van akkor valóban a szinkron a legkevesebb ...

De mondjuk akkor, ha valaki eleve olyan játékot csinált, ami elférne NTSC -n, akkor se futna egy NTSC gépen, amíg az új szinkront hozzá nem írná ... ami akkor megint rossz.
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.October.27. 12:08:12
Persze az is lehet, hogy szerencsétlen EP -nek ez volt a legkisebb gondja ... hogy jujj, mi lesz akkor, ha programok százait vagy ezreit kell majd NTSC -síteni, az amerikai piacra ... úgy gondolt rá inkább, hogy "bárcsak ez lenne már az egyetlen problémám ..."
Title: Re: Grafikai trükkök
Post by: ergoGnomik on 2013.October.27. 12:12:50
Nagyon nem vagy kibékülve ezekkel a szinkronjelekkel. Az mindig adottságnak tekinthető, legfeljebb olyan rendszerekben, ahol szabadabban hozzáférhetsz nem volt addig piacra érett a program, amíg hibás szinkront generált. Már ha a programozó volt olyan bátor és babrált vele.

 Az NTSC/PAL kérdést szerintem egy kicsit félreértelmezed. Akkoriban nem nagyon nyűglődtek azzal, hogy minden rendszeren egyazon kódnak kelljen futnia. Ha át kellett írni, akkor átírták. Azt csak a későbbiekben végbement nagyfokú szabványosodás tette lehetővé, hogy már ne kelljen foglalkozni ilyesmivel. Az EP, C64, stb. szintjén ezt nem tudod kikerülni. A legtöbb esetben két dolgot csináltak. Vagy letojták, ha csak az egyik rendszeren megy, akkor csak ott megy és kész. A másik, hogy megfontoltan álltak neki, vették a rendszerek közös nevezőjét, és az ebből fakadó korlátok szerint készítették a dolgot. Pl.: NTSC-ben függőlegesen nyújtott lett a kép, de legalább a zene PAL-ban lassabban vagy egyenetlenül ment. Vagy ha nem fért ki a PAL-nál az alsó meg felső keretre szorított kijelző NTSC-ben, akkor PAL only lett a program és kész. Téged, mint Enterprise fejlesztőt ez szerencsére nem érint egy kicsit sem.
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.October.27. 12:28:00
Quote
Nagyon nem vagy kibékülve ezekkel a szinkronjelekkel. 

Hát annó, mikor ott voltál, hogy 15 éves vagy, van egy EP -d, és az egyetlen doksid hozzá a kezelési útmutató (ami tulajdonképp egy EP BASIC tankönyv :)), de te játékot akarsz írni, és mi az a "gépikód", meg "hexa", és egy elszállás után percekig töltöd vissza az ASMON -t, akkor elég undok dolog tudott lenni meglévő programokból barkóbázni kifele az LPT szinkron értékeinek jelentését, hogy képes legyél egy saját képet bekapcsolni ...

De a mostani tárgyalását Zozo vetette fel az NTSC kapcsán, engem meg simán csak érdekelt.
Title: Re: Grafikai trükkök
Post by: endi on 2013.October.27. 12:41:33
nem értem mit kell már ilyen tök alap dolgokon problémázni, mint az lpt...
én általában valami kész lpt építő kódot használtam, mi a fenének újraírni azt ami már megvan?
Title: Re: Grafikai trükkök
Post by: IstvanV on 2013.October.27. 14:44:54
Quote from: Zozosoft
Arra nagyon kíváncsi vagyok, hogy ha belépett volna az amerikai piacra az EP (Las Vegasban ugye kiállítottak egy shown), akkor hogyan készült volna az NTSC verzió?
Viszonylag kevés változtatással megoldható lett volna:
- 4.43361875 MHz helyett 3.579545 MHz-es színsegédvivő (kristály cseréje és még egy-két passzív alkatrész módosítása az LM1889 körül az eltérő frekvenciának megfelelően)
- NICK módosítása: a H/2 frekvencia a színsegédvivő 456-od (illetve a szabvány szerint pontosabban 457-ed lenne) része 568-ad helyett. Ez az osztó állítható lehetne szoftveresen is I/O porton keresztül, vagy a NICK egy ilyen célú bemenetén hardveresen
- az LM1886 H/2 bemenetére H/2 jel helyett felhúzó ellenállás kerül (ezzel lehet PAL helyett NTSC jelet generálni)
- az LPT hosszát 312-ről 262 sorra kell csökkenteni (szoftver változtatás). Többé-kevésbé használható fekete-fehér képhez akár ez is elég lehet, attól függően, hogy a TV mennyire érzékeny a "szabálytalan" sorfrekvenciára
Title: Re: Grafikai trükkök
Post by: IstvanV on 2013.October.27. 14:49:45
Quote from: Z80System
Hát annó, mikor ott voltál, hogy 15 éves vagy, van egy EP -d, és az egyetlen doksid hozzá a kezelési útmutató (ami tulajdonképp egy EP BASIC tankönyv :)), de te játékot akarsz írni, és mi az a "gépikód", meg "hexa", és egy elszállás után percekig töltöd vissza az ASMON -t, akkor elég undok dolog tudott lenni meglévő programokból barkóbázni kifele az LPT szinkron értékeinek jelentését, hogy képes legyél egy saját képet bekapcsolni ...
Általában elég az "EXOS 2.1 Műszaki Leírás"-ból másolni. :)
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.October.27. 14:51:00
Quote
Általában elég az "EXOS 2.1 Műszaki Leírás"-ból másolni. (http://enterpriseforever.com/Smileys/phpbb/smiley.gif)
Ha tudod hogy létezik, és ha tudsz egyet szerezni ...
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.October.27. 14:52:57
Quote
az LPT hosszát 312-ről 262 sorra kell csökkenteni (szoftver változtatás). 



Hát lehet, hogy technikailag a hardvereseknek mindez bágátell, de az alkalmazásosok elmorzsolnának pár "imát" mikor ezt meghallanák ...
Title: Re: Grafikai trükkök
Post by: IstvanV on 2013.October.27. 14:57:37
Quote from: Zozosoft
Igen, meg úgy általában a programok 99%-a. Geco CPC átirataiban van olyan, hogy kellett a 300Hz-es CPC megszakítás is, így több videó megszakítás lett egy LPT-n belül.
Illetve az én átirataim jelentős részében. :oops: Azonban sokszor így is egyszerre csak egy megszakítást használtam az LPT-ben, mert különben nehéz megállapítani, hogy a 6 közül éppen melyik történt. :) Tehát a program minden megszakításnál módosítja az LPT-t a következő megszakítás pozíciójának megfelelően.
Title: Re: Grafikai trükkök
Post by: Zozosoft on 2013.October.27. 15:01:50
Quote from: IstvanV
- az LPT hosszát 312-ről 262 sorra kell csökkenteni
Hmmm, a 28 karaktersoros EXOS kép (status+27 sor) az 252 sor, még pont belefér. Lehet, hogy erre is kalkuláltak?
Title: Re: Grafikai trükkök
Post by: IstvanV on 2013.October.27. 15:03:12
Quote from: Z80System
Ha tudod hogy létezik, és ha tudsz egyet szerezni ...
A hiányában nehéz lehetett a gépi kódú programozás (a csak EXOS-on keresztül történő hardver kezeléstől eltekintve, de akkor is kellene ez a könyv az EXOS hívások dokumentációjához), mert ebben volt található a DAVE és NICK programozásának a leírása is. És még ebben a könyvben sem volt információ a hardver szintű billentyűzet kezelésről. :)
Title: Re: Grafikai trükkök
Post by: Zozosoft on 2013.October.27. 15:04:03
Quote from: Z80System
Ha tudod hogy létezik, és ha tudsz egyet szerezni ...
Ez mondjuk nem a Nick hibája. A fejlesztők példaértékű dokumentációt csináltak a gép minden porcikájáról.
Title: Re: Grafikai trükkök
Post by: IstvanV on 2013.October.27. 15:07:38
Quote from: Zozosoft
Hmmm, a 28 karaktersoros EXOS kép (status+27 sor) az 252 sor, még pont belefér. Lehet, hogy erre is kalkuláltak?
Így azonban csak 10 sor marad a VBLANK+VSYNC-re, ami ugyan elég lehet (különösen fekete kerettel), de nem szabványos, illetve az NTSC TV-ken gyakran nem lett volna látható minden sor, mert a "szabványos" látható függőleges felbontás interlace módban csak 480 (2 * 240) sor.
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.October.27. 15:19:45
Quote
A hiányában nehéz lehetett a gépi kódú programozás 


Idővel persze megtudtuk, és szereztünk is ... de addig tömény horror. Persze akkor még ezt nem úgy éltük ám meg. Nem mondom, nagy fellélegzés volt a doksi, meg a cartridge -os ASMON, de addig is minden pixelnek, meg minden egyes új infónak vagy puzzle darabkának örültünk mint majom.
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.October.27. 16:16:25
Most én úgy írtam meg az LPT beváltómat, hogy van egy bool falg -je hogy forced vagy nem forced,

ha nem forced, akkor betolja a 0x82 -t, 0x83 -at a címmel és mást nem csinál, de ha forced, akkor 0x83 -ra beírja a címkomponens + 64, aztán a címkomponens + 64 + 128 -at is ...

forced esetben jól működök,

nem forced esetben meg az egész kép border lesz.

Nem forced esetben sem csak simán a címkomponenseket kell kiírni, vagy csak valamit elrontok ?
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.October.27. 16:26:33
Quote
In normal use these bits are both set to one.

Jaaa ... azt írja az EXOS, hogy 1 -re kell őket állítani normálnál ...
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.October.27. 16:43:36
Na most mondja meg nekem valaki, hogy miért nem jelent az LPT újratöltésének módja időzített atombombát nem forszolt reload esetén ...

Az egész forszolás ugye azért lett kitalálva, hogy egy invalidus memóriát szkennelő NICK -et ki lehessen billenteni az elszálltságból.

Ha ilyen nem lehetne, akkor nem is kéne forszolás.

Az egyik mód, ahogy a NICK invalidus memóriát szkennelhet, az az, hogy a Z80 nem forszolt LPT címváltáskor beírta a 0x82 -es portot, és mielőtt beírná a 0x83 -mast is, a NICK pont reload -os LPB -t kezel, és újratölti a félig beírt címet.

Ezt írják is, hogy videó megszakkal kerüljem el.

Nade mi van, ha a programom nem frame -es, és nem is tudom hány frame -mel megy, sőt mondjuk 0 és 5 frame között változik az ideje.

A videómegszak megtörténtekor ( korábbi megállapodás szerint az a reload -ot jelölte egyben ) nem írhatom egyből át az LPT címeket nem forszolt módon, mert a frame végén a NICK be fogja tölteni, az én programom meg lehet 3 frame -ig fut.

Tehát backbufferbe le kell generáljam a képet, majd csak azután írhatom be az új LPT -t (ami a backbuffer -emre mutat), és majd annak a (mondjuk épp harmadik) frame -nek a végén fogja a NICK így újratölteni.

Igen ám, de mivel a programom ákármennyi ideig is tarthat, ezért bármikor lehet a fél beírás miatt NICK halál.

Tehát vígan fut a programom, majd egy pillanatban mikor pont úgy jön ki, akkor a NICK megbolondul, amiből egy forszolt írás kihozná, de hát az egyrészt ronda, ráadásul nem is tudom mikor bolondult meg ...

Magyarul egy időzített, kivédhetetlen NICK elszállás lebeg a programom feje fölött végig ... nem ?

Nincs megoldás ?
Title: Re: Grafikai trükkök
Post by: ergoGnomik on 2013.October.28. 07:50:31
Nem értem ezt az aggódásodat az LPT elszálláson. Ha a programod nem "frame-es", akkor egy sima osztott állapotgéppel kezeled a szinkronizációt. Ahogy javasolják, oda teszel egy VINT-et, ahol biztonságos az LPT váltás. A megszakításkezelő megvizsgál egy flaget, hogy a rajzolásod elkészült-e már? Ha úgy találja igen, akkor átírja az LPT mutatót, és jelzi egy flagben, hogy a rajzolás kezdje meg a másik buffer feltöltését. Ha az aktuális puffer rajzolása kész, a rajzoló beállítja a flaget és vár, hogy a videómegszakítás jelezze, mikor folytathatja a másik bufferrel. Ha jól gondolom, a két flag akár egy is lehet - mondjuk egy kijelölt cím alsó két bitje - és csak sima növelgetéssel is lehet helyesen változtatni. De ezt jobban végig kellene gondolni.

A veszély persze valószínűleg tényleg megvan, dehát jól sikerült pointer aritmetikával olyan "memória szántást" lehet csinálni, hogy ihajj, aztán mégis használjuk.

U.I.: Egyébként meg úgy kell igazítani az LPT-ket, hogy a címük alsó bájtja mindig azonos legyen, így elég csak egy port írás a váltáshoz, és nem is tud elkalandozni. Szerintem Zozo - vagy valaki más nagy tapasztalatú guru - ezt már írta is valamelyik témánál.
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.October.28. 08:54:57
Quote
Nem értem ezt az aggódásodat az LPT elszálláson.
Nagyon nem aggódom, de azért tudni szeretem mi a stejsz, és nem is tetszene ha tényleg úgy lenne, ahogy problémázok rajta.


Quote
Ha a programod nem "frame-es", akkor egy sima osztott állapotgéppel kezeled a szinkronizációt.

Na ez túl absztrakt volt, nem végeztem progmatot, szal ez nekem dzsiberis.


Quote
Ahogy javasolják, oda teszel egy VINT-et, ahol biztonságos az LPT váltás.

Hát az LPT váltás nagyjából mindenhol biztonságos, ha megszakhoz van szinkronolva, nem? De maradjunk a végénél, mert azt alkudtuk ki Zozo -val.


Quote
A megszakításkezelő megvizsgál egy flaget, hogy a rajzolásod elkészült-e már? Ha úgy találja igen, akkor átírja az LPT mutatót, és jelzi egy flagben, hogy a rajzolás kezdje meg a másik buffer feltöltését.

Nem oda buda. Ha arra várok, hogy a megszakkezelő írja át a címet (aki mellesleg figyeli hogy már kész -e a rajzolás, ahogy írod), akkor lemaradhatok egy frame -ről.

Tehát a megszakítás (és az általa kezelt flag) csak azt jelzi a főprogramnak, hogy a NICK már betoltotte a főprogram által korábban megadott új LPT címet, ezért már a főprogram pusztíthatja az előző LPT által mutatott képet.

Ha megszakra várnék az átírással, akkor valóban biztosan stabil lenne, de mikor 2.5 frame alatt megvan egy kép, akkor 3/4 frame határon nem töltődne be a cím a NICK -be, hiszen nem írtam bele, mert várok a megszakra, hanem a megszaknál írnám be a 3/4 frame határon, és majd a 4/5 frame -nél töltené csak be a NICK.

Ha meg nem várok megszakra a beírással, ahogy most van, hanem csak a regi kép lebontásával várok a megszakra, akkor pedig előfordulhat NICK elszállás ... sztm.
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.October.28. 09:20:09
Quote
A megszakításkezelő megvizsgál egy flaget, hogy a rajzolásod elkészült-e már? Ha úgy találja igen, akkor átírja az LPT mutatót, és jelzi egy flagben, hogy a rajzolás kezdje meg a másik buffer feltöltését.

Mondjuk egy nekem nem nagyon tetsző módon lehet hogy megiscsak jó amit mondasz ...

Ha a megszakot nem az LPT legvégéhez, hanem kicsit korábbra teszem (csak az a baj, hogy elég sok ídőt visz a szinkron, azt meg nem tudom szabad -e darabolni), szóval csak 1-2 pixelsorral korábbra tenném, mint most a legvége,

akkor ott valóban el lehetne kapni a megszakkal azt a pillanatot, ahol már kész van egy 2,95 frame -es lefutás is, és a rendelkezésre álló 1-2 pixelsoron még stabilan be lehetne váltani az új LPT -t ...

Csak mégse tetszene ha csak ezt lehetne ...

Meg egyáltalan ... lehet a szinkront így megbontani ? Hogy a szinkron utolsó előtti raszterében legyen egy megszak rakva ?
Title: Re: Grafikai trükkök
Post by: ergoGnomik on 2013.October.28. 09:37:27
Továbbra sem világos a problémád. A megszakítás bárhol lehet, akár képlefutásonként többször is, bár az némi többlet munkát igényel. Az a lényeg, hogy amikor a végére ér az LPT és újra töltené magát, addigra ha már tudsz puffert váltani, legyen újraírva a bázismutató. Amit eredetileg mondtam megoldást, azzal nem hagysz ki képet, legfeljebb rajzolási időt veszítesz. Amit visszanyerhetsz kicsit bonyolultabb szinkronizációval és tripla puffereléssel. Ha nagyon változó a rajzolási időd, valószínűleg amúgy is érdemes erre váltani.

De ez csak elméleti fejtegetés, és lehet hogy nagyon félreértem a sorparaméter tábla működését.
Title: Re: Grafikai trükkök
Post by: Zozosoft on 2013.October.28. 09:48:06
Szerintem akárhány LPB-re feloszthatod, csak összeségében legyen ugyanaz az értelme.
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.October.28. 09:55:01
Hát jó ... végülis most ez nem veszélyes, mert ugye éppenhogy szigorúan 50 FPS cuccot akarok írni, de később bármikor érdekes lehet ez ...

Egyébként megarulez van! Megmozdultak az első pixelek ... :)
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.October.28. 10:20:22
Itt az 50 FPS vergődéseim közben az lett a végeredményem, hogy a galaga szerű izémet LORES 4 színben kísérlem meg (legalábbis először :)). Függőlegesen is duplázott pixelekkel.

Namost ehhez lesz ugye fekete háttérrel együtt 4 színem ... hát nem vagyok elragadtatva a lehetőségek széles tárházától ...

Persze bevetek majd mindenféle soronkénti LPT -t meg ilyeneket, de hát az csak egy effekt, ha a többi tényleges grafika "monokróm", attól még nem lesz "szép színes" hatású.

És ezt kompenzálandó arra gondoltam, hogy megpróbálok villogtatással színt keverni.

Ha az egész képet villogtatjuk, az ugye azért elég mákos dolog tud lenni. De én ugye 50 FPS játékot csinálok, ahol (feltéve ugye hogy persze egyáltalán valami is létrejön) megtehetem, hogy nem az egész képet villogtatom valami HW trükkel, és nem kell kifollyon az ember szeme tőle, hanem csak ott keverem villogtatással a színt, ahol plussz színeket akarok. Mivel a galaga -s vackom ugye alapvetően egy csillagmozgás és sprite -ok, ezért a sprite -oknak rajzolhatok minden fázisuknak dupla grafikát, amiket 50 FPS -sel váltogatok majd. Ha a két ugyanahhoz a fázishoz tartozó kép egyforma, akkor nyilván a plettám 4 színét használva normál képet fog adni, de ha egyik ilyen "színkeverő mapot" megváltoztatom, akkor ott a szokásos vibrálásos módon új szín fog keletkezni. Elviekben gondolkodva 4*4 = 16 szín lesz így akkor mégis megoldható.

Mivel ezek sprite- ok és ráadásul nagyon absztrakt (nyilván nem fogok rendes grafikát tenni bele) dolgok lesznek, ezért a színkeveréshez szükséges villogás nem lesz zavaró tematikailag sem, meg a felszínük is viszonylag kicsi lesz, nem az egész kép fog vibrálni.
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.October.28. 10:23:34
Persze ettől emuban akkor nem fog igazán jól mutatni ... :(

Na de valamit valamiért ... :)
Title: Re: Grafikai trükkök
Post by: Zozosoft on 2013.October.28. 10:25:58
Ilyesmivel én is foglalkoztam. (http://ep128.hu/Ep_Demo/Leiras/Zozolace.html)
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.October.28. 10:31:56
Quote
A "Zozolace"-ban két négy színű kép van összekeverve váltott soros LPT-vel,


Én váltott képekről beszélek, ez tényleg váltott sor, vagy csak elírás



Quote
így összesen fekete+6 tetszőleges szín használható négy szín módnak megfelelő felbontásban.

itt fekete + 6 színről van szó, én meg 4 * 4 = 16 színről ... én gondolom rosszul ?
Title: Re: Grafikai trükkök
Post by: Zozosoft on 2013.October.28. 10:37:15
Quote from: Z80System
Én váltott képekről beszélek, ez tényleg váltott sor, vagy csak elírás
Nálam úgy volt, hogy az 1. kép 1. sora, 2. kép 2. sora, 1. kép 3. sora, 2. kép 4. sora, stb a következő LPT részben pedig a 2. kép 1. sora, 1. kép 2. sora, 2. kép 3. sora, 1. kép 4. sora, stb
Így nagy felületeknél kevésbé volt zavaró a villogás.


Quote
itt fekete + 6 színről van szó, én meg 4 * 4 = 16 színről ... én gondolom rosszul ?
Ezt is odaírtam :-)
"Lehetne még tovább is játszani, hogy a két képernyő 1-1 színét összekeverve újabb színt kaphatunk. "
Title: Re: Grafikai trükkök
Post by: Zozosoft on 2013.October.28. 10:45:53
Quote from: Z80System
Itt az 50 FPS vergődéseim közben az lett a végeredményem, hogy a galaga szerű izémet LORES 4 színben kísérlem meg (legalábbis először :)). Függőlegesen is duplázott pixelekkel.
Nem jobb lenne Hires 16? Akkor lenne elég szín, nem kéne villogtatással foglalkozni.
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.October.28. 10:53:19
Quote
Nem jobb lenne Hires 16? Akkor lenne elég szín, nem kéne villogtatással foglalkozni.
De, színek szempontjából sokkal jobb lenne, csak hát dupla annyi memória, dupla annyi iteráció, dupla annyi idő.

Döbbenetesen kevés az idő, vagy döbbenetesen béna vagyok, tök mindegy is, még ebben a normál HIRES módhoz képest NEGYEDELT! memória igénnyel is csak nagyon szűken fogok beférni.

Titkon azon reménykedek, hogy ha összerakok valamit, és látszik valami már a képen, akkor valamelyik optimalizáló isten majd megnézi és felgyorsítja, és akkor lehet még majd feljebb tolni a darabszámokat ...

De jelenleg ahogy kinéz lesz kint a képen "3 pixel", oszt kész ...

Konkrétumokban, a csillagmozgás és a főhős mellé nem biztos hogy ki tudok hozni 8 ellenség sprite -ot ... de azért még az elején vagyok, majd nyugtával a papot.
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.October.28. 17:05:47
Lehet, hogy túlépítem ezt a gondolatkört, és ha megint testközelből meglátom, hogy egy VAS konfigon mennyire vibrál az 50 FPS -ses váltott kép, akkor sikítva szaladok amerre látok, és még a galagás szprájtjaimból is kiveszem a pár villogtatással beinjektált plussz színt,

de most azt kezdem remélni, hogy valójában azért remegtek azok a régi interlace képek ANNYIRA csúnyán, mert ugye volt a félképek között egy függőleges elcsúsztatás, és ettől nem csak intenzitásban, de pozícióban is remegett a pixel,

és ha ez így van, és olyankor mikor a pixelek fedésben vannak és csak színben változnak, akkor ez sokkal kevésbé zavaró, mint az igazi interlace (ami a galagás cuccból majd úgyis kiderül) akkor lehetne ebben a dologban kiterjedtebben gondolkodni ...

Gondoljunk csak bele egy olyan cuccba, ami ugyen egész képernyőn remeg, de intenzív, nagy világosságtartalmú színekkel kompenzáljuk az alapvetően fekete háttérrel való villogtatásukat,

akkor egész playfield -eket kaphatnánk ... mint amigán ... lenne 2 playfiled -unk, overlay -unk, nevezd aminek akarod, amik hardverből blendelődnek ... (lehet hogy egy jó lassú kioltású display csodákat tenne itt)

olyanokat lehetne csinálni pld, hogy egyik playfiled -en karakteres módban vízszintes scroll pár pixelsornyi időből, másik playfield -en meg a sprite -ok HIRES 16 -ban, vagy egy egészen másik színüzemmódú karakteres képen ...

sok szín lenne egyből, és a mozgó dolgok nem kéne háttért el/vissza mentsenek, hanem a sima törlés is elég volna ...

nem emlékszem mennyire villog a villogás már, meg tudnék -e szerezni lassú kioltású monitort, és hogy mennyivel jobb a színekkel villogás a pozícióban villogástól, és abban egész biztos vagyok, hogy régen nem próbáltam volna villogtatott képen csinálni semmit ...

de most nem régen van. És a lehetőségek így azért igencsak kitágulnának ...
Title: Re: Grafikai trükkök
Post by: endi on 2013.October.28. 17:13:10
ilyesmikről már sokat beszélgettünk itt...
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.October.28. 17:35:05
Quote
ilyesmikről már sokat beszélgettünk itt...

Az lehet, de az még a karakteres módos megvilágosodásom előtt volt. Most pedig már tudom, hogy miért cserébe lenne érdemes (esetleg) beáldozni a kép vibrálásmentességét ...

Egy 50 FPS sidescroller, ami még szép színes is ... ráadásul többé kevésbé 320 -as felbontásban ... nyami ...

Lehet ezért már érdemes lenne beáldozni egy kis vakulást ...
Title: Re: Grafikai trükkök
Post by: ergoGnomik on 2013.October.29. 18:21:01
Z80System! Küldtem neked PM-et, bár arról a témáról már elkanyarodott a beszélgetés.
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.October.29. 18:41:20
Quote
Z80System! Küldtem neked PM-et, bár arról a témáról már elkanyarodott a beszélgetés.

Igen, csak gondoltam, ha priviben küldted, akkor szíved csücske a téma, előbb át kell gondoljam rendesen, nem lehet csak úgy érzésből válaszolni, mert vagy nem értettem még meg amit mondani akarsz, vagy te nem érted meg amit én tolok.

De egyébként ilyeneket nem kell priviben küldjél, ez abszolúte a topik sztm. Nem ?

A video is valszeg érdekelhet sok embert.
Title: Re: Grafikai trükkök
Post by: ergoGnomik on 2013.October.29. 19:37:15
Quote
De egyébként ilyeneket nem kell priviben küldjél, ez abszolúte a topik sztm. Nem ?
Lehet, hogy a témába vág, de ha rajtad kívül valakit érdekelt volna, akkor kérdeznek mások is. Vagy magyaráznak. Például IstvanV. Miután nem vetett hullámokat a kérdés, gondoltam nem terhelem vele a topic-ot.

Quote
A video is valszeg érdekelhet sok embert.
Akkor itt van a link: Poem for bugs by LFT (http://www.youtube.com/watch?v=9ZNjB5jmHdE)
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.October.29. 20:00:07
Quote
gondoltam nem terhelem vele a topic-ot.
Hát lehet hogy csak én fejlődök lassan a "fórumozzunk okosan" kérdéskörökben, de a fórum sztm. azt szereti, ha terhelik.

Én legalábbis biztosan azt szeretem.

Ha minnél többen, minnél részletesebben fejtenek ki rajta bármit.

A fórum úgysem lesz, nem is lehet egy wiki oldal, épp azért, mert fórum.

Épp azért mert aki oda ír, az bötű szerint akarja látni ott az állítmányát az alanyokkal együtt.

A wiki -ket szerkesztik. Szépek lesznek, összefogottak, jól struktúráltak. A fórumok pedig szerkesztetlen hozzászólások gyülevészkedései.

És igen, egy olyan minimális szintig el lehet menni a rendezésében, hogy ha arról, amiről most írok egy kisebb szál kibontakozik, akkor azt át lehet metszeni a "fórumozzunk okosan" vagy az "általános csevej" rovatokba innen.

De ezzel szerintem vége. Az nem fórum, ha én a hozzászólásom előtt végig kell gondoljam, hogy a hsz -em most struktúrailag hova is illik be ... Ez most azért itt van, mert itt merült fel a dolog.

Ezzel én most terhelem a topikot ? Rosszul fórumozok ?

Pláne te, az állapotgép kérdéskörrel. Az állapotgép ugyan szintén nem grafikai trükk, és ha lesz alszál belőle, lehet csinálni neki állapotgép topikot.

De ez lenne a megoldás ? Örökké lattolgassam, hogy mi a privi téma, és mit tolhatok be oda, mégha már témaidegen is, de egyszer épp most oda kapcsolódik ?
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.October.29. 20:25:02
Quote
Akkor itt van a link: Poem for bugs by LFT (http://www.youtube.com/watch?v=9ZNjB5jmHdE)
(http://www.youtube.com/watch?v=9ZNjB5jmHdE)
11:23 -tól az is nézzen meg 10 másodpercet, akit nem érdekel ... :)
Title: Re: Grafikai trükkök
Post by: Zozosoft on 2013.October.29. 20:29:26
Quote from: Z80System
11:23 -tól az is nézzen meg 10 másodpercet, akit nem érdekel ... :)
:ds_icon_cheesygrin:
Title: Re: Grafikai trükkök
Post by: Zozosoft on 2013.October.29. 20:34:11
Quote from: ergoGnomik
 Vagy magyaráznak.
Vagy figyelnek :-)
Title: Re: Grafikai trükkök
Post by: lgb on 2013.October.29. 21:00:45
Quote from: Z80System
Persze az is lehet, hogy szerencsétlen EP -nek ez volt a legkisebb gondja ... hogy jujj, mi lesz akkor, ha programok százait vagy ezreit kell majd NTSC -síteni, az amerikai piacra ... úgy gondolt rá inkább, hogy "bárcsak ez lenne már az egyetlen problémám ..."

Igazabol ez pl PC-nel is igy van, ott sem szokas kozvetlenul a VGA mindenfele regisztereit irogatni (most foleg meg a DOS-os idoszakra es a sima - nem 3D gyorsitott genya-ize - videokartyakra gondolok), pedig azzal ott is lehet szinkron jelekbe beavatkozni stb. EP-n amugy is volt par hajmereszto dolog, amit egy cikkben is olvastam, ahol "az EP nem kompatibilis az EP-vel" es kb arrol volt szo, hogy egyesek olyan nagy ivben tettek a gep felepitesere, hogy azt hittek, egy gepen megtudvan a video memoria eppen aktualis cimet, az minden gepen tok ugyanott van, aztan ok voltak megsertodve, hogy nem :) Tehat, vagy kozvetlenul akarunk a hw-hez piszkalni, de akkor bizony elfogadjuk, hogy ennek lehetnek akar kompatibilitasi (akar jovobeli is, lasd NTSC verzio megjelenhetett volna szeles korben) problemakat, vagy inkabb ugymond az OS-re bizzak, es nem maguk akarjak az egesz LPT-t felepiteni legalabbis. Persze abban is vagyon igazsag, hogy az igazan "meresz" trukkok nyilvan igenylik a "meresz" huzasokat ...
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.October.29. 22:34:24
Quote
gondoltam nem terhelem vele a topic-ot.

Na, akkor visszahozom ide a témát, remélem nem bánod, ha mégis, akkor mondd, és többet ilyet nem csinálok.

Először is szétválasztandó a dolog az én érdeklődésem szerint 2 dologra.

Az egyik az állapotgépes kérdés, amilyen módszerrel te a példádat lehoztad a levélben, ez sztm. a kevésbé fontos része a dolognak, én pld. más változókkal oldom meg a dolgot, és ez a konkrét állapotokra bontás az eredeti problémámhoz nem szorosan kötődik, csak részlet.

A második rész az eredeti probléma, és abban valóban van változás.

Az eredeti probléma felvetésem az volt, hogy akkor írhatom be az új LPT címet (mikor már a rajzolásom kész van és) mikor nem vagyok pont abban a pillanatban mikor a NICK beolvassa a címet, viszont a cím beolvasása a NICK által, és ezáltal a tényleges képváltás majd csak ez után, az alsó borderem alatt, a teljes kép végekor fog megtörténni, ekkortól van átkapcsolva a nick az új LPT -re, és ekkor kezdhetem csak pusztítani az előző kép tartalmat.

Én a jelenlegi implementációm szerint "hibásan" működök, mert amikor a képrajzolásom készen van, akkor főprogramból direktben semmit nem nézve (tehát nem biztonságosan) bevágom a NICK -be a címet, aztán várok a megszakra. A NICK majd beolvassa a kép legalján a címet, mellesleg ugyanott generál egy megszakot is, ami szól a főprogramnak, hogy mehet tovább és bonthatja az eddig megjelenített képet.

A Zozo által javasolt módszer az, ha a videomegszakot az LPT reload mellé tesszuk, igy a programom kap információt arról, mikor már az LPT lecserélődött.
Igen ám, de ahhoz előtte be kell írjam, hogy lecserélődhessen, viszont arról meg nincs infó, hogy mikor írhatom be biztonságosan.
Tehát ha az LPT reload -ot és a megszakot ugyanoda teszem, akkor mire megjön a megszakom a képváltásról, addigra lekéstem a beírásról.

Eredeti véleményedben az állt, hogy a videómegszakot oda rakhatom, ahol csak az stabilan lehet LPT címet váltani, és abból írjak LPT címet.
Ez így nem igaz, mert a képernyő látható részéről is lehet LPT címet váltani biztonságosan, de az előző (kintlevő) képet még nem kezdhetem lebontani, mindaddig míg nem olvasta be a NICK a címet a kép alján.
A priviben a megszaknak azonban már ki volt jelölve a helye a látható kép és az alsó border határára. Így már valóban jó lehet, bár erre csak a privi olvasgatása közben jöttem rá. Hogy azért mégsem kell teljes egészében megvárni a beolvasást a kép végén, elég csak az alsó border tetejéig várni, és ha ide tesszük a megszakot, akkor két legyet üthetünk vele egy csapásra, mert itt egyrészt biztonságosan írhatjuk az LPT címet, másrészt ez jelzési pontnak is jó a kirajzolásnak, hogy ennél tovább már nem kell várnia, mert innentől a border van, vagyis a szinkron LPB -k, amiket ugysem módosítunk a kirajzolással.

Magyarul mikor készvagyok a képpel (éppúgy, ahogy eddig, és az most mindegy, hogy milyen állapotgéppel, vagy milyen biteken jelzem ezt melyik program szálnak), akkor az LPT címet nem szabad beírnom egyből, úgy ahogy most, hanem várnom kell időzítésre a video megszak formájában.

Ezt a video megszakot azonban nem rakhatom a reload mellé, hisz a megszak érkezésekor az új LPT címe még nem lesz beírva, leghamarabb a video megszak megérkezése pillanatában kerülhet az új LPT cím beírásra. Ha pedig a reload és a video megszak egy LPB -ben van, akkor ponthogy a reload után fog csak megérkezni a video megszak.

( Hacsak nincs erre valami okosság ... Zozo, ha egy LPB -ben van LPT reload és video megszak is, akkor melyik történik meg előbb, a video megszak, vagy hogy a NICK beolvassa a címet ? )

Na tehát ha nincs erre automatikus okosság akkor a megszakomat nem rakhatom a reload mellé közvetlenül, hanem valamennyivel korábbra kell tennem, mikor még a video megszak és az LPT reload között van időm időzítetten beírni az LPT címet. Én először tévesen azt gondoltam, hogy mivel a kintlévő kép bontásával úgyis várni kell a reload - ig, akkor max 1 pixelsorral lehet (érdemes) korábbra rakni a megszakot a reloadnál. Ez mindenképp hulyeség. Valójában a video megszakot az LPT végén lévő reload és az alsó border kezdete között (tehát a teljes alsó borderen belül) bárhova lehet rakni, hisz azon a teljes részen a látható képünk kirajzolása már befejeződött, és igaz lesz, hogy egy megszakkal mindkét legyet üthetjuk.
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.October.29. 22:51:30
A legeslegjobban az tetszene, ha Zozo azt mondaná végül, hogy ha egy LPB tartalmaz LPT reload -ot, meg tartalmaz video megszakot is, akkor először megérkezik már a z80 -hoz a video megszak, és csak UTÁNA fog valami legalább pár utasításnyi idővel a NICK által ujratöltödni az LPT cím.

Akkor ez a gondolatmenet továbbra is igaz és érdekes maradna számomra, DE minden maradhatna úgy ahogy eddig volt a programomban, tehát a reload és a megszak ugyanott maradhatna, csak a rajzolásom végeztével nem szabadna LPT címet írnom, hanem egyből el kellene kezdjek várni a megszakra, és csak a videomegszakom legelején, vagy a nagyon rövid video megszakom visszatérte után válthatnám az LPT címet.

Vagyis a módosítás csak annyi volna, hogy atrakom a tényleges LPT beváltást a megszak előttről a megszak utánra.

Ha Zozo viszont azt mondja, hogy nem a megszak jön meg előbb, akkor a megszakot is át kell helyezzem, az utolsó látható LPB -be (vagy bárhova az alsó borderen). És akkor mély szomorúság fog eltölteni ... :)
Title: Re: Grafikai trükkök
Post by: geco on 2013.October.29. 23:36:11
Miért ne adhatnál új címet az LPT-nek, amikor elkészült a rajzolásod?
Csak a törlés legyen a border elérése után.
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.October.29. 23:59:00
Hát mert a cím adása 2 lépésből áll. 0x82 és 0x83 hexa portot kell írni. Ebben a sorrendben. És ha video szinkronizálás nélkül írod ezeket egymás után, és minden összeesküszik ellened hiába is csinálod a Zozo féle gyors out szekvenciával, elméletileg akkor is lehet hogy pont, hogy akkor írod be az elsőt mikor a NICK kiolvassa MINDKETTŐT, és a 82 -ben már az új érték van, de a 83 -ban még a régi. Ekkor a NICK értelmetlen címet tölt újra, ahol elvben bármilyen hülyeség is lehet a memóriában, és széteshet a kijelzés, mely magától többé helyre nem áll.
Title: Re: Grafikai trükkök
Post by: geco on 2013.October.30. 00:14:18
A rajzolásod nem a reload előtt ér véget?
Sokkal egyszerűbb, ha csak az egyik portot írod, mondjuk csak a 82-est, akkor a két LPT-dnek 4k-s range-en belül kell lennie, ennyi a megkötés, vagy, ha egy LPB-ben van megoldva a játék képernyője, akkor elég csak a képernyőd címét változtatni az LPB+6-on
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.October.30. 00:31:50
Quote
A rajzolásod nem a reload előtt ér véget?


Elvben beszélünk, tetszőleges és változó idejű kirajzolást feltételezve. Mint pld. egy 3D render, ahol frame -ről frame -re változhat a kirajzolási idő attól függően, hogy hova nézel.



Quote
Sokkal egyszerűbb, ha csak az egyik portot írod, mondjuk csak a 82-est, akkor a két LPT-dnek 4k-s range-en belül kell lennie, ennyi a megkötés,



Egy 4K- ra align -olt 4K -s range -en belül, igen.


Megszívlelendő tanács, símán lehet, hogy alkalmazni fogom, de szintén nem képvisel elvi megoldást.



Quote
ha egy LPB-ben van megoldva a játék képernyője, akkor elég csak a képernyőd címét változtatni az LPB+6-on



Igen, de egy valamire való EP játék esetében ezt a luxust nem engedhetjük meg magunknak. Ha másért nem, akkor egy színátmenetért kell a soronkénti LPB felbontás.
Title: Re: Grafikai trükkök
Post by: geco on 2013.October.30. 00:42:02
Jaaa, én azt hittem, gyakorlati problémánál járunk :)
Jó, hát render se kell hozzá, bármilyen feltétel megváltozhat, hogy a rajzolási idő változzon, azt hittem, hogy 50 fps-nél járunk.
Hát igen, egy kis színátmenet sosem árt :D , amúgy még azon is gondolkoztam, hogy jól jöhet sebességnövelés érdekében is, pl egy 40 széles képernyőn minden sor kezdőcíme 80h-val eltolva az előzőhöz képest, igaz sosem használtam még, és eléggé pazarló.
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.October.30. 00:49:46
Quote
Jaaa, én azt hittem, gyakorlati problémánál járunk (http://enterpriseforever.com/Smileys/phpbb/smiley.gif)
Jó, hát render se kell hozzá, bármilyen feltétel megváltozhat, hogy a rajzolási idő változzon, azt hittem, hogy 50 fps-nél járunk.
50 FPS stuffokat írok, de valójában elvi ez a téma, az érdekel hogy lehet megkötések nélkül, 100% korrekten megcsinálni.

Illetve, ha belegondolunk ... akkor mégsem elvi. Ugyanis 50 FPS cuccnál nyilván nagyon be lesz cipőkanalzva minden a frame -be. Éppenséggel lehet hogy pont néha átcsúszik majd tizedpixelsort a frame -en ... és pont ez a határon lebegés a veszélyes ugye ...


Quote
Hát igen, egy kis színátmenet sosem árt (http://enterpriseforever.com/Smileys/phpbb/ds_icon_biggrin.gif) , amúgy még azon is gondolkoztam, hogy jól jöhet sebességnövelés érdekében is, pl egy 40 széles képernyőn minden sor kezdőcíme 80h-val eltolva az előzőhöz képest, igaz sosem használtam még, és eléggé pazarló.

Én amikor csak lehet ezt használom, csak éppen 100H -val, nem 80H -val. Igy ugye magasabb byte Y koordináta, alacsonyabb byte meg X. Automatikus a címszámítás per byte.

A közöket pedig jól ki lehet tölteni sprite adattal.
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.October.30. 00:53:37
Közben még egy kis adalék arra az esetre, ha Zozo majd azt mondja, hogy a címbeolvasás előbb van, mint a megszak:

Akkor ha így tároljuk le az LPT -t:

hasznos adat
vég szinkron
kezdő szinkron <- reload

akkor a két borderünk "egyben lesz", magyarul a reload elött a megszak jöhet a teljes (alsó/felső) border alatt, nem pedig csak az alsó alatt, ahogy a "hagyományos" LPT layout -nál.
Title: Re: Grafikai trükkök
Post by: geco on 2013.October.30. 00:58:29
Quote from: Z80System
50 FPS stuffokat írok, de valójában elvi ez a téma, az érdekel hogy lehet megkötések nélkül, 100% korrekten megcsinálni.
Illetve, ha belegondolunk ... akkor mégsem elvi. Ugyanis 50 FPS cuccnál nyilván nagyon be lesz cipőkanalzva minden a frame -be. Éppenséggel lehet hogy pont néha átcsúszik majd tizedpixelsort a frame -en ... és pont ez a határon lebegés a veszélyes ugye ...
Erre tényleg a legegyszerűbb megoldás, ha csak az egyik regisztert írod, vagy ott a Zozó által említett megoldás, amúgy az EP128emuban letesztelheted, hogyha a reloadot, a megszakítással egy lpb-be teszed, akkor mi történik hamarabb, és ha hamarabb jön a megszak, akkor van-e elég idő az LPT címének kiadására.
Quote
Én amikor csak lehet ezt használom, csak éppen 100H -val, nem 80H -val. Igy ugye magasabb byte Y koordináta, alacsonyabb byte meg X. Automatikus a címszámítás per pixel.
A közöket pedig jól ki lehet tölteni sprite adattal.
Hát igen, ettől gyorsabb nincs is :lol:
Title: Re: Grafikai trükkök
Post by: geco on 2013.October.30. 01:10:01
Quote from: Z80System
akkor a két borderünk "egyben lesz", magyarul a reload elött a megszak jöhet a teljes (alsó/felső) border alatt, nem pedig csak az alsó alatt, ahogy a "hagyományos" LPT layout -nál.
Úgy emlékszem, hogy amikor rátér a megszakítás bitet beállított LPB utáni LPB-re, akkor generálódik a megszakítás, ezért kell minden megszakítást tartalmazó LPB után egy megszakításmentes.
Title: Re: Grafikai trükkök
Post by: geco on 2013.October.30. 01:12:43
Leteszteltem, ha egy helyre teszed a reload-ot a megszakítással, akkor már megtörtént az LPT reload, amikor jön a megszakítás.
Mondjuk ez az előzőekből következik is, ezek szerint jól rémlett :lol:
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.October.30. 02:04:54
Quote

Quote
Leteszteltem, ha egy helyre teszed a reload-ot a megszakítással, akkor már megtörtént az LPT reload, amikor jön a megszakítás.

Hát azt nem tom hogy tesztelted le, azt meg pláne nem, hogy hihetünk -e vajon az emunak esetleg ilyen dolgok időzítése kapcsán is,

de ha így van, akkor most összetörted szívem ... (http://enterpriseforever.com/Smileys/phpbb/smiley.gif)

Bár végülis ha belegondolunk ... valami szinkron mindíg lesz ... tehát idő az mindíg lesz átírni az alsó(/felső) borderek alatt ... az meg hogy en a borderre is úgy gondolok, mint a "kép része mindaddig, amíg át nem váltódott az LPT a NICK betöltése által" az nem annyira számít ...

Csak nagyon szélsőséges esetben lenne értelme annak amit mondok, hogy a teljes LPT is az "aktuális képünknek" számítson, és igenis meg kell várni a tényleges teljes kirajzolást mielőtt bonthatjuk a képet, ez a szélsőséges eset pedig az, hogyha magát az LPT -t is "törölni", újragenerálni akarnám.

Tehát most akkor valóban megtehetjük, hogy a hasznos kép tartalmát már töröljük a border(ek) alatt,

de magát a képernyőn még aktuálisan látszódó LPT -t még nem kezdhetjük letörölni, és újragenerálni,
mert azt TÉNYLEGESEN csak akkor tehetjük meg, ahogy először gondoltam, vagyis a NICK LPT újratöltés után,
amiről viszont akkor most NINCS jelzésünk, hiszen a jelző megszak már elsült a border alatt, és felhasználtuk a cím beírására ...

Na az ilyen esetekhez viszont elvi megoldást most nem is látok ...

Ilyenkor 22 -es csapdája van. Ahhoz hogy átírhassam az LPT címet, ahhoz tudnom kell hogy biztonságos időpillanat van -e éppen. Ehhez más eszközöm nincs, csak hogy megszakítást kell kapjak. Ezért várok a megszakra, de a megszak már csak az UTÁN fog megérkezni hogy a NICK újratöltötte a RÉGI LPT címet, hisz nem írtam bele az újat, mert vártam a biztonságos pillanatra.
A megszak meg ugye a reload mellé van téve, mert a teljes LPT ki kell rajzolódjon, mielőtt újra lenne generálva.

Ezt az ellentmondást sikeresen feloldja a borderes módszer a korábbi esetben, ahol ezt alkalmazni lehet.

De ha jól gondoltam végig, akkor ezt a problémát ebben a TELJESEN ÁLTALÁNOS / LPT ÚJRAGENERÁLÓS esetben feloldani nem lehet. Tehát van egy csomó kerülő megoldásunk, amik közül választanunk lehet és/vagy kell, de NINCS teljesen általános módszer. Trükközni, hekkelni, kompromisszumokat kötni kell ahhoz, hogy biztosak lehessünk abban, hogy a NICK egyszer csak nem fog elszállni az egyébként teljesen korrekt programunk mellett ...

( Tényleg ilyen nehéz lehetett volna megoldani, hogy éppúgy mint a forced reload -ot, jelezni tudjam a NICK -nek, hogy én most mindkét portot érintő címmódosítást hajtok végre ? )

Sztm. ez durva ... (Ha jól látom át. Ilyenkor szokott jönni valaki, és egy 117. eddig a gondolkodásba be nem vont körülménnyel értelmét veszi a problémának. :))
Title: Re: Grafikai trükkök
Post by: geco on 2013.October.30. 09:46:42
Én hiszek az emunak, eddig 1 buggal találkoztunk benne, az out (c),0 utasításnál, vagyis az se volt bug, az egyik gyártó processzora ennél az utasításnál 0-t írt a portra (ez volt az emuban is), a másik gyártóé meg ffh-t
Űgy teszteltem le, hogy betettem az EXOS LPT végére az interrupt bitet, és a programom egy önmagára ugró jr volt, így nem kavart be DI, betettem egy breakpointot 0038h-ra, és megnéztem, hogy amikor breakel a futás, hol jár az LPB olvasásnál a debuggerben. Mindig a következő az EXOS LPT első LPB-jén járt.
Akkor biztosra mehetsz a portok írásával, ha a reload bitet tartalmazó LPB elé teszed 2 LPB-vel a megszakítást, így pont a kettő közötti LPB-ben lesz megszakításod, és a megszakítás elejére teszed az LPT címkiadást, mindezt úgy, hogy a főkódodban nem használsz DI-t.
Title: Re: Grafikai trükkök
Post by: ergoGnomik on 2013.October.30. 09:53:09
Quote from: Z80System
Eredeti véleményedben az állt, hogy a videómegszakot oda rakhatom, ahol csak az stabilan lehet LPT címet váltani, és abból írjak LPT címet.
Ez így nem igaz, mert a képernyő látható részéről is lehet LPT címet váltani biztonságosan, de az előző (kintlevő) képet még nem kezdhetem lebontani, mindaddig míg nem olvasta be a NICK a címet a kép alján.
A priviben a megszaknak azonban már ki volt jelölve a helye a látható kép és az alsó border határára. Így már valóban jó lehet, bár erre csak a privi olvasgatása közben jöttem rá. Hogy azért mégsem kell teljes egészében megvárni a beolvasást a kép végén, elég csak az alsó border tetejéig várni, és ha ide tesszük a megszakot, akkor két legyet üthetünk vele egy csapásra, mert itt egyrészt biztonságosan írhatjuk az LPT címet, másrészt ez jelzési pontnak is jó a kirajzolásnak, hogy ennél tovább már nem kell várnia, mert innentől a border van, vagyis a szinkron LPB -k, amiket ugysem módosítunk a kirajzolással.

Magyarul mikor készvagyok a képpel (éppúgy, ahogy eddig, és az most mindegy, hogy milyen állapotgéppel, vagy milyen biteken jelzem ezt melyik program szálnak), akkor az LPT címet nem szabad beírnom egyből, úgy ahogy most, hanem várnom kell időzítésre a video megszak formájában.
Továbbra is tartom azt a véleményemet, hogy oda rakod a VINT-et, ahová akarod. Természetesen az akarásba beleértettem azt is, hogy azért van némi fogalmad arról, hogy minimum/maximum mennyi időt vesz igénybe a képgenerálásod, illetőleg az lineárisan fentről lefelé vagy össze-vissza történik. Ha tudod, hogy a tartalom újraírása soha nem fogja beelőzni a tényleges Nick által végzett képgenerálást, akkor megteheted azt, hogy a látható területre időzíted a szinkronizáló mechanizmusodat.

Amit a PM-ben írtam - bár tettem bele felkiáltójeleket - az nem kötelező jellegű utasítás, hanem egyszerűen a példa része a magyar nyelvtan szabályai szerint ("Legyen" kezdetű mondat az felszólítás, így a végére kell a "!".) leírva. Bár most elbizonytalanítottál a helyességét illetően. (Lehet, hogy egyszer erre jár majd egy nyelvtan náci és jól kijavít. :)) Amit írtam, az csak a klasszikus változat volt. Az egész lényege a helyes szinkronizáció. Az állapotgép pedig csak egy eszköz.
Title: Re: Grafikai trükkök
Post by: IstvanV on 2013.October.30. 10:27:11
Valószínűleg lemaradtam valamiről, de miért kell a programban a képernyő puffereket feltétlenül az LPT címének az átírásával váltani ? :oops: Általában elég csak a video (LD1/LD2) cím(ek)et módosítani az LPT-ben. De ha problémát jelent, hogy esetleg pont az LPT cím átírása (ha elkerülhetetlen) közben történik egy RELOAD, akkor az is megoldás lehet, ha mindkét LPT 4096-al osztható címen kezdődik, így csak a 83h port értéke változik.Vagy rövid LPT esetén mindkettő kezdődhet ugyanabban a 4K-s blokkban, és akkor csak a 82h porton módosul a cím.

A video megszakítás egyébként a VINT lefutó élénél történik, tehát valóban csak a következő LPB elején.
Title: Re: Grafikai trükkök
Post by: Zozosoft on 2013.October.30. 10:35:59
Quote from: IstvanV
A video megszakítás egyébként a VINT lefutó élénél történik, tehát valóban csak a következő LPB elején.
Akkor ha az utolsó kijelzendő LPB-re tesszük a VINT-et, akkor jön a megszakítás amikor már utána bordert kezdi kirajzolni, és a border/üres sorok/szinkron alatt bőven van idő beírni az új címet, jól gondolom?
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.October.30. 10:54:36
Quote
Valószínűleg lemaradtam valamiről, de miért kell a programban a képernyő puffereket feltétlenül az LPT címének az átírásával váltani ? (http://enterpriseforever.com/Smileys/phpbb/ds_icon_redface.gif) Általában elég csak a video (LD1/LD2) cím(ek)et módosítani az LPT-ben.


Igen, általában elég, de ha pld. pixelenkénti LPT -nk van, akkor elég tetemes idő -be telik az összes pixelsor memóriacímének átírása. 50 FPS játéknál nem pocsékolnám azt el, az idő alatt ki lehet tenni 2 sprite -ot, ha egyszer van rá mód, hogy előre legyen generálva a 2 LPT és azokat váltogassam. Azon kívül gondolkodom olyan cuccba is, ami 2 egész különböző módú LPT -ket villogtat, pld. karakteres/pixel mód, soronkénti más palettával ... szóval kell az LPT anim.


Quote
De ha problémát jelent, hogy esetleg pont az LPT cím átírása (ha elkerülhetetlen) közben történik egy RELOAD, akkor az is megoldás lehet, ha mindkét LPT 4096-al osztható címen kezdődik, így csak a 83h port értéke változik.Vagy rövid LPT esetén mindkettő kezdődhet ugyanabban a 4K-s blokkban, és akkor csak a 82h porton módosul a cím.
Igen már többször elhangzott az elmúlt hsz -ek alatt, ami egy ígéretes jó trükk, de TRÜKK. Mi van ha az amber egy sok darab, csak sok idő alatt előállítható, ezért legenerált LPT -ből akar kódból változó sorrendű LPT -ket animálni, és ezek az LPT -k nem férnek el 1000H -n ?

Jó trükk, de csak trükk. Én arról beszélek itt, hogy ELVI gebasz van. 22 -es csapdája.

Ha tudod, olvasd vissza a szálat innentől:

(http://enterpriseforever.com/Themes/EP4Ever/images/post/xx.gif)

Re: Grafikai trükkök (http://enterpriseforever.com/programozas/grafikai-trukkok/msg35324/#msg35324)« Reply #306 on: Yesterday at 22:34 »

 mert nagyon kiváncsi lennék, hogy tényleg elvi -e a gebasz, vagy van valami kibújás alóla.
Title: Re: Grafikai trükkök
Post by: IstvanV on 2013.October.30. 10:56:56
Quote from: Zozosoft
Akkor ha az utolsó kijelzendő LPB-re tesszük a VINT-et, akkor jön a megszakítás amikor már utána bordert kezdi kirajzolni, és a border/üres sorok/szinkron alatt bőven van idő beírni az új címet, jól gondolom?
Igen.
Title: Re: Grafikai trükkök
Post by: IstvanV on 2013.October.30. 11:01:18
Quote from: Z80System
Igen már többször elhangzott az elmúlt hsz -ek alatt, ami egy ígéretes jó trükk, de TRÜKK. Mi van ha az amber egy sok darab, csak sok idő alatt előállítható, ezért legenerált LPT -ből akar kódból változó sorrendű LPT -ket animálni, és ezek az LPT -k nem férnek el 1000H -n ?

Jó trükk, de csak trükk. Én arról beszélek itt, hogy ELVI gebasz van. 22 -es csapdája.
A trükkök használata nem szokatlan 8 bites gépeken, így például C64-en sem. :) Tehát ha más megoldás nem működik megbízhatóan, akkor esetleg marad az 1000h határra igazítás.
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.October.30. 11:07:44
Quote
Továbbra is tartom azt a véleményemet, hogy oda rakod a VINT-et, ahová akarod. Természetesen az akarásba beleértettem azt is, hogy azért van némi fogalmad arról, hogy minimum/maximum mennyi időt vesz igénybe a képgenerálásod, illetőleg az lineárisan fentről lefelé vagy össze-vissza történik. Ha tudod, hogy a tartalom újraírása soha nem fogja beelőzni a tényleges Nick által végzett képgenerálást, akkor megteheted azt, hogy a látható területre időzíted a szinkronizáló mechanizmusodat.
Igen, ez egy újabb módosítás, ahhoz képest mindenképp, ahogy én gondolkodok a dologról,

viszont míg a borderes dologra még boldogan rábólintok, mert nem tudok jobbat,

addig ezt már határozottan vissza kell utasítsam, biztos vannak olyan feladatok, amiknek a kirajzolásánál ilyeneket figyelembe lehetne venni,

de egy sprite -os grafikánál, vagy egy csillagmozgásnál felülről lefele rendezni a grafikát, és mindíg a videó sugár mögött tartani magam minden sugár pozíció kiolvasási lehetőség nélkül sztm túl sokat lassítana, ez maximum valami komondoros raszter trükknél, vagy ilyesminél lehetne sztm. gazdaságosan alkalmazható.

Azon kívül vegyük észre hogy mind a borderes módszer is (csak az még kevésbé), de ez a "sugárral szinkronizálom magam" módszer pláne, PONT AZ ELLENTÉTE a backbuffer lényegének.

A doublebuffer pont azért lenne, hogy 100% -ban független lehessek a sugártól, egyedül a képváltás van szinkronizálva (elvileg a függöleges visszafutásra, EP- n egy jelentéktelennek tűnő dolog miatt úgy tűnik csak a borderre), és a rajzolás pedig innentől kezdve teljesen szabad a backbufferen, ahogy a legszebbet a leggyorsabban ki tudjuk rajzolni.

Ha én tudom magam a sugárhoz szinkronizálni, akkor rajzolhatok mindent úgy, hogy szinkronizálva vagyok a sugárhoz, és kész, nem kell semilyen doublebuffer.

De mi nem akarunk ilyennel bíbelődni, ezért doublebuffert használunk, csak nem tudjuk a doublebuffert biztonságosan váltani, ezért elkezdünk szinkronizálni a sugárhoz ? Sztm ez értelmetlen. Újabb manifesztálódása csak a 22 -es csapdája problémának.
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.October.30. 11:42:46
A probléma általános feloldása sztm. a 2 darab video megszakítás használata. Ez igényli a legkevesebb hekket szerintem, legáltalánosabban kezelhető vele akárhány LPT.

A hátránya, hogy egy icipicit (egy rasztersort) ellop az időből.

Úgy működne, hogy az egyik megszakítás az a reload előtti pixelsorban van (tehát kell hozzá a szinkron bontás, ami Zozo szerint megy), a második megszak pedig a reload mellett az utolsó pixelsorban.

Az első megszakítás nem csinálna semmit, csak beírná (a rendelkezésre állo egy pixelsprnyi idő alatt) az LPT címet. Ettől még nem kezdődne el a következő kirajzolási kör, továbbra is várna a game loop.

Majd a következő megszakítás már ugye akkor kezdődne, mikor az előbb beírt című LPT már be lett olvasva a NICK által, mivel az a reload mellett volt. Na ekkor már kezdődhetne az új kirajzolás, és akár az előbbi LPT -t is lehet írni, újragenerálni, hisz már betöltődött az új.

Tehát egy rasztersor lecsípésével meg lehet oldani a dolgot általánosan, ha nem is elvben.

A két megszakítás megkülönböztetésére meg sztm. simán jó lehetne egy olyan módszer, hogy letiltott megszakkal reszetelünk egy flag -et, mivel tiltottak a megszakok, nem érdekel bennünket ha az éppen aktuális LPT -ben van video megszak, beváltjuk az új LPT -nket forszoltan, onnantól az fog futni, és mivel az LPT -nknek csak a végén lesznek a megszakok, ezért van időnk engedélyezni a megszakokat, és azután csak minden megszakban invertáljuk a flag -et. És ekkor sztm. a flag mutatni fogja melyik megszakunk jött meg éppen.
Title: Re: Grafikai trükkök
Post by: endi on 2013.October.30. 11:49:24
Egy kérdés, lehet, hogy a témához semmi köze: vannak olyan lpt animok amik z80-tól függetlenül is működnek, tehát pl. a Scroll demó töltője, NasaGuy demók stb. Ezek hogy is működtek? Képernyő magasságánál*frame magasságú lpt volt csinálva? Asszem így.
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.October.30. 11:52:00
Quote
Egy kérdés, lehet, hogy a témához semmi köze: vannak olyan lpt animok amik z80-tól függetlenül is működnek, tehát pl. a Scroll demó töltője, NasaGuy demók stb. Ezek hogy is működtek? Képernyő magasságánál*frame magasságú lpt volt csinálva? Asszem így.

Ja. Símán csak egymás után teszed a memóriában az LPT -ket, mintha normál LPT -k lennének, és a reload flag -et csak a legutolsó végére teszed be.
Title: Re: Grafikai trükkök
Post by: endi on 2013.October.30. 12:13:53
Quote from: Z80System
Ja. Símán csak egymás után teszed a memóriában az LPT -ket, mintha normál LPT -k lennének, és a reload flag -et csak a legutolsó végére teszed be.
csináld te is ezt :)
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.October.30. 12:18:41
Quote
csináld te is ezt (http://enterpriseforever.com/Smileys/phpbb/smiley.gif)
Az én szempontomból nézve ez megint csak egy százhuszonnyolcadik trükk. Ennek is túl nagy kötöttsége van, fixen az a szekvencia van, amit letároltál.

Én meg azt akarom, hogy cpu -val váthassam akármelyik frame -be, akaármelyik LPT -t, kódtól függő logikával.
Title: Re: Grafikai trükkök
Post by: endi on 2013.October.30. 12:30:28
Quote from: Z80System
Az én szempontomból nézve ez megint csak egy százhuszonnyolcadik trükk. Ennek is túl nagy kötöttsége van, fixen az a szekvencia van, amit letároltál.

Én meg azt akarom, hogy cpu -val váthassam akármelyik frame -be, akaármelyik LPT -t, kódtól függő logikával.
na de úgyis fix 50fps-t akarsz, tehát a logika miért szól itt bele?
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.October.30. 12:46:55
Quote
na de úgyis fix 50fps-t akarsz, tehát a logika miért szól itt bele?

Az 50 FPS -valóban jó lenne mindaddig, míg annyira ki nem cipőkanalazom, hogy néha mégis átbukik a frame határon, és akkor onnantól csúnya villogás lenne, míg nem bukik megint egyet.

De ez a szál most nem a gyakorlati problémák kezelésére való, hanem elvben gondolkodik.

- mivel a kódomban Zozo féle gyors port írás van, ez kb. eliminálja a problémát, gyakorlatban többet vacakolni vele felesleges
- mivel összesen 2 sor megváltozatásával meg tudom csinálni a stabil borderes működést, ezért az jobb, mint egy statikus NICK animhoz kötődni
- mivel csak 2 LPT -t váltogatok, amik elférnek 1000H -n, és történetesen c000H -án vannak, ezért az egy port írás hack is teljesen 100% megoldást jelentene

De ez mind smafu. Én ELVI MEGOLDÁS -ban gondokodok. De legalábbis egy teljesen általános megoldásban, ha elvit nem is sikerül.

Egy olyan stuffot feltételezek, aminek a kirajzolása minden körben szélsőséges értékek között változhat, mondjuk 0 és 10 frame között, amire ráadásul egy olyan double bufferes LPT váltogatást akarok ráhúzni, mi kódból változó sorrendű és nem fér el 1000H -n. Ilyen lehetne pld. egy 3D vektoros demó, amin komplex LPT effektek vannak. Mily fura, ismerek olyan embert, aki két játékdemó között ilyenben gondolkodik.

Egy tiszta, ideális PC -szerű double buffer működésen gondolkodok, mert ha másról nem is, de erről azt hittem, hogy ez az EP nagy erőssége, hiszen minden máshoz képest ő még baszikból is képes képernyőt vágni ... Meg videólapokat animálni ... amit aztán rajta kívül nemtudom még ki tud ... (Tán az Amiga tud ilyeneket még OS -ből, de az nagyon unfair volna, ha a 16 bites amígóhoz mércéznénk.)

És akkor a tüzetes vizsgálódásból az derül ki, hogy az ELVI, IDEÁLIS double buffert, ha ki akarom terjeszteni a buffer fogalmát az LPT tulajdonságokra is, na azt azért mégsem tudja ...
Title: Re: Grafikai trükkök
Post by: ergoGnomik on 2013.October.30. 12:52:19
Quote from: Z80System
Igen, ez egy újabb módosítás, ahhoz képest mindenképp, ahogy én gondolkodok a dologról,

viszont míg a borderes dologra még boldogan rábólintok, mert nem tudok jobbat,

addig ezt már határozottan vissza kell utasítsam, biztos vannak olyan feladatok, amiknek a kirajzolásánál ilyeneket figyelembe lehetne venni,

de egy sprite -os grafikánál, vagy egy csillagmozgásnál felülről lefele rendezni a grafikát, és mindíg a videó sugár mögött tartani magam minden sugár pozíció kiolvasási lehetőség nélkül sztm túl sokat lassítana, ez maximum valami komondoros raszter trükknél, vagy ilyesminél lehetne sztm. gazdaságosan alkalmazható.

Azon kívül vegyük észre hogy mind a borderes módszer is (csak az még kevésbé), de ez a "sugárral szinkronizálom magam" módszer pláne, PONT AZ ELLENTÉTE a backbuffer lényegének.

A doublebuffer pont azért lenne, hogy 100% -ban független lehessek a sugártól, egyedül a képváltás van szinkronizálva (elvileg a függöleges visszafutásra, EP- n egy jelentéktelennek tűnő dolog miatt úgy tűnik csak a borderre), és a rajzolás pedig innentől kezdve teljesen szabad a backbufferen, ahogy a legszebbet a leggyorsabban ki tudjuk rajzolni.

Ha én tudom magam a sugárhoz szinkronizálni, akkor rajzolhatok mindent úgy, hogy szinkronizálva vagyok a sugárhoz, és kész, nem kell semilyen doublebuffer.

De mi nem akarunk ilyennel bíbelődni, ezért doublebuffert használunk, csak nem tudjuk a doublebuffert biztonságosan váltani, ezért elkezdünk szinkronizálni a sugárhoz ? Sztm ez értelmetlen. Újabb manifesztálódása csak a 22 -es csapdája problémának.
Nézd, az én szempontomból mindegy hogy a tanácsot amit próbálok adni miközben együtt gondolkodok veled, azt elfogadod, vagy valamilyen szép elvi megfontolásból határozottan elutasítod. Nem tud egyikőnk se kötelezni arra, hogy amit mondunk ahhoz betű szerint ragaszkodj, és nem is akarunk. Én csak felhívtam a figyelmedet arra, hogy amennyiben jól kézben tartod az erőforrás használatodat, akkor a tankönyvi double buffering megvalósításhoz képest esetleg lehet egy kis teljesítményt nyerni. Ha erre nincs szükséged vagy lehetőséged, akkor nem használod. Ez az "Az elfajult dupla pufferelés monnyon le!" teljesen értelmetlen. Te írod a programodat, pontosan olyanra amilyennek szeretnéd.

Egyébként - ha van erre lehetőség - mondd már el légy szíves, hogy mit értesz a double buffer biztonságos váltásán és az hogyan valósul meg a sugárhoz szinkronizálás nélkül?
Title: Re: Grafikai trükkök
Post by: endi on 2013.October.30. 12:56:07
ergoGnomik,
akar egy x Hz-s hangot is, lehet hogy az adja a bizonytalanságot
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.October.30. 13:14:55
Quote
Egyébként - ha van erre lehetőség - mondd már el légy szíves, hogy mit értesz a double buffer biztonságos váltásán és az hogyan valósul meg a sugárhoz szinkronizálás nélkül?

Hát nem tudom, hogy ezt a témát hogy tudnám még ennél is jobban kirészletezni ...

Ezt írtam:

"A doublebuffer pont azért lenne, hogy 100% -ban független lehessek a sugártól, egyedül a képváltás van szinkronizálva (elvileg a függöleges visszafutásra, EP- n egy jelentéktelenne"

Mikor azt írtam, hogy "független a sugártól" akkor a rajzolókódra gondoltam, nem a váltásra. Ezt erősíti, hogy utána ezzel folytatom, hogy "egyedül a képváltás van szinkronizálva (elvileg a függöleges visszafutásra, EP- n egy jelentéktelennek ..."

Tehát a kép váltása igenis szinkronizálva van a függőleges visszafutáshoz, de ez az egyetlen dolog ami szinkronizálva van, ezen kívül az összes backbuffer műveletem szabad sorrendben és időzítésben történhet.

Ezt az ep a NICK reload -dal el is tudja mellesleg végezni, csak éppen amit betölt annak MEGADÁSÁHOZ is szinkronizálnom kell, és ez hazavágja az elvi szép megoldást, mindenféle trükkök bevetését igényli.
Title: Re: Grafikai trükkök
Post by: Zozosoft on 2013.October.30. 13:19:47
Én csak azt nem értem hogy miért okoz neked lelki traumát hogy a border kezdetére tedd a váltást kiváltó VNT-et, amikor az pont erre van kitalálva? :oops:
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.October.30. 13:26:21
Quote
Én csak azt nem értem hogy miért okoz neked lelki traumát hogy a border kezdetére tedd a váltást kiváltó VNT-et, amikor az pont erre van kitalálva? (http://enterpriseforever.com/Smileys/phpbb/ds_icon_redface.gif)

Márpedig te állítólag mindent elolvasol, tehát érthetnéd a traumám okát, mert már írtam:

Azért, mert ha ott van a megszak, akkor a megszak érkezésekor ugyan beírhatom az LPT címet, és a hasznos területet, pld. képernyőbuffert már generálhatom is újra, de MAGÁT az LPT -t még nem, mert az még kijelzés alatt lesz a frame végéig. És mi van ha ez én programom az LPT -t is újra akarja generálni ? Mert a programom "backbuffer" fogalmába beletartoznak az LPT tulajdonságok is. Azt éppúgy újra akarja generálni, mint a pixel adatokat.

Akkor az van, hogy ELVI problémával állunk szembe. A legszebb, legáltalánosabb megoldás a -1 pixelsor -os 2 megszakos verzió, de még az sem elvi. Csak általános.
Title: Re: Grafikai trükkök
Post by: ergoGnomik on 2013.October.30. 13:39:43
Quote from: Z80System
Márpedig te állítólag mindent elolvasol, tehát érthetnéd a traumám okát, mert már írtam:

Azért, mert ha ott van a megszak, akkor a megszak érkezésekor ugyan beírhatom az LPT címet, és a hasznos területet, pld. képernyőbuffert már generálhatom is újra, de MAGÁT az LPT -t még nem, mert az még kijelzés alatt lesz a frame végéig. És mi van ha ez én programom az LPT -t is újra akarja generálni ? Mert a programom "backbuffer" fogalmába beletartoznak az LPT tulajdonságok is. Azt éppúgy újra akarja generálni, mint a pixel adatokat.

Akkor az van, hogy ELVI problémával állunk szembe. A legszebb, legáltalánosabb megoldás a -1 pixelsor -os 2 megszakos verzió, de még az sem elvi. Csak általános.
Ha az LPT-d állandó méretű, akkor amint a keretre érsz nyugodtan átírhatod azt a részt ami a megjelenítést végzi, mert azt a Nick már nem olvassa. Ha változó méretű az LPT-d, akkor meg lehet triple buffering-et használni. Akár csak külön a sorparaméter táblára.

Te elveket akarsz fejleszteni, vagy hatékonyan futó programot, amihez nem kell csillió megahertzes erőmű, elég az EP is?

Félre ne értsd, nem az elvekkel van a bajom, hanem azzal hogy keseregsz nincs elég jó program, nekilátsz lelkiismeretes kutató munkát végezni a felhasználandó technikákról, majd elvi megfontolások alapján ezeket elutasítod. Így hogyan készül el majd az a jó program?
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.October.30. 13:49:21
Quote
Ha az LPT-d állandó méretű, akkor amint a keretre érsz nyugodtan átírhatod azt a részt ami a megjelenítést végzi, mert azt a Nick már nem olvassa.
Igaz, de csak hekk. Te magad is folytattad a nem hekk verzióval.


Quote
Ha változó méretű az LPT-d, akkor meg lehet triple buffering-et használni. Akár csak külön a sorparaméter táblára.

Na hasonló nekem is felrémlett, de ezt a triple buffering -et még PC vonatkozásában sem sikerült logikailag összerakjam eddig, hogy mi a mákér jó, mégis valahogy felderengett nekem is itt a mostani gondolkozások közepedte, de nem értem a végére.

Úgyhogy ezen elgondolkozok akkor ... lehet -e LPT triplabuffer elvi megoldas ide ...


Quote
Te elveket akarsz fejleszteni, vagy hatékonyan futó programot, amihez nem kell csillió megahertzes erőmű, elég az EP is?

Amíg nem lassítanak, addig elveket akarok. Minnél kevesebb szabályból álló, minnél merőlegesebb szabályrendszert, ahol a legnagyobb a szabadság. Nem vagyok zseni típus, nem szeretek sok komplex szabálynak engedelmeskedve dolgozni. Akkor haladok csak a komplexitás fele, ha muszaly.

Tehát nem lassító, villámgyors elveket akarok. És ha beláttam, hogy ilyen nincs, akkor menni csak a bonyiba, lecsóba.

És ha valamiről, akkor erről a kép váltogatásról azt hittem, hogy na ezt aztán CSONTRA tudja az EP.

Na de most akkor új remény csillant ... a tripla LPT buffer ... csak meg kéne értsem.
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.October.30. 14:55:21
Quote
Na de most akkor új remény csillant ... a tripla LPT buffer ... csak meg kéne értsem.
Hopp, ugyan a tripla bufferes működés átgondolásába még nem fogtam bele, de közben bekattant, hogy mitől nem jó semmiképp, még ha egyébként pedig elvi megoldás is lenne.

Hát ha teljes három készletről beszélünk, akkor képernyő pufferekből is három kellene, ami túl nagy áldozat már az én súlyozásomban.

Ha meg csak az LPT tripla, ahogy az imént ráharaptam, akkor meg mivel csak 2 képernyőpufferünk van, akkor az LPT -ben a címeket frissíteni kell. Ami egy soronkénti LPT esetén olyan sok idő, hogy szintén nem tekintem elvi megoldásnak, egy 20 rasztersor árán megvalósított buffer váltás szerintem szintén túl nagy áldozat ...

Vagyis tripla buffer is lehúzva ... :(

Nincs elvi megoldás ... továbbra sem.
Title: Re: Grafikai trükkök
Post by: Zozosoft on 2013.October.30. 15:04:17
Quote from: Z80System
 akkor az LPT -ben a címeket frissíteni kell.
Na de pont onnan indultunk, hogy mi van ha az LPT-t is újra akarod generálni.
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.October.30. 15:09:08
Quote
Na de pont onnan indultunk, hogy mi van ha az LPT-t is újra akarod generálni.
Na, látom te legalább figyelsz ! :)

Már az előző hsz -emen gondolkodtam, hogy kijavítom precízebbre, de gondoltam, hogy "á, úgyse veszik észre ...", de látom azért nincs ennyire könnyű dolgom ... :)

Oks, akkor tovább részletezem:

Olyan pixelsoros, nagy és sok, nem újragenerált LPT -t akarok változó sorrendben kód logika szerint animálni,

amikben viszont a szinkronjaikban (az alsó felső borderen) valós idejű változtatásokkal akarok operálni. Szinkron trükkökkel.

És akkor máris visszakanyarodtunk az elvi probémához ... :)
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.October.30. 15:42:38
Hát demóban nyilván rengeteg helyen van, én a Sorcery -t vádoltam meg 50 FPS -ességgel, de valaki azt is csak 25 -nek véleményezte ...

Mindenesetre az elég jó reszponzív ... Én majd akkor hiszem, hogy nem 50 FPS, ha látom vason.
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.October.30. 15:44:59
Quote
milyen jó hogy senki se akart csúcs giga c64 szintű 50(000000) fps-es programokat EP-re csinálni, mert akkor soha egyetlen game vagy demó se született volna
(http://enterpriseforever.com/Smileys/phpbb/ds_icon_twisted.gif)
Egyébként itt most ponthogy NEM az 50 FPS cuccokról folyik a traccs ...
Title: Re: Grafikai trükkök
Post by: IstvanV on 2013.October.30. 18:29:27
Quote from: Z80System
Hát demóban nyilván rengeteg helyen van, én a Sorcery -t vádoltam meg 50 FPS -ességgel, de valaki azt is csak 25 -nek véleményezte ...
Ha jól emlékszem, a Sorcery valójában 37.5 fps sebességű. Egy képkocka időtartama ugyanis 8 CPC (300 Hz-es) video megszakítás.
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.October.30. 18:31:57
Quote
Ha jól emlékszem, a Sorcery valójában 37.5 fps sebességű. Egy képkocka időtartama ugyanis 8 CPC (300 Hz-es) video megszakítás.

És olyan hogy lehetséges ? Nincs vsync, és néha tearing van és/vagy villódzás, csak nem zavaró ?
Title: Re: Grafikai trükkök
Post by: IstvanV on 2013.October.30. 18:36:01
Quote from: Z80System
néha tearing van és/vagy villódzás ?
Igen. Az, hogy a képernyőn hol, az 3 képes ciklusban változik. Az Entersoft féle átiratban lehet, hogy nem így van, de az eredeti CPC verzióban és az én átiratomban igen.
Title: Re: Grafikai trükkök
Post by: Z80System on 2013.October.30. 18:40:15
Quote
Igen. Az, hogy a képernyőn hol, az 3 képes ciklusban változik. Az Entersoft féle átiratban lehet, hogy nem így van, de az eredeti CPC verzióban és az én átiratomban igen.
Hát ez remeg ... tolom itt a nagy perfekcionizmust, oszt kiderül, hogy bármit bárhogy kilökünk a képre, oszt úgy is jó ...

Vagy van benne valami trükközés, meg logika, amitől csökkennek a hibák ?

Vagy egyszerűen így is jó, és kész ?
Title: Re: Grafikai trükkök
Post by: endi on 2013.November.01. 15:33:42
hoppá mit vettem észre!!! és nem is értem
van ez a demóm, amiben biast állítottam soronként többször, lásd mellékelt snapshot
na most ez eddig tuti nem volt jó az emuban. legalábbis amikor régebben néztem (jópár éve). ezek szerint azóta új emu verzió volt?
mert most jó :)
sőt, kicsit villog is, mint igazi gépen :)

a trükk lényege hogy a hátsó 8 szín van kirajzolva és egy sorban 8x(?) van váltva a bias
előtte pedig a paletta színekkel a logó
így egy sorban jó sok szín van (scrollban írom is mennyi de má nem emlékszek)
Title: Re: Grafikai trükkök
Post by: IstvanV on 2013.November.01. 19:21:58
Quote from: endi
hoppá mit vettem észre!!! és nem is értem
van ez a demóm, amiben biast állítottam soronként többször, lásd mellékelt snapshot
na most ez eddig tuti nem volt jó az emuban. legalábbis amikor régebben néztem (jópár éve). ezek szerint azóta új emu verzió volt?
Minden 2.x verzió támogatja a soron belül változó BIAS-t, de az időzítés nem egészen pontos (a CPC és ZX emuláció valójában pontosabb, mint az EP, de az EP-s programok 99.9 százalékánál ez nem probléma).

Soron belül változó BIAS témában talán említést érdemel ez a rövid "demo" (http://enterpriseforever.com/hardver/nick/msg34003/#msg34003), amely a BIAS regiszter pontosan időzített írásával scrolloz a képernyőn. Emulátoron csak némi Lua trükközéssel működik elfogadhatóan.
Title: Re: Grafikai trükkök
Post by: endi on 2013.November.01. 19:26:46
Amúgy ez eredeti gépen se volt mindenhol ugyanolyan. Úgy értem volt gép amin nem csúszkált, volt amin igen.
Sőt a scrollba azt írtam hogy ha bemelegszik a gép akkor csúszkál???  :)
Title: Re: Grafikai trükkök
Post by: Zozosoft on 2013.November.01. 19:34:13
Quote from: endi
Úgy értem volt gép amin nem csúszkált, volt amin igen.
Nick órajel némileg állítható (power LED mellett van egy tekerentyű), gépek közt van szórás, és bemelegedés után áll be stabilra.
Volt olyan gépem, ami amíg be nem melegedett, színuszhullámban táncolt a két félkép jobbra-balra. (Legutóbb szkópos méréssel beállítottam az elméleti értékhez minél közelebb, azóta hidegen is stabil a kép.)
Title: Re: Grafikai trükkök
Post by: endi on 2013.November.02. 14:30:30
Na ez itt egy demóm egyik része. Azért rakom be ide, mert tuti hogy senki se várta meg mire megjelent a háttér, sőt, amire elkezdett mozogni is! :)
Az első az amikor még áll a háttér, a másik meg amiben mozog.
Persze egyszerű paletta rotálás trükk, szó sincs arról, hogy ilyen nagy golyót ennyi fps-el meg tudna mozgatni az EP. 

Csak azt sajnálom, hogy csak függőleges csíkokat raktam be, pedig függőlegesen is lehetett volna változtatni (pl sakktábla), mennyivel jobb lett volna.
Title: Re: Grafikai trükkök
Post by: geco on 2013.November.02. 21:59:09
Én pl most láttam először a háttéranimot :) , de jó, és tényleg egy függőleges +anim még ütősebbé varázsolta volna.
Title: Re: Grafikai trükkök
Post by: endi on 2013.November.02. 22:04:22
Quote from: geco
Én pl most láttam először a háttéranimot :) , de jó, és tényleg egy függőleges +anim még ütősebbé varázsolta volna.
hát íme itt vannak a mindenféle ötletek amiket fel lehet javítani :)
Title: Re: Grafikai trükkök
Post by: endi on 2013.November.03. 14:42:34
amúgy mióta a google tud animált gifre keresni, lehetne találni olyan animokat amik felhasználhatóak lennének ep-n
pl forgó gömb
persze keresgélni kell így is hogy egy jót találjunk, meg olyat ami kevés fázisból is jó

Pl. ezt nézzétek meg! (https://www.google.hu/search?q=rotating+ball&safe=off&tbm=isch&source=lnt&tbs=itp:animated&sa=X&ei=TVF2UpbHBInQtAbW_4C4Aw&ved=0CEAQpwUoBQ&dpr=1&biw=1206&bih=771#facrc=_&imgdii=_&imgrc=EEuvMaGsJxo4zM%3A%3BiqirK63EOJy12M%3Bhttp%3A%2F%2Fmath.ucr.edu%2Fhome%2Fbaez%2FTruncatedicosahedron.gif%3Bhttp%3A%2F%2Fmath.ucr.edu%2Fhome%2Fbaez%2Fweek79.html%3B256%3B256)

itt van pl pár ami jó lehet:
http://math.ucr.edu/home/baez/Truncatedicosahedron.gif
http://i29.photobucket.com/albums/c251/DonDrev/Gode_V_3_1_duale.gif
http://www.amigalog.com/data/boingball/gifs/boingball_10_80x80_128.gif

persze ezeket animálni kell, úgyhogy a fentebb mutatott demó effektembe lehet hogy nem lennének jók, bár ha kisebbek akkor esetleg
Title: Re: Grafikai trükkök
Post by: endi on 2013.November.06. 19:20:52
Olyat lehetne vajon, hogy basicben az lpt sorokba megszakítást írni, és ezáltal felgyorsítani az EXOS sound megszakítást?
Title: Re: Grafikai trükkök
Post by: lgb on 2013.November.06. 23:19:17
Quote from: IstvanV
A trükkök használata nem szokatlan 8 bites gépeken, így például C64-en sem. :)

Sot, ott vannak aztan igazan nagyon durva (es gyakran csunya ...) trukkok, dehat az eredmeny szamit, nem a kod szepsege, maskulonben lehetne PC-n VisualBasicben irni inkabb, vagy kinek mi tetszik :) 8bit kategoriaban az a szep, hogy keves az eroforras (relative) es nagyon okos/kormonfont (de gyakran ronda) trukkot kell bevetni a cel elerese erdekeben.
Title: Re: Grafikai trükkök
Post by: Zozosoft on 2013.November.06. 23:22:54
Quote from: endi
Olyat lehetne vajon, hogy basicben az lpt sorokba megszakítást írni, és ezáltal felgyorsítani az EXOS sound megszakítást?
Szerintem igen, de az a billentyűzetet is felgyorsítja.
Title: Re: Grafikai trükkök
Post by: geco on 2013.November.07. 09:50:25
Nem úgy van, hogy valamelyik verzió frissíti az LPT-t is minden megszakításban?
Valami a német Basic ROM-ot tartalmazó gépekkel kapcsolatban lett megemlítve, ha jól emléxem.
Title: Re: Grafikai trükkök
Post by: Zozosoft on 2013.November.07. 09:57:01
Quote from: geco
Nem úgy van, hogy valamelyik verzió frissíti az LPT-t is minden megszakításban?
Valami a német Basic ROM-ot tartalmazó gépekkel kapcsolatban lett megemlítve, ha jól emléxem.
A szinkron szakaszt piszkálja.
Title: Re: Grafikai trükkök
Post by: geco on 2013.November.07. 10:10:10
Quote from: Zozosoft
A szinkron szakaszt piszkálja.
Akkor stornó :) , viszont azt észrevettem, hogy amikor színátmeneteket teszteltem ,akkor a leggyorsabb megoldásnak az tűnt, hogy az EXOS LPT palettáját módosítottam debuggerben, de idővel mindig lenullázta a változtatásaimat, gondolom ez csak a palettára érvényes, amikor frissíti a palettát az EXOS-ban megadott palettára.
Title: Re: Grafikai trükkök
Post by: endi on 2014.September.24. 20:17:15
hát ez érdekes, ilyet is lehet. text80 mód, grafikusan, úgy tűnik c16! sajna a karakterek átdefiniálása nem hat globálisan, ahogy text80-ban se :(
Title: Re: Grafikai trükkök
Post by: endi on 2014.September.24. 23:53:00
na ki tudja c16 módban gyorsabban betölteni a képernyőt random pixelekkel, basicben? :)
(lletve bármilyen módban)
Title: Re: Grafikai trükkök
Post by: endi on 2014.September.24. 23:58:23
illetve ez is érdekes, hogy kockák a pixelek
Title: Re: Grafikai trükkök
Post by: szipucsu on 2014.September.25. 19:19:57
Quote from: endi
furamode.ep128s (http://enterpriseforever.com/programozas/grafikai-trukkok/?action=dlattach;attach=10923)
Nem gyenge, ezeket a betűket még emulátor teljesképernyőn se lehet elolvasni, antennás tévés EP-n aztán pláne nem lehetne.

 (http://enterpriseforever.com/programozas/grafikai-trukkok/?action=dlattach;attach=10926)
Quote
eff5.ep128s (http://enterpriseforever.com/programozas/grafikai-trukkok/?action=dlattach;attach=10926)

Azt hittem, én voltam egyedül a világon, aki a SET CHARACTER után már adott meg RND számokat, de ezek szerint nem. :D

Kicsit jobban trükközve talán egész látványosan változó ábrákat is meg lehetne oldani.

Soha nem használt RND függvény:
SET KEY DELAY RND(255); SET STATUS RND(50)
SET VIDEO X RND(valamennyi)
GRAPHICS HIRES RND(...)
RESTORE RND(...), GOTO RND(...) - ilyet el se fogad szerintem.
Title: Re: Grafikai trükkök
Post by: szipucsu on 2014.September.25. 19:27:48
Nem nagy cucc, de kicsit látványos lehet telerakni a teljes képernyőt egy bizonyos karakterrel (vagy szóköznél ez el is maradhat), majd alkalmazni rá a következőt, vagy akár bonyolultabb, összetettebb függvényt:

10 FOR A=1 TO 255
20 SET CHARACTER 32,A,A,A,A,A,A,A,A
30 NEXT A

A 15-ös sorba még be lehet rakni valami függvényt, amitől még látványosabb lehet, de normálisat én nem tudok kitalálni, mert pl. a LET A=SIN(A) nem hogy nem értelmes, de talán még hibát is okoz.
Title: Re: Grafikai trükkök
Post by: endi on 2014.December.31. 16:37:18
akartam egy olyat csinálni, hogy basicból egy tunnel, sakktábla falakkal paletta rotálással

a sakktábla sajnos nem jött össze... azt hogy térbeli hatása legyen, könnyű volt megcsinálni, eleinte gyakrabban váltom a körök színét, aztán egyre ritkábban. így a közelebbi részeken gyorsabb  a pal rotálás

a pepitaságot úgy akartam megoldani, hogy xor (set line mode 3) módban átszínezem a cső színeit. csakhogy ez nem megy, ugyanis a line egymásra íródik folyton és ezáltal hülyeség jön ki

szerintem a probléma nem megoldható basicben :)

az invert függvégy csinálná a sakktáblásítást, de be se fejeztem mert nem lesz jó úgyse


Title: Re: Grafikai trükkök
Post by: endi on 2014.December.31. 16:49:57
itt van pepitasággal... rossz



Title: Re: Grafikai trükkök
Post by: endi on 2014.December.31. 17:06:05
wow ez viszont állat lett :)
Title: Re: Grafikai trükkök
Post by: ergoGnomik on 2014.December.31. 17:26:33
Valószínűleg meg lehet oldani, csak fordított megközelítésre lenne szükség. Igazából a képernyő pontjairól egyesével el kellene dönteni viszonylag bonyi (gondolom most én) koordinátageometriai számolással, hogy a pepita cső melyik paletta forgatási fázisához tartozó négyszögbe esik bele, és aszerint kell kiszínezni. Ha jól választod meg a pepita mintát, akkor elég a képernyő negyedére elvégezni a számolást, a többit megkaphatod tükrözéssel.
Title: Re: Grafikai trükkök
Post by: endi on 2014.December.31. 17:38:23
Valószínűleg meg lehet oldani, csak fordított megközelítésre lenne szükség. Igazából a képernyő pontjairól egyesével el kellene dönteni viszonylag bonyi (gondolom most én) koordinátageometriai számolással, hogy a pepita cső melyik paletta forgatási fázisához tartozó négyszögbe esik bele, és aszerint kell kiszínezni. Ha jól választod meg a pepita mintát, akkor elég a képernyő negyedére elvégezni a számolást, a többit megkaphatod tükrözéssel.

na ja... :) csak hát ahhoz matek kell, amihez én nem értek. de talán van itt aki igen :)
meg biztos lassú is lenne... bár ez se gyors :)
Title: Re: Grafikai trükkök
Post by: endi on 2014.December.31. 17:47:16
amúgy tök jó lett volna, ha a basic készítői csinálnak ilyesmi funkciókat a basic-be:

-videómemória másolása, pl egyik csatornáról a másikra
-téglalap alakú memória másolása egyik csatornáról a másikra (pl egyik csatornán rajzolgat az ember sprite-okat és a másik csatornára pályát rajzol velük)

ezek gépi kódban megírva nagyon hasznosak lettek volna, és totál egyszerűek is ráadásul...
Title: Re: Grafikai trükkök
Post by: endi on 2014.December.31. 18:17:27
ennek semmi értelme, pixeles "pepita"
Title: Re: Grafikai trükkök
Post by: endi on 2014.December.31. 18:39:17
amúgy eszembe jutott egy módszer:
-a köröket és a vonalakat két külön videólapra kell rajzolni
-ezután az egyik videólapról pontonként leolvasni a színt és xor-al a másikra rakni

ez is jó lassú lenne, de működne :)
lehet hogy meg is csinálom :)
Title: Re: Grafikai trükkök
Post by: endi on 2014.December.31. 20:02:48
na ez olyan mint a somb demóban
csinál 15 videólapot és pontokat rajzol rájuk, miközben váltja a videó lapot
200%-os emu sebességgel elég jó, persze ha csak lap váltás van akkor 100%-on is szépen mozognának
meg ügye max sebességen kell várni hogy jó sok pont legyen

pontok mozgásával lehetne tök jókat csinál, ez most olyan kb random
Title: Re: Grafikai trükkök
Post by: endi on 2014.December.31. 20:12:35
na ez jobb, pixel helyett egy karakter .-ot írok ki. lehet betűt is :)
de a mozgás amire valami jót ki kéne találni

Title: Re: Grafikai trükkök
Post by: ergoGnomik on 2014.December.31. 20:41:41
Felteszem a somb 2 unlimited bob effektjére gondoltál. Ehhez parasztosan Lissajous görbéket szoktak használni, ami viszonylag egyszerű és látványos, lehetőleg relatív prím együtthatókkal. Azután persze lehet variálni a dolgokat. Ha keresel demó példákat, biztosan találsz neked tetszőt is.
Title: Re: Grafikai trükkök
Post by: endi on 2014.December.31. 21:27:55
ja de én nem olyat akarok, olyan má van :)
valami újat! :)
Title: Re: Grafikai trükkök
Post by: endi on 2014.December.31. 22:09:17
na ez már alakul, csak közben rájöttem hogy én ezt már megcsináltam egy demómban :D

Title: Re: Grafikai trükkök
Post by: endi on 2014.December.31. 23:04:25
itt van az a demóm, de ennél sokkal jobbat lehetne csinálni

http://youtu.be/lKhmY_Wmu5Q?t=9m52s
Title: Re: Grafikai trükkök
Post by: endi on 2015.January.01. 15:37:17
ennek sincs túl sok értelme de szép :)

edit: persze igazi gépen marha lassú mire kirajzolja..
Title: Re: Grafikai trükkök
Post by: geco on 2015.January.01. 15:41:40
Jó, az alt+W sokat segít a rajzoláson is, kéne egy ilyen kombó az EP-re is ;)
Title: Re: Grafikai trükkök
Post by: endi on 2015.January.01. 15:45:01
ez se rossz. kár, hogy az ellipse-re nem hat a line style :(

Title: Re: Grafikai trükkök
Post by: endi on 2015.January.01. 15:48:20
ez meg már modern művészeti alkotás :)
amúgy eredeti gépen a kör rajzolás elég gyors, szóval ez viszonylag hamar feltölti a képernyőt ott is (pár óra... hehe)

edit: hm dehogy pár óra! pár perc! tök jó :)
Title: Re: Grafikai trükkök
Post by: endi on 2015.January.01. 17:39:16
ez csak egy verizója egy régebbinek, de itt jobban kijön több szín
Title: Re: Grafikai trükkök
Post by: endi on 2015.January.01. 21:10:16
esik a piros eső :)

Title: Re: Grafikai trükkök
Post by: endi on 2015.January.01. 23:12:39
az is tök kár, hogy hiba, ha egy pontot a képernyőn kívülre akarunk rajzolni
milyen jó lenne ha ez nem lenne. a kör rajzolásnál is kilóghat a kör a képről...
Title: Re: Grafikai trükkök
Post by: Zozosoft on 2015.January.01. 23:13:38
Használj WHEN blokkot.
Title: Re: Grafikai trükkök
Post by: endi on 2015.January.01. 23:26:38
Használj WHEN blokkot.

ja tényleg, van az a when exception vagy mi
Title: Re: Grafikai trükkök
Post by: endi on 2015.January.01. 23:27:31
na ehhez mit szóltok?
látom alig tölti valaki ezeket, érdekel egyáltalán valakit? :) vagy ne foglaljam vele a tárhelyet? :)
Title: Re: Grafikai trükkök
Post by: Zozosoft on 2015.January.01. 23:30:54
Én töltöm mindet!
És irigykedve nézem, hogyan tudsz ilyen egyszerű de tök jól kinéző dolgokat kitalálni!
Title: Re: Grafikai trükkök
Post by: endi on 2015.January.01. 23:41:36
oké akkor folytatom :)
itt egy új, mai utolsó :)
az a baj, itt már nagyon látszik hogy kevés az a 64k videó mem :( kevés lapot lehet hiresben nyitni, loresben meg már elég csúnya
Title: Re: Grafikai trükkök
Post by: Lacika on 2015.January.02. 14:43:15
na ehhez mit szóltok?
látom alig tölti valaki ezeket, érdekel egyáltalán valakit? :) vagy ne foglaljam vele a tárhelyet? :)

Egy kis tuning.
Title: Re: Grafikai trükkök
Post by: Lacika on 2015.January.02. 15:41:38
Az előzőnél nincs külön ROT eljárás. Ennél kell, mert nem jóa a túl sok "esőcsepp". Így viszont valamivel lassítani kellene... Szipucsu, van valami jó zenéd, amit berakhatnánk?
Title: Re: Grafikai trükkök
Post by: endi on 2015.January.02. 17:45:58
karakter képernyős :)
lehetne mátrixos betű potyogást (bár az grafikus lenne jó inkább)

amúgy van valami bug itten, ugyanis ha ennél nagyobb képernyőket nyitok, akkor a 2. basic sor törlődik!

Title: Re: Grafikai trükkök
Post by: szipucsu on 2015.January.05. 16:12:21
Szipucsu, van valami jó zenéd, amit berakhatnánk?
Hirtelen nincs rá ötletem, de elég jók ezek a demók, fel lehetne használni pl. youtube-on zenék alá videónak. A tunnelek is jók mind, még azzal lehetne bővíteni, hogy menet közben a paletta fokozatosan változzon színátmenetekkel.
Title: Re: Grafikai trükkök
Post by: endi on 2015.January.13. 00:16:05
Egy kis érdekesség: a Mutant Test játékomban úgy oldottam meg a figura ütközésvizsgálatát a falakkal, hogy a pálya grafikához hasonlóan vonalakat és fillezést rajzoltam egy lores képernyőre a háttérben. :)
Title: Re: Grafikai trükkök
Post by: endi on 2015.January.15. 21:29:53
másik topikban volt szó arról hogy sorba állítható-e a bias fényesség szerint
hát, tökéletesen nem, de azért kb:
Title: Re: Grafikai trükkök
Post by: endi on 2015.January.15. 21:36:11
és itt egy program ami fade-li fel le
igazából szerintem nem az a baj hogy nem állítható tökéletesen fényességi sorba, hanem az hogy nincs elég sötét verizó, mert mindegyik elég világos (pongyolán megfogalmazva)
Title: Re: Grafikai trükkök
Post by: szipucsu on 2015.January.16. 11:45:17
biasfade.ep128s
Látom, Picasso feltámadt. :D
Title: Re: Grafikai trükkök
Post by: endi on 2015.January.16. 18:37:53
amúgy azért érdekes ez a bias-fade, mert nagyon jól lehetett volna játékokban, demókban használni, akár úgy hogy soronként változtatva! persze ez esetben bizonyos dolgokat csak a bias színekkel kell megrajzolni, de szerintem bizonyos esetekben megérte volna, látványos effekt lehetett volna az eredmény
Title: Re: Grafikai trükkök
Post by: szipucsu on 2015.January.16. 20:17:11
Ez a bias nekem kínai. Viszont ilyesmivel próbálkoztam:

Code: [Select]
100 FOR A=1 TO 0 STEP -.1
110   SET COLOR 1,RBG(A,A,A)
120 NEXT A

Már nem tudom, mennyire működött. Az a baj, nem minden színnél lehet belőni a fokozatos elhalványodást könnyen. Erre lenne jó, amit linkeltél, gondolom.
De gondolom, valami POKE-kal lehetne megoldani, hogy pl. menüből kilépéskor fokozatosan elhalványodjon az összes szín. Valamelyik játékban mintha lenne is ilyen, most nem jut eszembe, melyikben.
Title: Re: Grafikai trükkök
Post by: endi on 2015.January.16. 22:28:04
na itt még a bias 8 színét is fényerő szerint sorba rendeztem és így rajzolom ki őket, majd bias fade
meg egy kis dithering is van benne, minden második sor line style-al mixelődik az előző színnel :)
Title: Re: Grafikai trükkök
Post by: endi on 2015.January.16. 23:55:51
esetleg az előző programomat valaki asb-ban kiegészíthetné úgy, hogy soronként változzon a bias a basic programban található táblázat alapján

lehet be kéne izzítanom az EP plus-t, hogy tudjak újra asm dolgokat csinálni (teljesen asmban nem akarok csinálni már ep-re semmit, mert az több munka lenne, annyi időt nem akarok ezzel foglalkozn)
Title: Re: Grafikai trükkök
Post by: endi on 2015.January.16. 23:57:35
az előző hozzászóláshoz, ilyesmire gondolod, de ezt photoshopban csináltam
Title: Re: Grafikai trükkök
Post by: endi on 2015.January.17. 00:13:22
na ez se rossz :)
Title: Re: Grafikai trükkök
Post by: szipucsu on 2015.January.18. 14:54:40
Egészen érdekesek ezek az effektek. Nem is gondoltam, hogy a 256 színből ilyet ki lehet hozni. (Na jó, csak 255, mert a fekete nem szín. :D )
Title: Re: Grafikai trükkök
Post by: endi on 2015.January.18. 17:16:50
én pont ezt élvezem az egészben hogy mit is lehetne még kihozni az EP-ből
persze gépi kódban lehetne ezt maximumra vinni, csak hát az már több munka, annyi időt nem akarok erre pazarolni :)
így hát marad a "mit lehet kihozni a basic-ből" dolog :)
Title: Re: Grafikai trükkök
Post by: endi on 2015.January.18. 19:06:19
új ep logo :)
mondjuk béna lett, mert a paletta anim nagyon elnyomja középen a bias színes részt
Title: Re: Grafikai trükkök
Post by: szipucsu on 2015.January.18. 19:18:29
új ep logo :)
mondjuk béna lett, mert a paletta anim nagyon elnyomja középen a bias színes részt
Picit még lehet módosítani rajta, és meg kell kérni Zozo-t, hogy a legközelebbi EXOS verzióba ezt tegye bele. De akkor nem úszod meg, és gépi kódban kell megcsinálni!
És EP indítóhangot is teszünk majd mellé. Igaz, abból eddig még csak két "pályamű" érkezett.
Title: Re: Grafikai trükkök
Post by: lgb on 2015.January.18. 20:25:25
Mondjuk ha mar EP meg Nick stb, akkor eleve lehet, a logoval is ki kene jobban emelni, hogy mire kepes a gep. Nem tudom, pl LPT manipulalassal egy felulrol "lezuhano" EP felirat (ami persze ettol meg animalhat szineiben vagy barmi), esetleg vmi vizszeru effekttel, ami tukrozodik alul (bar nem probaltam, de elvileg nem LPT trukkel meg lehet csinalni, hogy pixeladatok hasonloak, soronkent forditva, de mas peletta, kozben neha ide-oda oldalra rangatni egyes sorait mintha a vizfelulet hullamozva tukrozodne. Persze nem tudom hogy nezne ez ki a valosagban). Vagy ezzel mar tullone az ember a celon ("ez mar tul sok") es nem is biztos (kb biztos h nem), hogy beleferne az eredeti logo cucc helyere a ROM-ba :)
Title: Re: Grafikai trükkök
Post by: endi on 2015.January.18. 20:46:08
na nem is hivatalos új ep logónak gondoltam :)
mondjuk ami van, az nem egy nagy szám, kicsit megerőltethették volna magukat :)
de mondjuk a maga egyszerűségében hangulatos :)
Title: Re: Grafikai trükkök
Post by: endi on 2015.January.18. 21:58:57
na megcsináltam amit régebben elkezdtem (asszem a basic topikban volt)
szóval egyik videólapra kirajzolom a körkörös tunnelt
egy másikra a sugár irányú részeket
aztán a második lapról olvasom a pixeleket és line mode 3-al rárakom az elsőre, így rendesen összemixelődik a sakktáblás tunnel

mondjuk tök lassú mire kirajzolja, még 2000%-os emun is pár perc :)

itt már a kész anim fut, a program újraindításával megfigyelhetjük a rajzolási folyamatot

Title: Re: Grafikai trükkök
Post by: endi on 2015.January.18. 22:06:17
itt van fehér/kék verzióban, sokkal jobb
a másodiknál meg ráírtam bias színnel, hogy látványos legyen ahogy áll a mozgó háttér előtt valami :)
Title: Re: Grafikai trükkök
Post by: szipucsu on 2015.January.18. 22:31:10
mondjuk tök lassú mire kirajzolja, még 2000%-os emun is pár perc :)
Akkor mondjuk úgy lenne érdemes megcsinálni, hogy csak a videomemória tartalmát mentse el először, majd azt töltse be, az gyorsabb lehet.
Title: Re: Grafikai trükkök
Post by: geco on 2015.January.19. 14:15:31
a Tunnel final nagyon jó lett, megnéztem a kirajzolást is, na azt nem kellett volna, emu full speeden is több,mint egy perc volt :D
Title: Re: Grafikai trükkök
Post by: endi on 2015.January.19. 14:35:07
a Tunnel final nagyon jó lett, megnéztem a kirajzolást is, na azt nem kellett volna, emu full speeden is több,mint egy perc volt :D

igen, ez azért érdekes, mert pont ez miatt nem biztos hogy ezeket bárki is megcsinálta volna annak idején igazi gépen
pedig elméletileg megcsinálhatta volna, csak marha sok idő :) renderelés :D éjszakára otthagyok, reggelre kiderül hogy jó lett-e, tisztára mint manapság amikor 3d-t renderel az ember :D
Title: Re: Grafikai trükkök
Post by: geco on 2015.January.19. 15:16:42
igen, ez azért érdekes, mert pont ez miatt nem biztos hogy ezeket bárki is megcsinálta volna annak idején igazi gépen
pedig elméletileg megcsinálhatta volna, csak marha sok idő :) renderelés :D éjszakára otthagyok, reggelre kiderül hogy jó lett-e, tisztára mint manapság amikor 3d-t renderel az ember :D
lol, viszont ha megvan a kép, azt csak le kell menteni, és utána újrahasznosít :D
Amúgy a C64-es képkonverzióimat Basic-ből konvertáltam, jópár perc volt egy :D
Title: Re: Grafikai trükkök
Post by: Zozosoft on 2015.January.19. 15:22:12
lol, viszont ha megvan a kép, azt csak le kell menteni, és utána újrahasznosít :D
Ilyen van több is, amit anno BASIC-ben kirajzoltak, aztán gépi kódú demókban felhasználták a képkockákat.
Title: Re: Grafikai trükkök
Post by: endi on 2015.January.19. 19:12:49
itt egy jó sűrű négyzetes
olyat akarok még hogy bias színekből fekete pontokat rakok a képre, középen egyre sűrűbben, mintha a távolban elsötétülne a tunnel :)

(vajon miért lett tunneR folyton a file név???) :D
Title: Re: Grafikai trükkök
Post by: geco on 2015.January.19. 19:32:52
jó lett :)
Title: Re: Grafikai trükkök
Post by: endi on 2015.January.19. 20:43:13
na itt a "köd"
végül is nem is rossz, rosszabbra számítottam :)
amúgy az a poén ebben az egészben hogy lehetne egy űrhajós játékot csinálni belőle, repkedő űrhajók, háttérben meg menne ez a tunnel kb 0 proci idő felhasználásával :)
Title: Re: Grafikai trükkök
Post by: endi on 2015.January.20. 00:13:23
na még egy utolsó, már abba kéne hagyni! :D
Title: Re: Grafikai trükkök
Post by: szipucsu on 2015.January.20. 12:13:08
már abba kéne hagyni! :D
Még nem. Kéne még egy olyan verzió, ahol rács helyett az űrhajó műszerfala látszik, és az ablakból látjuk, ahogy megyünk előre. Lehetne olyan is, hogy balra ill. jobbra lehetne kanyarodni, jönne ellenfél, és ki kéne lőni a célkereszttel. Bár ehhez nem kéne ennyire "aktív" tunnel, amiben haladunk, lehetne pár csillag is.
Title: Re: Grafikai trükkök
Post by: lgb on 2015.January.20. 12:29:25
Még nem. Kéne még egy olyan verzió, ahol rács helyett az űrhajó műszerfala látszik, és az ablakból látjuk, ahogy megyünk előre. Lehetne olyan is, hogy balra ill. jobbra lehetne kanyarodni, jönne ellenfél, és ki kéne lőni a célkereszttel. Bár ehhez nem kéne ennyire "aktív" tunnel, amiben haladunk, lehetne pár csillag is.

Keszul az uj Elite? :) Az mar milyen jo volt, nem jatszok szamitogeppel, de az kivetel volt ;)
Title: Re: Grafikai trükkök
Post by: szipucsu on 2015.January.20. 12:40:41
Keszul az uj Elite? :)
Nem is rossz ötlet! Ki kéne bővíteni, hogy játék előtt legyen egy kis Diktátor szerű akció, és az abban elért eredményünktől függ, mennyi ellenfél jön a csatornában. A probléma már csak, hogy fél napot kéne várni a csatorna kirajzolására, de ezt talán meg lehet csinálni úgy, hogy elmentjük a kész videólapok tartalmát, és diktátorozás után betöltjük, az talán gyorsabb.
A "csatornázás" után pedig az esetleg megmaradt ellenfeleket a szép színes grafikus képernyőn kéne kinyiffantani, a Miner folytatásában, amit Endi a Mit lehet még kihozni a basic-ből topikban készített.
Utántöltős, eredeti EP-s játék, az lenne az igazi!
Title: Re: Grafikai trükkök
Post by: endi on 2015.January.22. 01:23:07
azon gondolkodom hogy lehetne fényesség szerint sorba rendezni a 256 színt? :)
Title: Re: Grafikai trükkök
Post by: IstvanV on 2015.January.22. 09:22:39
azon gondolkodom hogy lehetne fényesség szerint sorba rendezni a 256 színt? :)

Ehhez ki kell számítani a fényességet. Erre a legegyszerűbb megoldás:

Y = 0.299 * R + 0.587 * G + 0.114 * B

Ezt használják például a TV-k és az ep128emu is fekete-fehér kép előállítására.

Kevésbé egyszerű, de a látható fényességet pontosabban határozza meg az RGB->XYZ->Lab konverzió. Erről itt (http://en.wikipedia.org/wiki/Lab_color_space) lehet olvasni.
Title: Re: Grafikai trükkök
Post by: endi on 2015.January.22. 10:27:33
ez ok, de írni kell egy programot ami sorbarendezi őket :)
a fő gond az hogy csak 256 szín van, ezért még arra is ügyelni kell hogy az ugyanolyanokat kiszűrjük :)
Title: Re: Grafikai trükkök
Post by: szipucsu on 2015.January.22. 12:19:06
azon gondolkodom hogy lehetne fényesség szerint sorba rendezni a 256 színt? :)
Először úgy olvastam, hogy "fénysebesség" szerint sorba rendezni. Amelyik szín gyorsabb, az nyer. Ha hangokkal lenne ugyanez, akkor "hangverseny" lenne.
Title: Re: Grafikai trükkök
Post by: IstvanV on 2015.January.22. 13:34:03
a fő gond az hogy csak 256 szín van, ezért még arra is ügyelni kell hogy az ugyanolyanokat kiszűrjük :)

A 256 szín között nincsenek azonosak, ez csak a BASIC rgb() függvényével fordul elő. Az azonban probléma lehet, hogy sok szín nagyon hasonló fényességű, de nagyon eltérő színű.

Az alábbi programok rendezve jelenítik meg a 256 színt:
[attachurl=1]
[attachurl=2]    <-- szerk.: ez egy BASIC file (epcsort.bas), amit a fórum hibásan képként próbál megjeleníteni

A Lua script végzi a rendezést, és az eredményt a 3000h-31FFh területen tárolja (ami a kis méretű BASIC programot remélhetőleg nem írja felül :oops:). Ezt a BASIC program jeleníti meg 256 színű módban, felül a YUV, alul pedig a Lab színtérben történő rendezés eredménye látható.

[attachimg=3]
Title: Re: Grafikai trükkök
Post by: endi on 2015.January.22. 16:11:47
igen, én is az rgb függvényre gondoltam hogy azonosakat dob ki
na megnézem majd este ezt amit csináltál. megelőztél :P
Title: Re: Grafikai trükkök
Post by: endi on 2015.January.22. 18:36:00
na megnéztem, sikerült a lua-t is elindítani :)
szerintem valahogy számításba kéne venni az EP korlátait, azaz itt arra gondolok hogy a blue az csak 2 bit
nem tudom hogyan, meg lua-t se akarok tanulni, csak ötlet :)
Title: Re: Grafikai trükkök
Post by: endi on 2015.January.22. 20:58:00
az első próba a sorbarendezett színekkel :)
Title: Re: Grafikai trükkök
Post by: endi on 2015.January.22. 21:10:41
na ez már tök jó :)
Title: Re: Grafikai trükkök
Post by: endi on 2015.January.22. 22:01:51
ez elindítva max emu sebességen jó

Title: Re: Grafikai trükkök
Post by: IstvanV on 2015.January.22. 23:41:12
Jók lettek. :) Az első kettőnél a színeket animálni is lehetne, de 256 színű módban csak asm lenne elfogadható sebességű.
Title: Re: Grafikai trükkök
Post by: endi on 2015.January.22. 23:53:44
Jók lettek. :) Az első kettőnél a színeket animálni is lehetne, de 256 színű módban csak asm lenne elfogadható sebességű.

asmban úgy egész jó lehetne, ha függőlegesen 4 pixelesen ismételve lenne
lehetne ilyen plazma szerű dolgokat is generálni és animálni, egész jó demó effekt lenne :)
vannak itt még lehetőségek :)
lehet hogy 50 év múlva ha még élünk és így folytatjuk, tényleg kihozunk mindent az EP-ből :D
Title: Re: Grafikai trükkök
Post by: lgb on 2015.January.23. 10:18:13
lehet hogy 50 év múlva ha még élünk és így folytatjuk, tényleg kihozunk mindent az EP-ből :D

Nem lehetetlen. C64-re meg most is jonnek ki uj "elkepszto" dolgok, amire mas nem gondolt, stb. Ott ugye elony, hogy nepszerubb platform mint az EP. Ha annyi ideig es annyi ember nekiesne EP-nek mint C64-nek, abbol is erdekes dolgok sulhetnenek ki. Es ha meg annyi ember nincs is, az idotenyezo itt is jot tehet :)
Title: Re: Grafikai trükkök
Post by: endi on 2015.January.24. 21:52:33
na ez egész jó lett, persze csak max emu sebességen
Title: Re: Grafikai trükkök
Post by: endi on 2015.January.24. 21:54:06
hm az a vicces hogy hires 2-ben vagy hires 4-ben szinte jobb :)
Title: Re: Grafikai trükkök
Post by: Lacika on 2015.January.25. 09:56:18
ez elindítva max emu sebességen jó

Így is elég gyors.
Title: Re: Grafikai trükkök
Post by: endi on 2015.January.25. 11:40:11
érdekes hogy ennyivel gyorsabb, pedig ez is csak az exos graf rutionokat hívja, és azok viszik itt a fő időt
de hát igen, ennyire lassú a basic interpreter :(
de azért szeretjük :)
Title: Re: Grafikai trükkök
Post by: Lacika on 2015.January.25. 11:52:48
érdekes hogy ennyivel gyorsabb, pedig ez is csak az exos graf rutionokat hívja, és azok viszik itt a fő időt
de hát igen, ennyire lassú a basic interpreter :(
de azért szeretjük :)

Mondjuk a kör középpontjának kijelölését végző PLOT urtasítást kapásból a külső ciklusba raktam át, így sokkal kevesebb exos graf rutint végzünk. :oops: Ez már a basic skiccen is gyorított.
Title: Re: Grafikai trükkök
Post by: endi on 2015.January.25. 14:51:36
amúgy az ilyen egyszerű, exos grafikára épülő dolgok szerintem zzzippel is elérnék ezt a sebességet
Title: Re: Grafikai trükkök
Post by: endi on 2015.January.25. 15:42:20
ez ilyen rgb függvényes dolog
nem egy nagy szám
Title: Re: Grafikai trükkök
Post by: endi on 2015.January.25. 15:49:41
na ez viszont érdekes!
hogyan írjuk basic-ből 256 színű pixeleket, amelyek nem 1 rasztersor magasak hanem 9! és hogy gyors is legyen?
karakteres módban :)
átváltom a karakteres mód szín modját, majd feltöltöm a karaktereket hogy minden soruk azonos színű legyen
bár valami furcsaság van, mintha nem jelenne meg minden szín?

egy clear font-ot érdemes kiadni ha listázni akarjuk (meg egy soft resetet)
Title: Re: Grafikai trükkök
Post by: endi on 2015.January.25. 17:03:22
haha ez nagyon jó, egy marha sok oldalas pdf egy 1 soros c64 programról :D
http://nickm.com/trope_tank/10_PRINT_121114.pdf
Title: Re: Grafikai trükkök
Post by: endi on 2015.January.25. 17:21:39
hehe meg is csináltam
mondjuk nem értem a c64-es verzióban miért van ott nem egész szám a karakternél
lehet hogy más az rnd értéke?
amúgy nemrég jöttem rá hogy ep-n is lehet hívni simán úgy hogy "rnd" és akkor 0-1-ig ad értéket

Title: Re: Grafikai trükkök
Post by: endi on 2015.January.25. 17:23:32
ha attr képre írom ki őket, akkor egy paint utasítással be lehet járni részeit :D
Title: Re: Grafikai trükkök
Post by: endi on 2015.January.25. 18:41:16
na itt van az a 256 színű karakteres izé, poke-al
persze gányolás a képernyő cím :)
Title: Re: Grafikai trükkök
Post by: szipucsu on 2015.January.25. 19:23:25
És mikor lesz pacman a labirintusban, és pontok, amiket össze kell szedni?
Title: Re: Grafikai trükkök
Post by: endi on 2015.January.25. 19:44:14
hát asmban lehetne szépeket csinálni
csak hát ennyit már nem akarok foglalkozni ezzel, ez csak szórakozás :)
Title: Re: Grafikai trükkök
Post by: endi on 2015.January.25. 21:57:38
na elvtársak! most nagy dolog készül! az első 256 színű basic-ben írt scrollos game!
állakat megfogni nehogy leessenek! :)
(gombnyomásra clear font, listázzátok ki, de soft resettel is listázzátok ki mert a lista végén van a 256 színű SPRITE!!!)

ez szerintem nagyon ígéretes, még én is elcsodálkoztam mik is lehetnek ebből :)

Title: Re: Grafikai trükkök
Post by: endi on 2015.January.25. 22:10:24
hm rájöttem hogy 0-127-ig van csak értelme átdefiniálni a karaktereket, mert a második felében ismétlődik a megjelenítés
dereng valami hogy két karakteres mód van, egyikben 128 másikben 256 karakter lehet
de amúgy nem gond ha itt csak 128 lehet, az is elég szín :)
Title: Re: Grafikai trükkök
Post by: endi on 2015.January.25. 22:16:25
na itt van egy, felül lehet egy űrhajót irányítani
elismerem, a gagyiság kategóriát súrolja, de higgyetek benne :)
esc-el lehet kilépni és clear font
Title: Re: Grafikai trükkök
Post by: szipucsu on 2015.January.25. 22:24:33
na itt van egy, felül lehet egy űrhajót irányítani
Ha csak 1-2 karakteres lenne az űrhajó, folyamatosabb lehetne talán a kirajzolása.
Zzzippelve is lehet, hogy egész elfogadható lenne.
A scroll része jó, lehetne esetleg több szín is? Mert itt csak a piros árnyalatai voltak, de amikor lestoppoltam, több szín is előjött, biztos azok is előhívhatók.
Title: Re: Grafikai trükkök
Post by: endi on 2015.January.25. 22:27:09
persze, lehet mindenféle objektumot rajzolni a data sorokba való beírással :) rajzolóprogram! csak tudd megjegyezni melyik betű melyik szín volt hahaha

na itt egy kis trükk, ahol a karaktereket kicsit árnyalom, a tetejük 255-ös szín, az aljuk meg a szín sötétebb verziója. érdekes szerintem, kicsit elveszi a téglapixel hatást
Title: Re: Grafikai trükkök
Post by: endi on 2015.January.25. 22:50:47
még árnyaltam a karaktereket, most már a saját színűkkel
kurzort space színre állítottam, hogy is lehetett ezt teljesen kikapcsolni
ja meg "csillagok" is vannak :)
Title: Re: Grafikai trükkök
Post by: Zozosoft on 2015.January.25. 23:01:18
PRINT #102:CHR$(27);"o";
Title: Re: Grafikai trükkök
Post by: endi on 2015.January.25. 23:18:13
köszi :)
Title: Re: Grafikai trükkök
Post by: Povi on 2015.June.02. 14:49:14
attribútum üzemmódban a video RAM-ban az attribútum adatok közvetlenül a pixel adatok után vannak?
Title: Re: Grafikai trükkök
Post by: geco on 2015.June.02. 14:55:58
attribútum üzemmódban a video RAM-ban az attribútum adatok közvetlenül a pixel adatok után vannak?
Attól függ, hogy van definiálva az LPT-ben, lehet bárhol máshol is.
Title: Re: Grafikai trükkök
Post by: lgb on 2015.June.02. 14:58:40
attribútum üzemmódban a video RAM-ban az attribútum adatok közvetlenül a pixel adatok után vannak?

Az adott LPB-ben attrib modban hasznalva van az LD1 es az LD2 is, azaz oda allitod a pixel es az attrib adatokat, ahova akarod, nincs megkotes, hogy utana legyen, vagy barmi.

http://ep.lgb.hu/doc/Nick.html#9 (http://ep.lgb.hu/doc/Nick.html#9)
Title: Re: Grafikai trükkök
Post by: Povi on 2015.June.02. 15:02:13
na és amikor az EXOS-szal nyitok videolapot? ő hova pakolja?
Title: Re: Grafikai trükkök
Post by: lgb on 2015.June.02. 15:24:15
na és amikor az EXOS-szal nyitok videolapot? ő hova pakolja?

Hat ez jo kerdes, logikusan gondolva szerintem ott tenyleg "egymas moge" fogja tenni, mivel ugye a rendszerszegmens stb feltoltes "sorban lefele" halad (es nem azert, mert a Nick barmi modon ezt igenyelne, vagy hasonlo).
Title: Re: Grafikai trükkök
Post by: Povi on 2015.August.10. 12:47:31
lehet "custom" karakteres módot létrehozni?
tehát arra gondolok, hogy a videoRAM-ban csak ASCII karakterek vannak (pl 40x25 byte, ha 40x25-ös karakteres képernyőt akarok), de a kijelzett karakterek nem 8x9 pixel méretűek, hanem pl. 4x8, vagy 6x7 stb...
Title: Re: Grafikai trükkök
Post by: Zozosoft on 2015.August.10. 12:52:35
A függőleges méret az szabadon választott, vízszintes az mindenképen 8 pixel.
Title: Re: Grafikai trükkök
Post by: ergoGnomik on 2015.August.10. 20:52:49
A "TEXT 80" is egy "custom" karakteres mód ha jól tudom (jól tudom?). Miért ne lehetne akár teljesen tetszőleges karakter méretűt csinálni? Legfeljebb nem lesz hardveres támogatása.
Title: Re: Grafikai trükkök
Post by: Z80System on 2015.August.10. 21:00:07
Quote
A "TEXT 80" is egy "custom" karakteres mód ha jól tudom (jól tudom?). Miért ne lehetne akár teljesen tetszőleges karakter méretűt csinálni? Legfeljebb nem lesz hardveres támogatása.

Annyira "custom", hogy grafikus ... :)

(Attól olyan küszködősen lassú ...)




Title: Re: Grafikai trükkök
Post by: geco on 2015.August.11. 10:59:53
na és amikor az EXOS-szal nyitok videolapot? ő hova pakolja?
Előfordulhatnak lyukaka még magában a pixel adat, és az attributum adat tárolási címekben is, attól függ, hogy hol talált az EXOS szabad helyet a memóriában egy-egy LPB-ben definiált karaktersorra. (Ha jól emlékszem, akkor EXOS-on keresztül definiált videólapnál mindig 9xY magas a videólap, nem lehet ezen változtatni. )
Title: Re: Grafikai trükkök
Post by: endi on 2015.August.22. 18:00:14
van egy ilyen videó, állítólag jó, bár nem néztem meg.
https://www.youtube.com/watch?v=Tfh0ytz8S0k

belenézegetve kicsit az volt az érzésem, hogy ez az ember nem tudja hogy a mai modern grafika is marha sok trükköt, módszert használ, és hogy brutális teljesítmény (géptől és embertől is) amit ma egy pc-n vagy konzolon látunk, pl játékok esetén.

pl hosszasan elemzi az attributum grafikát, miközben hasonló a mai gépeken is van a textúra tömörítésnél (4x4-es blokkok, 16 szin mindegyik, de az egész textúrában nincs minden ilyen blokkra külön paletta - ráadásul ezt a fajta textúrát is realtime rakja ki a GPU, realtime kicsomagolással, és ami a poén, hogy ez még gyorsabb is lehet mint a nem tömörített textúra) - és ezrével lehetne ezeket a trükköket sorolni.
Title: Re: Grafikai trükkök
Post by: ergoGnomik on 2015.August.22. 18:27:57
A videó címét elolvastad? (Bocs ha gyökérnek tűnök.)
Title: Re: Grafikai trükkök
Post by: endi on 2015.August.22. 18:37:33
A videó címét elolvastad? (Bocs ha gyökérnek tűnök.)

na de pont ezt mondom, hogy kicsit olyan a videó, mintha csak ezeken a régi gépeken lett volna a sok trükközés, memóriatakarékoskodás stb. miközben ma is ez van nagyon sok esetben :)
Title: Re: Grafikai trükkök
Post by: endi on 2015.October.11. 11:33:15
egy jó színsor data sorokban, az ep demonstrációs kazettán lévő program alapján
hasznos adatsor szép színek rajzolásához

szerk.: és különlegessége hogy minden szín szerepel benne (legalábbis asszem) :)
Title: Re: Grafikai trükkök
Post by: endi on 2015.October.11. 14:06:24
kísérletezgetés... tudom hogy sokkal jobb minőségben tudunk már képeket konvertálni, de a hires 2 mód nagy felbontásával gondolkodtam most, tehát amikor 1 sorban csak két szín van.
ez a bal oldali kép. a trükk az hogy 4 soronként más színek vannak:
1. sor: R
2. sor: G
3. sor: B
4. sor: világosság
és persze az egész kép ditherelt 2 színű soronként (néhol hibás mert csak PS-ben gányoltam össze, szóval néha több szín is van, de az összhatást nem befolyásolja).

a jobb oldali kép meg az r g b komponensek ditherelve 3 layeren, átlátszóan. szóval képzeljünk el 3 képet, egyik kék, másik zöld, harmadik piros, és ezeket villogtatnánk EP-n.
Title: Re: Grafikai trükkök
Post by: endi on 2015.December.11. 16:04:28
egy kis vizuális trükk
Title: Re: Grafikai trükkök
Post by: IstvanV on 2015.December.11. 18:17:20
a jobb oldali kép meg az r g b komponensek ditherelve 3 layeren, átlátszóan. szóval képzeljünk el 3 képet, egyik kék, másik zöld, harmadik piros, és ezeket villogtatnánk EP-n.

Egy másik lehetőség: 4 színű módban RGB komponensek:
Code: [Select]
-mode 11 -palres 0 -color0 0 -color1 73 -color2 146 -color3 36 -ymax 0.3333 -outfmt 11
Title: Re: Grafikai trükkök
Post by: geco on 2015.December.11. 19:18:09
egy kis vizuális trükk
Eléggé becsapós, mintha a V-k is mozognának :)
Title: Re: Grafikai trükkök
Post by: szipucsu on 2015.December.11. 20:53:32
Eléggé becsapós, mintha a V-k is mozognának :)
Biztos vagyok benne, hogy Endi hipnotizálni akar minket és uralma alá hajtani. Ne nézzétek túl sokáig a vizuális trükköt! :D
Title: Re: Grafikai trükkök
Post by: geco on 2015.December.11. 21:42:25
Biztos vagyok benne, hogy Endi hipnotizálni akar minket és uralma alá hajtani. Ne nézzétek túl sokáig a vizuális trükköt! :D
Már késő :D
Title: Re: Grafikai trükkök
Post by: IstvanV on 2015.December.15. 19:19:23
egy kis vizuális trükk

Ugyanezen az elven működő, Magic Ball-hoz hasonló effektus (a rajzolást hatékonyabban is meg lehetett volna oldani :oops:):
[attachurl=1]
Title: Re: Grafikai trükkök
Post by: endi on 2015.December.15. 19:27:10
Ugyanezen az elven működő, Magic Ball-hoz hasonló effektus (a rajzolást hatékonyabban is meg lehetett volna oldani :oops:):
(Attachment Link)

hú ez király, én is raktam már be ide ilyet de az béna volt :)
hát igen, én mindig is lusta voltam átgondolni a matekot az ilyenek mögött :D
Title: Re: Grafikai trükkök
Post by: endi on 2015.December.15. 20:02:27
egy kicsit játszottam vele
Title: Re: Grafikai trükkök
Post by: IstvanV on 2015.December.15. 20:42:29
egy kicsit játszottam vele

Egy másik lehetséges megoldás az átlátszóságra:
[attachurl=1]
Lehet még próbálkozni a 191-220 sorok törlésével is. Az átlátszóság nélkül attribútum mód is használható:
[attachurl=2]
Title: Re: Grafikai trükkök
Post by: endi on 2015.December.15. 21:42:47
tök jók!
ez az attributes parancs tök jó, nem is használtam én sose
nagyon jól megcsináltad hogy úgy rajzol hogy teljesen észrevehetetlen hogy attr módban van
Title: Re: Grafikai trükkök
Post by: geco on 2015.December.16. 09:05:31
Nagyon jóóók :)
Title: Re: Grafikai trükkök
Post by: IstvanV on 2015.December.16. 20:10:00
[attachurl=1]
[attachurl=2]

Szerk.: teljesen BASIC-ben írt (és nagyon lassú :oops: - emulátoron 250 MHz-es Z80, kikapcsolt memória időzítés, és Alt+W ajánlott a rajzolás közben) verzió:
[attachurl=3]
Title: Re: Grafikai trükkök
Post by: geco on 2015.December.17. 09:07:09
Szerk.: teljesen BASIC-ben írt (és nagyon lassú :oops: - emulátoron 250 MHz-es Z80, kikapcsolt memória időzítés, és Alt+W ajánlott a rajzolás közben) verzió:
Nagyon jók , egy kis demót is összehozhatnál ezekből az effektekből :)
Title: Re: Grafikai trükkök
Post by: endi on 2015.December.17. 09:37:17
scanline render :)
Title: Re: Grafikai trükkök
Post by: IstvanV on 2015.December.17. 12:17:22
Nagyon jók , egy kis demót is összehozhatnál ezekből az effektekből :)

Még lehetne javítani rajta például két video lap használatával (8 helyett 16 fázis). De a "Magic Ball" effektust asm-ben lényegesen jobban meg lehetne oldani soronként változó palettával, az egyszerű minta helyett tetszőleges "pálya" is megjeleníthető lenne.

A fenti tunnel.lua script-ben található drawPixel() rutin egyszerűen használható EXOS kompatibilis rajzolásra 16 színű PIXEL módban.
Title: Re: Grafikai trükkök
Post by: endi on 2015.December.17. 12:33:25
basic magicball, régebbi topikból
majd rárakom a te grafikádra mert az jó térbelileg
Title: Re: Grafikai trükkök
Post by: IstvanV on 2015.December.17. 12:48:14
Karakteres felbontással nehéz megoldani, hogy pontosan jelenjen meg térben. Soronként változó palettával asm-ben minden sorhoz hozzárendelhető Z koordináta (táblázatban), amihez hozzáadva az aktuális pozíciót egyszerűen számítható az olvasási pozíció egy tömbben, amely a megjelenítendő "pályát" tartalmazza.
Title: Re: Grafikai trükkök
Post by: endi on 2015.December.17. 13:05:39
Karakteres felbontással nehéz megoldani, hogy pontosan jelenjen meg térben. Soronként változó palettával asm-ben minden sorhoz hozzárendelhető Z koordináta (táblázatban), amihez hozzáadva az aktuális pozíciót egyszerűen számítható az olvasási pozíció egy tömbben, amely a megjelenítendő "pályát" tartalmazza.

hát én tudom :)
egy csomó demómban van ilyen effekt, pl a legelsőben vízszintes, ami újszerű volt szerintem :)
https://www.youtube.com/watch?v=5Eg14WLJmEk
Title: Re: Grafikai trükkök
Post by: IstvanV on 2015.December.17. 19:31:53
Még lehetne javítani rajta például két video lap használatával (8 helyett 16 fázis).

[attachurl=1]

Forrás:

[attachurl=2]
[attachurl=3]
[attachurl=4]
Title: Re: Grafikai trükkök
Post by: endi on 2015.December.17. 19:46:01
(Attachment Link)

tök jó. már csak egy űrhajó kell meg ellenségek és kész is a játék :)
Title: Re: Grafikai trükkök
Post by: ssr86 on 2015.December.17. 20:07:41
(Attachment Link)

Forrás:

(Attachment Link)
(Attachment Link)
(Attachment Link)
Looks fantastic:D
Title: Re: Grafikai trükkök
Post by: geco on 2015.December.18. 08:51:45
:smt041 :smt041 :smt041
Title: Re: Grafikai trükkök
Post by: Zozosoft on 2015.December.18. 08:56:55
Wow! :smt038
Title: Re: Grafikai trükkök
Post by: IstvanV on 2015.December.18. 13:56:38
Egyszerű "Magic Ball" demo:
[attachurl=1]
A beépített joystick használható gyorsításra (fel) és lassításra (le). Space billentyűre kilép.

A "pálya" (legfeljebb 4096 hosszúságú lehet, de ez csak 256):
[attachurl=2]

Forrás file-ok:
[attachurl=3]
[attachurl=4]    (a demo1.lua kimenete)
[attachurl=5]    (a levelconv.cpp kimenete, epcompress -raw -m2 -9 tömörítéssel)
[attachurl=6]    (a demo1.lua kimenete, epcompress -raw -m2 -9 tömörítéssel)
[attachurl=7]    (a levelconv.cpp fordításához a "pálya" XPM formátumra konvertálva GIMP segítségével)
[attachurl=8]    (a demo1.lua előtt futtatandó EP program, amely beállítja a video módot)
[attachurl=9]    (ztable.s és tömörítetlen imgdata.bin készítése)
[attachurl=10]    (level_01.xpm konverziója tömörítetlen level_01.bin file-ra)
[attachurl=11]
Title: Re: Grafikai trükkök
Post by: endi on 2015.December.18. 14:06:46
tök jó, bár szerintem ha már csinálsz valamit, valami újat kéne. pl nem ugrálós magicballt hanem csak sávváltóst, ezek nagy divatok mobilon (runner játékok, bár ugrani kell a legtöbben, de a jobbra balra kitérés az akadályok elől elsődlegesebb).

nem mellesleg sokkal jobb játékélmény szerintem (magic ball szerintem frusztráló)

ötlet: fent lehetne az íves tunnel mint háttér anim! persze fél-tunnel
Title: Re: Grafikai trükkök
Post by: geco on 2015.December.18. 14:09:21
Ez nagyon jó, és tök jók lettek a színek, meg a mozgás is, nem értek egyet Endivel, nekem pl csak a sima sávváltós verzió nem tetszene.
Title: Re: Grafikai trükkök
Post by: endi on 2015.December.18. 14:12:22
Ez nagyon jó, és tök jók lettek a színek, meg a mozgás is, nem értek egyet Endivel, nekem pl csak a sima sávváltós verzió nem tetszene.

asszem rosszul mondtam. inkább talán arra gondoltam hogy a golyó csak a sávokban lehessen, tehát nem akármilyen koordinátán. szerintem sokkal játszhatóbb, kevésbé frusztráló.
na meg akkor már lehetne animált figura is golyó helyett, látványos lenne
Title: Re: Grafikai trükkök
Post by: Z80System on 2016.March.05. 19:48:45
Jól látom, hogy Joe annak idején a megademó 2 -ben LPT -vel összenyomta a képet függőlegesen ? (Pixel manipuláció nélkül...)

Tehát feltételezhetően CRT monitorokon lehetne csinálni függőleges zselé effektet scrollokra, vektorokra, bármire a képen ?
Title: Re: Grafikai trükkök
Post by: endi on 2016.March.05. 20:20:57
jópár demóban van ilyen, pl még az enyémek között is többen :)
a világ legegyszerűbb effektje...
Title: Re: Grafikai trükkök
Post by: endi on 2016.April.07. 20:21:35
geco ilyen robbanás effektet gondoltam a karakteres falbontóba :)
persze ez basic, tök lassú, max emu sebességgel műxik csak! szerk: ja és max z80 speeddel! úgy már tök szép
space-t kell nyomni
Title: Re: Grafikai trükkök
Post by: endi on 2016.April.07. 21:26:50
itt ez zippelt, már nem kell neki max z80, csak max emu speed :)
megpróbálom mindjárt print helyet poke-okkal
Title: Re: Grafikai trükkök
Post by: geco on 2016.April.08. 08:42:52
na, én egy ettől kisebb robbanásra gondoltam amikor mondtad, ez jól néz ki, de sztem még gépi kódban is megfogta volna a játékot, és egyszerre csak egy tégla robbanhatott volna.
Title: Re: Grafikai trükkök
Post by: endi on 2016.April.08. 09:46:00
szerintem 8-10 karakterrel elbírná
az meg nem lenne zavaró ha az előző eltűnik
de persze jó ez így ahogy van! tök jó
Title: Re: Grafikai trükkök
Post by: szipucsu on 2016.April.09. 23:00:58
A Wikipédiában ez van: (https://hu.wikipedia.org/wiki/Enterprise_128)
Quote
Az sincs előírva, hogy a karakternek 9 pixel sor magasnak kell lennie, lehet például 8 is, mint a Spectrumon
Tehát beállítható akármilyen magas karakter? És akkor a set character utasításban annyival több/kevesebb számot kell megadni?
Title: Re: Grafikai trükkök
Post by: lgb on 2016.April.09. 23:19:53
A Wikipédiában ez van: (https://hu.wikipedia.org/wiki/Enterprise_128)Tehát beállítható akármilyen magas karakter? És akkor a set character utasításban annyival több/kevesebb számot kell megadni?

A karakter magassagot az aktualis LPB-n levo SC mezo adja. Lehetne akar 200 is :D Ezert is van a charset ugy tarolva, hogy minden karakter elso scanline-ja, utana minden masodik (ellenben pl commdore-nal ahol szepen sorban az elso karakter osszes scanline-ja stb), mert igy a magassagtol nem valtozik a "layout" vagy hogy mondjam. Amugy mivel minden karakter sorhoz egy LPB tartozik, az is lehetseges elvileg, hogy minden sorban mas a magassag ...
Title: Re: Grafikai trükkök
Post by: ergoGnomik on 2016.April.09. 23:22:47
A Wikipédiában ez van: (https://hu.wikipedia.org/wiki/Enterprise_128)Tehát beállítható akármilyen magas karakter? És akkor a set character utasításban annyival több/kevesebb számot kell megadni?
IS-BASIC-et nem vágom, de abban szerintem nemigen fog menni, hacsak nem SPOKE-olgatsz be egy LPT-t is. Ja, és ott van még az is, hogy mit lép az eltérő paraméterszámra a SET CHARACTER esetében?
Title: Re: Grafikai trükkök
Post by: endi on 2016.April.09. 23:42:14
a képernyő rezegtető úgy műxik hogy az első lpt sor magasságát változtatja
át lehetne írni, hogy végigmenjen az lpt-én és mindenhol 8 sort állítson be, az utolsó sorban meg ezeket az elveszett sorokat ellensúlyozná egy magasabb sorral (hogy a tévé szinkron ne vesszen el vagy mi)

csak hát ügye az exos azonnal felül fogja írni egy set color, set palette, display stb utasítással

de mi bajotok a 9 sorral, szerintem egyedi :)
Title: Re: Grafikai trükkök
Post by: szipucsu on 2016.April.10. 09:38:39
Eddig EP-n mindig csak a szokásos magasságú karaktereket láttam. Kíváncsi lennék, milyen lenne máshogy. Szerintem eddig még semmilyen program nem használta ki ezt a lehetőséget. Pláne érdekes lenne egy olyan karakterkészlet, ahol nem egyforma magasak a karakterek. Így a pontnak elég lenne nagyon kicsi karakter is. Hogy nézne ki így egy szöveg?
Title: Re: Grafikai trükkök
Post by: endi on 2016.April.10. 10:12:33
két dolog van, az egyik az általános sor felépítés, itt határozzuk meg a sor magasságát. ez az exosban 9 sor. de bármilyen program beállíthat mást, és játékokban pl máshogy van
az meg hogy milyen magas egy karakter, függ attól is milyet rajzolsz. 9 sorosba is rajzolhatsz kevesebbet, meg változót is. végül is a kisbetűk is kisebbek mint a nagybetűk... ja és igazából ügye a 9 sor azért van az exosban, mert egyik sor üres, tehát a karakterek alapból grafikailag 8 vagy kevesebb sorosak
Title: Re: Grafikai trükkök
Post by: endi on 2016.April.12. 17:53:42
az a karakteres robbanás grafikus képernyőn
majd még fejlesztgetem :)
space-ra új robbanás, és persze max emu sebességgel jó csak
Title: Re: Grafikai trükkök
Post by: endi on 2016.April.21. 20:16:24
ilyeneket a demóimban szoktam használni annak idején. akkor is basic-el rajzoltattam meg és képként töltöttem be a demókban

jó sokáig tartott annak idején kirajzoltatni ezeket :) akkoriban ez volt a renderelés
Title: Re: Grafikai trükkök
Post by: geco on 2016.April.22. 08:44:03
ilyeneket a demóimban szoktam használni annak idején. akkor is basic-el rajzoltattam meg és képként töltöttem be a demókban
jó sokáig tartott annak idején kirajzoltatni ezeket :) akkoriban ez volt a renderelés
Jó lett, ne is mondd, a C64, és PC képkonverziót én is Basic programmal csináltam anno, eltartott jópár órán keresztül, mire az összeset sikerült átkonvertálni :D
Title: Re: Grafikai trükkök
Post by: IstvanV on 2016.April.22. 18:55:55
jó sokáig tartott annak idején kirajzoltatni ezeket :) akkoriban ez volt a renderelés

C változat z88dk-val fordítva:

[attachurl=1]
[attachurl=2]

zcc.exe +enterprise -lm -create-app -O3 -DFASTMATH -oplazma plazma.c

Valamivel gyorsabb, de az EXOS hívásokkal pixelenként történő rajzolás nélkül valószínűleg lehetne jobb is. :oops:
Title: Re: Grafikai trükkök
Post by: endi on 2016.April.22. 19:14:02
hát igen, ilyesmiket nem érdemes átírni c-be se... :)
Title: Re: Grafikai trükkök
Post by: IstvanV on 2016.April.23. 11:50:26
hát igen, ilyesmiket nem érdemes átírni c-be se... :)

A main() függvény nem sokkal bonyolultabb a BASIC verziónál, a forráskód jelentős részét a video rutinok teszik ki. Ezeket azonban más programokban újra fel lehet használni. Továbbfejlesztett változat, amely az EXOS escape szekvenciákat puffereli és letiltja a megszakításokat a BASIC-ben használt POKE 56, 201 megoldáshoz hasonlóan, illetve Space, Escape, vagy Stop billentyűre kilép:

[attachurl=1]
[attachurl=2]
[attachurl=3]
Title: Re: Grafikai trükkök
Post by: endi on 2016.April.23. 13:06:52
hát igen, sebességhez el lehet felejteni az exost

amúgy emlékszem, annak idején próbálkoztam kicsit "matekosabb" effektekkel is (szinusz stb felhasználásával), csak hát ügye ott már aztán totál lassú lett. és ez az oka annak hogy nem is nagyon értek ezekhez, mert nem tudtam megtanulni emiatt.

persze karikákat meg spirált rajzoltattam én is, csak hát az demó effektnek kevés :)
Title: Re: Grafikai trükkök
Post by: IstvanV on 2016.April.23. 17:34:52
amúgy emlékszem, annak idején próbálkoztam kicsit "matekosabb" effektekkel is (szinusz stb felhasználásával), csak hát ügye ott már aztán totál lassú lett.

A szögfüggvényekhez érdemesebb lehet táblázatot használni, mint például az itt (https://enterpriseforever.com/programozas/fraktalok-assemblyben/msg35541/#msg35541) található fraktál programokban. Ezeknél a táblázat felbontása 360/256 fok, és egész számos aritmetikát használnak, de ez is elfogadható eredményt ad.
Title: Re: Grafikai trükkök
Post by: endi on 2016.April.23. 17:55:47
A szögfüggvényekhez érdemesebb lehet táblázatot használni, mint például az itt (https://enterpriseforever.com/programozas/fraktalok-assemblyben/msg35541/#msg35541) található fraktál programokban. Ezeknél a táblázat felbontása 360/256 fok, és egész számos aritmetikát használnak, de ez is elfogadható eredményt ad.

ja hát az asm demóimban már én is így csináltam
kisebbeket kézzel is megírtam (pl raszter bar fel-le mozgás) :)

Title: Re: Grafikai trükkök
Post by: endi on 2016.May.29. 16:51:21
egy kis line style trükk
Title: Re: Grafikai trükkök
Post by: Lacika on 2016.May.29. 17:41:10
Ugyanaz Pascalban.
2*PI a teljes kör, így nem marad ki egy vékony cikk. Lores 2-ben gyorsabb.
Title: Re: Grafikai trükkök
Post by: endi on 2016.May.31. 19:55:19
egy érdekes demó effekt lehetne, hogy fogunk képeket és az epimgconv-al csinálunk belőlük 2 szín, attr és 256 szín módú verziókat és úgy jelenítjük meg a képet hogy ezeket a verziókat soronként random változtatjuk
Title: Re: Grafikai trükkök
Post by: endi on 2016.May.31. 23:45:29
line style értékek sorba rakva "világosság" szerint
aztán kirajzolva vízszintesen, függőlegesen, xor-al
szép minta :)
Title: Re: Grafikai trükkök
Post by: endi on 2016.June.02. 11:21:15
ilyet hogy lehetne basicben?
van ott kód is, aki jobb matekból, biztos egyből tudja :)
https://en.wikipedia.org/wiki/Floyd–Steinberg_dithering (https://en.wikipedia.org/wiki/Floyd–Steinberg_dithering)
Title: Re: Grafikai trükkök
Post by: ergoGnomik on 2016.June.03. 09:26:22
ilyet hogy lehetne basicben?
van ott kód is, aki jobb matekból, biztos egyből tudja :)
https://en.wikipedia.org/wiki/Floyd–Steinberg_dithering (https://en.wikipedia.org/wiki/Floyd–Steinberg_dithering)
Ez nem teljesen világos hogy mire is lenne jó a lassú BASIC-ben. Szerintem sokkal többre lehetne jutni egy betölthető IView BASIC bővítővel és IstvanV képkonverterével, ami elvégzi ezt a fajta szűrést a Nick korlátainak figyelembevételével.
Title: Re: Grafikai trükkök
Post by: endi on 2016.June.04. 09:49:25
Ez nem teljesen világos hogy mire is lenne jó a lassú BASIC-ben. Szerintem sokkal többre lehetne jutni egy betölthető IView BASIC bővítővel és IstvanV képkonverterével, ami elvégzi ezt a fajta szűrést a Nick korlátainak figyelembevételével.

azért lenne jó mert jó szórakozás ilyesmiket programozni.
pl annak idején írtam egy rajzolóprogramot, amiben box-okat lehetett random dithereléssel rajzolni
ennek a demómnak a képei ezzel készültek: http://www.ep128.hu/Ep_Demo/Leiras/Ork_Demo2.htm
mondjuk pont ezeken a képeken nem látszik ez a box dolog
Title: Re: Grafikai trükkök
Post by: endi on 2016.June.12. 23:10:48
ep logo
sajna csak gyorsított emuval szép :)
de meg lehetne csinálni gyorsabbra
Title: Re: Grafikai trükkök
Post by: endi on 2016.June.12. 23:14:05
itt egy mozgós verzió
Title: Re: Grafikai trükkök
Post by: szipucsu on 2016.June.13. 14:59:28
ep logo
Azt bírom ezekben a programokban, hogy kilistázom, arra számítok, jó hosszú lesz, és szinte egy képernyőn is elfér a lista. Bezzeg amikor az ember telerak extrákkal egy alapból már működő programot (pl. Bomber), akkor az négyszeresére is meghízik.

Ha a sok DIM egy sorban lenne, még kisebb is lenne. Bár jelentősége nincs. Én úgy szoktam, hogy ha kell közben egy újabb változó, akkor oda a DIM sor végére beírom.
Title: Re: Grafikai trükkök
Post by: Lacika on 2016.June.13. 16:47:50
Az RGB függvény hogy számol? Hisoft-Pascal-ban mér jó lenne a sebesség...
Title: Re: Grafikai trükkök
Post by: endi on 2016.June.13. 18:24:43
Az RGB függvény hogy számol? Hisoft-Pascal-ban mér jó lenne a sebesség...

0-1-ig lehet beadni neki r g b értékeket
Title: Re: Grafikai trükkök
Post by: IstvanV on 2016.June.13. 18:42:35
ilyet hogy lehetne basicben?
van ott kód is, aki jobb matekból, biztos egyből tudja :)

Nagyon lassú és nem biztos, hogy hibátlan: :oops:
[attachurl=1]
Ez egyszerűbb megoldás, mint ami az epimgconv (https://enterpriseforever.com/egyeb-temak/pc-gt-ep-kepkonverzio/msg23520/#msg23520)-ban található, nem használ például soronként változó irányt, és nem támogatja a -dither-nél megadható paramétert sem. Egész számokkal és Zzzip-elve, vagy C nyelven talán használhatóbb sebességű lenne. :)
Title: Re: Grafikai trükkök
Post by: Lacika on 2016.June.13. 20:20:19
0-1-ig lehet beadni neki r g b értékeket

Azt tudom, de hogy lesz belőle színkód? Le kellene programozni PASCAL-ban.
Title: Re: Grafikai trükkök
Post by: endi on 2016.June.13. 20:24:57
Azt tudom, de hogy lesz belőle színkód? Le kellene programozni PASCAL-ban.

hát 3 bit red, 3 bit green, 2 bit blue
asszem így, de nem biztos: rgbrgbrg
Title: Re: Grafikai trükkök
Post by: IstvanV on 2016.June.13. 20:41:17
hát 3 bit red, 3 bit green, 2 bit blue
asszem így, de nem biztos: rgbrgbrg

G0*128 + R0*64  + B0*32  + G1*16  + R1*8  + B1*4  + G2*2  + R2
Title: Re: Grafikai trükkök
Post by: endi on 2016.June.14. 00:05:57
ha nem randommal indítom akkor szépen futnak a színek :)
Title: Re: Grafikai trükkök
Post by: Ep128 on 2016.June.14. 00:11:02
ha nem randommal indítom akkor szépen futnak a színek :)
Ez tetszik! :-) (Most már "csak" meg kellene írni normális sebességben valami más nyelven. :-D ;-) )
Title: Re: Grafikai trükkök
Post by: szipucsu on 2016.June.14. 08:31:37
ha nem randommal indítom akkor szépen futnak a színek :)
Jobb lenne, ha nem jobbról balra, hanem balról jobbra futna át rajta a hullám.
Lehetne olyat is, hogy mindkét irányból fut.
Ezek váltakoznának mondjuk percenként, és az eredeti is játszana.
Utána át lehet írni a memóriában a kezdőképet a sokadik exos verzióhoz.
Title: Re: Grafikai trükkök
Post by: IstvanV on 2016.June.14. 09:58:13
Valamivel gyorsabb változat a következő színek számítását a belső cikluson kívül megoldva, de ez is csak kb. 10-szeres sebességnél fut elfogadhatóan: :)

[attachurl=1]

Floyd-Steinberg dither C-ben, 4 színű módban:

[attachurl=2]

Forráskód (az itt (https://enterpriseforever.com/programozas/c-origramozas-aztec-c-hisoft-c/msg51763/#msg51763) leírt módon fordítható SDCC-vel):

[attachurl=3]
[attachurl=4]
[attachurl=5]
Title: Re: Grafikai trükkök
Post by: endi on 2016.June.14. 12:14:54
komoly ez a dither
kár hogy lassú
Title: Re: Grafikai trükkök
Post by: IstvanV on 2016.June.14. 15:19:36
komoly ez a dither
kár hogy lassú

Valószínűleg lehetne még gyorsítani rajta :oops:, bár a futásidő jelentős részét úgy látszik, a pixel rajzolás (EXOS VIDEO: eszköz) teszi ki, a C verzió 526.8 másodperc alatt fut le, a draw_pixel() függvényt hívó CALL utasítás törlése után azonban "csak" 81.3 másodperc. A program puffereli az escape szekvenciákat, amitől elvileg gyorsul a rajzolás, de jobb eredményt lehetne elérni saját (assembly ?) pixel rutinnal.
Title: Re: Grafikai trükkök
Post by: endi on 2016.June.14. 15:41:32
Valószínűleg lehetne még gyorsítani rajta :oops:, bár a futásidő jelentős részét úgy látszik, a pixel rajzolás (EXOS VIDEO: eszköz) teszi ki, a C verzió 526.8 másodperc alatt fut le, a draw_pixel() függvényt hívó CALL utasítás törlése után azonban "csak" 81.3 másodperc. A program puffereli az escape szekvenciákat, amitől elvileg gyorsul a rajzolás, de jobb eredményt lehetne elérni saját (assembly ?) pixel rutinnal.

na ez érdekes, ez az esc pufferelés, bár gondolom sokat az se gyorsít
Title: Re: Grafikai trükkök
Post by: Zozosoft on 2016.June.14. 15:55:58
Anélkül szerintem még 5x lassabb lenne.
Title: Re: Grafikai trükkök
Post by: endi on 2016.June.14. 16:14:59
Anélkül szerintem még 5x lassabb lenne.

ja lehet, de 1-1 pixel kirajzolásán gyorsít szerintem főleg
tegyük fel hogy egy basic játékban a mozgó figurákat pufferelnénk, az tuti nem számítana sokat
Title: Re: Grafikai trükkök
Post by: Lacika on 2016.June.14. 16:59:10
Ez tetszik! :-) (Most már "csak" meg kellene írni normális sebességben valami más nyelven. :-D ;-) )

Ha Hisoft-Pascalban tudnánk csinálni RGB függvényt, sima ügy lenne.
Title: Re: Grafikai trükkök
Post by: Zozosoft on 2016.June.14. 19:24:00
Ha Hisoft-Pascalban tudnánk csinálni RGB függvényt, sima ügy lenne.
István leírta a képletet.
Title: Re: Grafikai trükkök
Post by: IstvanV on 2016.June.14. 19:47:06
na ez érdekes, ez az esc pufferelés, bár gondolom sokat az se gyorsít

A pufferelést letiltva 598.4 másodperc alatt fut le 526.8 helyett, meglepően lassú a pixelek rajzolása.

Logo effektus C-ben:
[attachurl=1]

Forráskód (tartalmaz RGB függvényt is :)), a fordításhoz szükséges többi file itt (https://enterpriseforever.com/programozas/grafikai-trukkok/msg56358/#msg56358) és itt (https://enterpriseforever.com/programozas/c-origramozas-aztec-c-hisoft-c/msg51763/#msg51763) található:
[attachurl=2]
Title: Re: Grafikai trükkök
Post by: endi on 2016.June.14. 19:59:32
na ez tök jó már
Title: Re: Grafikai trükkök
Post by: IstvanV on 2016.June.15. 09:52:41
Még lehet rajta gyorsítani a memória várakozás és az EXOS megszakításkezelőjének a letiltásával:
Code: [Select]
O BF 0C
A 38 RET
Title: Re: Grafikai trükkök
Post by: gflorez on 2016.June.15. 13:54:41
Gyönyörű!

Tedd a Space-Fires-MouseClick csekket, és tökéletes lesz minden program bemutatása.

----------------------------------

Beautiful!

Put a Space-Fires-MouseClick check and it will be perfect for any program presentation.
Title: Re: Grafikai trükkök
Post by: IstvanV on 2016.June.16. 10:31:11
Anélkül szerintem még 5x lassabb lenne.

Karakterenként írva EXOS 7 hívásokkal valóban sokkal lassabb lenne, de a "nem pufferelt" verzió is blokk írást használ, csak minden pixel egy blokk. Azonban a VIDEO: eszköz mindig karakterenként dolgozza fel az escape szekvenciákat, a 00:D200h címnél található ciklus hívja a D4D0h-nál kezdődő karakter írás rutint. Talán lehetne azonban egyszerűsíteni a kiírt szekvenciát:

Esc I <szín> Esc A <xl> <xh> <yl> <yh> Esc S Esc s

ez 13 byte, de estleg a sugár kikapcsolása elkerülhető lenne (bár az elvileg vonalat rajzol) ? Szerk.: ezzel a megoldással (csak Esc A és Esc I) 421.7 másodperc lenne a futásidő 526.8 helyett, a megszakításkezelést és memória várakozást is letiltva pedig 297.3 másodperc.
Title: Re: Grafikai trükkök
Post by: endi on 2016.November.01. 15:25:09
demó effekt ötlet:
-fogunk egy jó képet és epimgconv-al csinálunk belőle hires256, hires16, attr és hires2 módú képeket.
-ezután ezeket a képeket váltogatjuk mindenféle módon:
  -oda vissza, tehát hires256, hires16, attr, hires2, attr, hires16, hires256, ezáltal olyan hatást érünk el hogy a pixelek nőnek-csőkkennek
  -soronként random váltjuk a képeket
  -egy fel-le mozgó, 30-40 sor magas tömb amiben más-más módot mutatunk
  -több fel le mozgő tömb, amikben más-más módot mutatunk
stb stb :)
Title: Re: Grafikai trükkök
Post by: Ep128 on 2016.November.02. 00:55:05
demó effekt ötlet:
-fogunk egy jó képet és epimgconv-al csinálunk belőle hires256, hires16, attr és hires2 módú képeket.
-ezután ezeket a képeket váltogatjuk mindenféle módon:
  -oda vissza, tehát hires256, hires16, attr, hires2, attr, hires16, hires256, ezáltal olyan hatást érünk el hogy a pixelek nőnek-csőkkennek
  -soronként random váltjuk a képeket
  -egy fel-le mozgó, 30-40 sor magas tömb amiben más-más módot mutatunk
  -több fel le mozgő tömb, amikben más-más módot mutatunk
stb stb :)

2-3 naponta hozod a (valóban!) jó 5leteket, de legalább a felét meg is csinálnád már... :-)
Title: Re: Grafikai trükkök
Post by: IstvanV on 2016.November.03. 21:21:56
demó effekt ötlet:
-fogunk egy jó képet és epimgconv-al csinálunk belőle hires256, hires16, attr és hires2 módú képeket.
-ezután ezeket a képeket váltogatjuk mindenféle módon:
  -oda vissza, tehát hires256, hires16, attr, hires2, attr, hires16, hires256, ezáltal olyan hatást érünk el hogy a pixelek nőnek-csőkkennek
  -soronként random váltjuk a képeket
  -egy fel-le mozgó, 30-40 sor magas tömb amiben más-más módot mutatunk
  -több fel le mozgő tömb, amikben más-más módot mutatunk
stb stb :)

[attachurl=1]

A fordításhoz sjasm 0.39g6 (http://xl2s.eu.pn/sjasm.html), epimgconv és epcompress (https://github.com/istvan-v/ep128emu/releases/tag/2.0.10-beta_20161102) kell, a képet 5 különböző módban konvertálva:

-mode 0 -size 32 192 -palres 0 -quality 9 -outfmt 1 hires2.pic
-mode 1 -size 32 192 -palres 0 -quality 9 -outfmt 1 hires4.pic
-mode 4 -size 32 192 -palres 0 -quality 9 -outfmt 1 hires16.pic        (itt lassú gépeken -quality 9 nélkül célszerű konvertálni, vagy -mode 3 használatával)
-mode 6 -size 32 192 -palres 0 -bias B -quality 9 -outfmt 1 attr16.pic
-mode 5 -size 32 192 -palres 0 -quality 9 -outfmt 1 hires256.pic

Az attribútum módú képnél a "B" a 16 színű bias értéke, ez ugyanis nem lehet különböző a képeken. A konvertálás után következhet a fordítás (sjasm), majd a program tömörítése (epcompress), mivel egyébként a nagy mérete miatt nem lehet betölteni.

A program futása a Space vagy Esc billentyűvel szakítható meg, a reset nem működik, mert a rendszerszegmens tartalmát elrontja (de menti és kilépéskor visszaállítja). Az 5 kép és az LPT több, mint 63 KB video memóriát fogyaszt, ezért nem lett teljesen EXOS kompatibilis, jobban megírt program csak egy képet tárolna a video RAM-ban. :oops: Ez könnyen megoldható lenne, mert egyszerre csak egy sor változik, tehát nem kellene sokat másolni.
Title: Re: Grafikai trükkök
Post by: endi on 2016.November.04. 10:02:37
pc-n lehet ep-re fordítani? :)
bocs, biztos le vagyok maradva.

és nem nem nem neeeem fogok asm-ban dolgozni, nem. ne kísértsetek :)
Title: Re: Grafikai trükkök
Post by: geco on 2016.November.04. 11:39:29
Itt nem kell ASM-ban programoznod, elég csak befordítanod a képekkel együtt, és futtathatod is, mindezt PC-n :D
Title: Re: Grafikai trükkök
Post by: endi on 2016.November.04. 13:53:30
Itt nem kell ASM-ban programoznod, elég csak befordítanod a képekkel együtt, és futtathatod is, mindezt PC-n :D

de ez most a demó effekt amit leírtam?
asm forrást látom csak, futtathatót nem
Title: Re: Grafikai trükkök
Post by: geco on 2016.November.04. 14:26:00
de ez most a demó effekt amit leírtam?
asm forrást látom csak, futtathatót nem
Mert azt neked kéne befordítani SJASM-mal, de előtte legenerálni a képeket a következő neveken:

 "hires256.pic"
 "hires16.pic"
 "attr16.pic"
 "hires4.pic"
 "hires2.pic"
Title: Re: Grafikai trükkök
Post by: endi on 2016.November.04. 15:19:40
Mert azt neked kéne befordítani SJASM-mal, de előtte legenerálni a képeket a következő neveken:

én nem tudom mi az a sjasm, de nem is akarom tudni :)
Title: Re: Grafikai trükkök
Post by: lgb on 2016.November.04. 18:13:28
én nem tudom mi az a sjasm, de nem is akarom tudni :)

Nemakarasnak .... sjasm a vege :)
Title: Re: Grafikai trükkök
Post by: endi on 2016.November.04. 18:19:52
Nemakarasnak .... sjasm a vege :)

ne kísérts! távozz tőlem gépi kód! :)
Title: Re: Grafikai trükkök
Post by: endi on 2016.November.04. 19:06:36
áááá nem igaz, nem igaz. letöltöttem a sjasmot... nem nem nem
Title: Re: Grafikai trükkök
Post by: endi on 2016.November.04. 19:12:29
az új sjasm-al lefordítva nem műxik, azzal amit megadtál meg ezt a hibát dobja:

---------------------------
Microsoft Visual C++ Debug Library
---------------------------
Debug Assertion Failed!

Program: C:\!\sjasm\sjasm.exe
File: fopen.c
Line: 54

Expression: *file != _T('\0')

For information on how your program can cause an assertion
failure, see the Visual C++ documentation on asserts.

(Press Retry to debug the application)
---------------------------
Leállítás   Ismét   Kihagyás   
---------------------------
Title: Re: Grafikai trükkök
Post by: Zozosoft on 2016.November.04. 19:35:34
az új sjasm-al lefordítva nem műxik, azzal amit megadtál meg ezt a hibát dobja:
Írva volt, hogy sjasm 0.39g6 kell.

"Sjasm 0.42 is not 100% compatible with version 0.3x." Ezt mondjuk nem értem miért kellett így elrontani :evil:
Title: Re: Grafikai trükkök
Post by: endi on 2016.November.04. 19:43:24
Írva volt, hogy sjasm 0.39g6 kell.

"Sjasm 0.42 is not 100% compatible with version 0.3x." Ezt mondjuk nem értem miért kellett így elrontani :evil:

ezt mondom, hogy a megadott verzióval kidobja fordításra azt a hibát.
a legújabb meg lefordítja de emuban futtatva csak fagyi van
Title: Re: Grafikai trükkök
Post by: ergoGnomik on 2016.November.04. 20:06:09
az új sjasm-al lefordítva nem műxik, azzal amit megadtál meg ezt a hibát dobja:

---------------------------
Microsoft Visual C++ Debug Library
---------------------------
Debug Assertion Failed!

Program: C:\!\sjasm\sjasm.exe
File: fopen.c
Line: 54

Expression: *file != _T('\0')

For information on how your program can cause an assertion
failure, see the Visual C++ documentation on asserts.

(Press Retry to debug the application)
---------------------------
Leállítás   Ismét   Kihagyás  
---------------------------
Első, felületes ránézésre valami fájlnevet hiányolhat. Ki kellene olvasni a parancssori paraméterek és kapcsolók specifikációját, hogy vajon mi maradhatott ki?
Title: Re: Grafikai trükkök
Post by: endi on 2016.November.04. 20:31:34
nem tudom. a legújabb nem ír semmi hibát, el is készül az ep-n futtatható cucc, ami el is indul de némi grafikai zajt kirajzolva lefagy.
Title: Re: Grafikai trükkök
Post by: endi on 2016.November.04. 20:32:30
itt van az amit az új sjasm fordított +képek:
Title: Re: Grafikai trükkök
Post by: IstvanV on 2016.November.04. 21:47:58
Valószínűleg az assembler nem találta a képeket, ha egyébként megfelelő verziójú. Nekem nem volt probléma a képeket a vmodes.s mellé másolva sjasm 0.39g6 verzióval:

[attachurl=1]

De az attribútum módú képnél lehet, hogy nem jó a BIAS, ennek azonosnak kell lennie a 16 színűével, a program csak az utóbbinál veszi figyelembe, mivel nem tud egyszerre több BIAS-t megjeleníteni (bár ez egyébként lehetséges lenne megszakítással időzítve a port írását).
Title: Re: Grafikai trükkök
Post by: endi on 2016.November.04. 21:55:48
ja hogy a fordításnál mellé kell rakni a képeket, aha, így lefordul, de nekem ez se fut
amit te fordítottál az jó, bár látom nincs soronkénti színváltás benne, pedig az lenne a lényeg :)

na majd még próbálkozok a fordítással is, csak nehogy az legyen a vége hogy asm-ban kezdek megint dolgozni :D
Title: Re: Grafikai trükkök
Post by: Zozosoft on 2016.November.04. 22:05:39
ja hogy a fordításnál mellé kell rakni a képeket, aha, így lefordul, de nekem ez se fut
Be kell még tömöríteni epcompress-el.


Quote
nehogy az legyen a vége hogy asm-ban kezdek megint dolgozni :D
De, az legyen a vége! :-)
Title: Re: Grafikai trükkök
Post by: endi on 2016.November.04. 23:11:01
inkább írom az ötleteket ti meg megcsináljátok :)

újabb ötletem: col16 módban a 8 palettaszínből feltöltjük a képernyőt úgy, hogy balról jobbra dithereve!
aztán ezen a 8 színen raszter bar-okat mozgatunk, de kis fázis eltolással. olyan lenne mintha elgörbülne a raszter bar (ilyet csináltam egyik demómban), de a dither miatt a görbülés nem éles! látványos lenne.
Title: Re: Grafikai trükkök
Post by: Ep128 on 2016.November.04. 23:27:13
inkább írom az ötleteket ti meg megcsináljátok :)

újabb ötletem: col16 módban a 8 palettaszínből feltöltjük a képernyőt úgy, hogy balról jobbra dithereve!
aztán ezen a 8 színen raszter bar-okat mozgatunk, de kis fázis eltolással. olyan lenne mintha elgörbülne a raszter bar (ilyet csináltam egyik demómban), de a dither miatt a görbülés nem éles! látványos lenne.

Endi elmész már valahová... :-D ;-) Illetve nem, épp ez az! Odamegyek és nem mész sehová, leláncollak egy Turbo Asmon elé néhány napi hideg élelemmel! :-D
Title: Re: Grafikai trükkök
Post by: Ep128 on 2016.November.04. 23:28:54
Amúgy meg ott a HEASS, ha az jobban tetszik! :-D
Title: Re: Grafikai trükkök
Post by: endi on 2016.November.05. 00:31:42
a ditheres rasztercsíkos ötlet: hires2-ben alulról felfelé dithereljük a két színt. két rasztercsík indul el, egyik alulról, másik felülről, és ahogy összeérnek, ditherelve egymásba olvadnak...
hm... ezek tök jó új ötletek... úgy látszik mindig ki lehet újat találni.
Title: Re: Grafikai trükkök
Post by: szipucsu on 2016.November.05. 17:32:06
én nem tudom mi az a sjasm
Nekem is kínai. Pontosabban a sjasm szónak kissé svéd beütése van inkább.
Title: Re: Grafikai trükkök
Post by: endi on 2016.November.05. 17:34:18
Nekem is kínai. Pontosabban a sjasm szónak kissé svéd beütése van inkább.

pc-n lehet fordítani vele z80-as kódot, pl ep-re. igazából tök jó.
Title: Re: Grafikai trükkök
Post by: lgb on 2016.November.05. 21:47:45
áááá nem igaz, nem igaz. letöltöttem a sjasmot... nem nem nem

Hehehehheeeee, atkom megfogant rajtad :-D
Title: Re: Grafikai trükkök
Post by: lgb on 2016.November.05. 22:31:21
Nekem is kínai. Pontosabban a sjasm szónak kissé svéd beütése van inkább.

Sjoerd Mastijn irta, talan azert van "sj" az "asm" elott. Mondjuk csak tippelek, nem biztos. Bar a "Sjoerd" is eleg svedes (vagy "norvegos") mondjuk fogalmam sincs, hogy ki o ...
Title: Re: Grafikai trükkök
Post by: ergoGnomik on 2016.November.06. 10:35:05
áááá nem igaz, nem igaz. letöltöttem a sjasmot... nem nem nem
Nincs mit tenni. Z80 assembly is the new black. ;-)
Title: Re: Grafikai trükkök
Post by: szipucsu on 2016.November.06. 11:29:24
pc-n lehet fordítani vele z80-as kódot, pl ep-re. igazából tök jó.
DEF OFF
Nem láttam az újabb hozzászólásokat. Valószínű az oldal tetején voltam, de volt még egy oldal, ami nem tűnt fel. Ezért voltam még lemaradva a témához képest. Azt hiszem, mással is lehetett már ilyen, én is néztem, mint a moziban, hogy minek kérdez olyat, amit az előbb már leírtak.
END OFF
CALL OFF
END
ok
és okozat
Title: Re: Grafikai trükkök
Post by: endi on 2016.November.13. 21:18:38
egyszerű kis graf trükk!
van ez az oldal ami a beírt szövegből ascci art-ot csinál, azaz a betűket kirajzolja jelekből: http://patorjk.com/software/taag/#p=display&h=3&f=Crawford2&t=ENTERPRISE

a mellékelt kép pedig azt mutatja hogy betöltöttem basic-be!
de lehet szebbet is, most próbálgatom a lehetőségeket
Title: Re: Grafikai trükkök
Post by: endi on 2016.November.13. 21:29:02
az a baj a szebbek jó nagyok, így nem fér ki csak pár betű
Title: Re: Grafikai trükkök
Post by: szipucsu on 2016.November.13. 22:12:08
az a baj a szebbek jó nagyok, így nem fér ki csak pár betű
Esetleg scrollozással lehetne trükközni? Több videólap kéne hozzá, és azokat váltogatni.
Title: Re: Grafikai trükkök
Post by: endi on 2016.November.14. 17:09:37
Esetleg scrollozással lehetne trükközni? Több videólap kéne hozzá, és azokat váltogatni.

vannak filmek is ascii animációval, pl star wars :)
http://www.asciimation.co.nz/#
Title: Re: Grafikai trükkök
Post by: lgb on 2016.November.14. 17:21:35
vannak filmek is ascii animációval, pl star wars :)
http://www.asciimation.co.nz/#

Az volt (szamomra ...) vicces, amikor hasonlok voltak (meg biztos ma is van) telnet-tel, szoval ratelneteltel neten at valami tavoli gepre, es shell helyett nezhetted a movie-t :)

A masik, mplayer amugy (win alatt nem tudom) tamogatja az "aa" video driver-t, amivel barmilyen filmet (amit le tud amugy jatszani "normalisan" is ...) ascii-ba renderelve lehet megtekinteni :D Ez akkoriban volt vicces, amikor meg csak dialup volt otthon, es melohelyrol fel akartam venni a TV-bol egy musort (tv tuner kartyaval), amde nem tudtam, pontosan mikor kezdodik. Szoval neten at beleptem az otthoni gepre (persze foleg a savszelesseg miatt szo sem lehetett mai ertelemben vett "grafikus" remote desktop vagy barmi hasonlo megoldasrol!), ott mplayer-rel a fenti "aa" driver-rel neztem a tv-tuner kartyarol jovo cuccot :-P aztan amikor "ugy tunt" az alapjan (ezt azert neha nehez megmondani hehe), hogy kezdododik, akkor elinditottam a rogzitest (ami persze "normalis" video formatumba mentette, csak azt tavolrol nezni dialup felett nem igazan lehetett).
Title: Re: Grafikai trükkök
Post by: endi on 2016.December.08. 13:34:29
van ez a marha jó bias scroll effekt. na ezzel lehetne egy oldal scrollos játékot, amiben a háttér lenne ez a bias scroll. persze kis felbontás, de látványos lenne.
persze lehet hogy sok cpu időt visz el, de szerintem egy űrhajó meg pár ellenség sprite elférne még

https://www.youtube.com/watch?v=XUb2FhD1l3Y&t=11s
Title: Re: Grafikai trükkök
Post by: endi on 2017.July.16. 09:23:08
mi az lpt-ben a "vertical resolution - teljes függőleges felbontást engedélyez"?
ez az interlace?
Title: Re: Grafikai trükkök
Post by: IstvanV on 2017.July.16. 11:40:40
mi az lpt-ben a "vertical resolution - teljes függőleges felbontást engedélyez"?

Ha 0, akkor az LPB-n belül minden sorban újratöltődik (ismétlődik) az LD1 cím.

Szerk.: az interlace az más, ehhez 625 soros LPT-re van szükség, a két VSYNC között 312.5 sor távolsággal. A lényeg, hogy az egyik fél sorral el legyen tolva.
Title: Re: Grafikai trükkök
Post by: endi on 2017.July.16. 17:55:00
Ha 0, akkor az LPB-n belül minden sorban újratöltődik (ismétlődik) az LD1 cím.

aha, már dereng :)
Title: Re: Grafikai trükkök
Post by: endi on 2017.July.26. 23:32:03
max z80 frekivel használható csak, vagy alt+w
joy-al lehet irányítani
semmit extra, húzza a falat :)
Title: Re: Grafikai trükkök
Post by: szipucsu on 2017.July.27. 00:12:47
joy-al lehet irányítani
Amit te rajzoltál vele eddig, az elmegy, de ahogy én folytattam, az köszönőviszonyban sincs a művészettel.
Title: Re: Grafikai trükkök
Post by: Povi on 2017.September.15. 12:51:57
van-e valami trükk villogás mentes sprite rajzolásra?

4 színű, 16x16 pixeles (4x16 byte) méretről van szó, de egy helyben állva is izgő-mozgó, szóval minden fázisnál törlés, majd újra rajzolás

képernyő tetején villog (gondolom, pont akkor ér oda a sugár) az alsóbb sorokban már szép

egy halt-ot tettem a törlés elé

ha a rajzolás elé is teszek halt-ot, akkor folyamatosan villog
Title: Re: Grafikai trükkök
Post by: Zozosoft on 2017.September.15. 13:04:30
Spritéhez nem értek :oops: De egy trükk ami segíthet némi időt nyerni:

A klasszikus LPT felépítése ez: felső keret, kép, alsó keret, szinkronizáció (esetleg: kép, alsó keret, szinkronizáció, felső keret).
Ehelyett így célszerű: alsó keret, szinkronizáció, felső keret, kép
A lényeg, hogy a kép végén történjen a videó megszakítás, a lehető legtöbb idő álljon rendelkezésre mielőtt újra a kép megjelenítéséhez érne.
Title: Re: Grafikai trükkök
Post by: IstvanV on 2017.September.15. 13:13:35
Ha nem lehet elég gyorsra írni a rajzolást ahhoz, hogy a képernyő felső része előtt befejeződjön (a felhasználható idő maximalizálása céljából érdemes a megszakítást a lehető legkorábbra helyezni, például az alsó keret elé, vagy ha a képernyő alsó részén pontszámkijelzés található, akkor akár már oda), akkor két video lap használata lehet a megoldás, így működik például a Skramble is. Azaz mindig arra a lapra kell rajzolni, amelyik éppen nem látható, és a megszakításnál váltani kell a megjelenítésüket. Így közel 100% CPU idő használható villogás nélkül, de kétszeres lesz a video memória fogyasztás, és késést ad a megjelenítéshez (azaz hosszabb idő telik el a billentyűzet bemenet és a sprite látható elmozdulása között).
Title: Re: Grafikai trükkök
Post by: Povi on 2017.September.15. 13:21:19
Ha nem lehet elég gyorsra írni a rajzolást ahhoz, hogy a képernyő felső része előtt befejeződjön (a felhasználható idő maximalizálása céljából érdemes a megszakítást a lehető legkorábbra helyezni, például az alsó keret elé, vagy ha a képernyő alsó részén pontszámkijelzés található, akkor akár már oda)

Szerintem a rajzolás elég gyors, max. 6 darab 4x16 byte-os sprite-ról lenne szó.
Ez a hova tegyem a megszakítást, és az egész LPT kérdés nekem nagyon nagy homály :oops:
Jelenleg egy 4 színű, 320x200-as képernyőt használok, azt is István valamelyik fraktál rajzoló programjából vettem ki :-)
Title: Re: Grafikai trükkök
Post by: IstvanV on 2017.September.15. 13:41:31
Jelenleg egy 4 színű, 320x200-as képernyőt használok, azt is István valamelyik fraktál rajzoló programjából vettem ki :-)

Ha ez az ep128.hu-n található Fractals.rar-ból a GRAPH.S, akkor így módosítható:

Ez az eredeti LPT, itt a VSYNC-nél van a video megszakítás:

        defb    256 - VIDEO_HEIGHT, 12h
        defb    (63 - VIDEO_WIDTH) / 2, (63 + VIDEO_WIDTH) / 2
        defw    0000h, 0000h
        defb    BG_COLOR, FG_COLOR, 0, 0, 0, 0, 0, 0
        defb    256 - ((294 - VIDEO_HEIGHT) / 2), 02h,  63, 0,  0, 0, 0, 0
        defb    0, 0, 0, 0, 0, 0, 0, 0
        defb    256 - 3, 80h,  63, 0,  0, 0, 0, 0
        defb    0, 0, 0, 0, 0, 0, 0, 0
        defb    256 - 2, 00h,  6, 63,  0, 0, 0, 0
        defb    0, 0, 0, 0, 0, 0, 0, 0
        defb    256 - 1, 00h,  63, 32,  0, 0, 0, 0
        defb    0, 0, 0, 0, 0, 0, 0, 0
        defb    256 - 3, 00h,  63, 0,  0, 0, 0, 0
        defb    0, 0, 0, 0, 0, 0, 0, 0
        defb    256 - 9, 02h,  6, 63,  0, 0, 0, 0
        defb    0, 0, 0, 0, 0, 0, 0, 0
        defb    256 - ((295 - VIDEO_HEIGHT) / 2), 03h,  63, 0,  0, 0, 0, 0
        defb    0, 0, 0, 0, 0, 0, 0, 0


Itt az alsó keret elejére kerül:

        defb    256 - VIDEO_HEIGHT, 12h
        defb    (63 - VIDEO_WIDTH) / 2, (63 + VIDEO_WIDTH) / 2
        defw    0000h, 0000h
        defb    BG_COLOR, FG_COLOR, 0, 0, 0, 0, 0, 0
        defb    256 - 1, 82h,  63, 0,  0, 0, 0, 0,  0, 0, 0, 0, 0, 0, 0, 0
        defb    256 - ((292 - VIDEO_HEIGHT) / 2), 02h,  63, 0,  0, 0, 0, 0
        defb    0, 0, 0, 0, 0, 0, 0, 0
        defb    256 - 3, 00h,  63, 0,  0, 0, 0, 0
        defb    0, 0, 0, 0, 0, 0, 0, 0
        defb    256 - 2, 00h,  6, 63,  0, 0, 0, 0
        defb    0, 0, 0, 0, 0, 0, 0, 0
        defb    256 - 1, 00h,  63, 32,  0, 0, 0, 0
        defb    0, 0, 0, 0, 0, 0, 0, 0
        defb    256 - 3, 00h,  63, 0,  0, 0, 0, 0
        defb    0, 0, 0, 0, 0, 0, 0, 0
        defb    256 - 9, 02h,  6, 63,  0, 0, 0, 0
        defb    0, 0, 0, 0, 0, 0, 0, 0
        defb    256 - ((295 - VIDEO_HEIGHT) / 2), 03h,  63, 0,  0, 0, 0, 0
        defb    0, 0, 0, 0, 0, 0, 0, 0


Egy másik lehetséges megoldás, amely nem növeli az LPT méretét (a VINT bitnek csak a lefutó éle lényeges, tehát itt is az alsó keret elején történik megszakítás):

        defb    256 - VIDEO_HEIGHT, 92h
        defb    (63 - VIDEO_WIDTH) / 2, (63 + VIDEO_WIDTH) / 2
        defw    0000h, 0000h
        defb    BG_COLOR, FG_COLOR, 0, 0, 0, 0, 0, 0
        defb    256 - ((294 - VIDEO_HEIGHT) / 2), 02h,  63, 0,  0, 0, 0, 0
        defb    0, 0, 0, 0, 0, 0, 0, 0
        defb    256 - 3, 00h,  63, 0,  0, 0, 0, 0
        defb    0, 0, 0, 0, 0, 0, 0, 0
        defb    256 - 2, 00h,  6, 63,  0, 0, 0, 0
        defb    0, 0, 0, 0, 0, 0, 0, 0
        defb    256 - 1, 00h,  63, 32,  0, 0, 0, 0
        defb    0, 0, 0, 0, 0, 0, 0, 0
        defb    256 - 3, 00h,  63, 0,  0, 0, 0, 0
        defb    0, 0, 0, 0, 0, 0, 0, 0
        defb    256 - 9, 02h,  6, 63,  0, 0, 0, 0
        defb    0, 0, 0, 0, 0, 0, 0, 0
        defb    256 - ((295 - VIDEO_HEIGHT) / 2), 03h,  63, 0,  0, 0, 0, 0
        defb    0, 0, 0, 0, 0, 0, 0, 0
Title: Re: Grafikai trükkök
Post by: Povi on 2017.September.16. 20:58:55
Itt az alsó keret elejére kerül:
Köszi, ez működik! Így nem villog! (egyelőre egy sprite-om van, kíváncsi vagyok, milyen lesz, ha a többit is kirakom)
Title: Re: Grafikai trükkök
Post by: Tomato77 on 2017.October.03. 22:11:09
Sziasztok!

Talán itt a legjobb feltenni ezt a kérdést: ha Basic-ben (vagy inkább Pascal-ban) közvetlenül szeretnék turkálni a videomemóriában poke-kal, le lehet kérdezni valahogyan a videomemória kezdő címét? Ha több grafikus lap van nyitva, honnan tudom megállapítani, hogy mondjuk pl. az 1-es video: csatornához megnyitott lap a memória melyik részén kezdődik? Gépi kódban és az EXOS memóriakezelésében egyáltalán nem vagyok járatos, ezeket a lapozásokat sem értem, hogyan működnek, vagy hogy mikor melyik 16K-s szegmenst lehet vagy kell belapozni. Egyáltalán Basic-ben vagy Pascal-ban lehet ilyeneket csinálni? A konkrét problémám az, hogy szeretnék képet betölteni gyorsan, nem pixelenként PLOT-olgatva, hanem valahogy soronként kirakva (Pascalban talán elég gyors lenne).
Title: Re: Grafikai trükkök
Post by: geco on 2017.October.04. 08:54:35
Ha jól emlékszem, akkor a következő parancs így néz ki:
10 LPTADDR=SPEEK  ( (255,16373) * 256 + SPEEK (255,16372) ) - 32768
20 LINE1ST=LPTADDR+16+4
30 ADDR1ST=SPEEK ( 255,LINE1ST+1) * 256 + SPEEK ( 255,LINE1ST)
40 ADDR2ND=SPEEK ( 255,LINE1ST+16+1) * 256 + SPEEK ( 255,LINE1ST+16)

10. sorban LPTADDR változóba bekerül az LPT címe az FF-szegmensen belül
20. LINE1ST az EXOS képernyő első sorának videócímére mutat az LPT-ben
30. ADDR1ST-ben az EXOS képernyő első sorának címe található, viszont ez még Nick cím, ki kell vonni belőle még 49152-t, ha ez negatív szám, akkor az aktuális EXOS képernyő sor nem az FF szegmensen van, ha 0-16383, akkor az FC szegmenst, ha 16384-32767, akkor az FD szegmenst, ha 32768-49151, akkor az FE szegmenst kell belapozni az adott sorba való adat íráshoz.
Title: Re: Grafikai trükkök
Post by: Povi on 2017.October.04. 11:33:49
Sziasztok!

Talán itt a legjobb feltenni ezt a kérdést: ha Basic-ben (vagy inkább Pascal-ban) közvetlenül szeretnék turkálni a videomemóriában poke-kal, le lehet kérdezni valahogyan a videomemória kezdő címét?

Az EXOS 11 pont erre való.
Code: [Select]
        ld   a, video_channel
        ld   b, 3       ; @@ADDR
        exos 11
A BC regiszterben kapod meg a videó memória címét (NICK cím, tehát abból még ki kell számolni, melyik szegmensre esik, és be kell lapozni!)

Pascal-ban: (ha el nem rontottam)
Code: [Select]
function GetVideoAddress(channel: integer) : integer;
begin
  inline(#dd,#7e,#02)       {ld a,(ix+02)};
  inline(#06,#03)           {ld b,3};
  inline(#f7,#0b)           {exos 11};
  inline(#dd,#70,#05)       {ld (ix+5),b};
  inline(#dd,#71,#04)       {ld (ix+4),c};
end;
Title: Re: Grafikai trükkök
Post by: Tomato77 on 2017.October.04. 13:22:04
@Geco: Köszönöm! Sikerült képpontokat megjeleníteni. :) A szegmens számát a Nick címből így számoltam ki: 252+INT(ADDR/16384), az ofszet-et pedig ADDR BAND 16383-mal.
Úgy látom, a sorok karaktersorokat jelentenek, ami jó, mert Basicből is karaktersoronként lehet videolapot nyitni. Feltételezem, hogy ha egymás után nyitok több videolapot, azok a memóriában is egymás után következnek. Olyankor mi történik, ha egy sor már nem fér el egy szegmensen, akkor átlóg a következőre? Tehát előfordulhat, hogy a sor első fele az egyik szegmens végén van, a másik pedig a következő szegmens elején?

@Povi: A gépi kódot egyáltalán nem értem, sajnos az ilyen hexa inline-os sorok még kommentekkel se mondanak semmit. :( Azért köszi! :)
Title: Re: Grafikai trükkök
Post by: geco on 2017.October.04. 13:33:00
Az a baj, hogy az LPT-ben nem, feltétlenül követi a következő sor a videómemóriában az előzőt, tehát akkor jársz a legjobban, ha minden LPB-ben (LPT sorban) lekérdezed annak kezdőcímét.
Title: Re: Grafikai trükkök
Post by: Tomato77 on 2017.October.04. 15:28:58
Rendben, köszönöm! Soronként fogom lekérdezni a kezdő címet.

Azt szeretném még megkérdezni, hogy ha egy videolap nem fér el a szegmensen, le lehet kérdezni, hogy a maradék része hová kerül? Pl. egy 42 karakter széles, 1 karakter magas lap 84*9, azaz 756 bájt helyet igényel. Mondjuk ha a szegmens végén már csak 500 szabad bájt van, akkor a maradék 256-ot másikon kezdi, vagy az egészet a következőn helyezi el? Nekem az előbbi lenne logikus, mert pl. egy 42*27 karakter méretű lap (20413bájt) is csak két szegmensen fér el. Jól gondolom, hogy ilyenkor a Nick címből lehet kiszámolni, hogy melyik lesz a következő szegmens és annak az elején folytatódik?

Még egyet szeretnék kérdezni: az Enterprise a szegmensek lapozásakor mit csinál? Történik olyankor 16 kilobájtnyi adatmozgás, vagy lapozáskor csak beállítja, hogy épp melyik szegmensekkel fog dolgozni, azaz gyorsan végrehajtja?
Title: Re: Grafikai trükkök
Post by: endi on 2017.October.04. 15:33:58
Még egyet szeretnék kérdezni: az Enterprise a szegmensek lapozásakor mit csinál? Történik olyankor 16 kilobájtnyi adatmozgás, vagy lapozáskor csak beállítja, hogy épp melyik szegmensekkel fog dolgozni, azaz gyorsan végrehajtja?

nincs adatmozgatás, nagyon gyors a váltás
Title: Re: Grafikai trükkök
Post by: geco on 2017.October.04. 15:44:29
Azt szeretném még megkérdezni, hogy ha egy videolap nem fér el a szegmensen, le lehet kérdezni, hogy a maradék része hová kerül? Pl. egy 42 karakter széles, 1 karakter magas lap 84*9, azaz 756 bájt helyet igényel. Mondjuk ha a szegmens végén már csak 500 szabad bájt van, akkor a maradék 256-ot másikon kezdi, vagy az egészet a következőn helyezi el? Nekem az előbbi lenne logikus, mert pl. egy 42*27 karakter méretű lap (20413bájt) is csak két szegmensen fér el. Jól gondolom, hogy ilyenkor a Nick címből lehet kiszámolni, hogy melyik lesz a következő szegmens és annak az elején folytatódik?
Nem tudom, ilyet csinál-e az EXOS, ha igen, akkor a következő lapon folytatódik, pl ha az FC szegmens végén lenne a kezdőcím, akkor az FD elején folyatatódna.
Title: Re: Grafikai trükkök
Post by: ergoGnomik on 2017.October.04. 15:46:58
Rendben, köszönöm! Soronként fogom lekérdezni a kezdő címet.

Azt szeretném még megkérdezni, hogy ha egy videolap nem fér el a szegmensen, le lehet kérdezni, hogy a maradék része hová kerül? Pl. egy 42 karakter széles, 1 karakter magas lap 84*9, azaz 756 bájt helyet igényel. Mondjuk ha a szegmens végén már csak 500 szabad bájt van, akkor a maradék 256-ot másikon kezdi, vagy az egészet a következőn helyezi el? Nekem az előbbi lenne logikus, mert pl. egy 42*27 karakter méretű lap (20413bájt) is csak két szegmensen fér el. Jól gondolom, hogy ilyenkor a Nick címből lehet kiszámolni, hogy melyik lesz a következő szegmens és annak az elején folytatódik?

Még egyet szeretnék kérdezni: az Enterprise a szegmensek lapozásakor mit csinál? Történik olyankor 16 kilobájtnyi adatmozgás, vagy lapozáskor csak beállítja, hogy épp melyik szegmensekkel fog dolgozni, azaz gyorsan végrehajtja?
A NICK nem ismeri a szegmensek fogalmát. Neki van 64kB memóriája, amit lineárisan címez. Tehát ha "átlóg" egy memóriaterület az aktuális "szegmensről", akkor az a a következő "szegmensen" folytatódik. A Z80 szempontjából, vagyis a saját programod szemszögéből ilyenkor eggyel nagyobb szegmensszámot kell választani. Kivéve persze a 255-ös szegmens esetét, mert akkor értelemszerűen a 252-esen kell folytatni. Ha jól tudom.
Title: Re: Grafikai trükkök
Post by: Tomato77 on 2017.October.04. 15:52:22
Köszönöm mindannyiótoknak a válaszokat, sokat segítettetek!
Title: Re: Grafikai trükkök
Post by: Tomato77 on 2018.January.16. 16:17:26
Sziasztok!

Megint segítséget szeretnék kérni, mert elakadtam. Továbbra is képbetöltő programon ügyködöm Pascalban, amihez saját LPT-t szeretnék használni. Odáig eljutottam, hogy az EXOS-tól kérek két videoszegmenst (FCh-t és FDh-t szokta adni), amiből az elsőnek a legelejére szeretnék egy sorparaméter táblát csinálni, utána töltöm a bittérképet. 16 bájtonként felépítem a kép sorainak megfelelően, majd az LPL és LPH regiszterekbe beírom a címet a 82h és 83h portokon keresztül és egy nagy villódzó kép lesz az eredmény. Utána hiába állítanám vissza az előző sorparaméter tábla címét (amit az FFh szegmens 16372-16373-as bájtjairól olvasok ki), marad a katyvasz meg a reset. A sorparaméter tábla végét úgy zárom le, ahogy pl. Basic-ben megnyitott videolapok után látom, azaz kiegészíti 312 sorra, meg a legvégén a RELOAD bit is be van kapcsolva az utolsó blokkban. Vajon hol rontom el?

Azt jól gondolom, hogy ha az FCh szegmens legelejére teszem az LPT-t, akkor az LPL-be és LPH-ba pont nullát kell tölteni Nick címnek? Természetesen nem akarom fixen beledrótozni a címet, csak debug-oláskor elsőre fura volt a csupa nulla. Van egy félkész, leforduló, de nem működő Pascal programom, ha valaki kíváncsi rá, később úgyis publikus lesz a kész változat. Egyébként bármikor, különösebb nehézség nélkül tudok írni leforduló, de nem működő programot. :)

Előre is köszönöm a segítséget!
Title: Re: Grafikai trükkök
Post by: geco on 2018.January.16. 16:29:15
Az DAVE 82h 83h regiszterébe nem a full Nick címet kell írni, hanem a 16-tal osztotthoz kell hozzáorolni c000h-t, tehát az FC szegmens elejéből a 82-es portra 00h-t írunk, a 83-asra pedig c0h-t, FD szegmens 4000H-jából pedig 00h 82-esre, és c4h 83-asra.
Title: Re: Grafikai trükkök
Post by: Tomato77 on 2018.January.16. 16:53:11
Kipróbáltam, de ugyanaz. Ha fixen 00h-t és C0h-t küldök, akkor is. Valamit elbénázok. Még küzdök, és köszi a választ!

A sorokat mindig ki kell egészíteni 312-re, vagy abbahagyhatom ott, ahol tetszik és onnantól border lesz?
Title: Re: Grafikai trükkök
Post by: ergoGnomik on 2018.January.16. 19:52:07
A sorokat mindig ki kell egészíteni 312-re, vagy abbahagyhatom ott, ahol tetszik és onnantól border lesz?
Mindig gondoskodnod kell arról, hogy az LPT 312 sort írjon le. Másképp meg fog változni a képfrekvencia.
Az LPT állítást pontosan úgy végzed, mint ahogyan az az EXOS könyvben le van írva? Emlékeim szerint az egyik regisztert egyszer, a másikat egynél többször kell írni, hogy korrekt legyen LPT az átállítása.
Title: Re: Grafikai trükkök
Post by: Tomato77 on 2018.January.16. 21:13:26
Az LPT állítást pontosan úgy végzed, mint ahogyan az az EXOS könyvben le van írva?

Most úgy csinálom, de megfagy. Az LPL-t küldi előbb 82h-ra, aztán az LPH-t 83h-ra úgy, hogy a 6-os és 7-es bit 0-ra állítva, majd a 6-osat 1-re állítja és újra küldi 83h-ra, aztán a 7-est is 1-re állítja és megint elküldi 83h-ra (ebből a két bitből lesz a hozzáadott C0h, amit Geco is említett). Gyanítom, hogy magát az LPT-t rontom el, úgyhogy tovább kutatom, mi lehet a baj.
Title: Re: Grafikai trükkök
Post by: Zozosoft on 2018.January.16. 21:32:46
Nézz bele a példaprogramomba. (https://enterpriseforever.com/other-topics/maybe-we-should-organize-a-gamedevcompo/?action=dlattach;attach=14058)
Title: Re: Grafikai trükkök
Post by: Tomato77 on 2018.January.16. 21:48:48
Assembly-ül nem tudok, de azért olvasható és nagyjából érthető is a kód. Meg van az esti olvasmány. :) Köszönöm mindenkinek a segítséget!
Title: Re: Grafikai trükkök
Post by: geco on 2018.January.17. 08:48:52
Elég csak egyszer kiírni a 82h, 83h portot 7. és 6. bit beállításával, úgy emlékszem ebben az esetben nem force-oljuk be az új LPT-t, hanem a következő Reloadnál tér át az új LPT-re, ha nem találod a hibát, vágd be ide az LPT-det, megnézzük.
Title: Re: Grafikai trükkök
Post by: Tomato77 on 2018.January.17. 19:27:59
Működik a képbetöltés saját LPT-vel! :) A szinkronizáció működését nem értem, de kijött a 312,5 sor és van kép. Sokat segítettetek, srácok, köszönöm!
Már csak az eredeti LPT címet kellene visszaállítani, amikor a program végez, az még nem megy. Amit kiolvasok az FF szegmens végéről, azzal nem jó. Azt is osztani kell 16-tal, mielőtt visszatöltöm?
Title: Re: Grafikai trükkök
Post by: Zozosoft on 2018.January.17. 19:29:49
Amit kiolvasok az FF szegmens végéről, azzal nem jó. Azt is osztani kell 16-tal, mielőtt visszatöltöm?
Igen, és videócímre is konvertálni kell. Lásd az EXIT rutint a példaprogramomban.
Title: Re: Grafikai trükkök
Post by: endi on 2018.June.05. 21:50:08
c64 típusú raszter
Title: Re: Grafikai trükkök
Post by: szipucsu on 2018.June.05. 21:53:00
c64 típusú raszter
Ez elég jól mutat!
Title: Re: Grafikai trükkök
Post by: endi on 2018.June.07. 23:33:14
semmi extra...
Title: Re: Grafikai trükkök
Post by: Lacika on 2018.June.08. 19:24:00
Jól néz ki.
Főleg a kettő kombinálva:
Title: Re: Grafikai trükkök
Post by: szipucsu on 2018.June.09. 10:32:17
Főleg a kettő kombinálva:
Még érdekesebb lenne, ha az alsó és a felső rész más színeket használnak, ehhez két különböző videólapot lenne érdemes használni. (Lehet, hogy most is kettő videólap volt, nem néztem meg.)
Title: Re: Grafikai trükkök
Post by: Lacika on 2018.June.09. 14:40:29
Két videólap van, ha Endi mond egy színpalettát, semmiből nem áll átírni.
Title: Re: Grafikai trükkök
Post by: Povi on 2018.August.03. 15:21:47
tud nekem valaki olyan LPT-t írni, ami 36 karakter széles (vagyis HIRES 256 módban 72 pixel), és 224 pixel magas?

a trükk az az lenne, hogy a vízszintes sorok 4-szerezve legyenek, azaz egy 72x224 pixeles 256 színű ábra 4kB-ba elférjen

nem tudom, érthető-e mit akarok, de az ábra szerintem segít :-)
Title: Re: Grafikai trükkök
Post by: IstvanV on 2018.August.03. 15:54:34
a trükk az az lenne, hogy a vízszintes sorok 4-szerezve legyenek, azaz egy 72x224 pixeles 256 színű ábra 4kB-ba elférjen

Ez úgy oldható meg, hogy minden sor külön 4 pixel magas LPB, és a VRES bit nincs beállítva (62h video mód).
Title: Re: Grafikai trükkök
Post by: geco on 2018.August.04. 13:35:19
A csatolt file ezt legenerálja :)
Title: Re: Grafikai trükkök
Post by: Povi on 2018.August.04. 15:01:09
A csatolt file ezt legenerálja :)
ó, de zsírkirály vagy! :-) otthon ki is próbálom! "Normál" videólappal 10 fps-t sikerült elérni (egy sornyi unrolled LDI-kkel), 0.1 sec kellett a 16kB videó RAM-ba másolásához, ezzel kicsit felgyorsul majd, és alapgépen is menni fog (12 frame-ből áll a videó, nem tömörítve nem fér el 128kB-ban). Sima LDIR-rel 8 fps volt.
Title: Re: Grafikai trükkök
Post by: ergoGnomik on 2018.August.04. 15:20:22
Óvatosan kérdem, mert lehet, hogy lemaradtam valamiről, de minek a másolgatás? Egyszer kell bemásolni a VRAM-ba utána csak az LPT-k kezdőcímét kell cserélgetni. Szerintem. Másik kérdés: 16 szín nem elég, vagy nem lehet jól palettát és biast választani hozzá? Azzal megint lehetne jócskán csökkenteni a memóriaigényt.
Title: Re: Grafikai trükkök
Post by: geco on 2018.August.04. 16:10:14
Óvatosan kérdem, mert lehet, hogy lemaradtam valamiről, de minek a másolgatás? Egyszer kell bemásolni a VRAM-ba utána csak az LPT-k kezdőcímét kell cserélgetni. Szerintem. Másik kérdés: 16 szín nem elég, vagy nem lehet jól palettát és biast választani hozzá? Azzal megint lehetne jócskán csökkenteni a memóriaigényt.
Jogos felvetés :) Az eredeti verzióban egy frame 16KB volt, így nem fért el a videó memóriában, és ahogy elnézem a csökkentett mérettel is karcos lesz EXOS kompatibilis verzóra. Egy ötlet, esetleg, hogy ne kelljen LDI-zni, az ugyanazt tartalmazó videó sorok ne legyenek többször bemásolva a memóriába, csak az adott LPB-k mutassanak ugyanoda, így kell egy táblázat az LPB címekhez is, de ha több azonos sor van, akkor szerintem sok nyerhető vele.
Title: Re: Grafikai trükkök
Post by: geco on 2018.August.04. 16:20:11
Ahogy elnéztem a videóban a háttér animot, nagyjából ugyanaz ismétlődik mindenhol, eltolva, ha az összes anim egymás mögé lenne másolva, akkor csak LPTB-k pozicionálásával egy nagyobb helyről ki lehetne pakolni mindenhová, és legalább 16KB megspórolható lenne.
Title: Re: Grafikai trükkök
Post by: endi on 2018.August.04. 16:31:44
csináljátok meg úgy, hogy cpu nélkül menjen az anim.
valami olyasmi volt hogy x*képernyőméret nagyságú lpt-t kell generálni és automatikusan animálódni fog, z80 nélkül.
volt pár ilyen demó effekt.
Title: Re: Grafikai trükkök
Post by: geco on 2018.August.04. 16:42:37
csináljátok meg úgy, hogy cpu nélkül menjen az anim.
valami olyasmi volt hogy x*képernyőméret nagyságú lpt-t kell generálni és automatikusan animálódni fog, z80 nélkül.
volt pár ilyen demó effekt.
Ehez hasonlót vetett fel ergoGnomik :) , csak az LPT címeket kéne frissíteni, a full CPU mentes megoldás csak a következő megvalósítással menne.
Eszembe jutott egy még egyszerűbb megoldás, és a videó RAM igény feleződik.
A 16 színű paletta elég egy sorra úgy látom, a fehér lehetne fixen a BIAS-ból, lehet a szürke is, és a maradék 8 színt lehetne használni a többire, kell egy attributum képernyő, ahol a bitmap ugyanarra a sakktábla sorra mutatna (36db 0fh), és az attributumokat kellene csak 12x eltárolni, így a memóriaigénye az adatnak 36+36*54*12=23364 byte lenne + 12*960=11520 byte LTP-k, összesen 34884 byte, de mindez megoldható egy LPT-vel is, csak ott az attributum címeket kell frissíteni minden fázisban, mind a két megoldásnál maradna egy raklapnyi CPU idő
Title: Re: Grafikai trükkök
Post by: endi on 2018.August.04. 16:47:17
ja és szipucsu kezdheti csinálni a midi nyan zenét, vagy biztos van mod is. ha 0 cpu idő lesz akkor legjobb minőségű mod is lehet akár :)
Title: Re: Grafikai trükkök
Post by: Povi on 2018.August.04. 16:51:53
ja és szipucsu kezdheti csinálni a midi nyan zenét, vagy biztos van mod is. ha 0 cpu idő lesz akkor legjobb minőségű mod is lehet akár :)
az már van, fölrakta a MIDI topikba! :-)
Title: Re: Grafikai trükkök
Post by: Povi on 2018.August.04. 16:55:17
Jogos felvetés :) Az eredeti verzióban egy frame 16KB volt, így nem fért el a videó memóriában, és ahogy elnézem a csökkentett mérettel is karcos lesz EXOS kompatibilis verzióra.
A csökkentett verzió már befér 48kB-ba, szerintem 5-ös program induláskor bőven van 3 szabad videószegmens, szóval 128k-s gépen működhetne már, 64k-son valóban nem.
Title: Re: Grafikai trükkök
Post by: ergoGnomik on 2018.August.04. 16:55:43
Azt is meg lehet nézni, hogy a felső részhez nem lenne-e elég kettő vagy négy színű üzemmód? Bár lehet, hogy ez geco attributum ötletéhez képest nem hozna megtakarítást.
Title: Re: Grafikai trükkök
Post by: Povi on 2018.August.04. 16:57:51
Eszembe jutott egy még egyszerűbb megoldás, és a videó RAM igény feleződik.
A 16 színű paletta elég egy sorra úgy látom, a fehér lehetne fixen a BIAS-ból, lehet a szürke is, és a maradék 8 színt lehetne használni a többire, kell egy attributum képernyő, ahol a bitmap ugyanarra a sakktábla sorra mutatna (36db 0fh), és az attributumokat kellene csak 12x eltárolni, így a memóriaigénye az adatnak 36+36*54*12=23364 byte lenne + 12*960=11520 byte LTP-k, összesen 34884 byte, de mindez megoldható egy LPT-vel is, csak ott az attributum címeket kell frissíteni minden fázisban, mind a két megoldásnál maradna egy raklapnyi CPU idő
Ha LORES 16 módot használnánk (a 4 pixel magas sorokkal), akkor is feleződne a VRAM igény, az egyszerűbbnek tűnik, mint az attribútum módos játszás. De 14 szín van használva, nem tudom, találnánk-e normális BIAS-t hozzá. Ha gondolod, átküldöm a frame-eket.
Title: Re: Grafikai trükkök
Post by: geco on 2018.August.04. 17:12:08
Ha LORES 16 módot használnánk (a 4 pixel magas sorokkal), akkor is feleződne a VRAM igény, az egyszerűbbnek tűnik, mint az attribútum módos játszás.
Igazad van :)
De 14 szín van használva, nem tudom, találnánk-e normális BIAS-t hozzá. Ha gondolod, átküldöm a frame-eket.
Ne az egész képernyőben gondolkozz :), soronként kell nekünk a palettát állítani, ha jól számoltam egy sorban maximum 9 szín van, ha rosszul akkor 10 :D
így a biasból be lehet vonni a fehéret, és lehet a szürkét is, a többi meg soronként állítva, az lenne a jó, ha mind a 12 fázisnak az azonos LPB-ben megegyezhetne a palettája, így az egy LPT-s megoldásban se kéne a színeket frissítgetni, a 12x-es LPT-nél meg nem számít :)
Title: Re: Grafikai trükkök
Post by: Povi on 2018.August.04. 17:18:49
Igazad van :)Ne az egész képernyőben gondolkozz :), soronként kell nekünk a palettát állítani
Ó, tényleg! Ezek a színek vannak használva:
0, 7, 38, 73, 75, 79, 111, 160, 172, 205, 207, 210, 219, 255
Title: Re: Grafikai trükkök
Post by: geco on 2018.August.04. 17:52:57
Ó, tényleg! Ezek a színek vannak használva:
0, 7, 38, 73, 75, 79, 111, 160, 172, 205, 207, 210, 219, 255
Bias registert 19h-ra, vagy a BIAS EXOS változót 0c8h-ra álltva megspórolhatjuk a 205-öt, és a 207-et
Bias registert 07h-re, vagy a BIAS EXOS változót 048h-ra álltva megspórolhatjuk a 73, 75, 79-et
már csak az  akérdés, hogy melyikkel járunk jobban.
Title: Re: Grafikai trükkök
Post by: Povi on 2018.August.04. 18:03:20
A csatolt file ezt legenerálja :)
no, jelentem, működik, már így is "élvezhetetlenül gyors" lett :-)

szóval akár digi zene is mehetne alá! :-)

az LPT cím állítgatással aztán meg pláne. Ha jól értem, akkor ott az lenne a megoldás, hogy az alsó három video lapot lefoglaljuk (FC, FD és FE), majd belapozva mondjuk a p1, p2 és p3-ra betöltjük sorban a 12 framet (akár 0x1000 határra), majd ezután már csak az LPT címeket kéne állítgatni, valójában ezzel az esetben egy byte írásával tudunk képkockát váltani???
Title: Re: Grafikai trükkök
Post by: geco on 2018.August.04. 18:08:49
az LPT cím állítgatással aztán meg pláne. Ha jól értem, akkor ott az lenne a megoldás, hogy az alsó három video lapot lefoglaljuk (FC, FD és FE), majd belapozva mondjuk a p1, p2 és p3-ra betöltjük sorban a 12 framet (akár 0x1000 határra), majd ezután már csak az LPT címeket kéne állítgatni, valójában ezzel az esetben egy byte írásával tudunk képkockát váltani???
igen, LPIXEL 16 módban meg 0800h határra is akár, és egy byte változtatással minden LPB-ben aktiválni az új képet, a CPU mentes megoldásban meg egymás mögé másolni a 12 képkocka LPT-jét, és a reload bitet csak az utolsó végén beállítani, igaz ez még élvezhetetlenebb lenne, úgyhogy az egy LPT-s megoldás lenne a jó, minden váltás között várni pár megszakítást.
Title: Re: Grafikai trükkök
Post by: Tutus on 2018.August.04. 18:16:52
És hol lehet megnézni? Nem látok sehol linket :)
Vagy még nem készült el és nem publikus?
Title: Re: Grafikai trükkök
Post by: Povi on 2018.August.04. 19:34:57
igen, LPIXEL 16 módban meg 0800h határra is akár, és egy byte változtatással minden LPB-ben aktiválni az új képet, a CPU mentes megoldásban meg egymás mögé másolni a 12 képkocka LPT-jét, és a reload bitet csak az utolsó végén beállítani, igaz ez még élvezhetetlenebb lenne, úgyhogy az egy LPT-s megoldás lenne a jó, minden váltás között várni pár megszakítást.

no, ez meghaladta a képességeimet... :-)
eleve gond, ha csak három video szegmenst foglalok, akkor ugye az teli lesz a 12 frame-mel. Kéne a 0xff szegmens is az LPT-nek. Itt már a beállítások gondot okoznak nekem :oops:

Próbaképpen csak annyit csináltam, hogy lefoglaltam az alsó három vid szegmenst, majd betöltöm 4 frame-t a P1-re (ahol a 0xfc video szegmens van), majd próbálgatom az lptaddr + 5 címre 0x00-t, 0x10, 0x20 majd 0x30-at írni végtelen ciklusban, de nem igazán akar működni...
Title: Re: Grafikai trükkök
Post by: Povi on 2018.August.04. 21:12:59
És hol lehet megnézni? Nem látok sehol linket :)
Vagy még nem készült el és nem publikus?
Még nem készült el, de addig is van a fapados módszerrel működő verzió (frame-nként másol a VRAM-ba):

Ja, és zene sincs :-)
Title: Re: Grafikai trükkök
Post by: endi on 2018.August.04. 21:46:04
hires módban majd lehetne ebből egy játékot csinálni :)
akkor kisebb a figura, és scrollosan jöhetnének akadályok amiket ki kell kerülni, vagy valami ilyesmi.
van sok nyan játék, többek között a cég, ahol dolgozom csinálja a legsikeresebb nyan játékot: https://play.google.com/store/apps/details?id=com.istomgames.engine

de van felfele ugrálgatós, flappy nyan meg más is ott :)
Title: Re: Grafikai trükkök
Post by: geco on 2018.August.04. 21:54:53
no, ez meghaladta a képességeimet... :-)
eleve gond, ha csak három video szegmenst foglalok, akkor ugye az teli lesz a 12 frame-mel. Kéne a 0xff szegmens is az LPT-nek. Itt már a beállítások gondot okoznak nekem :oops:

Próbaképpen csak annyit csináltam, hogy lefoglaltam az alsó három vid szegmenst, majd betöltöm 4 frame-t a P1-re (ahol a 0xfc video szegmens van), majd próbálgatom az lptaddr + 5 címre 0x00-t, 0x10, 0x20 majd 0x30-at írni végtelen ciklusban, de nem igazán akar működni...
Úgy látom az volt a gond, hogy az LPT első sorát ápdételted csak, ilyenkor mind az 56 sort frissíteni kell, mondjuk így
Code: [Select]
           ei
vegtelen_ciklus:
            ld   hl,lptaddr + 5
            ld   de,0010h
            ld   bc,383fh
updlpt      ld   a,(hl)
            add  a, e
            and  c
            ld   (hl), a
            add  hl,de
            djnz updlpt

            ld   b,04h
wait:       halt
            djnz wait

            jp   vegtelen_ciklus
Title: Re: Grafikai trükkök
Post by: Povi on 2018.August.04. 22:27:44
Úgy látom az volt a gond, hogy az LPT első sorát ápdételted csak, ilyenkor mind az 56 sort frissíteni kell, mondjuk így
áááá, az lehet

nem tudtam, hogy minden egyes sornak külön le van tárolva a címe... :oops:

na, ennyire értek az LPT-hez :-D
Title: Re: Grafikai trükkök
Post by: geco on 2018.August.04. 22:36:02
áááá, az lehet

nem tudtam, hogy minden egyes sornak külön le van tárolva a címe... :oops:

na, ennyire értek az LPT-hez :-D
Ezért lehet jól játszani vele, vagy adatot spórolni, vagy a pointerek állítgatásával gyors animációra, stb :)
Title: Re: Grafikai trükkök
Post by: szipucsu on 2018.August.05. 15:31:15
az már van, fölrakta a MIDI topikba! :-)
Igen, már van. Endi is reagált rá anno, hogy "na, már ilyenünk is van", vagy ilyesmi, emlékszem. Jó, hogy a teljesen lényegtelen részleteket sokszor megjegyzem.
De MOD lehet, hogy van jobb is, azt még konvertálni sem kell.
Title: Re: Grafikai trükkök
Post by: IstvanV on 2018.August.06. 13:30:52
4K méretű verzió:
[attachurl=1]
Title: Re: Grafikai trükkök
Post by: Povi on 2018.August.06. 14:53:32
4K méretű verzió:
(Attachment Link)
nice! mondjuk a frame-k baromi jól tömöríthetők, epcompress-el nézegettem, asszem valami 1k-ra összement :-)
Title: Re: Grafikai trükkök
Post by: IstvanV on 2018.August.06. 15:35:49
Valóban, és a zene a legnagyobb méretű, kb. 1600 byte.

epvideoconv formátumú animáció:
[attachurl=1]
Title: Re: Grafikai trükkök
Post by: IstvanV on 2018.August.06. 16:43:19
A csökkentett verzió már befér 48kB-ba, szerintem 5-ös program induláskor bőven van 3 szabad videószegmens, szóval 128k-s gépen működhetne már, 64k-son valóban nem.

EP64 kompatibilitás megoldható lenne azt kihasználva, hogy a frames.all (ha jól számoltam) csak 187 egyedi sort tartalmaz, ez pedig egy szegmensen is elfér. Hátránya, hogy tömörítve valamivel nagyobb.

[attachurl=1]
Title: Re: Grafikai trükkök
Post by: Povi on 2018.August.06. 20:30:31
a frames.all (ha jól számoltam) csak 187 egyedi sort tartalmaz
Ezt úgy érted, hogy a 12 x 56 (= 672) sorban csak 187 különböző van? És akkor LPT cím módosítással kéne játszadozni?

Egyébként a C+4 forrása publikus:
http://plus4world.powweb.com/software/Nyan_Cat

ők elvileg csak 6 frame-t használnak, ahogy nézem a csillagokon van különbség
Title: Re: Grafikai trükkök
Post by: IstvanV on 2018.August.06. 20:57:04
Ezt úgy érted, hogy a 12 x 56 (= 672) sorban csak 187 különböző van? És akkor LPT cím módosítással kéne játszadozni?

Igen. Tovább csökkenhet az adat mérete, ha a címzése nem csak sor határon lehetséges (tehát van egy adathalmaz, és 12*56 16 bites cím ami ebben bárhova mutathat). Bár ez a tömöríthetőséget is tovább rontja, aminek akkor lehet jelentősége, ha a kész demó mérete korlátozott lesz (pl. 4K).
Title: Re: Grafikai trükkök
Post by: Povi on 2018.August.06. 21:03:14
ha a kész demó mérete korlátozott lesz (pl. 4K).
Nem voltak ilyen ambicióim :-) Szerintem fontosabb, hogy fusson 64K-s gépen is :-)
Nyugodtan fejleszthetitek, 3 hétig nem leszek most netközelben :-)
Title: Re: Grafikai trükkök
Post by: Zozosoft on 2018.August.09. 09:06:42
Jó lett ez a repülő macska :-)
Igazán hiánypótló :ds_icon_cheesygrin:
Title: Re: Grafikai trükkök
Post by: ergoGnomik on 2018.August.09. 12:54:57
Igazán hiánypótló :ds_icon_cheesygrin:
Így igaz! Nem számít komoly platformnak, amin nincs Nyan Cat. :D Hasonlóan fontos lenne még egy TV-noise is. Ez is nélkülözhetetlen. :mrgreen:
Title: Re: Grafikai trükkök
Post by: szipucsu on 2018.August.09. 13:33:36
Hasonlóan fontos lenne még egy TV-noise is. Ez is nélkülözhetetlen. :mrgreen:
Mármint a TV adáskimaradás "emulálására" gondolsz? Ilyen van már, IstvánV készített ilyet nem olyan régen. Alá meg bedobtuk hangnak a zajcsatornát, az tökéletes.
Title: Re: Grafikai trükkök
Post by: endi on 2018.August.09. 16:44:04
több régi demóban is volt már tévé zaj, többek között egyik saját demómban is :)
itt inkább azon lehetne versenyezni hogy ki tud rövidebbet. szerintem 128byte-on is lehetséges :)
Title: Re: Grafikai trükkök
Post by: IstvanV on 2018.August.09. 17:00:56
EP64 és EXOS kompatibilis verzió a frames2.all módszerrel:
[attachurl=1]

Lehetne még fejleszteni például függőleges mozgatással vagy más effektussal.
Title: Re: Grafikai trükkök
Post by: geco on 2018.August.10. 17:37:05
EP64 és EXOS kompatibilis verzió a frames2.all módszerrel:
(Attachment Link)

Lehetne még fejleszteni például függőleges mozgatással vagy más effektussal.
Na ez tök jó, és ha jól láttam, akkor kb 15% CPU időt visz el az LPT update. (EP128-on)
Title: Re: Grafikai trükkök
Post by: Povi on 2018.October.04. 09:57:13
Van ez az Isvtán féle pixelrajzoló rutin (vagy legalábbis az ő kódjából szedtem ki, és módosítottam :-)). Tud valaki abban segíteni, hogy ezt a pixelrajzoló rutint, ami 16 színű felbontáson működik, átírja nekem 4 színűre? Valójában a ".x" címke utáni rész lenne érdekes. A videolap 0xc000-tól kezdődik, és 32 széles. Gondolom a PixelTable-t is le kell cserélni (0x100-ra igazított táblázat)

Code: [Select]
PutPixel:
.y:     equ  $ + 1
        ld   hl, 0
        xor  a
        srl  h
        rr   l
        rra
        srl  h
        rr   l
        rra
        ld   h, l
        ld   l, a
.x:     equ  $ + 1
        ld   de, 0
        srl  e
        sbc  a, a
        xor  0xaa
        add  hl, de
        set  7, h
        ld   c, a
        cpl
        ld   b, a
.color: equ  $ + 1
        ld   a, 0
        and  0x0f
        ld   d, high (PixelTable)
        ld   e, a
        ld   a, (de)
        and  c
        ld   c, a
        ld   a, (hl)
        and  b
        or   c
        ld   (hl), a
        ret
Title: Re: Grafikai trükkök
Post by: geco on 2018.October.04. 10:56:41
Húú, sztem ez sokkal bonyolultabb lenne 4 szín módban.
Ha jól értem, akkor az X után C-ben eltárolja a az adott pixel maskhát (55h vagy 0aah), B-ben pedig annak az inverzét, ami a háttér maszkolásához kell, aztán a szín kódjának megfelelő értéket kiveszi a 16 színű táblából, és megkapja a szín pixelnek megfelelő értékét (AND C) ,majd a háttér nem pixel értékét kapja meg (AND B) és a beilleszti a háttérbe a kirajzolandó pixelt (OR C)
Na ez 4 szín módnál 4 pixel lehetőséget jelent.
Title: Re: Grafikai trükkök
Post by: Povi on 2018.October.04. 11:04:30
Húú, sztem ez sokkal bonyolultabb lenne 4 szín módban.
Ha jól értem, akkor az X után C-ben eltárolja a az adott pixel maskhát (55h vagy 0aah), B-ben pedig annak az inverzét, ami a háttér maszkolásához kell, aztán a szín kódjának megfelelő értéket kiveszi a 16 színű táblából, és megkapja a szín pixelnek megfelelő értékét (AND C) ,majd a háttér nem pixel értékét kapja meg (AND B) és a beilleszti a háttérbe a kirajzolandó pixelt (OR C)
Na ez 4 szín módnál 4 pixel lehetőséget jelent.
ööööö..... igen :-) Egyébként ugyanennek a két színű módja is érdekelne (az talán kicsit egyszerűbb)
Title: Re: Grafikai trükkök
Post by: geco on 2018.October.04. 11:09:00
Szerintem ez lenne a négy színű, ha nem szúrtam el semmit :D

Code: [Select]
PutPixel:
.y:     equ  $ + 1
        ld   hl, 0
        xor  a
        srl  h
        rr   l
        rra
        srl  h
        rr   l
        rra
        ld   h, l
        ld   l, a
.x:     equ  $ + 1
        ld   de, 0
        ld   a,01h
        srl  e
        rla
        srl  e
        rla
        ld   c,a
        ld   b, high pixelmask
        ld   a,(bc)
        add  hl, de
        set  7, h
        ld   c, a
        cpl
        ld   b, a
.color: equ  $ + 1
        ld   a, 0
        and  0x0f
        ld   d, high (PixelTable)
        ld   e, a
        ld   a, (de)
        and  c
        ld   c, a
        ld   a, (hl)
        and  b
        or   c
        ld   (hl), a
        ret

        defs low -$
PixelTable
        db   0ffh,0fh,0f0h,00h
pixelmask
        db   88h,44h,22h,11h
Title: Re: Grafikai trükkök
Post by: geco on 2018.October.04. 11:19:45
És ez a 2 színű:

Code: [Select]
PutPixel:
.y:     equ  $ + 1
        ld   hl, 0
        xor  a
        srl  h
        rr   l
        rra
        srl  h
        rr   l
        rra
        ld   h, l
        ld   l, a
.x:     equ  $ + 1
        ld   de, 0
        ld   a,01h
        srl  e
        rla
        srl  e
        rla
        srl  e
        rla
        srl  e
        rla
        ld   c,a
        ld   b, high pixelmask
        ld   a,(bc)
        add  hl, de
        set  7, h
        ld   c, a
        cpl
        ld   b, a
.color: equ  $ + 1
        ld   a, 0                   ;szín érték vagy 00h, vagy 0ffh
        and  c
        ld   c, a
        ld   a, (hl)
        and  b
        or   c
        ld   (hl), a
        ret

        defs low -$
pixelmask
        db   80h,40h,20h,10h,08h,04h,02h,01h
Title: Re: Grafikai trükkök
Post by: geco on 2018.October.04. 11:22:18
Bocs, a táblázatokat módosítani kellett, mert az első X pozícióba kerül a magasabb érték, a másodikba az alacsonyabb, és így tovább.
Title: Re: Grafikai trükkök
Post by: Povi on 2018.October.04. 15:39:49
Szerintem ez lenne a négy színű, ha nem szúrtam el semmit :D

Nekem a 00, f0, 0f, ff pixeltable sorrend jobbnak tűnik.
de a mask még nem az igazi - szőrös lesz a kép

az and 7-et lecseréltem and 3-ra, hogy 0-3 intervallumba legyen a szín
Title: Re: Grafikai trükkök
Post by: geco on 2018.October.04. 16:52:41
Nekem a 00, f0, 0f, ff pixeltable sorrend jobbnak tűnik.
de a mask még nem az igazi - szőrös lesz a kép

az and 7-et lecseréltem and 3-ra, hogy 0-3 intervallumba legyen a szín
Igazad van :)
Title: Re: Grafikai trükkök
Post by: IstvanV on 2018.October.06. 14:52:51
Talán működik:

Code: ZiLOG Z80 Assembler
  1. PutPixel:
  2. .y:     equ  $ + 1
  3.         ld   hl, 0
  4. .x:     equ  $ + 1
  5.         ld   de, 0
  6.         ld   h, l
  7.         ld   l, 0
  8.         add  hl, de
  9.         scf
  10.         rr   h
  11.         rr   l
  12.         sra  h
  13.         rr   l
  14.         ld   a, e
  15.         and  03h
  16.         ld   de, pixelmask
  17.         or   e
  18.         ld   e, a
  19.         ld   a, (de)
  20.         ld   c, a
  21.         cpl
  22.         ld   b, a
  23. .color: equ  $ + 1
  24.         ld   a, 0
  25.         and  03h
  26.         ld   e, a
  27.         ld   a, (de)
  28.         and  c
  29.         ld   c, a
  30.         ld   a, (hl)
  31.         and  b
  32.         or   c
  33.         ld   (hl), a
  34.         ret
  35.  
  36.         defs low -$
  37. PixelTable
  38.         db   00h,0f0h,0fh,0ffh
  39. pixelmask
  40.         db   88h,44h,22h,11h
  41.  
Title: Re: Grafikai trükkök
Post by: IstvanV on 2018.October.07. 16:22:40
Teszt program a fenti rutin kissé módosított változatával:

[attachurl=1]
[attachurl=2]

Szerk.: optimalizált PutPixel, pontosabb kör rajzolás, és ditherelt pixel rutin.
Title: Re: Grafikai trükkök
Post by: Povi on 2018.October.09. 15:53:16
Teszt program a fenti rutin kissé módosított változatával:

(Attachment Link)
(Attachment Link)

Szerk.: optimalizált PutPixel, pontosabb kör rajzolás, és ditherelt pixel rutin.

tetszik az LPT készítése, lopom az ötletet ;-)

viszont itt vszínűleg elírás van:
Code: [Select]
        ld    bc, 011ch                 ; BORD_VID
        ld    d, 00h
        exos  16
        ld    bc, 011ch                 ; BIAS_VID
        ld    d, 00h
        exos  16
        halt
        halt

ugyanazt a két változót állítod egymás után

viszont a kérdésem az, hogy a két HALT-ra mi szükség van utána?
Title: Re: Grafikai trükkök
Post by: Zozosoft on 2018.October.09. 16:39:35
viszont a kérdésem az, hogy a két HALT-ra mi szükség van utána?
Hogy biztosan lefusson videó megszakítás, ami kiírja az új értékeket a Nick-nek.
Title: Re: Grafikai trükkök
Post by: IstvanV on 2018.October.09. 16:46:37
ugyanazt a két változót állítod egymás után

Valóban hiba. :oops: Ez egyébként egy régebbi egyszerű "demó" (köröket rajzolt 16 színű módban), amibe beépítettem a 4 színű PutPixel rutint.

Quote
viszont a kérdésem az, hogy a két HALT-ra mi szükség van utána?

Így biztosan be tudja állítani az EXOS az új keret színt és biast video megszakításban, bár itt a gyakorlatban nem sok jelentősége van. Akkor lenne elsősorban, ha a változók állítása után a program azonnal tiltaná az EXOS megszakítás kezelését.
Title: Re: Grafikai trükkök
Post by: Povi on 2018.October.10. 11:18:02
Így biztosan be tudja állítani az EXOS az új keret színt és biast video megszakításban, bár itt a gyakorlatban nem sok jelentősége van. Akkor lenne elsősorban, ha a változók állítása után a program azonnal tiltaná az EXOS megszakítás kezelését.
Hm... és tényleg! HALT nélkül, és egy HALT-tal is maradt a keretszín.
Title: Re: Grafikai trükkök
Post by: Povi on 2019.August.11. 20:19:18
Vízszintes scrollozásra van valami trükk?

Nem kéne teljes képernyő, csak kb. 150 pixel magas, de teljese szélesség (80 karakteres).

Pl. az "Áttörés"-ben hogy csinálják? (persze az nem a legjobb példa, emlékeim szerint kicsit szaggat),
Vagy bármilyen mászkálós játékban, ahol az emberke nagyjából fix helyen van, és a háttér mozog mögötte.
Title: Re: Grafikai trükkök
Post by: geco on 2019.August.12. 08:26:31
Vízszintes scrollozásra van valami trükk?

Nem kéne teljes képernyő, csak kb. 150 pixel magas, de teljese szélesség (80 karakteres).

Pl. az "Áttörés"-ben hogy csinálják? (persze az nem a legjobb példa, emlékeim szerint kicsit szaggat),
Vagy bármilyen mászkálós játékban, ahol az emberke nagyjából fix helyen van, és a háttér mozog mögötte.
Sztem az Áttörés újrarajzolja a képet mindig, TVC-ről lett konvertálva.
A legjobb, és leggyorsabb scroll az, ha csak legszélső fél karakter oszlopot másolod minden fázisban, és az LPT címet lépteted eggyel jobbra, így 4 pixeles vízszintes scrollod lesz.
Title: Re: Grafikai trükkök
Post by: Povi on 2019.August.12. 09:03:19
Sztem az Áttörés újrarajzolja a képet mindig, TVC-ről lett konvertálva.
A legjobb, és leggyorsabb scroll az, ha csak legszélső fél karakter oszlopot másolod minden fázisban, és az LPT címet lépteted eggyel jobbra, így 4 pixeles vízszintes scrollod lesz.

de ha jól értem, és pl. van egy 15 képernyő szélességű pályám, akkor előre le kéne tárolni az egészet, és azelőtt csúsztatom az LPT ablakot? De már egy 3-4 képernyővel teli lesz a memória.
És mi van akkor, ha a pálya véletlenszerű? (pl. random hegyes háttér)
Title: Re: Grafikai trükkök
Post by: geco on 2019.August.12. 09:28:27
de ha jól értem, és pl. van egy 15 képernyő szélességű pályám, akkor előre le kéne tárolni az egészet, és azelőtt csúsztatom az LPT ablakot? De már egy 3-4 képernyővel teli lesz a memória.
És mi van akkor, ha a pálya véletlenszerű? (pl. random hegyes háttér)
Nem kell előre legenerálni, generálhatod csak azt az oszlopot, vagy esetleg egy picivel nagyobb területet.
Random hegynél meg generálhatod a Random hegy aktuális fél karakter oszlopát.
Title: Re: Grafikai trükkök
Post by: Povi on 2019.August.12. 10:09:07
Nem kell előre legenerálni, generálhatod csak azt az oszlopot, vagy esetleg egy picivel nagyobb területet.
Random hegynél meg generálhatod a Random hegy aktuális fél karakter oszlopát.
egyébként eszembe jutott egy jó példa: ilyen a flappy bird: horizontálisan egy helyben van a madár, de a háttér folyamatosan scrollozódik mögötte, ráadásul végtelen hosszú, és random.

Viszonrt amit még nem értek:
80 karakter széles a képernyő. Van egy bufferem, ami mondjuk 160 karakter széles. Ennek az elejére mutat az LPT. Eggyel növelem az LPT-t, most az 1-81 karakter látszik a bufferemből. Előbb-utóbb elérek 80-159 "ablakhoz", amit nem tudok tovább tolni.

Vagy én értek valamit nagyon félre.
Title: Re: Grafikai trükkök
Post by: Zozosoft on 2019.August.12. 10:16:20
Szerintem úgy, hogy ami kimegy oda mindig már rajzolod a +80-al későbbi részt, és amikor elérsz a végére visszaállítod a címet az elejére.
Title: Re: Grafikai trükkök
Post by: geco on 2019.August.12. 10:53:00
Van a Zozó-féle megoldás két videó memóriával, és van az egy videómemóriás megoldás (bocs itt nem lehet többet rajzolni, csak az egy oszlopot):
Ez akkor működik, ha sikerül egy frame-ben ápdételni, akkor az igazi, mert frémenként csak egy byte-ot kell jobbra léptetni, és a te esetedben a 40 karakter széles képen az 50h. byte-tól lefelé kirajzolni az oszlopot, következő frame-ben az 51h. byte-tól kirajzolni az oszlopot, és az LPT kezdőcímét 02h-ra állítani, és így tovább. Így egy videólapon 4384 frame-et jeleníthetsz meg a 40chr x 150-es beállítások mellett, ami majdnem másfél perc folyamatos mozgás ha egy fázis egy frame, ha ettől többre van szükséged, akkor be kell vonni a következő videólapot is, vagy a Zozó által javasolt megoldást választani.
Ha nem lehet megoldani villogásmentesen az előbbi verziót, és másfél perc mozgás elég, akkor meg lehet két videólappal is valósítani ezt, az egyik a látható kép memória, a másik pedig a munka terület, és mihelyt befejezted a melót a munka területen, váltasz, itt viszont már 2x4 pixel oszlopokat kell kirajzolni mindegyik lapra.
Title: Re: Grafikai trükkök
Post by: endi on 2019.August.12. 12:27:35
nocsak, vízszinte scrollos game készül? :)
nem is emlékszem hogy eredeti ep játékban lett volna vízszintes scroll, legalábbis ami lpt trükkös. csak az eggs of death-ban volt talán.
Title: Re: Grafikai trükkök
Post by: endi on 2019.August.19. 09:57:36
egy ilyen c256 módban elég érdekes lenne ep-n, meg talán gyorsabb is, ha mondjuk 2 pixel magas, és nem teljes képernyős. egy alsó félképernyős jó lehetne egy játék terep megjelenítéséhez.
https://youtu.be/bK2fvKq7USo?t=63

tudom, volt pár játékban is hasonló