Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > hr.comp.programiranje.java > #37
| From | Chupo <bad_n_mad@yahoo.com> |
|---|---|
| Newsgroups | hr.comp.programiranje, hr.comp.programiranje.java |
| Subject | Re: Citanje color offset-a za svaki pixel u indexed color .bmp file-u? |
| Date | 2017-07-21 17:24 +0200 |
| Organization | Noname d.o.o. |
| Message-ID | <MPG.33dc3b1d233493a298afb7@news.t-com.hr> (permalink) |
| References | (16 earlier) <MPG.33d989586fd9d64198afb0@news.t-com.hr> <okqk9n$la5$1@sunce.iskon.hr> <MPG.33db1810b8d453c098afb4@news.t-com.hr> <MPG.33db8ffff84ee9298afb6@news.t-com.hr> <oksjjc$66v$1@sunce.iskon.hr> |
Cross-posted to 2 groups.
In article <oksjjc$66v$1@sunce.iskon.hr>, Bruno Babic <a@b.c> says... > Uzmi u obzir da nemam iskustva sa Z70, pa mi moras malo detaljnije > pojasniti ovu pricu. Jasno mi je da postoji video RAM i da ce ono sto je > u njemu biti prikazano na ekranu, ali s obzirom na to da nemas > hardverske spriteove, onda mi nije jasno kako ustvari crtas konkretan > sprite? Odnosno, zbunjuje me to sto spominjes inettrupt za svaku liniju > ekrana, ja bih ocekivao da se interrupt dogodi kada iscrtavanje dodje do > dna ekrana i onda iscrtas spriteove po ekranu dok se el. snop vraca na > pocetak ekrana. > > P.S. nebi me iznenadilo da je to sve prekomplicirano za objasniti > pisanjem, ali probaj :) Jednostavno je to za objasniti ali je *vrlo* komplicirano za isprogramirati :-) Da ne bude zabune, hardware-ske sprite-ove nije imao Spectrum a Pac-Man hardware ih ima. Na Pac-Man hardware-u se sprite-ovi kontroliraju z par byte-ova, jedan kontrolira broj sprite-a i zrcaljenje po x i y osi a par byte-ova kontrolira koordinate. To da se na Spectrumu 'sprite' ovi moraju iscrtavati programski ne znaci da se mora koristiti ova metoda koju sam opisao - gdje bi se cekalo da elektronski snop stigne na odredjeno mjesto. Naprotiv, sprite-ovi se moraju iscrtati cim je brze moguce, prije nego elektronski snop 'pregazi' mjesto na koje se crta jer bi se u tom slucaju pojavio tearing - dio slike bi bio iz proslog frame-a a dio iz trenutnog. Recimo ako je slicica visine 16 pixela a elektronski snop je vec stigo do pete linije unutar sprite-a - ako bi se video RAM update-ao tek u tom trenutku onda bi prvih 5 linija u tom frame-u ostalo nepromijenjeno a ostalih 11 linija bi se update-alo i ako se sprite krece bi ga to u tom frame-u na pedesetinku sekunde izduljilo ili skratilo po visini, a ako se sprite ne krece nego se samo update-a animacija onda bi jedan cijeli frame prvih 5 linija bila iz jednog sprite-a a ostalih 11 iz sljedeceg frame-a animacije. To se moze sprijeciti na par nacina. Ili se mora koristiti jako brza rutina koja ce video RAM update-ai u interrupt-u prije nego elektronski snop stigne u podrucje ekrana. Vrijeme koje je na raspolaganju je vrijeme za povratak snopa na vrh ekrana nakon VBLANK + vrijeme za iscrtavanj border-a koji je iznad ekrana s grafikom. Ako je grafika komplicirana onda rutina ne moze biti dovoljno brza pa se izvan interrupt-a crta u frame buffer a onda se unutar interrupt-a tak blok brzo prebaci na odgovarajuce mjesto. Z80 ima instrukcije za pomicanje bloka podataka (LDIR i slicne) ali onda treba u RAM-u imati kopiju video RAM-a. Ekran se moze update-ati i tako da se van interrupt rutine stavi instrukcija HALT (koja ceka interrupt) pa se onda ekran brzo update-a izvan interrupt rutine, ali u tom slucaju interrupt rutina mora biti jako kratka da ne potrosi previse vremena jer ce se nakon HALT najprije izvrsiti ona a tek onda ce se nastaviti izvrsavanje glavnog programa. U dosta ranih komercijalnih igri za Spectrum se moze vidjeti da su te rutine napravljene dosta lose i zato je grafika trzava. Ovo o cemu sam govorio, kada rutina mora cekati elektronski snop, se koristi u drugim slucajevima. Prvi slucaj je da bi se boja border-a promijenila u tocno odredjenoj liniji tako da se ta linija spoji sa sadrzajem ekrana. Recimo ako se hoce nacrtati horizont preko cijelog ekrana ukljucujui i border. Na Spectrumu sliku iscrtava ULA a boja border-a se kontrolira pomocu najniza 3 bita upisanih na port 254 za sta se koristi recimo: OUT (#FE), A Na taj se nacin informacija upisuje direktno u ULA-u i boja koju snop iscrtava po border-u se promijeni trenutno, bez obzira na kojem je mjestu snop. Ako je snop iznad ekrana onda se moze vidjeti na kojem se je mjestu nalazio u trenutku kad se je izvrsila OUT instrukcija. To se moze koristiti za odokativno 'mjerenje' trajanja interrupt rutine i upravo sam to koristio ovdje: https://youtu.be/eGDLdf3nZL0 Ovo gdje na vrhu titra plavi dio bordera je indikacija trajanja interrupt rutine. Jer na pocetku interrupt rutine boju boder-a postavljam na cyan a na krajuju vracam u bijelu. S obzirom da trajanje svake pojedine interrupt rutine ovisi o raznim petljama pa nije konstantno, mjesto na kojem se elektronski snop nalazi na izlasku iz rutine se of frame-a do frame-a mijenja. Ako bi se napravila rutina koja bi svaki put, bez obzira na petlje trajala do u na takt isto vremena, onda bi plavi dio na vrhu ekrana bio savrseno stabilan a ako bi trajanje rutine bilo jos doze onda bi linija u kojoj se boja border-a mijenja bila u podrucju ekrana. Da bi se tova linija u border-u savrseno spojila s necim sta je nacrtano na ekranu, timing kada ce se izvrsiti OUT instrukcija mora biti savrsen - to se mora desiti za vrijeme horizontalnog povratka snopa nakon sta se iscrta linija iznad ciljne. Cim je linija koju treba povuci kroz border nize, to ce interrupt rutina morati duze cekati pa ce ostati manje vremena za sve ostale stvari - a vrlo je tesko napraviti rutine koje taktove trose precizno a ipak rade korisne stvari. Iscrtavanje svake linije ekrana traje tocno 224 T stanja a trajanja Z80 instrukcija su u rasponu od 4 do 23 T stanja pa ispada da bi se boja border-a mogla promijeniti i vise puta unutar jedne linije (recimo u dijelu na vrhu iznad ekrana) i na taj nacin iscrtati neki text. Da bi se to postiglo se mora unaprijed pripremiti blok byte-ova koji ce se poslati na port 254 i onda se koriste genijalni trikovi da bi se to uspjelo napraviti dovoljno brzo pa da se dobiju cim krace horizontalne linije - jer cim su linije krace je rezolucija veca. Drugi slucaj kada se mora tocno cekati da elektronski snop stigne na odredjeno mjesto je u rutinama koje omogucavaju da Spectrum ima vecu rezoluciju boje nego sta mu to hardware dozvoljava. Pixeli se na Spectrumu ne prikazuju tako da bi svaki pixel imao odredjeni broj bitova a o kojem broju bi ovisio ukupni broj mogucih boja nego pixeli uvijek imaju 1 bit po pixelu a boje se kontroliraju preko attributa koji se nalaze iza video RAM-a koji kontrolira pixele. Svaki atribut kontrorira blok od 8x8 pixela unutar kojega se mogu koristiti samo dvije boje (INK i PAPER). Recimo na adresi 16384 (ekran) + 6144 (duzina ekrana) = 22528 se do adrese 23295 nalazi 768 atributa nalaze atributi s bojama za svaki blok od 8x8 pixela. Na adresi 22528 je opis boja za blok pixela u gornjem lijevom uglu. Ako se u interrupt rutini poceka dok elektronski snop stigne do recimo kraja cetvrtog reda pixela ekrana pa se onda brzo promijeni sadrzaj na adresi 22528 onda ce prva cetiri reda tog bloka pixela imati prve dvije boje a druga 4 reda ce imati druge dvije boje pa ce tako unutar bloka od 8x8 pixela biti prikazano vise boja nego sta to hardware dozvoljava. Ovo sta sam opisao je prilicno tesko i realizirati a ako se ove dvije stvari (crtanje po border-u i promjena attributa ekrana u tocno odredjenom trenutku) iskombiniraju onda se stvari *stvarno* pocinju komplicirati :-) A ako se onda na sve to doda i da je ovo sam opis principa a u stvarnosti se ne mijenja samo jedan attribut nego treba promijeniti 32 attributa (jedan red), paziti da se sve promjene dese prije nego elektronski snop 'pregazi' lokaciju u koju se podatak upisuje (a snop je samo par desetina pixela lijevo od te lokacije) i da istovremeno rutina mora uvijek trositi tocno do na takt 224 T stanja po liniji, onda je jasno zasto su takvi programi koji to rade kvalitetno napravljeni tek pod kraj osamdesetih ili cak tek u jos novije vrijeme od 2000. na dalje. Ono sta pretpostavljam (a ne mogu ispitati jer nemam originalni aparat a MAME ne emulira njegov video hardware na dovoljno niskom nivou) je da bi se slicne tehnike mogle koristiti i na Pac-Man hardware-u da bi se prikazalo vise od osam sprite-ova ili da bi se postiglo vise od 4 boje unutar jednog tile-a. Vec sam i napisao rutinu za koju sam skoro siguran da bi na pravom aparatu omogucila vise od 4 boje po tile-u pa cu ju poslati nekome tko ima originalni Pac-Man i zna sprziti EEPROM-e. Ovaj covjek ocito ima i originalni uredjaj a zna i kako u ROM-ove ubaciti svoje podatke ali izgleda da mi ne vjeruje da je to sta sam opisao moguce :-) https://youtu.be/4-o57DPCt8k Odlican opis rada ULA-e (a i jos puno toga) nalazi se ovdje: http://www.worldofspectrum.org/faq/reference/48kreference.htm Ako se u Find upise: 224 T states se moze odma pronaci opis iscrtavanja linija. -- Let There Be Light Custom LED driveri prema specifikacijama http://tinyurl.com/customleddriver Chupo
Back to hr.comp.programiranje.java | Previous | Next — Previous in thread | Next in thread | Find similar
Citanje color offset-a za svaki pixel u indexed color .bmp file-u? Chupo <bad_n_mad@yahoo.com> - 2017-07-10 05:46 +0200
Re: Citanje color offset-a za svaki pixel u indexed color .bmp file-u? Bruno Babic <a@b.c> - 2017-07-10 14:16 +0200
Re: Citanje color offset-a za svaki pixel u indexed color .bmp file-u? Chupo <bad_n_mad@yahoo.com> - 2017-07-10 15:18 +0200
Re: Citanje color offset-a za svaki pixel u indexed color .bmp file-u? Bruno Babic <a@b.c> - 2017-07-12 09:32 +0200
Re: Citanje color offset-a za svaki pixel u indexed color .bmp file-u? Chupo <bad_n_mad@yahoo.com> - 2017-07-12 23:08 +0200
Re: Citanje color offset-a za svaki pixel u indexed color .bmp file-u? Bruno Babic <a@b.c> - 2017-07-14 11:25 +0200
Re: Citanje color offset-a za svaki pixel u indexed color .bmp file-u? Bruno Babic <a@b.c> - 2017-07-14 11:27 +0200
Re: Citanje color offset-a za svaki pixel u indexed color .bmp file-u? Chupo <bad_n_mad@yahoo.com> - 2017-07-14 15:09 +0200
Re: Citanje color offset-a za svaki pixel u indexed color .bmp file-u? Bruno Babic <a@b.c> - 2017-07-14 16:22 +0200
Re: Citanje color offset-a za svaki pixel u indexed color .bmp file-u? Chupo <bad_n_mad@yahoo.com> - 2017-07-14 17:21 +0200
Re: Citanje color offset-a za svaki pixel u indexed color .bmp file-u? Bruno Babic <a@b.c> - 2017-07-16 11:37 +0200
Re: Citanje color offset-a za svaki pixel u indexed color .bmp file-u? Chupo <bad_n_mad@yahoo.com> - 2017-07-16 15:20 +0200
Re: Citanje color offset-a za svaki pixel u indexed color .bmp file-u? Bruno Babic <a@b.c> - 2017-07-17 12:36 +0200
Re: Citanje color offset-a za svaki pixel u indexed color .bmp file-u? Chupo <bad_n_mad@yahoo.com> - 2017-07-18 00:37 +0200
Re: Citanje color offset-a za svaki pixel u indexed color .bmp file-u? Bruno Babic <a@b.c> - 2017-07-18 17:23 +0200
Re: Citanje color offset-a za svaki pixel u indexed color .bmp file-u? Chupo <bad_n_mad@yahoo.com> - 2017-07-19 01:10 +0200
Re: Citanje color offset-a za svaki pixel u indexed color .bmp file-u? Bruno Babic <a@b.c> - 2017-07-19 15:14 +0200
Re: Citanje color offset-a za svaki pixel u indexed color .bmp file-u? Chupo <bad_n_mad@yahoo.com> - 2017-07-19 16:21 +0200
Re: Citanje color offset-a za svaki pixel u indexed color .bmp file-u? Nikolaj Lazic <nlazicBEZ_OVOGA@mudrac.ffzg.hr> - 2017-07-19 17:08 +0000
Re: Citanje color offset-a za svaki pixel u indexed color .bmp file-u? Bruno Babic <a@b.c> - 2017-07-20 18:04 +0200
Re: Citanje color offset-a za svaki pixel u indexed color .bmp file-u? Chupo <bad_n_mad@yahoo.com> - 2017-07-20 19:17 +0200
Re: Citanje color offset-a za svaki pixel u indexed color .bmp file-u? Chupo <bad_n_mad@yahoo.com> - 2017-07-20 20:42 +0200
Re: Citanje color offset-a za svaki pixel u indexed color .bmp file-u? Chupo <bad_n_mad@yahoo.com> - 2017-07-21 03:58 +0200
Re: Citanje color offset-a za svaki pixel u indexed color .bmp file-u? Chupo <bad_n_mad@yahoo.com> - 2017-07-21 05:14 +0200
Re: Citanje color offset-a za svaki pixel u indexed color .bmp file-u? Bruno Babic <a@b.c> - 2017-07-21 12:04 +0200
Re: Citanje color offset-a za svaki pixel u indexed color .bmp file-u? Chupo <bad_n_mad@yahoo.com> - 2017-07-21 17:24 +0200
Re: Citanje color offset-a za svaki pixel u indexed color .bmp file-u? Bruno Babic <a@b.c> - 2017-08-04 13:10 +0200
Re: Citanje color offset-a za svaki pixel u indexed color .bmp file-u? Chupo <bad_n_mad@yahoo.com> - 2017-08-04 17:21 +0200
Re: Citanje color offset-a za svaki pixel u indexed color .bmp file-u? Bruno Babic <a@b.c> - 2017-08-07 17:30 +0200
Re: Citanje color offset-a za svaki pixel u indexed color .bmp file-u? Chupo <bad_n_mad@yahoo.com> - 2017-08-07 18:30 +0200
Re: Citanje color offset-a za svaki pixel u indexed color .bmp file-u? Chupo <bad_n_mad@yahoo.com> - 2017-08-07 18:35 +0200
Re: Citanje color offset-a za svaki pixel u indexed color .bmp file-u? Chupo <bad_n_mad@yahoo.com> - 2017-07-16 01:04 +0200
Re: Citanje color offset-a za svaki pixel u indexed color .bmp file-u? Bruno Babic <a@b.c> - 2017-07-16 11:32 +0200
csiph-web