Nem érez "véletlenül" valaki késztetést arra, hogy gif, jpg, bmp vagy akármi (PC-n egyszerû konvertálni) formátumú képeket valamilyen Enterprise számára "ehetõ" formátumra hozza (akár megkötésekkel a színszámra, méretre stb.)? Vagy már létezik ilyen program csak én vagyok tájékozatlan?
Quote from: "gafz"Nem érez "véletlenül" valaki késztetést arra, hogy gif, jpg, bmp vagy akármi (PC-n egyszerû konvertálni) formátumú képeket valamilyen Enterprise számára "ehetõ" formátumra hozza (akár megkötésekkel a színszámra, méretre stb.)? Vagy már létezik ilyen program csak én vagyok tájékozatlan?
Létezik. Úgy hívják, hogy grafikus alkalmazás ;-)
Bármelyik normálisabb grafikus progival (GIMP,PS,PaintShop Pro) tudsz képeket konvertálni tetszõleges színmélységre, felbontásra és akár raw formátumban is le tudod menteni (GIMP-pel akár C forráskódként). Ezután ezt már gyerekjáték megjeleníteni Enterprise-on.
Anno a Paintbox-hoz volt 5 kép amit gondolom Amiga-ról "loptak".
Bocsánat, de ilyen magamfajta windows-hoz szokott embernek az sem világos, hogy hogyan tárolódik a file-ban a kép pc-n.
A raw formátumban csak maga a képadat van tárolva? Semmi fejléc?
Javaslat valami EGYSZERÛ, ingyenes raw-ba menteni tudó programra?
1x1 pixeles pontot hogy lehet rajzolni? :oops:
Melyik is lenne az a formázatlan nyers képadatokat tartalmazó formátum? Mert raw-ot nem találok... :oops:
És ez a RAW nincs megbolonditva hülye bit-rétegekkel? Ugyanugy vannak a pixel adatok mint EP-n?
Mert akkor csak egy VLOAD fejléc kell az elejére és kész :)
Ha 8 bites a kép akkor nincs semmi réteg.
Quote from: "MrPrise"Ha 8 bites a kép akkor nincs semmi réteg.
És ha nem 8 bites?
EP-n igazából csak a 2 és a 4 szín mód használható felbontású :-(
Quote from: "gafz"Melyik is lenne az a formázatlan nyers képadatokat tartalmazó formátum? Mert raw-ot nem találok... :oops:
ctrl+shift+s beírod a filenevet és kiterjesztésnek pedig add meg azt, hogy pmm.
Utána kiválasztod hogy raw. Ezután vmi ASCII szerkesztõvel az elsõ 4 sort ki kell törölni és kész is.
Ettõl kényelmesebb lehet ez (http://registry.gimp.org/plugin?id=3457) a plugin.
Windows verzióhoz való nincs? :) Vagy megint én vagyok sötét... :oops:
Létezik. Úgy hívják, hogy grafikus alkalmazás ;-)
Bármelyik normálisabb grafikus progival (GIMP,PS,PaintShop Pro) tudsz képeket konvertálni tetszõleges színmélységre, felbontásra és akár raw formátumban is le tudod menteni (GIMP-pel akár C forráskódként). Ezután ezt már gyerekjáték megjeleníteni Enterprise-on.
Anno a Paintbox-hoz volt 5 kép amit gondolom Amiga-ról "loptak".
volt egy rajzolóprogram EP-re, amelyik betöltötte a pcx formátumot
valami Devil írta, az progi nevére már nem emlékszem, elég komoly rajzprogram volt
de amúgy pc-s programokkal érdemesebb konvertálni, jobb palettát generálnak, ditheringet stb-t lehet állítani...
bár ha jól emlékszem ez az EP-s progi úgy konvertált, hogy raszterenként új palettát is generált akár, ami nem semmi!
Quote from: "endi"volt egy rajzolóprogram EP-re, amelyik betöltötte a pcx formátumot
valami Devil írta, az progi nevére már nem emlékszem, elég komoly rajzprogram volt
de amúgy pc-s programokkal érdemesebb konvertálni, jobb palettát generálnak, ditheringet stb-t lehet állítani...
bár ha jól emlékszem ez az EP-s progi úgy konvertált, hogy raszterenként új palettát is generált akár, ami nem semmi!
A PCX eleg primitiv, ha jol remlik akkor RLE kodolast hasznal (Run Length Enconding vagy vmi hasonlo roviditese) a lenyeg az, hogy adott byte ha ismetlodik akkor azt letaroljak az ismetlodes szamaval egyutt. Ha jol remlik FLI (autodesk animatornak volt ez ugye az anim formatuma, itt nem a C64-es FLI-rol van szo ami egy eljaras a szinek szamanak novelesere ott) is hasonlot hasznal, anno x86 asm-ban irtam erre alkalmas cucokat nagy mennyisegeb, par byte az egesz szinte ...
RLE kodolast hasznal (Run Length Enconding vagy vmi hasonlo roviditese)
Quote from: "lgb"RLE kodolast hasznal (Run Length Enconding vagy vmi hasonlo roviditese)
Ennek ilyen tudományos neve van? :)
A Zozotools VS/VL is ezt használja :)
az LBM is RLE kódolású volt... :) mivel nem volt doksim róla, meg kellett fejtenem :)
a DP is ezt használta, de ha jól tudom semmi köze a DP-hez a formátumnak amúgy
LBM file format is used in Electronic Arts' Deluxe Paint package
igen, neked is igazad van, meg nekem is. a lbm formátum az iff-re épült, ami nem DP dolog
Quote from: "lgb"RLE kodolast hasznal (Run Length Enconding vagy vmi hasonlo roviditese)
Ennek ilyen tudományos neve van? :)
A Zozotools VS/VL is ezt használja :)
ez mar kvazi normalis tomorgeto algoritmus nem csak egy RLE, ami ugye azonnal nem muxik ha ismetlodo byte pl nincs is a cumoban ...
Quote from: "lgb"ez mar kvazi normalis tomorgeto algoritmus nem csak egy RLE, ami ugye azonnal nem muxik ha ismetlodo byte pl nincs is a cumoban ...
Errõl jut eszembe! ZIP,RAR vagy hasonló algoritmust tud valaki? Mennyire bonyolult az, meg lehetne írni Z80-ra?
Quote from: "Zozosoft"
Errõl jut eszembe! ZIP,RAR vagy hasonló algoritmust tud valaki? Mennyire bonyolult az, meg lehetne írni Z80-ra?
A zip forrása a libzip (http://www.zlib.net/)-ben elérhetõ. RAR-t nem tudom, viszont van 1 újabb a 7zip (http://www.7-zip.org/) aminek szintén elérhetõ a forrása és jobb szinte minden másnál.
...animált GIF-et csinálni?
...leboruló smiley...
amit a VLOAD is be tudott tölteni, a palettát külön file-ba tettem.
Ezek szerint nem volt Zozotools-od, ott a paletta is a fejlécben van :-)
Mi az EnterSprite-os spr fájlok formátuma ?
A fájlméret 2048 byte. 8 fázis, egy fázis 16x32 pixel. Az annyi mint 8*16*32=4096 byte. 16 színû, 1 szín 4 biten tárolható tehát 1 byte két szín. Így 16 színnel 2048 byte.
Kérdés, hogy egy fázis pixeladatai egymás után sorban vannak-e, byte-onként két egymást követõ pixel színei ? Vagy van valami palettaféle és máshogy tárolja a pixelek színeit ?
Érdekelne a többi Ep-es képformátum szerkezete is.
Érdekelne a többi Ep-es képformátum szerkezete is.
A fejléc tartalmazza a Video Mode-ot, a Video Colour-t, és a Video X-et, és Y-t, ha érdekel, és megtalálom, akkor leírom pontosabban.
A ZOZOTOOLS-é annyiban különbözhet, hogy vagy a fejlécben, vagy a file végén eltárolja a palettát, ami fölöttébb hasznos.
Zozo! Azok a képek hogyan is készültek, amik interlace -módban csodálatosak minálunk? :-) (Fehér tigris, és társai...)
Én anno úgy csináltam, hogy a BMP-t lebutítottam 16 ( de inkább 11-12 színûre a bias miatt ), a BMP fejlécét levágtam, majd átkonvertáltam EP formátumra, amit a VLOAD is be tudott tölteni, a palettát külön file-ba tettem.
Egyébként ez itt OFF, mert ezek a képek Atari ST-rõl lettek áthozva :-)
A Legelterjedtebb az a SCR, ami majdnem minden játéknál így van, az valamivel talán kisebb, mint 8 KB (pl. Art Studio is ezt kezeli, a Bam-féle legalábbis).
A VLOAD-os az azonos valamelyikkel, vagy az külön formátum?
Én csak VLOAD által megemészthetõt ismer(t)em, ott a fejléc után egybõl tolja az adatokat képernyõsoronként fentrõl lefelé. A fejléc tartalmazza a Video Mode-ot, a Video Colour-t, és a Video X-et, és Y-t, ha érdekel, és megtalálom, akkor leírom pontosabban.
Nahát, szinte nem hiszem el. :o Ilyen egyszerû lenne az egész? Ennyire hasonló módon tárolja a képet az EP és a PC-s bmp? Egyébként bõvebben kifejtve a fejléclevágás, a konverzió és a palettakészítés hogyan megy? És mekkora képméretet (hányszor hányast) kell PC-n beállítani ehhez?
Így pont maradt 10 szabad bájt a fejlécben, amiben kényelmesen elfér a 8 paletta szín + fixbias :)
EP:
b1,b5,b3,b7.....b0,b4,b2,b6
Erre a bitsorrendre az életben nem jöttem volna rá :)
Papíron leírva ezzel a módszerrel gyönyörûen kijönnek az Entersprite spr fájljainak színei. De miért van így megkeverve EP-en a bitek sorrendje ? Van valami egyszerû trükk a színek kiemelésére ? Már teljesen beleõrültem a bitek rotálásába és kiemelgetésébe :shock: Help plízz :oops:
Igazándiból semmi konkrét tervem nincs, csak gondoltam ebbõl ki lehetne hozni valamit pl. EPSee (ACDSee mintára :) ) vagy csak egyszerûen oda vissza konvertálgatni. Esetleg egy újabb sprite tervezõt Spred-nél is több extrával.
Hát nekem így valami nem stimmel. :oops:
Addig rendben van, hogy 55h-el és AAh-el kiemelem a páratlan és a páros biteket de mitõl fog a sorrendjük ilyenné változni ? :
- b0,b2,b4,b6 ---> b0,b4,b2,b6
- b1,b3,b5,b7 ---> b1,b5,b3,b7
Ugyanis papíron a jobb oldali a helyes, ahogy mondtad. De én azt a sorrendet semmilyen tologatással nem tudom elérni.
ld b,00h
ld a,érték
rrca ;bit 0 ki
rl b
rrca ;bit 1 ki
rl b
rrca
rrca
rrca ;bit 4 ki
rl b
rrca ;bit 5 ki
rl b
rlca
rlca
rlca
rlca ;bit 2 ki
rl b
rrca
rrca ;bit 3 ki
rl b
rrca
rrca
rrca ;bit 6 ki
rl b
rrca ;bit 7 ki
rl b
ld b,érték
ld a,b
or 3ch
bit 2,b
jr nz,bt3
res 4,a
bt3 bit 3,b
jr nz,bt4
res 5,a
bt4 bit 4,b
jr nz,bt5
res 2,a
bt5 bit 5,b
jr nz,bt6
res 3,a
bt6 vége
Egy nem pont ide vágó kérdés olyasmi cuccok létezik már kifejlesztve, ami mondjuk egy tetszõleges pc formátumú képet képes olyan byte formátumba menteni amit bedobva az ep videó memóriájába máris a megfelelõ képet kapjuk (esetleg elõ is állítja hozzá az optimális palettát) ? Mert ha igen akkor nem görcsölök vele :)Kifejezetten ilyen nincs, pedig érdekes lenne egy olyan ami pixelsoronként képes lenne új palettát számolni, maximálisan kihasználva az EP lehetõségeit.
Zozosoft igen sokmindent tud a képekrõl, lévén már 2 (elég sok PC (?) fotót tartalmazó) demót csinált anno. :-)Én egy darab PC képet nem konvertáltam át, hanem Atari ST képeket :-) Abban az idõben azon volt olyan rajzoló program, amivel tetszõleges színszámra lehetett lebutítani a képeket (ditheringgel). Így csak annyi volt a móka, hogy EP videó formátumra kellett hozni. Atarin bitmap-es a grafika, vagyis a memóriában elöször minden pixel 0. bitje van, aztán minden pixel 1. bitje, stb (a színek számától függõen 1,2,4,stb bitmap), EP-n pedig folyamatosan vannak pixel adatok, az egy bájton belüli bit sorrend megtalálható a Nick leírásban.
Szóval bõven elég lenne egy tök egyszerû file térkép. :)Miután ilyet még senki nem csinált, így nincs fájltérkép se :-) nekünk kell most megalkotni :-)
Az Exos fejlécrõl nem sokat tudok, ha dobnátok valami linket egy leírásról azt meg köszönném.Itt a leírás. (http://ep.homeserver.hu/Dokumentacio/Konyvek/EXOS_2.1_muszaki_leiras/EXOS.htm#42)
Na meg az LPT tábláról is többet kéne tudnom.Ajánlott olvasmány :-) (http://ep.homeserver.hu/Dokumentacio/Konyvek/EXOS_2.1_muszaki_leiras/EXOS.htm#228)
A képet fejjel lefelé kéne el tárolni mert ha emlékeim nem csalnak a 0,0 pont az EP-n a bal alsó pixel.Az csak a BASIC koordinátarendszere, a kép normálisan van tárolva.
soronkénti palettánál még nem próbáltam, de így fejben ha elképzelem lehet, hogy csíkos képet fog eredményezni, persze majd akkor derül ki ha látom az eredményt)Majd nyílván kellhet valami optimalizáció, ez lesz benne az izgalmas feladat :-)
Néhány konvertált kép 16 színû módban: ep_images.zip (http://www.sharemation.com/IstvanV/ep_images.zip)Szóhoz se jutok! :smt038 :smt038 :smt038 :smt038 :smt038
Szóhoz se jutok! :smt038 :smt038 :smt038 :smt038 :smt038
Lehetne majd úgy, hogy nem minden kép külön program, hanem lesz egy képnézegetõ program, és hozzá a képek?
Amikhez kitalálunk valami jó fileformátumot :-)
bár mintha valamelyik rajzolóprogramnak (Agsys?) van ilyen soronkénti paletás formátuma, talán lehetne azzal kompatibilisre csinálni?
* tömörítés ?Hogy tömörítés kell-e, attól függ, mire akarjuk a képeket felhasználni. Ha csak önmagukban nézegetni, nem kell tömörítés. De ha pl egy demót ír valaki a XXI. században EP-re (amit egyébként a sok DTM zene mellett támogatnék), és abban lenne ilyen kép, akkor jó, ha kisebb helyet foglal, hogy más is elférjen még a memóriában.
ez a soronként paletta ez hogy van? miért jobb mint az attributum mód?Ha minden sorban más lehet az első 8 paletta szín, az elvileg jobb minőséget tesz lehetővé, bár ez nem mindig működik tökéletesen (a fenti példáknál is látható vízszintes csíkozódás probléma lehet); soronként változó paletta nélkül ugyanazok a képek ugyanazzal a programmal konvertálva így néznek ki: ep_images_2.zip (http://www.sharemation.com/IstvanV/ep_images_2.zip)
Hú ez nagyon állat! Végre valaki megcsinálta! :DAzt meg lehet oldani, hogy a fixbias soronként (esetleg 2 soronként) változzon, de remegés nélkül, akkor is, ha pl. 42 karakter széles a kép ?
Megjegyzem a biast is lehet soronként állítani, sõt egy sorban többször is, egyik demómban megoldottam (bár kicsit remeg). :)
Azt meg lehet oldani, hogy a fixbias soronként (esetleg 2 soronként) változzon, de remegés nélkül, akkor is, ha pl. 42 karakter széles a kép ?Mondjuk ez esetben már nem képrõl beszélünk, hanem demóról!
Viszont kérdés, hogy ha az IRQ rutin elején beállítjuk a FIXBIAS-t, akkor az a képernyõn mikor is okoz változást?Ha jól emlékszem, túl későn ahhoz, hogy az adott sor elején már az új FIXBIAS legyen látható, tehát elvileg meg kell várni (nop utasításokkal) a sor végét.
Lehetne pl "I" mint István :) még leellenörzöm, de szerintem ez szabad.
001h: ?? (EXOS file típus)
002h: video módA mód meg a szín lehetne az LPT-ben használatos bit kiosztással tárolva, így ez a bájt közvetlenül felhasználható lenne az LPT generáláshoz.
Lehetne pl "I" mint István :) még leellenörzöm, de szerintem ez szabad.A mód meg a szín lehetne az LPT-ben használatos bit kiosztással tárolva, így ez a bájt közvetlenül felhasználható lenne az LPT generáláshoz.OK. Az egyszerűsítené a file olvasását, ha a 003h byte-on található három paraméter külön byte-okra kerülne (még így is maradna 3 nem használt byte) ?
OK. Az egyszerûsítené a file olvasását, ha a 003h byte-on található három paraméter külön byte-okra kerülne (még így is maradna 3 nem használt byte) ?Ez esetben a FIXBIAS és paletta mód esetén lehetne a sorok számát tárolni: 0= egész képernyõ, egyébként meg a megadott soronként váltakozik.
Esetleg valami villogtatásos színpaletta kiterjesztés is jó lenne, bár azzal kétszeresére nõne a memória igény...Pont ezt kezdtem írni, csak közben jól lehalt az egész fórum :-(
bit1, bit0: interlace módMi az a csak villogtatás?
00: nincs
01: csak villogtatás
10: 2x függõleges felbontás
11: - (nem használt)
Mi az a csak villogtatás?
Egy ötlet: szerintem érdemes lenne a konvertálás elõtt valami pc programmal az EP palettájára hozni a képet. Vannak jó programok amelyek ditheringgel elég jóra meg tudnak egy képet csinálni a 256 színû palettára konvertáláskor. Aztán ezután a te programod már lehet hogy jobb eredményt adna a soronkénti palettaváltás technikával.Ez azt jelenti, hogy először konvertáljam 256 színre ditherelve, és aztán ezt az átmeneti képet 16 színűre (soronként változó paletta, esetleg fixbias használatával) dither nélkül ? Ezt a megoldást már használtam egy programban, ami Plus/4-es többszínű FLI módba konvertál, de az EP-n egy egész sorban összesen csak 16 szín lehet (amiből 8 választható szabadon), és ez "nehezebb" képeknél nem biztos, hogy elég. Mindenesetre az jó, ha több algoritmus közül lehet választani, mert az egyes képeknél nem mindig ugyanaz eredményezi a legjobb minőséget.
Valaki tudna nekem küldeni egy 256 színû EP palettát tartalmazó gif-et vagy akármilyen formátumú képet?ep_palette.gif (http://www.sharemation.com/IstvanV/ep_palette.gif) (ep128emu paletta)
Valahol van nekem de nem találom.
Kíváncsi lennék hogy néznek ki ezek a te programoddal konvertálva. :)
ep_images_3.zip (http://www.sharemation.com/IstvanV/ep_images_3.zip)Ez nagyon durva, 20 év után lehet megdöbbeni, hogy miket is tud kedvenc masinánk!!!
Esetleg addig is ezt átkonvertálnád? http://www.etyekfilm.hu/scene_render_11_small.jpghttp://www.sharemation.com/IstvanV/scene_render_11.zip (http://www.sharemation.com/IstvanV/scene_render_11.zip)
Vagy elég a közepén a lovag is.
Mikor lesz publikus a konvertáló program? :) Már nagyon várom ám. :)Még nagyon kezdetleges állapotban van, de megpróbálok egy valamennyire használható változatot készíteni hamarosan. A file formátumon már nem kell változtatni ?
A file formátumon már nem kell változtatni ?Felvetõdött bennem még egy gondolat: akarjuk-e támogatni, hogy a videómód is változzon, akár soronként?
Felvetõdött bennem még egy gondolat: akarjuk-e támogatni, hogy a videómód is változzon, akár soronként?Erre én is gondoltam, bár egyszerűbb megoldani, ha nem változik a felbontás a kép külöböző részein. Mindenesetre ha változó mód is lenne, akkor talán az LPT egyszerűsített változatát is lehetne tárolni ?
Elképzelhetõ, hogy a kép egyes részein kevesebb szín is elég, így itt lehetne jobb felbontást használni.
És amirõl még nem volt szó: a fejléc után pontosan, hogyan lennének az adatok tárolva?A formátum ugyanaz lenne, mint a video memóriában: az attribute és pixel adatok soronként felülről lefelé és balról jobbra, a paletta csak az adott módban használt színeket tárolja (tehát pl. egy 272 soros kép 2 soronként változó palettával 4 színű módban (272/2)*4 byte paletta adatot használna), és a nem használt részek (pl. nem attribute módban az attribute adatok, vagy interlace módban ami a második félképben nem változik) nem lennének tárolva.
oopsz, egy kis help nem ártana, mert amit kiír az hirtelen kevésA legegyszerűbb példa:
pl. egy-két példát is kiírhatna
én most hirtelen nem jöttem rá milyen fájl formátumot eszik meg.jpg, .png, .gif, .bmp, és .xpm
Szóval a képek, szerintem döbbenetesek:Ezek az eredeti képek, vagy netalán az EP-vel konvertáltak? Ha az utóbbi, akkor melyik beállítással konvertáltad? Az alappal?
http://www.etyekfilm.hu/ep128_characters.png
http://www.etyekfilm.hu/ep128_cars.png
Egyébként hogyan kell használni? Mi az a 7z kiterjesztés? Simán DOS-ból kell megnyitni?Bocsi, közben rájöttem, elõször a ZIP-pel ki kell csomizni.
(Ami vicces: PC-s formátumban az EP képek nagyobb helyet foglalnak, mint EP-n, 256 színûre állítva és tömörítve, lásd a csatolmányokat.)A PNG tömörítése veszteségmentes (hasonló a ZIP-hez), ezért pl kiváló olyan képekhez ahol viszonylag nagy területek azonos színűek, tehát kevés szín fordul elő adott területen ill. ha fontos, hogy minden pixel látszódjon, de a fényképekhez hasonlóan részletgazdag képekhez a tömörítése nem a legjobb hatásfokú (il. akkor igen, ha nem akarjuk, hogy részletet veszítsünk el a képből). Persze sok értelme nincs egy veszteségmentes és egy nem veszteségmentes tömörítést összehasonlítani ;-)
Ááááááááááááá ez hihetetleeeeeen!!!!!! :D:D:DHátttt... :-P Ha nem (!) nézed meg alaposan a képet, csak úgy "rápillantasz", akkor nem egyértelmû, hogy a jobb oldalon lévõ sor (attr.) a szebbik. Megnézettem egy családtaggal, akinek fogalma sincs az EP -rõl. (Tehát egyszerûen csak a képeket nézte.) A jobb oldali sor "zajosabb", felületes szemlélõnek nem szebb. Ok, én látom benne, "mitõl szebb", de egy egység sugarú ember nem az attr. módban készült sort fogja szebbnek látni!
Az Attr üzemmód sokkal szebb még a 4szín üzemmódnál is!!!!!!
Lacika, persze, nyugodtan használd õket.
De már linkeltem egy csomót, azokat nem néztétek meg? :(
Ah, hát én az futtatható fájlokat nem hagytam meg...Akkor kérjük újragyártani õket! Különben senki nem fogja elhinni, hogy tényleg az EP tud ilyet! :-)
Vagy majd késõbb lesz hozzá pl. IstvanView képnézegetõ alkalmazás? :)Igen errõl kezdtünk itt beszélgetni kb 2 héttel korábban :-)
Na, igen, így már érteném, miért mondta Ork, hogy az attr. a szebbik! Ha felcserélte, és a BAL (!) oldali az attr., (és nem a jobb, amire írta) akkor valóban az a szebb! ;-)
Az elõzõ összehasonlító képgyûjteményben én a bal oldali hasábot nézem attr-formátumúnak! Nézd meg légyszíves, mielõtt nagyon belemerülünk a minõségbe.
Szerintem várjuk meg amíg kiforr, ki tudja mit hoz még ki belõle IstvanV...
TV-n érdekesen nézhetnek ki...
Igen errõl kezdtünk itt beszélgetni kb 2 héttel korábban :-)Már csak meg kéne írni a programot :)
Már csak meg kéne írni a programot :)Szerintem valami olyasmit (is) lenne érdemes csinálni, amivel könnyen be lehet tenni ilyen képet esetleges újabb EP-s programba, akár BASIC-be, akár gépi kódúba - már ha valaki egyáltalán ír még újabb programokat EP-re. Szóval azt akarom mondani, hogy ha valaki napjainkban EP program írására vetemedne, akkor már ki tudja kihasználni ezt az egyedülálló lehetõséget is programjában.
Már csak meg kéne írni a programot :)Dolgozik már rajta valaki, vagy szabad jelentkezni? :-)
Dolgozik már rajta valaki, vagy szabad jelentkezni? :-)
Azon törtem a fejem, hogy hogy lehet majd olyat csinálni, hogy egy file elindítása után kép, space nyomás, újabb kép, újabb space nyomás, stb.:IVIEW *.kép :-)
Zozo Te anno konvertáltál át (tényleg, az mennyire hasonlított ehhez a módszerhez?) képeket a Matusa Pistivel!Nem a Matusával, ha nem a Dr. Préry fedõnevü osztálytársammal (aki Z&A Demo-ban is emlegetve van :-) )
Vagyis az kéne, hogy meg lehessen adni a programnak, hogy egyes színeket ne használjon fel, és/vagy egyes színeknek fix értéket megadni.Feltöltöttem egy új verziót, amely lehetővé teszi, hogy fix paletta színeket lehessen megadni a -color0 ... -color7 paraméterekkel, de azt egyelőre nem tudja, hogy ne használjon egyes színeket. A FIXBIAS is állítható a -bias segítségével, így esetleg jobb minőséget is el lehet érni, mint az automatikusan választott értékkel. A színeket #RGB formátumban is meg lehet adni, pl. a #773 a fehér szín, vagy a #331 a bias=31.
Na itt van egy kis teszt. Feliratoztam a képeket, egyértelmûen az attr mód a legszebb.Néhány további változat:
Néhány további változat:
2 színû interlace: -mode 10 -size 46 269 -dither 3 0.75 -gamma 0.85
attribute interlace: -mode 16 -size 46 269 -dither 2 0.5 -quality 9
16 színû: -mode 4 -size 46 269
Megpróbálnám elõállítani ezt az extra grafikus üzemmódot.Még az eddigieknél is extrábbat? Határ a csillagos ég? :D
Van valahol infó az lpt tábláról?Nick leírás (http://ep.homeserver.hu/Dokumentacio/Konyvek/EXOS_2.1_technikal_information/hardware/Nick.html)
Egyébként nem hinnétek a szemeteknek, hogy milyen játékot lehetett volna ilyen üzemmódban csinálni...
A kb. 600 játék közül egyik sem használja ezt? EP-s példát nem is tudnál mutatni?A Diamonds (http://www.ep128.hu/Ep_Games/Leiras/Diamonds.htm) fut 4 színû karakter módban. (Ezt az EP32 nem is tudja megjeleníteni.)
Gyerekek!Egyelőre valóban úgy tűnik, hogy kissé feledésbe merült a téma :)
A képbetöltő / képnéző programmal foglalkozik valaki?
Kár lenne, ha a PC-s képkonvertálás lehetősége (is) sülyllesztőben végezné, mint sok más zseniális fejlesztés Ep-re...
endike.blog.hu
Gyerekek!Tulajképpen ott hagytuk abba, hogy már készen volt. :lol: Illetve ami készen volt, annak egy végleges formát kellett volna adni. (Valami olyasmit, hogy képeket lehessen (ilyen-olyan paraméterekkel, beállításokkal) konvertálni, picit egyszerûbben, mint ahogy a mostani állapotában lehetséges!
A képbetöltõ / képnézõ programmal foglalkozik valaki?
Kár lenne, ha a PC-s képkonvertálás lehetõsége (is) sülyllesztõben végezné, mint sok más zseniális fejlesztés Ep-re...
A konvertálás tulajdonképpen jó így is, leginkább egy képnézegetõ program kellene. Egy rendszerbõvítõ (mint pl. a VLOAD), esetleg egy felület is hozzá, de ez már nem annyira fontos.Igen, ebben igazad van! Egy képnézegetõ valóban nagyon jó lenne, mert macerás megjeleníteni a képet!
Van annak valami gyakorlati akadálya, hogy 32x32-nél kisebb képeket is lehessen konvertálni?Nincs, bár a program jelenlegi változata nem fogad el 32x32-nél kisebb vagy 8192x6144-nél nagyobb képeket, ezeket a korlátozásokat könnyen meg lehet szüntetni, és lehetne konvertálni akár 1x1 pixel méretű "képet" is :)
De úgy tûnik megtaláltam azt, ami nem volt betervezve a program írásakor :-)Az átméretezés sin(x)/x interpolációt használ, az eredeti képen kívüli pixeleket keretszínűnek feltételezve, és először mindig 2 színű interlace felbontásra konvertál, amit utána egyszerűen a pixelek átlagolásával csökkent a tényleges - kisebb - felbontásra (tehát például 16 színű nem interlace módban 4x2 kicsinyítés van). Ezért az interpolációból származó "hibák" elkerülésére a -size W H mérethez W*16xH*2 felbontású kép kell, a választott video módtól függetlenül.
Ebbõl a 32x32-es képbõl:
Ez lesz:
A konkrét példának nincs sok értelme, de elméletileg pl egy 640x200-as 2 színû kép, változatlan formában átvehetõ lenne 2 szín módba. Vagy 640x400 2 szín, interlace 2 színbe. Vagy 320x200 4 színben... stb
Szuper!Nem rossz ötlet, a következő verzióban megpróbálom megoldani.
Ami még eszembe jutott: a keretszint is lehetne optimalizáltan generálni? Mondjuk ami körbe a kép szélén a legtöbbet használt szín, vagy valami ilyesmi...
Az IVIEW már 0.1 verziónál tart...Ez jó hír :)
Az IVIEW már 0.1 verziónál tart...Ez valóban nagyon-nagyon jó hír! :-) Bármikor szívesen jelentkezem BETA tesztelésre! ;-)
Feltöltöttem a javított verziót.István hozzászólása alapján kibõvítettem az angol és a magyar wikit is az új verzióról. Aki esetleg tudja is, mit jelent az átméretezéssel járó interpoláció, megnézhetné, hogy jól írtam-e.
Az IVIEW már 0.1 verziónál tart...Ez jó hír! A tesztelését én is vállalom.
István, esetleg azzal az extra karakteres móddal foglalkozol, vagy gondolkodsz rajta? :)Nem ismerem ennek a módnak a pontos részleteit, például hogy a karakterkészletet az egész képernyőre kell-e generálni (ami lényegében egy "veszteséges tömörítés" lenne), vagy minden karaktersorban más lehet-e (igaz, így nem sok értelme van az egyszerű PIXEL/LPIXEL módokhoz képest; bár a karakterkészlet egy része kihasználatlan maradna, például 64 karakteres módban 40 karakter szélességű képnél minden karaktersorban lenne 24 szabadon felhasználható karakter) ? Ezen kívül a színek az egész képernyőn azonosak legyenek, vagy választhatóak karakter- vagy pixel soronként ? Használja-e az ALTIND0 bitet, amellyel két 4 színű paletta közül lehet választani karakterenként ? A karakterek magassága 8 vagy 9 pixel legyen, esetleg választható ?
még nincs például LPIXEL módErröl jut eszembe egy bug: a videó mód bájtban nincs beállitva a VRES bit!
így megoldható a legnagyobb felbontás mellett 4 szín használata!Szerintem nem, hiszen a karakteres képernyö eleve fele akkora felbontású. A spéci vezérlö bitekkel ugyan 8 színt is össze lehet hozni 64-es karakterkészlet mellett, de itt csak 4 kötött párból lehet választani, ehhez képest az ugyanilyen felbontású attributum mód sokkal jobb.
hm vagy az nem is karakteres mód?Igen az kétszínû nagyfelbontású grafikus módban van szímulálva.
Tehát függõleges csíkos lenne a grafika amit megjelenítenénk vele...Így van.
Erröl jut eszembe egy bug: a videó mód bájtban nincs beállitva a VRES bit!Bár az eredeti dokumentáció szerint (lásd itt (http://enterpriseforever.com/enterprise_forum/pc_ep_kepkonverzio-t27.0.html;msg9899#msg9899)) a mód byte-ban a VINT, VRES, és RELOAD bitek értéke mindig 0 - mert ezeket a képet megjelenítő program állítja be, az epimgconv.7z-t lecseréltem, így már be van állítva a VRES bit a file-okban.
Bár az eredeti dokumentáció szerint (lásd itt (http://enterpriseforever.com/enterprise_forum/pc_ep_kepkonverzio-t27.0.html;msg9899#msg9899)) a mód byte-ban a VINT, VRES, és RELOAD bitek értéke mindig 0 - mert ezeket a képet megjelenítõ program állítja be,Igen itt:
A mód meg a szín lehetne az LPT-ben használatos bit kiosztással tárolva, így ez a bájt közvetlenül felhasználható lenne az LPT generáláshoz.nem fogalmaztam egyértelmûen, hogy teljesen "konyhakészre" kérem :oops: A VINT meg RELOAD az egyértelmû, hogy a program dolga.
Kétszínû módban nem lehetne soronkénti palettát használni? Pl egy RTL Klub logót (http://tv.tvnet.hu/tv/img/rtlklub.jpg) vagy más hasonlót jól meg lehetne jeleníteni 2 színben is, hiszen egy sorban max annyi van :-)
OK, átírom, hogy a 4 színű módhoz hasonló algoritmust használjon. Az eredeti fekete-fehér konverziót a '-color0 0 -color1 255' paraméterekkel lehet majd engedélyezni.Feltöltöttem az új verziót, a fent leírt módosítással és egy-két kisebb hiba javításával.
a minõség nem túl jó :(Ha jól sejtem a jpg tömörítés a hiba oka, amiatt már nem tiszta színekbõl áll a kép.
IVIEW 0.2Nagyon jó lett :) Egy kisebb hibát azonban találtam: az alábbi résznél hiányzik egy 'LD A, B', ezért a FIXBIAS mindig 0.
Egy kisebb hibát azonban találtam: az alábbi résznél hiányzik egy 'LD A, B', ezért a FIXBIAS mindig 0.Jár egy bétateszter pirospont :-)
pl. nem lehet tárolni a margókat, ALTIND0/MSBALT biteket, stb.Még van szabad bájt a fejlécben :-) Be lehet tenni egy jelzõ bítet, hogy margóbájtok is vannak a fájlban. (Ebbe akkor benne lehetnek a spéci bitek is.)
Még van szabad bájt a fejlécben :-) Be lehet tenni egy jelzõ bítet, hogy margóbájtok is vannak a fájlban. (Ebbe akkor benne lehetnek a spéci bitek is.)Elvileg megoldható, bár így már lassan egyszerűbb csak a kész LPB-ket tárolni :)
Egy másik pedig: van ilyen, hogy "bit 4: video adat interlace"Nem, mindig csak 2 képkocka van, az egyes interlace bitek egyszerűen azt jelentik, hogy az adott típusú adat (pl. paletta) a második félképben különböző lehet-e (és ennek megfelelően tartalmazza-e a file), vagy pedig ugyanaz, mint az elsőben; így lehetőség van például arra, hogy attribute módban a paletta és az attribútumok azonosak legyenek a két félképen, és így a file mérete kisebb legyen valamivel rosszabb minőség árán. A gyakorlatban azonban a konverter ezt a lehetőséget egyelőre nem használja, és mindig minden adatot (paletta, attribútumok, és pixelek) külön tárol a két félképhez, a video mód és a FIXBIAS kivételével.
Ez ugye azt jelenti, amit a Nasa Guy demókban csináltak, hogy több képkockás LPT-vel csinálnak animációt?
Ehhez akkor kéne tárolni, hogy hány képfázis van.
Lekezeli a modultöltés funkcióhívást, vagyis amikor a rendszerben van, akkor ha kiadunk LOAD parancsot egy RAW formátumú képre, az betöltõdik. Billentyûnyomásra kilép a bejelentkezõ képhez.Ez nekem lefagy nagy méretű képek esetén - amelyek azonban az IVIEW file választó menüjéből hibátlanul betöltődnek - bár lehet, hogy a probléma a memória konfigurációtól is függ.
Ez nekem lefagy nagy méretû képek esetén - amelyek azonban az IVIEW file választó menüjébõl hibátlanul betöltõdnek - bár lehet, hogy a probléma a memória konfigurációtól is függ.Elõfordulhat, mivel memória menedzsment még nincs :oops:
És egy kis segítség a kezdõ képgyárosoknak (pl Ep128 kolléga :-) ):A legjobb mód keresésekor érdemes lehet a minőséget (-quality) a legalacsonyabbra (1) állítani, mert a gyakorlatban a növelése csak lassulást eredményez, kis mértékű (illetve gyakran semmilyen) minőség javulással; kivétel lehet a 2-es és 3-a mód, ahol a '-quality 9' minden lehetséges FIXBIAS értékkel elvégzi a konverziót, az - elvileg - legjobb változatot megtartva, ami valóban látható változást (ami nem feltétlenül javulás esztétikailag) eredményezhet. A nagyobb -quality értékeket általában csak a végleges konverziónál érdemes használni, amikor a többi paramétert már sikerült megfelelően beállítani.
Itt egy bat fájl, amivel könnyen gyorsan lehet egy kupac képet gyártani:
Kell egy jpg kép, célszerû átnevezni szabvány 8.3-as formájúra, hogy ne legyen majd EP-n gond.
Ha mondjuk PROBA.JPG-nk van, akkor csak ennyit kell írni:
R PROBA
És ez legyártja a képet többféle formában, majd a hozzá tartozó IVIEW.INI-t is. Aztán lehet nézegetni, hogy melyik konvertálási mód a legjobb, és azt a változatot megtartani.
Fontos, hogy a -size paraméterrel beállított szélesség és magasság aránya azonos legyen a konvertálandó képpel, mert különben oldalt vagy alul és felül keretszínnel feltöltött részek lesznekHa nincs size megadva, akkor egy fix alapértéket használ, vagy a kép méretébõl megpróbál egy optimális értéket kitalálni?
azaz -mode 16, de azt az iview még nem tudja megjeleníteniMár dolgozunk az ügyön :-)
a file mérete is nagy lehetIgen, elkezdtem számolgatni, elvileg 46 karakter, 300 sor lehet a max, amit bele lehet zsúfolni egy LPT táblába. (Kérdés, hogy van-e olyan monitor ami képes ezt mind megjeleníteni :-) )
Mindenestre felraksz pár ilyen képet? Jól fog jönni majd teszteléshez :-)A konvertált képtől függetlenül pl. a '-mode 2 -size 46 286 -raw 1' lefagy, de a '-mode 2 -size 46 240 -raw 1' még nem.
Mindenesetre elõfordulhat, hogy a rendszerszegmenst ideiglenesen el kell költöztetni a kép megjelenítésének idejére.Így valóban megoldható ez a probléma (de a reset használata kilépésre ilyenkor nem ajánlott :)).
Ha nincs size megadva, akkor egy fix alapértéket használ, vagy a kép méretébõl megpróbál egy optimális értéket kitalálni?Az alapértelmezett 40,240 méretet használja (azaz 320x240 4 színű módban, 4:3 arány), és nem optimalizálja a video méretet a konvertált képnek megfelelően. Az átméretezést úgy állítja be, hogy az alapértelmezett -scale és -offset értékekkel a legnagyobb legyen a kép mérete levágott részek nélkül.
Így valóban megoldható ez a probléma (de a reset használata kilépésre ilyenkor nem ajánlott :)).:-) Ezen is elmélkedtem már... meg kell nézni mennyi adatra van szüksége az EXOS-nak ahhoz, hogy a melegindítási rutin elindításához eljusson.
Az átméretezést úgy állítja be, hogy az alapértelmezett -scale és -offset értékekkel a legnagyobb legyen a kép mérete levágott részek nélkül.Esetleg nem lehetne egy olyan opció is, hogy miután megvan ez az átméretezési érték, optimalizálja a size értékeket, hogy a legkevesebb üres terület maradjon?
video mód 0 (LPT mód & 06Eh)Lehetne ezen módosítani? Ilyenre:
FIXBIAS 0 (csak 16 színû és attribute módokban)
paletta 0 (256 színû módban nincs, 2 és 4 színû módban csak 2 vagy 4 szín, egyébként 8 szín)
attribute adat 0 (csak attribute módban)
video adat 0
video mód 1 (csak interlace módban)
FIXBIAS 1 (csak interlace módban)
paletta 1 (csak interlace módban)
attribute adat 1 (csak interlace módban)
video adat 1 (csak interlace módban)
Lehetne ezen módosítani? Ilyenre:OK, átírom, hogy az adatok ne félkép, hanem adattípus szerint legyenek rendezve.
OK, átírom, hogy az adatok ne félkép, hanem adattípus szerint legyenek rendezve.Köszi, várom nagyon :-)
Köszi, várom nagyon :-)epimgconv.7z frissítve :) Az új verzióval az adatok már típus és nem félkép szerint vannak rendezve.
Ilyen animációra már én is gondoltam, Nasa Guy demók mintájára. Ehhze viszont be kéne vezetni egy új változót a fejlécben: LPT fázisok száma (interlacenél ez 2)Animációknál az egyes képkockák közötti időt is tárolni kell ?
Animációknál az egyes képkockák közötti idõt is tárolni kell ?Most kibeleztem egy Nasa&Guy (http://www.ep128.hu/Ep_Demo/Pic/NasaGuy7.gif)-demót :-) Ott úgy biztosították, hogy ne legyen túl gyors a kép váltás, hogy 3 LPT fázisban van ugyanaz a képkocka kitéve. (és összesen 20 képkocka van)
Szóval igen, célszerû lenne ezt is tárolni, hogy 1 kép, hány fázisban legyen kirakva.Akkor az még egy byte felhasználva a fejlécben :) A fenti leírást ennek megfelelően módosítottam.
elvileg 46 karakter, 300 sor lehet a max, amit bele lehet zsúfolni egy LPT táblába. (Kérdés, hogy van-e olyan monitor ami képes ezt mind megjeleníteni :-) )Úgy tünik, hogy a közkedvelt Philips CM88xx monitorok, tudják! Csak kell használni a hátsó képméret potmétereket a beállításhoz :-)
Úgy tünik, hogy a közkedvelt Philips CM88xx monitorok, tudják! Csak kell használni a hátsó képméret potmétereket a beállításhoz :-)Akkor lehetne "monoszkóp" programot is írni EP-re, amivel pontosan be lehet állítani a monitort az EP-hez...
- ha nincs billentyûlenyomás, akkor automatikusan tovább lép kb félperc után (slideshow :-) ) (késöbb majd paraméterezhetõ lesz)Azt meg lehet oldani, hogy egy kép esetén ne lépjen ki automatikusan fél perc után ?
Bug vadászatot a bétateszterekre bízom, én most megyek aludni, mielõtt még egyszer hajnali 2 óra lesz :-)Egy lehetséges kisebb hibát találtam: a FILE: eszközről load paranccsal töltött képeknél a FIXBIAS-t nem állítja be. Ennek az lehet az oka, hogy a FILE: olvasása túl gyors, és így nincs elég idő video megszakításra, és az EXOS nem tudja beállítani a FIXBIAS-t mielőtt a program letiltaná a megszakításokat (a régebbi verziók a 080h portot közvetlenül írták). De ez lehet, hogy elsősorban emulátor/epfileio.rom probléma, mert igazi gépen ilyen hiba nem fordul elő :)
Ezen kívül a "raw" formátum tömöríthető az epcompress által használt algoritmussal (aminek a hasznossága ugyan még nem egyértelmű :)).Ezt le lehetne cserélni a DTF egy továbbfejlesztett változatára is, amit talán egyszerűbb (ha esetleg lassabb is) olvasni.
Bug vadászatot a bétateszterekre bízom, én most megyek aludni, mielõtt még egyszer hajnali 2 óra lesz :-)Még egy hibát találtam: interlace módban nincs nagyobb függőleges felbontás, mert a második félkép nincs eltolva fél sorral. Ezt úgy lehet megoldani, hogy a VSYNC ne sor elején legyen bekapcsolva, hanem sor közepén (a kikapcsolás pedig nem a sor közepén, hanem a sor végén, de a bekapcsolás időpontja a fontosabb). Az IVIEW LPT-t egy 46x276 attribute interlace képnél az alábbi módon megváltoztatva az interlace működik ep128emu alatt, de ezt természetesen igazi gépen sem árt tesztelni, esetleg több TV-n és monitoron is :)
>3F11A0 FC 10 20 3F 00 00 00 00 :|."?....
>3F11A8 00 00 00 00 00 00 00 00 :........
>3F11B0 FF 90 3F 38 00 00 00 00 :..?8....
>3F11B8 00 00 00 00 00 00 00 00 :........
>3F11C0 FB 12 06 3F 00 00 00 00 :{..?....
>3F11C8 00 00 00 00 00 00 00 00 :........
Összehasonlításképpen az első félkép VBLANK része:>3F0010 FC 10 06 3F 00 00 00 00 :|..?....
>3F0018 00 00 00 00 00 00 00 00 :........
>3F0020 FF 90 3F 20 00 00 00 00 :..? ....
>3F0028 00 00 00 00 00 00 00 00 :........
>3F0030 FC 12 06 3F 00 00 00 00 :|..?....
>3F0038 00 00 00 00 00 00 00 00 :........
Egy lehetséges kisebb hibát találtam: a FILE: eszközről load paranccsal töltött képeknél a FIXBIAS-t nem állítja be. Ennek az lehet az oka, hogy a FILE: olvasása túl gyors, és így nincs elég idő video megszakításra, és az EXOS nem tudja beállítani a FIXBIAS-t mielőtt a program letiltaná a megszakításokat (a régebbi verziók a 080h portot közvetlenül írták).Természetesen ugyanez a "hiba" a keretszínt is érinti. Megoldásként az IVIEW.EXT-ben az EXOS változók állítása mellett a keretszínt és a FIXBIAS-t azonnal ki lehetne írni a 081h és 080h portokra is. De az epfileio.rom-ot is le lehetne lassítani, hogy a betöltés ideje ne legyen kevesebb, mint 0.02 másodperc (igazi gépen ilyen sebesség valószínűleg nem lenne lehetséges :)).
Esetleg lehetne olyan extra dolog, hogy nem minden sor kap új palettát, hanem csak minden x. sor. Ezzel nyernénk valamennyi memóriát némi minõség csökkenéssel.Ezt az IVIEW formátum már lehetővé teszi, de a konverterben még nincs megvalósítva. Az a kisebb hátránya lenne ugyan, hogy a 0, 1, 4, és 6 módokban használt algoritmus, amely a soronként változó palettát és a dithert kombinálja, így nem működne annyira jól.
Attr üzemmódban ugyanez mehetne a color információra.
Vagy ez már túlbonyolítás? :)
Slideshow esetén különbözõ kép eltûntetõ és megjelenítõ effektek is mehetnének. :)EP-n az LPT jól használható ilyen effektusokhoz :)
a VSYNC ne sor elején legyen bekapcsolva, hanem sor közepénÉs akkor kell ez, ha az interlace bájt 7-es bitje 1, igaz?
Akkor lehetne "monoszkóp" programot is írni EP-re, amivel pontosan be lehet állítani a monitort az EP-hez...Már gondoltam ilyenre, hogy le lehessen mérni, hogy egyes megjelenítõk mekkora képet bírnak kirakni.
Ezt az IVIEW formátum már lehetõvé tesziLehet, hogy rosszul nézem, de az Attributum terület x. soronként változikra nem látok lehetõséget.
Ezen kívül a "raw" formátum tömöríthetõ az epcompress által használt algoritmussal (aminek a hasznossága ugyan még nem egyértelmû :))A tömörítésnek EP64 + bazi nagy interlace kép esetén lesz értelme, ugyanis itt nincs hely hova elmenteni a rendszerszegmenst. És így be se lehet tölteni a kép végét, mert azzal már töltés közben felülírjuk a rendszert. Egyetlen lehetõség a kép megjelenítésére, ha a betöltendõ adatmennyiség befér a rendesen elérhetõ memóriába, és csak utána kicsomagoláskor írjuk felül a rendszert.
Lehet, hogy rosszul nézem, de az Attributum terület x. soronként változikra nem látok lehetõséget.Valóban nincs ilyen paraméter :oops: A formátum dokumentációját (http://wiki.enterpriseforever.com/index.php?title=Epimgconv_le%C3%ADr%C3%A1s#Az_EPimgconv.2FIVIEW_form.C3.A1tum_le.C3.ADr.C3.A1sa) módosítottam, hogy a fejléc tárolja ezt is, de lassan elfogy a hely :)
És akkor kell ez, ha az interlace bájt 7-es bitje 1, igaz?Igen.
de lassan elfogy a hely :)00Fh<>0: kiterjesztett fejléc következik :)
A tömörítésnek EP64 + bazi nagy interlace kép esetén lesz értelme, ugyanis itt nincs hely hova elmenteni a rendszerszegmenst. És így be se lehet tölteni a kép végét, mert azzal már töltés közben felülírjuk a rendszert. Egyetlen lehetõség a kép megjelenítésére, ha a betöltendõ adatmennyiség befér a rendesen elérhetõ memóriába, és csak utána kicsomagoláskor írjuk felül a rendszert.Ha nem probléma, hogy a kép megjelenítése után csak hidegindítással lehet kilépni, akkor így valóban meg lehet oldani nagyobb képek betoltését EP64-en (ez a .com formátum használatakor már működik, bár kicsomagolás közben az EXOS LPT-t felülírhatja, ami kisebb esztétikai hiba :)). Igaz, a kitömörítéshez viszont kell még néhány száz byte memória, és a memóriakezelés még 128K memóriával sem egyszerű, ha az egész képet először be kell tölteni a memóriába és ott kicsomagolni, majd a video memóriába másolni és LPT-t generálni, mindezt lehetőleg úgy, hogy közben semmilyen adat ne íródjon felül, amire később még szükség lehet.
Ezen kívül a "raw" formátum tömöríthetõ az epcompress által használt algoritmussal (aminek a hasznossága ugyan még nem egyértelmû :)).Szerintem hasznos, mert ha a jövõben valaki netalán EP-re írna programot és tesz bele szép képeket és ez így együtt sok helyet foglal, akkor a tömörítés kapóra jöhet.
Az LPT VBLANK részében még lehetne 3 fekete sor a szinkron elõtt, és a szinkron utáni fekete részt is meg lehetne hosszabbítani néhány sorral, mert elvileg a nem blanking résznek csak 294 sornak kéne lennie, és nem 300-nak. Ez ugyan nem biztos, hogy a gyakorlatban probléma, bár lehet, hogy néhány régebbi TV-n ugrálna vagy futna a kép, ha nem fekete a keret :) A szinkron viszont lehet rövidebb is egy vagy két sorral (a szabványos hossza 2.5 sor).Én a Spectrum Világban leközölt LPT-bõl (http://ep.homeserver.hu/Programozas/Spectrum_programok_atirasa/Forras/LOADER.txt) indultam ki, ez gondolom nagyjából az átíratok legalább 3/4-ében megtalálható, így valószínüleg gond nélkül mûködik :-)
Én a Spectrum Világban leközölt LPT-bõl (http://ep.homeserver.hu/Programozas/Spectrum_programok_atirasa/Forras/LOADER.txt) indultam ki, ez gondolom nagyjából az átíratok legalább 3/4-ében megtalálható, így valószínüleg gond nélkül mûködik :-)Ez az LPT megegyezik azzal, amit az EXOS használ, tehát valószínűleg tényleg jó. :) Azonban, a Spectrum Világ és az EXOS LPT-je is tartalmaz 3 sort a szinkron előtt, amelyek látszólag keretszínűek (LM=63, RM=0), de VSYNC mód van beállítva, és ez a 3 sor az IVIEW esetén hiányzik, ha jól emlékszem.
(a régebbi verziók a 080h portot közvetlenül írták). De ez lehet, hogy elsõsorban emulátor/epfileio.rom probléma, mert igazi gépen ilyen hiba nem fordul elõ :)Direkt lett átrakva EXOS-ra, mivel átkerült e beolvasás elé, hogy már töltõdés közben jól jelenjen meg. Viszont ha itt port írás volt, az utána következõ rengeteg EXOS hívás alatt az EXOS visszaállította valódi gépen :-)
Szerintem hasznos, mert ha a jövõben valaki netalán EP-re írna programot és tesz bele szép képeket és ez így együtt sok helyet foglal, akkor a tömörítés kapóra jöhet.Igaz, csak a lemezen foglalna kevesebb helyet, de az is hasznos lehet esetleg, hogy például egy floppyn a lehető legtöbb képnek legyen hely.
Egyébként a mód, bias, és paletta adatokat, illetve az attribútumokat és pixel adatot talán célszerûbb lenne külön blokkban tárolni (jelenleg az egész kép egyben van tömörítve, a fejléc kivételével), mert így meg lehetne oldani, hogy látható legyen a kép már kicsomagolt része.No meg így könnyebb is lenne a betöltés :-)
Mindenesetre feladat a bétatesztereknek, hogy minden lehetséges megjelenítõn próbálják ki, mit szól ilyen maximalista képmérethez?TV kártyával az RF kimenetről működik, ezt a 42x600 (interlace) méretű képet stabilan jelenítette meg. Igaz, valójában csak 576 sor látható :) Azonban a szinkron előtti 3 fekete sort, ami a "szabványos" LPT-kben található, talán be lehetne építeni a biztonság kedvéért - így pontosan 300 sor maradna keret nélkül.
No meg így könnyebb is lenne a betöltés :-)Erre gondoltam én is, miután megnéztem, hogyan tölti be az IVIEW a képeket :)
Az elejét nem is tudom van-e értelme tömöríteni, a nagy megtakarítás úgyis az attribútum és pixel területeknél érhetõ el.Bár a paletta valóban viszonylag kis méretű, az egyes sorok között gyakran csak kis eltérések vannak, ezért általában jól tömöríthető. Az attribútumok kevésbé, a pixel adat pedig - legalábbis attr módban - alig tömöríthető (de 16 színű módban már jobban, és 2, 4, és 256 színű módban még jobban).
Azonban a szinkron elõtti 3 fekete sort, ami a "szabványos" LPT-kben található, talán be lehetne építeni a biztonság kedvéért - így pontosan 300 sor maradna keret nélkül.Akkor pontosan mi is lenne az ajánlott SYNC blokk?
ezt a 42x600 (interlace) méretû képet stabilan jelenítette megKérjük szépen EP formátumban is ezt a képet :-)
Kérjük szépen EP formátumban is ezt a képet :-)eredeti kép (http://commons.wikimedia.org/wiki/Image:Yellowstone_Castle_Geysir_Edit.jpg), epimgconv paraméterek:
Akkor pontosan mi is lenne az ajánlott SYNC blokk?Az EXOS LPT-ben használt VBLANK rész csak annyiban tér el az IVIEW-től, hogy van a szinkron előtt a már említett 3 fekete sor:
>BAD0 FD 10 3F 00 00 00 00 00 :}.?.....
>BAD8 00 00 00 00 00 00 00 00 :........
>BAE0 FC 10 06 3F 00 00 00 00 :|..?....
>BAE8 00 00 00 00 00 00 00 00 :........
>BAF0 FF 10 3F 20 00 00 00 00 :..? ....
>BAF8 00 00 00 00 00 00 00 00 :........
>BB00 FC 12 06 3F 00 00 00 00 :|..?....
>BB08 00 00 00 00 00 00 00 00 :........
Megnézném pár attr kép pixel adatát az attr-ek nélkül. :) Biztos szép látvány lehet. :)Pixel adat attribútumok nélkül, és attribútumok véletlenszerű pixelekkel. A tömörítésen egyébként valószínűleg lehetne javítani egy keveset a paletta és az attribútumok rendezésével, hogy az adatok kevésbé legyenek véletlenszerűek.
A szinkron viszont lehet rövidebb is egy vagy két sorral (a szabványos hossza 2.5 sor).És ezt honnan is lehetne lecsípni?
És ezt honnan is lehetne lecsípni?Elvileg innen, és az EXOS dokumentáció szerint is csak 2 sor van itt:
>BAE0 FC 10 06 3F 00 00 00 00 :|..?....
>BAE8 00 00 00 00 00 00 00 00 :........
De ha a legnagyobb függőleges méret a cél, akkor a már meglevő IVIEW LPT-hez képest ezeknek a változtatásoknak az a hátránya, hogy a kép felfelé mozdul el néhány sorral, és így esetleg a TV vagy monitor többet vág le.No meg így könnyebb is lenne a betöltés :-)Feltöltöttem egy módosított epimgconv verziót, amely tömörített formátum esetén külön tárolja a mód/ bias/paletta, illetve az attr/pixel adatokat (jelenleg mindkettőt tömörítve). A paletta és attribútumok rendezésével javult a hatásfok is valamennyire, például az előbbi kép mérete kb. 1400 byte-al csökkent.
"mód, bias, és paletta adatokat" ezeket már az LPT létrehozásakor beolvassa (pl a paletta darabokat rögtön a helyükre), utána az attribútum és a pixel adatokat már egy menetben (pontosabban szegmensenként)
Ez nekem lefagy nagy méretû képek esetén - amelyek azonban az IVIEW file választó menüjébõl hibátlanul betöltõdnek - bár lehet, hogy a probléma a memória konfigurációtól is függ.Ezzel mi a tapasztalat az aktuális verzió esetén?
Ezzel mi a tapasztalat az aktuális verzió esetén?Néhány gyors próba:
64K, EXDOS+epfileio, 46x600i: nem mûködikEz annyira nem lep meg, mivel mint korábban írtam, 64K-ra még "nem gyúrtam" rá elég alaposan :oops:
64K, EXDOS+epfileio, 46x300: nem mûködik :eek: (az IVIEW.ROM-al se, de 80K-ra bõvítve már igen)
Úgy látom új imgconv került fel :-)Valóban, két kisebb újdonság van:
Lehetne olyan scalemode is, ami úgy dolgozik, hogy a kép mérete lehetõ legjobban közelítsen a megadotthoz, de ne legyen se levágás, se felesleges üres terület?A legújabb verzióban ha a -size után megadott egyik érték 0 vagy negatív, akkor azt kiszámolja a másikból és a kép méretéből. Például a -size 46 0 azt jelenti, hogy a szélesség mindig 46 karakter, a magasságot pedig automatikusan választja a kép mérete alapján. Így azonban a magasság túl nagy is lehetne, ezért negatív értéket megadva be lehet állítani egy maximális méretet. A -size 46 -300 hatása tehát azonos a -size 46 0-al, de ha a magasság így nagyobb lenne, mint 300 sor, akkor az 300 sor lesz, és a szélességet csökkenti.
Ezzel mi a tapasztalat az aktuális verzió esetén?Egy talán egyelőre kisebb jelentőségű hiba: attribute módban fix (nem soronként változó) palettával 256 sornál magasabb képnél az alsó rész pixel adat (LD2) címe ugyanaz, mint a felsőnek. Példa:
Én egy 46x300 interlace képpel próbáltam, azzal mûködött, legalábbis az én konfgomon :-)
A legújabb verzióban ha a -size után megadott egyik érték 0 vagy negatív, akkor azt kiszámolja a másikból és a kép méretébõl.Ez szuper, pont ilyesmire gondoltam!
-mûködik magnós konfigban is :-)Így egy picit többet kell várni a képek betöltésére? :D
Így egy picit többet kell várni a képek betöltésére? :DIgen, egy 46x288 méretű attribute interlace kép kb. 4 perc, de közben látni lehet a már betöltött részt. A tömörített formátummal valamivel rövidebb lenne, bár esetleg nem lehetne látni a képet betöltés közben, és a magnóhang is kevésbé lenne érdekes :)
Van az iview-ről valami összeszedett leírás?A képnézegető programról még nincs, de egyszerű a használata, és a korábbi hozzászólásokban meg lehet találni minden lényeges információt; a file formátumról is van leírás. Ezeket talán össze lehetne gyűjteni a wikin, ahol a konverterhez (epimgconv) már van viszonylag részletes dokumentáció.
Ezeket talán össze lehetne gyűjteni a wikin, ahol a konverterhez (epimgconv) már van viszonylag részletes dokumentáció.Az epimgconv paraméterek leírásánál még meg lehetne említeni a '--help'-et, illetve a még nem dokumentált paramétereket a --help alapján röviden le lehetne írni.
Nálam az Util rovatba természetesen bekerül, ha kész az 1.0 :)Kérdés, hogy mik a célkitűzések az IVIEW 1.0 kiadásáig ? :) Van még valamilyen lényeges funkció, ami hiányzik, vagy csak hibákat kell javítani (például a már említett memóriakezelési problémákat) ?
Van még valamilyen lényeges funkció, ami hiányzikTömörített formátumok kezelése :-)
Tömörített formátumok kezelése :-)Ez tök jó! :-) kíváncsi vagyok, mi minden jut majd még menet közben eszedbe! :-)
Ami még biztosan lesz a :IVIEW utáni paraméterezési lehetõség. Más EP-s képformátumok betöltése is.
Késõbbiekben RAM bõvítés kihasználása "image cache"-nak, vagyis elõre betölteni több képet a RAM-ba, utána már gyorsan lehet köztük váltani. Ha éppen nincs felülírva a rendszerszegmens, akkor amíg nézzük a képet, már töltõdhet befele a következõ.
Ez tök jó! :-) kíváncsi vagyok, mi minden jut majd még menet közben eszedbe! :-)Esetleg a kép betöltése után a háttérben véletlenszerû Musicbox/DTM zene lejátszása a képhez. :D (Ez inkább külön másik program lehetne, EP media player...)
Tömörített formátumok kezelése :-)Erre a célra megfelel a jelenlegi formátum, vagy esetleg lehetne még javítani (pl. egyszerűbb kicsomagolás, vagy jobb hatásfok) ?
Ami még biztosan lesz a :IVIEW utáni paraméterezési lehetõség.Tehát nem csak LOAD paranccsal lehessen betölteni képeket, hanem az IVIEW után is megadható legyen file név (esetleg több is) ?
Más EP-s képformátumok betöltése is.Milyen formátumok lesznek betölthetők ? Ezeknek a mentését meg lehetne valósítani a konverterben is. Természetesen az Agsys kivételével a legtöbb formátum nem támogatja a soronként változó palettát, így ezekhez meg kell oldani azt is, hogy a palettát az egész képre generálja.
Újabb epimgconv.7z frissítés. Ez tartalmazza az IVIEW legújabb verzióját, egy új paramétert (-palres), és két további file formátumot (ZozoTools VL/VS és PaintBox).Nem semmi, micsoda fejlemények vannak a 21. század hajnalán. :smt041
Az Iview-nak jelenleg a csomagban megtalálható verziója különbözik valamiben a régebbitõl? Ha jól tudom követni az eseményeket, akkor a 0.3-as volt a legutóbbi. Tényleg, 0.1-es verzió volt, vagy 0.2-essel indult a legelején?Ezt a verziót tartalmazza:
-slideshow-nál ha ESC-t vagy STOP-ot nyomunk a képbõl kilépéshez, akkor befejezi a lista végrehajtását, visszalép a FILE-hezAz előzőben az eggyel korábbi IVIEW volt.
-szinte slideshow, a funkció billentyûkkel lehet a képváltás sebességét állítani, F1 a leggyorsabb
-ha a listafájlban nem létezõ fájlra van hivatkozás, nem lép ki, hanem folytatja a következõvel
-mûködik magnós konfigban is :-) (tök jó, hogy az ep128emu magnóhangot is generál :-) ), itt .COM verziót célszerû a kazetta elejére venni, és aztán mehetnek a képek sorban
Tényleg, 0.1-es verzió voltAz nem volt publikus :-) Az kb az volt amikor a palettaváltás nélküli képeket betöltötte már. (Vagyis a 256 színû, meg a teljesen 2 színû)
Néhány gyenge próbálkozás képekre.Teljesen jók ezek a képek, nem gyengék. :smt041
Szerintem az attr üzemmódnál nem ad ez sem jobb megoldástSzerintem nézzük meg mi lesz belõle, aztán lehet eldönteni :-)
mivel az attrnek is az a lényege, hogy a szín információt kisebb felbontásban tárolja, mivel az emberi szem a szín változásra kevésbé érzékeny mint a fényerõ változásra. Ez a jpg egyik lényeges része is.Ez igaz, viszont a mi kedvenc lassan 25 éves technikánk olyan alacsony felbontásban dolgozik, hogy ha minden pixel más színû, az is bõven az emberi szem érzékenysége felett van :-)
Itt egy újabb adagnyi próbálkozás.Jók lettek :) Szerintem fel lehetne tenni ezt is, meg az előzőeket is a letöltésekhez, ahol van külön kategória a konvertált képeknek.
Ha már Interlace... István! A "Zozolace" féle szín-interlace megvalósítása mikor jön? :-)Ez természetesen megoldható, bár interlace módban soronként változó palettával már most is közvetve javul a színek megjelenítése, mert a nagyobb felbontást ditherelésre is lehet használni. Azonban ez az ötlet hasznos lehet olyan rajzoknál, ahol kifejezetten 7 színre van szükség, és azt hibátlanul kell megjeleníteni.
Nagyon kíváncsi vagyok, hogy ebbõl az elvbõl mit tudna kihozni egy ilyen szuper konvertáló progi!
Emlékeztetõül az alapelv:
Pl van két négyszínû képernyõnk, amit váltogatunk, persze ez esetben nincs félsoros eltolás.
A fekete szín közös, és ezenkívül van 2x3 paletta színünk. Az elsõ 3 színt használó pixelek az elsõ "félképben" vannak tárolva, második 3 szín pedig a másikban. Ami az egyik képben nincs használva az fekete.
Ez természetesen megoldható, bár interlace módban soronként változó palettával már most is közvetve javul a színek megjelenítése, mert a nagyobb felbontást ditherelésre is lehet használni.Akkor nem káprázott a szemem, amikor úgy vettem észre, hogy jobbak az Interlace színek!
Azonban ez az ötlet hasznos lehet olyan rajzoknál, ahol kifejezetten 7 színre van szükség, és azt hibátlanul kell megjeleníteni.Meg képekben is elõfordul olyan, hogy több apró részlet van közel egymáshoz, ami attributtum módban már elveszik. Négyszín módban módban meg összességében kevés a szín a képen, 16 színben meg bumszlik a pixelek...
még mindig meglehetõsen lassúKérdés: újabb procikra lehetne SSE3 verziót is fordítani? Számítana egyáltalán valamit? :-)
Szerintem nem gond az Epimgconv lassúsága, mert csak egyszer kell átkonvertálni a képetViszont ahhoz, hogy találj egy jó képet, lehet, hogy egy tucatot kipróbálsz közben. És egy képnél is ott van egy tucatnyi mód... és a mindenféle advanced opciókkal még nem is próbálkoztunk.
Kérdés: újabb procikra lehetne SSE3 verziót is fordítani? Számítana egyáltalán valamit? :-)Nem tudom, mert az én gépemen nem futna :) Mindenesetre feltölthetek egy ilyen verziót is (milyen CPU-ra legyen optimalizálva ?), és ki lehet próbálni, hogy van-e javulás. Az -fprofile-generate/-fprofile-use GCC opciókkal viszont sikerült a 4-es módban 10-12% gyorsulást elérni, de ezzel még kísérletezni kell. Az Intel Linuxra letölthető C++ fordítója egyelőre rosszabbnak tűnik, mint a GCC (talán mert AMD CPU-t használok ? :)), de lehet, hogy csak nem találtam meg a legjobb beállításokat.
Másik: olyat, ami több proci magot is ki tud használni egyszerre?Elvileg igen. Bár a legújabb verzió változtatásai ezt éppen nehezebbé teszik, de több olyan rész is van, ahol párhuzamosítható lenne a paletta keresés. Természetesen már most is lehet több konverziót futtatni egyszerre, külön ablakban :)
Már annyi opció van, hogy egy gui is kéne hozzá, preview-el. :)Ilyet valójában már készítettem régebben, csak más gépre. A previewhez be lehetne építeni az emulátor egy egyszerűsített változatát, vagy a konvertált adatokból közvetlenül is lehetne generálni.
Meg képekben is elõfordul olyan, hogy több apró részlet van közel egymáshoz, ami attributtum módban már elveszik. Négyszín módban módban meg összességében kevés a szín a képen, 16 színben meg bumszlik a pixelek...Akkor ez lesz majd a -mode 21.
Akkor ez lesz majd a -mode 21.Pontosabban 20-26, kivéve 25 :-) bár elvileg a keverék színekkel ott is el lehetne játszani, és akkor több mint 256, csak sok értelme nincs :-)
Elképesztõ továbbra is... :)Ha 25 évvel ezelõtt ilyen képeket raktak volna az "In Store Demonstration" kazettára, akkor tuti vitték volna a gépet mint a cukrot :-)
Ha 25 évvel ezelõtt ilyen képeket raktak volna az "In Store Demonstration" kazettára, akkor tuti vitték volna a gépet mint a cukrot :-)
Az elõbbi script tesztelése közben találtam egy IVIEW hibát: ha a kép magassága pontosan 256 sor, és a paletta az egész képen azonos, akkor hibás LPT-t generál.Javítva.
Egy talán egyelõre kisebb jelentõségû hiba: attribute módban fix (nem soronként változó) palettával 256 sornál magasabb képnél az alsó rész pixel adat (LD2) címe ugyanaz, mint a felsõnek.Ez is.
Na, próbálta valaki? Újabb felfedezett hibák?Nálam az IVIEW hibátlannak találtatott.
Na, próbálta valaki? Újabb felfedezett hibák?Nekem az ez elõttiben sem volt hiba, ill. nem vettem észre... ;-)
Na, próbálta valaki? Újabb felfedezett hibák?
Két újabb hiba, a változatosság kedvéért megint a nagy méretû, fix palettát használó képek esetén::oops: javítva.
Bár ez már valószínûleg csak szõrszálhasogatás :), de a kép nehány sorral el van csúszva felfelé.Ez már nekem is feltünt, csak még nem foglalkoztam vele :oops:
Ez a kiegészítés (természetesen a címkék és változónevek az IVIEW forrásában mások) az emulátoron pontosan középre igazítja a képetKöszi az ötletet, beépítettem! (Remélem nem rontottam el :) )
Ezen kívül még hiányzik a tömörített formátumú képek betöltésének a lehetõsége. Ez ugyan talán nem annyira fontos, és növelné a program méretét, de ha mégis tervezed a megvalósításátTervezem, csak elõbb a normál mûködés legyen hibátlan :)
akkor lehet, hogy tudnék segíteni az esetleges problémák megoldásábanEgy kis segítség jól jöhet :)
Esetleg az eltolás mértékét lehetne majd paraméterezhetõvé tenni?Lehetne az is, hogy a kép pozíciója a beépített joystick segítségével állítható legyen, és több kép megjelenítésekor a többi is automatikusan a módosított beállítást használja.
Egy kis segítség jól jöhet :)
Köszi az ötletet, beépítettem! (Remélem nem rontottam el :) )Jónak tűnik :)
Még egy apróság: "The converter program writed by IstvanV" - itt a 'writed' helyett 'written'-t kellene írni :)De akár el is hagyható: Converter program by IstvanV (Így több hely marad majd az esetleges késõbbi kitömörítõ rész számára. :ds_icon_cheesygrin: Sok kicsi sokra megy. Még az is lehet, hogy ezen fog múlni egyszer, hogy egy pár bájttal nagyobb kép elférjen a memóriában.)
A módosított iview.ext file:Ezt megnézte valaki :?:
- EP64 gépeken az iview.ext általában az FD szegmensre töltõdik beEzért is ajánlott oda a .COM vagy a ROM verzió :-)
A lukkal az a baj, hogy nem biztos, hogy pont képsor határra esik a szegmens határ. Talán úgy lesz a legegyszerübb, ha ilyenkor a csonka sort már az új szegmens elején kezdjük.Az is egy lehetséges megoldás, hogy az egész kép kezdőcíme változzon az FC szegmensben, hogy a szegmenshatár pont egy sor végére essen, így nem lesz a kép adat "lyukas", ami a tömörített formátumnál fontos. Igaz, ez a megoldás nem működne, ha kétszer kellene szegmens(eke)t átugrani, de az az eset egyébként sem fordulhat elő, mert csak 4 video szegmens van :)
Az is egy lehetséges megoldás, hogy az egész kép kezdõcíme változzon az FC szegmensben, hogy a szegmenshatár pont egy sor végére essen, így nem lesz a kép adat "lyukas", ami a tömörített formátumnál fontos.Nem rossz ötlet, szerintem ez lesz. Nem csak tömörítettnél fontos, hiszen egy LPT sor közben nem tudunk új címre ugrani :-)
Ezen kívül még ha az FD szegmensen van a bõvítõ EP64-en, akkor a szegmens nagy részét felül lehetne írni a képpelErre már gondoltam én is :-) Tulajdonképpen a luk eleje-vége videocímeket kell összegyûjteni, LPT készítéskor ugrani, no meg betöltéskor is.
A módosított iview.ext file:Az IVIEW leírását a wikin kiegészítettem egy linkkel erre a változatra.
Itt nagyon magas (pl. 300 soros) képnél a D túlcsordul, de az LPT-ben ilyenkor nem a 0 értéket kellene tárolni (mert akkor 256 sor lesz a keret és "fut" a kép), hanem a növelés elõtti 255-öt.Ez javítva, remélhetõleg más hibát nem okozva :-)
A 2.0.0.9-es idei verziószám a 0.5-öt vagy az 1.0-ást jelenti?Az 2009-et jelent, merthogy utoljára már az idén piszkáltam bele :-) a verziószám még maradt 0.4
Aktuális forrás is mellékelve, kéretik nem nagyon szörnyülködni :oops: így hátha könnyebb Istvánnak belebarkácsolni a tömörített kezelést :)Egyelőre készítettem egy IVIEW + tömörített formátumot támogató IVIEW + UNCOMPRESS + IPLAY ROM-ot. A módosított IVIEW még a régi 0.4-es verzión alapul, nem írtam át az új memóriakezelésre, és a 'CVIEW' paranccsal lehet elindítani; az új, 2009-es IVIEW verziószámát 0.42-re változtattam, hogy meg lehessen különböztetni, és az 'IVIEW' parancsra ez indul el, illetve modul betöltéskor is, ha a file tömörítetlen. Tömörített file LOAD paranccsal való betöltésekor viszont automatikusan a 'CVIEW' változatot használja.
Meg lehetne közös IVIEW-IPLAY ROM-ot fordítani, a szegmensben úgyis bõven van hely!
Frissítettem az epimgconv.7z csomagot:
- a .com formátumban mentett képek (használja ezt még valaki ? :)) betöltője "EXOS kompatibilis" lett, és a Space billentyűvel ki lehet lépni az ENTERPRISE felirathoz. Ez a verzió elvileg bármilyen - akár "lyukas" - memória konfigurációval működik, bár hibák előfordulhatnak :oops: Kisebb hátránya, hogy nagyobb méretű lett (92 helyett 428 byte)
Meg lehetne közös IVIEW-IPLAY ROM-ot fordítani, a szegmensben úgyis bõven van hely!Az SNDPLAY-t is be lehetne építeni. Esetleg az is megoldható, hogy a FILE bővítéssel bármilyen típusú file választható legyen, és automatikusan a megfelelő lejátszó vagy nézegető programot másolja a nullás lapra :?:
Az SNDPLAY-t is be lehetne építeni.Már akartam is javasolni, hogy legyen majd egy multimédia ROM :-)
Esetleg az is megoldható, hogy a FILE bõvítéssel bármilyen típusú file választható legyen, és automatikusan a megfelelõ lejátszó vagy nézegetõ programot másolja a nullás lapra :?:Nem látom elvi akadályát :-)
Már akartam is javasolni, hogy legyen majd egy multimédia ROM :-)[attachthumb=#]
Lehet, hogy ez a kép jó lesz valamire? Átkonvertáltam EP formátumra is, normál függõleges felbontással mind a 7 módban. Interlace módokkal nem próbálkoztam. Sztem az attribute mód lett a legjobb (mily meglepõ :D ). Ha valaki tovább kísérletezne, itt a kép (a ZIP-be is betettem az eredetit is):Attributum üzemmódban tökéletesen olyannak kéne lennie, mint az eredeti kép, ha kikapcsolod a ditherelést sztem.
(Attachment Link)
Attributum üzemmódban tökéletesen olyannak kéne lennie, mint az eredeti kép, ha kikapcsolod a ditherelést sztem.
Ezeket "-mode 6 -size 46 288 -nointerp 1 -dither 0 0 -chromaerr 1.0 -quality 9 -outfmt 19" beállításokkal konvertáltam:
Na, nekem nem akarja ezeket betölteni, betöltés után egybõl visszalép az ENTERPRISE felirathoz. :(Ezek tömörített képek, CVIEW-vel kell nézni.
Na, igen, nekem sem ment, gyanús is volt a képek mérete... :)Azért nem semmi, hogy kicsit több mint 1 kilóbájtba belefér egy ilyen kép. "Képtelenség", a szó legszorosabb értelmében.
Azért nem semmi, hogy kicsit több mint 1 kilóbájtba belefér egy ilyen kép.Sok az egyszínű vagy ismétlődő rész, ezért jól lehetett tömöríteni. A fényképekről konvertált file-ok mérete jóval kisebb mértékben csökken.
az IVIEW lefagyott kilépéskor).Ez az a hiba amit tegnap írtál ide? Nyugodtan maradhatott volna itt, nem baj ha látszik, hogy idõnként bénázok :oops:
Új "multiplay" bővítő csomag:Az ep128.hu-n található Multiplay.rar-ban a forráskód egy kisebb hibát tartalmaz: az uncompress.s file neve uncomprs.s-re lett rövidítve, azonban a main.s-ben a 128. sornál az include direktívát is módosítani kell ahhoz, hogy hiba nélkül lefordítható legyen. A szerzőknél Zozosoft is említhető lenne, mert az IVIEW-t nem én írtam :)
A frissített SNDPLAY és UNCOMPRESS verziókon kívül ez néhány kisebb javítást tartalmaz (a :LOAD parancs nem működött SNDPLAY file-okon, és az IVIEW lefagyott kilépéskor).
Az ep128.hu-n található Multiplay.rar-ban a forráskód egy kisebb hibát tartalmaz: az uncompress.s file neve uncomprs.s-re lett rövidítve, azonban a main.s-ben a 128. sornál az include direktívát is módosítani kell ahhoz, hogy hiba nélkül lefordítható legyen. A szerzőknél Zozosoft is említhető lenne, mert az IVIEW-t nem én írtam :)
Kijavítottam!Köszönöm. Mivel az "emulátor" oldalon új EXDOS ROM-ok vannak, amelyek a nagyobb RAMDISK mellett 128 szektor/sáv lemezformátumot is támogatnak, szerintem az emulátorhoz letölthető üres floppy image file-okat ki lehetne egészíteni nagyobbakkal is (pl. 16 MB, de akár szabványos 1.44 MB is, ami eddig is működött) :?:
Kijavítottam!Újabb kisebb észrevételek :oops: :) A név nem egészen jól van írva ("Multipaly"), és a szerzők listája időközben Gyányi Sándorral is kiegészült :)
A továbbfejlesztett DTM lejátszót és az epsndconv/sndplay-t esetleg a "Zene" oldalon is lehetne említeni, bár talán akkora jelentõsége ezeknek a programoknak nincsen :oops:Én támogatom, hogy a "Zene" oldalról is elérhetõek legyenek ezek a jó kis cuccok.
Én támogatom, hogy a "Zene" oldalról is elérhetõek legyenek ezek a jó kis cuccok.Én is!
0.4-es IVIEW Ep64-en nekem nem nem jeleníti meg jól a képek (lásd. Ep Slideshow 3).
Ha az .ext verziót használtad, akkor EP64-en problémát jelent, hogy a bővítő az FDh szegmensre töltődik be, ahol azonban a kép is lenne (feltéve, hogy nem annyira kis méretű, hogy az FCh-n elfér az egész). Tehát a .com vagy a .rom változattal kell nézni a képeket.
Multiplay-ben található IVIEW és CVIEW már nem tartalmazza ezt a hibát.
A com-al és ext-el próbáltam. A demólemezeken eleve a .com indul.
Ha jót nézek, abban viszont nincsen .com változat... :(
Régen voltak már konvertált képek :-)Hû, de mennyi... :-) Betelik vele egy fél (Ep) partició a vinyón. :lol:
Régen voltak már konvertált képek :-)
Párat én is megnéztem már, tényleg nagyon jók! :smt041
Ha magnós konfigot emulálok, akkor van valami módszer arra, hogy slideshow szerûen lehessen nézni a képeket, ne kelljen mindig az ENTERPRISE felirattól kezdeni? Biztos volt errõl szó, de nem találom. :oops:
a betöltõképet - amelyet egyébként dither nélküli változatra cseréltemA dithert hogy is kell letiltani?
A dithert hogy is kell letiltani?
Persze most lehet hogy azt gondoljátok hogy így csak ilyen pacman meg boulder dash szerû pályákat lehet csinálni, azonban ez súlyos tévedés. :)Azért én az ilyen pacman játékot is megnézném. :)
Gondolom, azért nem lett szebb a kép, mert a kép mérete nem arányos az eredetivel és a színeket is kicsit megváltoztattam. Jobb minõséget nem lehet elérni ilyen szerkesztett screenshotoknál?
Nincs valakinek kedve feltenni az Enterprise SlideShow 3-at a Youtube-ra, elkápráztatni a jónépet? :)Azt be lehet valahogy állítani, hogy pl. 10 másodpercenként automatikusan a következõ képre ugorjon? Nincs kedvem stopperrel a kezemben nyomkodni a SPACE-et. Nyom space folytat game. Space: kilépés a hypertérbe. :D
Azt be lehet valahogy állítani, hogy pl. 10 másodpercenként automatikusan a következõ képre ugorjon? Nincs kedvem stopperrel a kezemben nyomkodni a SPACE-et.IVIEW leirast erdemes elolvasni :-) (http://ep128.hu/Ep_Util/IVIEW.htm)
IVIEW leirast erdemes elolvasni :-) (http://ep128.hu/Ep_Util/IVIEW.htm)Ennél már csak az lett volna gázabb, ha a leírást egyszer angolra is lefordítottam volna és úgy teszem fel a kérdést. :ds_icon_cheesygrin:
melyik sebesség a legjobb youtube-os videóhoz?
Nincs valakinek kedve feltenni az Enterprise SlideShow 3-at a Youtube-ra, elkápráztatni a jónépet? :)Az a baj, eszméletlen nagy fájlméret lesz... nem baj, ha a 3 darab slideshow 3 külön videó, nem pedig egyetlen?
Nincs valakinek kedve feltenni az Enterprise SlideShow 3-at a Youtube-ra, elkápráztatni a jónépet? :)
Milyen lett az elsõ rész? (http://www.youtube.com/watch?v=jOYY0bemZzA)Szerintem teljesen jó.
Szerintem teljesen jó.Nagyon jó lett :)
Leírásba írd bele, hogy mi is ez, meg hogy le lehet tölteni és kipróbálni valódi EP-n is, ha valaki nem hiszi el :-)
Zozosoft kérésére itt egy módosított epimgconv verzió, amellyel fejléc nélküli formátumban lehet menteni csak az attribútum és pixel adatotKöszi!!!
Akkor ha valaki nagyon tud rajzolni PC-n, ezzel megcsinálhatja pl., hogy a Wrigglerben máshogy nézzen ki a kukac, esetleg kukac helyett sündisznó, ember, netalán úthenger közlekedjen?
ezek a paraméter-hegyek mindig megriasztanak engem, mint õskövület felhasználót.Ahogy írtam neked, berakod egy .BAT fájlba, és onnantól már csak annyit kell írni, hogy pl: KONV SPRITE1
christmas.img (720 KB - letöltve 5912 .)Jók lettek! Van néhány közte, ami különösen ütõs.
Boldog Karácsonyt!Lementettem, amint visszavándorolt a kártyám, ezen fogom kipróbálni! :-)
Boldog Karácsonyt!
Zozosoft kérésére itt egy módosított epimgconv verzió, amellyel fejléc nélküli formátumban lehet menteni csak az attribútum és pixel adatot:
epimgconv.7z (1135.96 KB - downloaded 22 times.)
A fejléc nélküli formátumot az -outfmt 6 paraméter engedélyezi. Ez automatikusan "-palres 0"-t állít be. Attribútum módban először az attribútumokat menti, aztán a pixel adatot. Elvileg interlace módban is lehetne használni, de ez egyelőre hibás, mert a második félkép pixel adata elcsúszik 8 byte-al.
Ez a verzió talán valamivel gyorsabb is az előzőnél, mert újabb C++ fordítóval készült.
Meg tudja mondani valaki, hogy ez az epimgconv a legfrisebb verzio, vagy van- e mar ujabb ? :Ez a legújabb.
Es tud- e valaki beirni nekem egy parancssort, ami nagyjabol kialakult, hogy minnel tobb szinre hogyan erdemes vele konvertalni ?Én ilyesmit szoktam használni:
Lehet soronkenti palettas, meg minden ...
Es tud- e valaki beirni nekem egy parancssort, ami nagyjabol kialakult, hogy minnel tobb szinre hogyan erdemes vele konvertalni ?Itt is van néhány tipp (http://wiki.enterpriseforever.com/index.php/Epimgconv_le%C3%ADr%C3%A1s), amiket Endi írt.
Tud most olyat a kepkonverzio, hogy a mindenkori 0- as paletta szint nem hasznalja a kepben fel ertekes helyen ? Tehat hogy a mindenkori 0- as paletta szin hatterszin lehessen, es ahol ez van ott "lyukas" a kep, lehessen color-key informacinak hasznalni ?
István!
Ez a legfrissebb IVIEW csomag? (http://enterpriseforever.com/programozas/legfrissebb_sw_fejlesztesek_epre-t44.0.html;msg21011#msg21011)
Valaki meg tudná mondani, hol van ennek a képnek az eredetije?
Az ep128.hu-n is fent van a konvertált kép. (http://www.ep128.hu/Ep_Hardware.htm)
(Attachment Link)
A Google Images segítségével ezt (http://www.mikecorriero.com/index/Albums/Album1/Source/blackbirdparadise.jpg) és ezt (http://4.bp.blogspot.com/-PdSQitMNFvs/T6BRt9il5DI/AAAAAAAAamo/m_zYhDd7xFs/s1600/Blackbird+Paradise,+Michael+Corriero+%282D%29+detail.jpg) találtam. Az ep128.hu-s változaton a kép egy része le van vágva.Köszi!
Border van, ha csinálsz, csak alapból nincs. :-)Ezt nem értem, hogyan jön ide :oops: ok beállítod a keret színét, és?
(Set border X :-) )
Ezt nem értem, hogyan jön ide :oops: ok beállítod a keret színét, és?
Itt arról van szó, hogy IVIEW képekkel, teljesen el lehet tüntetni a keretet! 46 karakter x 300 sort enged meg az IVIEW, ez két szín módban 736x300, interlace esetén 736x600 felbontást jelent.
4 szín vagy attributum mód esetén pedig 368x300/368x600.
Itt arról van szó, hogy IVIEW képekkel, teljesen el lehet tüntetni a keretet!Szerintem árnyalatnyi különbség azért van aközött, hogy nincs border és hogy teljesen el lehet tüntetni. :)
Szerintem árnyalatnyi különbség azért van aközött, hogy nincs border és hogy teljesen el lehet tüntetni. :)
Szóval van, csak beállítható, hogy mekkora legyen és akár az is, hogy ne legyen.
kikerült a cikk:Nagyon jó lett a cikk, és a képek is nagyon jól lettek megválogatva :)
http://www.scene.hu/2012/10/08/az-enterprise-szamitogep-grafikai-kepessegei/
A gépünk max felbontása nem 672x512 interlace-ben?Az a baj az ilyen fix adatokkal, hogy nem számolnak a Nick rugalmasságával!
Az a baj az ilyen fix adatokkal, hogy nem számolnak a Nick rugalmasságával!:) Igenis, értettem :)
Amit ott leírtunk az a maximális amit ki lehet hozni, ill. függőlegesen lehetne még plusz 3 (interlace 6) sor de akkor már nagyon szabványtalan lesz a szinkronizációs blokk :-)
kikerült a cikk:Jó lett, helyesírásilag is! Csak egyszer kimaradt a "hardver" szóból a "d" betű.
http://www.scene.hu/2012/10/08/az-enterprise-szamitogep-grafikai-kepessegei/
Az rémlett ,hogy elméletileg 46 oszlopot tud a Nick megjeleníteni, de úgy emléxem, hogy az már nem látszik.A nagyon régi (20-30-40 éves :-) ) tévéken valóban nem, de a mai modern LCD-ken simán látszik. És az EP-vel egyidős RGB monitorokon (pl a közkedvelt Philips CM883x) is állítható a képméret, így simán látszik.
Ezek szerint a szinkron jelnek elég 9,5 sor?
Anno mikor úgy 20 éve megvettük az első színestévét, egyből hívtuk a szerelőt, hogy állítsa be (még a 42 se fért be), utána a filmekből is többet láttunk :-)Ez a jelenség megvolt nálunk is :D, ott csak vagy a sarkok lógtak ki 42-es képszélesség esetén, vagy nem igazán volt ott keret :D
Öööööö, nem is tudom hogy kérdezzem ... annak idején a PC VGA kezdő időszakában elég sok "szépnénis" képcsomag terjengett közkézen ... az Enterprise-osok ilyeneket nem konvertáltak? (igazából fogalmam sincs, miről beszélek, volt ilyen? Nahát!)Girl szóra keress :-)
Pgyuri
Amit ott leírtunk az a maximális amit ki lehet hozni, ill. függőlegesen lehetne még plusz 3 (interlace 6) sor de akkor már nagyon szabványtalan lesz a szinkronizációs blokk :-)"Szabálytalan" szinkronizációnál még a kép teljes mérete is növelhető 312 sor/félképről. Kb. +10 sor/félkép (~48.5 Hz) talán még nem fut a TV-k többségén, de néha több is működik. Viszont a "szabványos" PAL felbontás 288 látható sor/félkép, az ep128emu-n és a PC-s TV kártyákon csak ennyit lehet látni, és ez a DVD video függőleges felbontása is.
Egy batch file-ban megadott összes képre epimgconv paranccsal :DErre én is gondoltam, de a képek neveit bepötyögni oda... Még ha file-ba kinyomtatom a directory-t, könnyít valamit, de a kimeneti fájlhoz is meg kell adni újra fájlnevet, és még a paramétert is copy-paste.
Érdemesebb lenne tömörítve konvertálni a képeket, vagy jó így?
A tömörítés sokat csökkent a méreten, én is úgy csináltam.Lehet az eddigieket utólag tömöríteni, vagy újra kéne konvertálni tömörítéssel?
Erre én is gondoltam, de a képek neveit bepötyögni oda... Még ha file-ba kinyomtatom a directory-t, könnyít valamit, de a kimeneti fájlhoz is meg kell adni újra fájlnevet, és még a paramétert is copy-paste.Ha van Contexted, vagy Notepad++, akkor csak a file neveket beszúrhatod az xmillió parancsba, ki tudsz jelölni x oszloptól y oszlopig mezőt benne. Nagyon hasznos funkció, rendszeresen élek is vele.
Bár igaz, jobb egyenként konvertálni, közben ellenőrizni lehet a minőséget és a proci sem izzad le annyira a sok melótól, mert van közben pihi neki.
#!/bin/bash
rm *.pic tmp.png
FILELIST=`find . -type f -name "*.jpg" -size +40k -print`
for i in ${FILELIST} ; do
BASENAME=`basename "${i}" .jpg | head -c 8 | tr "[A-Z]" "[a-z]"`
convert "${i}" -normalize -quality 95 PNG:tmp.png
./epimgconv/linux/epimgconv_sse2 -mode 11 -outfmt 19 -size 46 276 -scalemode 1 -quality 9 tmp.png "${BASENAME}.pic" ;
done
rm tmp.png
Ezek a konvertált képek attribútum módúakHát ez gyors volt! És milyen jók lettek a képek! :smt041
C64 screenshot-okat hogy érdemes egy az egyben konvertálni?énelsődlegesen az attribútum módot használnám, másodlagosan 16 szín mód, és egész képernyőre vonatkozó palettával
Itt vannak jópofák, pár lemeznyit össze lehetne hozni...
http://c64pixels.com/main.php
Egyszerűen pontra pontosan kellene konvertálni, ha lehet. Hogyan?Az epimgconv nem jó? Az is majdnem pixel pontosan konvertál. Ha nem, akkor mentsd le a képeket, és konvertáld át BMP-be, írok egy kis programot, ami pixel pontosan átalakítja a fájlt.
Az epimgconv nem jó?De igen, István már csinált ilyen pixel pontos konvertálást. Csak nem tudom, hogyan... :smt017
De igen, István már csinált ilyen pixel pontos konvertálást. Csak nem tudom, hogyan... :smt017A Boulder Dash 3 betöltőképéhez nem az epimgconv-ot használtam, hanem ezt a scriptet:
Ez a szkript hogyan használható?Nem screenshotot konvertál, hanem a memóriába töltött több színű (160x200, 4 szín/karakter) C64 formátumú képet. Ha csak screenshot van, akkor érdemesebb az epimgconv-al próbálkozni.
Ha csak screenshot van, akkor érdemesebb az epimgconv-al próbálkozni.A színekre van valami ötlet?
De készítek módosított epimgconv verziót, ami a C64 színeket a képeken "EP kompatibilisre" cseréli.Előre is köszönöm!
static const unsigned char c64ColorTable[64] = {
// EP R G B
0x00, 0x00, 0x00, 0x00,
0xFF, 0xFF, 0xFF, 0xFF,
0x31, 0x88, 0x39, 0x32,
0xCE, 0x67, 0xB6, 0xBD,
0x15, 0x8B, 0x3F, 0x96,
0x0A, 0x55, 0xA0, 0x49,
0x8C, 0x40, 0x31, 0x8D,
0x73, 0xBF, 0xCE, 0x72,
0x91, 0x8B, 0x54, 0x29,
0x58, 0x57, 0x42, 0x00,
0xF1, 0xB8, 0x69, 0x62,
0x38, 0x50, 0x50, 0x50,
0x07, 0x78, 0x78, 0x78,
0x33, 0x94, 0xE0, 0x89,
0xFC, 0x78, 0x69, 0xC4,
0xC7, 0x9F, 0x9F, 0x9F
};
Szuper lett!Nem egészen jó, néhány helyen hibásak a színek. :( De ez a kép
epimgconv.exe -mode 2 -quality 9 -dither 0 0 -nointerp 1 -chromaerr 1 proba1.png proba1.com
erre a programra konvertálódik, és ez viszont jónak tűnik:István, még azt leírnád, hogyan kell tömöríteni. Már egyszer elmodntad, de nem találom a txt-t, amibe lejegyeztem... :oops:Az -outfmt 11..19 (a legkisebbtől a legnagyobb mértékű tömörítésig) használatával, például:
epimgconv.exe -mode 2 -quality 9 -dither 0 0 -nointerp 1 -chromaerr 1 -outfmt 19 proba1.png proba1.pic
István, még azt leírnád, hogyan kell tömöríteni. Már egyszer elmodntad, de nem találom a txt-t, amibe lejegyeztem... :oops:Itt a Wikin (http://wiki.enterpriseforever.com/index.php/Epimgconv_leírás) is van ismertető az EPimgconv-ról, benne vannak a paraméterek is. De nem az összes szerintem, mert István most írt a -chromaerr, -ymin, -ymax, -gamma, -saturation paraméterekről, azok nem ismerősek. Egyébként Laci, ha gondolod, az ep128.hu-ra is mehetne, ami a Wikin van az EPimconv-ról. De előtte még lehetne bővíteni, ha szükséges.
kicseréltem az Atomix-ban a Hiscore képernyőt, ha valakit érdekel... :-)Ha angol nyelvű a program, nem lehetne Mengyelejev nevét is angol helyesírás szerint írni (Mendeleev)? Ha nem magyar anyanyelvű kezébe kerül, furcsa lesz neki.
karakteres képre is konvertáljon?Így biztos sokkal "karakteresebbek" lennének a képek. :D
konvertáltam pár képet a híres mobilos játékból, hát, annyira jók nem lettek, talán túl finomat a színárnyalatok az eredetinlehet, hogy dither nélkül jobb eredmény jönne ki
de azért érdemes megnézni
epimgconv_sse2 -mode 16 -size 46 276 -quality 9 -scalemode 1 -outfmt 1 IMG_0082.jpg mv.pic -scale 1.24 1.24 -offset 8 -160 -palres 1 -dither 1 0.75 -ymin -0.5 -ymax 1.05
On real tv:I've just tried an epslideshow. Still curious what it would look with some flicker techniques... Are the images in the slideshow (puppies, parrots) in interlace or normal because I can't tell. Also what is the reason for the way the images load or get shown? Is it because of some compression or it's a limitation of the uses video mode?
(Attachment Link)
Do you have a SD interface? On a .VHD (with lot of EP programs) you can found many converted image packs, can you try it on your real machine and tv.
hmmm...
could someone do a preview of how it would look on a real tv when there would be two screens with slighly different dither or colors and exchange them at every frame for the shown game screen? But for the not-interlaced version... I'm really curious..because it should "polish" the dither somewhat...although I wonder how much flicker it will produce...
Please;)
EDIT: so this mode is: up to 16 different colors per line, but only 2 colors per 8x1, yes?
it should "polish" the ditherA Polish speaks about "polish". :D
Ott van még az is, hogy Spectrumon összekeverve van a videóadat, nem folyamatosan.
Ott van még az is, hogy Spectrumon összekeverve van a videóadat, nem folyamatosan.
ja, hát még ha nem ilyen ronda színek lennének specin...Teljes mértékben egyetértek, Pgyuri ezt ne olvasd :)
átírásnál ha nem a gagyi specy színeket használták volna az átírók, még szebb játékok lennének ep-n!
Teljes mértékben egyetértek, Pgyuri ezt ne olvasd :)
Nekem a legnagyobb najom a lilákkal van, és a sötét sárgával speccyn, de a többi színt is kicsit pasztelesebbé kellett volna tenni, sokat dobott volna a palettán, ja, és legalább egy jó szürke hiányzik, érdekes, mert a C64 palettája is egy f*s, ha külön-külön nézzük a színeket, de összhatásban meg nagyon el van találva.
A C64 paletta erdekes dolog. Spectrum es EP-nel is "matematikai" a dolog. C64 VIC-II eseten en azt olvastam, hogy a tervezok valogattak parat, ami nekik eppen tetszett (vegulis teljesen szabadon, ossze-vissza kvazi, max annyi van, hogy nehany szin egymas "ellentete" vmi egyszerusegi okbol), tehat nem ilyen jellegu kiosztas van, mint a ket emlitett masik gepen ...Ez rendben is van, és látszik is :)
de specy esetén mi volt az oka? egyszerűbb az elektronika ha pl rgb 255 0 0 vagy 0 255 0 stb? (nem is tudom hirtelen rgb-ben hogy vannak specyn a színek)
Nem rossz, ossze kene hasonlitani az attributum modu keppel
Képváltogatással nem lehetne? Úgy értem két képet cserélgetni a képfrissítési frekvenciával, és a két képet úgy generálnád, hogy a nagy felbontású és a 256 színű sorok megcserélődnek bennük? (Ha az egyikben a páros sorok a nagy felbontásúak és a páratlan sorok a 256 színűek, akkor a másik képben a páros sorok 256 színűek és a páratlan sorok nagy felbontásúak.) Persze vigyázni kell a kép generálásánál, hogy a fényerő különbségeket valahogyan minimalizáld, mert különben ocsmány villogás lesz az eredmény.
most próbáltam olyat, hogy egy kép r g b csatornáít kétszínűsítettem ditherrel, majd 3 sorban jelenítettem meg: első sor 3, másodig g, harmadik b. hát, nem túl jó eredmény...ez szerintem képvillogtatással jobb lenne, speccyn láttam ilyen megoldásokat, igz kifolyik az ember szeme ha fél percnél tovább nézi :D
most próbáltam olyat, hogy egy kép r g b csatornáít kétszínűsítettem ditherrel, majd 3 sorban jelenítettem meg: első sor 3, másodig g, harmadik b. hát, nem túl jó eredmény...PC-s demókban régen volt olyan softRGB mód - amikor még nem voltak elterjedve az elég erős processzorok a 15 és több bites valódi RGB módok natív feldolgozására - ami szétbontotta a képernyőt 2x2-es darabokra, majd ezekben (például) bal felül a piros, jobb felül a zöld, bal alul a kék színkomponensek voltak, jobb alul pedig üres fekete képpont. Így a tényleges felbontás - kis hunyorítással - negyedével egyező képet produkáltak, aminek jobb volt a színmélysége. És szerintem még lett volna lehetőség a feketén hagyott pixellel is játszani, de olyanra nem emlékszem. Kár, hogy a BIAS miatt ez csak elképesztően korlátozottan működhetne EP-n, ha egyáltalán volna értelme.
amúgy az epimgconv-nál jobbat tuti nem lehet kihozni ebből az egészből. ott csúcsra lett járatva az EP :)
annyival lehetne bővíteni, bár sok meló lenne biztos, hogy karakteres módra is tudjon konvertálni. ennek persze csak úgy lenne értelme, ha direkt arra mennénk rá, hogy kevés memóriát foglaló képeket csináljunk így. azaz: ismétlődő karakterekkel. tehát az egész képenyőn ugyanaz lenne a karakterkészlet, és a konvertáló leoptimalizálná a képet hogy 128 vagy 256 karakterből álljon.
na és persze ki kéne használni a 2*2 és 4*2 színű karakteres módokat is.
és persze az lenne király, ha az így készült képeket basic-ből kis lehetne használni :)
Egy lehetséges bug még, hogy turbós konfigurációkon a FILE-hoz való visszatéréskor néha egy ideig nincs kép. Ezt az okozhatja, hogy a NICK még az IVIEW LPT-jét használja (nem érte el az utolsó LPB-t) amikor azt a területet a FILE már felülírja.Kilépés előtt kiküldeni az EXOS LPT címét, force reloaddal?
Az itt található BIT 4,(HL)-t azonban nem építettem be, ez valószínűleg csak véletlenül maradt a PCK-FL14.HEA-banIgen :oops: Kiszedtem.
A PRINTER szerintem megfelel (az BASIC-ben is alapértelmezetten nyitva van).
a :LOAD parancs is azt használja.Pontosabban az első szabadot amit talál, BASIC alatt mivel a 0-ás az EDITOR, így lesz ez az 1-es.
*.KEP
0. bájt: 'K'
1. bájt: 'E'
2. bájt: 'P'
3. bájt: kép típusa:
7..4 bit: 0000b (fenntartott)
3..2 bit: tömörítés (00b- fenntartott 01b- RLE tömörített 10b- tömörítetlen 11b- fenntartott)
1..0 bit: videó mód (00b- 2 színű 01b- 4 színű 10b- 16 színű 11b- interlaced)
4. bájt: paletta[0]
5. bájt: paletta[1]
6. bájt: paletta[2]
7. bájt: paletta[3]
8. bájt: X méret pixelben (alsó bájt)
9. bájt: X méret pixelben (felső bájt)
10. bájt: Y méret pixelben (alsó bájt)
11. bájt: Y méret pixelben (felső bájt)
12. bájt: 0 (fenntartott)
13. bájt: 0 (fenntartott)
14. bájt: 0 (fenntartott)
15. bájt: 0 (fenntartott)
16.. képadatok:
- tömörítetlen mód esetén: soronként tárolt képbájtok
vízszintes bájtszám = [(pixelben adott X méret)/(bájtonkénti pixelszám)] felkerekítve bájthatárra
függőleges bájtszám = Y méret
adatbájtok száma = vízszintes bájtszám * függőleges bájtszám
- RLE (futási hossz) tömörítésnél a tömörített adatblokk a sor végéig tart (bájhatárra felkerekítve), majd új tömörített blokk kezdődik
0. bájt: számláló értéke, ha a 7..6 bit = maszk , egyébként közvetlen képbájt
1. bájt: ismétlendő képbájt, ha az előző bájt számlálóértéket tartalmazott
induláskor maszk=0, majd maszk növelése 64-el, ha a számláló érték=1
pl.: tömörítetlen képbájtok: KKKKLLLLLCDGVKAACCCCCC
RLE tömörített: 4*K 5*L CDGVK 2*A 6*C
És a képnéző forráskódja, a KEPLIB van használva az SD-s demókban is.
Nem tudom mennyire nagy munka lenne :oops: Esetleg lehetne TVC-s kimenet opciót is berakni?
Megoldhatónak tűnik, de természetesen nem lenne soronként változó paletta, és a színek is eltérnek az EP-től.Ez nyilvánvaló. Egyébként a TVC-s színeknek mely EP-s színek felelnek meg legjobban?
az utóbbiban nem látom az interlace módot (az egyébként a színek számát növelné villogtatással, és nem a felbontást?)Lehet, hogy csak tervezett, de még meg nem valósult funkció? Mindenesetre ez gondolom 64+ gépen menne, ahol több videólap van.
, a tömörítésnél pedig a fenntartott bit a formázott módot állítja, azaz hogy a fejléc tartalmazza-e a kép méretét.Utána kérdezek, hogy van-e frissebb leírás/forrás mint ami a neten volt, ill. mi a helyzet a kérdéses pontok ügyében.
Viszont ha lehetséges a képnéző program bővítése, akkor könnyen lehetne az epcompress által támogatott tömörítésekkel is menteni.Ennek gondolom semmi akadálya, csak tisztázandó, hogy az előbb emlegetett fenntartott bitekből mit lehetne felhasználni ezek jelzésére.
Ez nyilvánvaló. Egyébként a TVC-s színeknek mely EP-s színek felelnek meg legjobban?
Ennek gondolom semmi akadálya, csak tisztázandó, hogy az előbb emlegetett fenntartott bitekből mit lehetne felhasználni ezek jelzésére.
EP-n a fényes színek használhatják az első 8 paletta színt, a BIAS pedig 0.És a sorrend egybeesik, nincs olyan kavarás, mint a Spectrum színekkel?
A leírás és a forráskód szerint a felső 4 bit nem használt.Hacsak azóta nem használták fel :-) Rákérdezek biztos ami biztos.
Megfelelő időzítéssel elvileg lehetne soronként változó paletta is, a sorok közötti 72 ciklus elég 4 I/O port írására.Na ez azt hiszem nagy durranás lenne TVC-n!
És a sorrend egybeesik, nincs olyan kavarás, mint a Spectrum színekkel?
Lassan mar kene egy altalanos koverter, ami aztan tud EP-re (kulonbozo modokban), TVC, C64-re tudomisenmire konvertalni :) mert ugye az elso lepes, a kep analizalasa, dither cuccok, kvantalas miegymas az vegulis hasonlo, csak a "profil" mas, hogy mire kell aztan az eredmenyt kihozni :-D
formátum leírása és a forráskód között vannak kisebb különbségek, az utóbbiban nem látom az interlace módot (az egyébként a színek számát növelné villogtatással, és nem a felbontást?)Az interlaced formátum kísérleti stádiumban maradt. Alapvetően 4-színű grafikus mód lenne, páratlan és páros sorokra különböző palettával. A képek Floyd-Steinberg dithering algoritmussal készülnek / készültek volna. A pcxkonv.exe beállítások párbeszéd-ablakában kell beikszelni az interlaced-módot. Ilyenkor látszólag 8-színű palettával dolgozna az algoritmus. Mivel mindkét palettában a 0. fekete és 3. fehér színt fixre vettem (ezek mindenképp kellenek az algoritmusnak az intenzitás kiegyenlítéséhez), lényegében csak 2x2 szín változtatható. Ez a 4 szín kerül a KEP fájl palettainformációs bájtjaiba. Ilyen beállítással a 4-színű konverzió során interlacelt kép jön létre.
, a tömörítésnél pedig a fenntartott bit a formázott módot állítja, azaz hogy a fejléc tartalmazza-e a kép méretét.A nem formázott képek kategória alapvetően a korabeli TVC-s programok betöltő képei. Pl. az Áttörés űrhajós képe vagy a Póklakoma virágkehelyből késsel/ villával/ kanállal falatozó méhecskét ábrázoló képe.:) Ezek eredetileg semmilyen fejlécet sem tartalmaznak, csak a 15-16kB-nyi képernyőbájtot. Szövegszerkesztővel anno eléjük írtam 8 bájtot (KEP + grafikus mód + paletta), és így lett némi fejlécük. Mivel az újabb KEP fájlokat csak a pcxkonv.exe -vel lehet létrehozni, azok mindig teljes formázott fejlécet tartalmaznak. A formázatlan képek a "legacy" kategória, nem fognak újabbak készülni, és nem is terveztem a támogatásukat, ezért nem is kerültek bele a hivatalos dokumentációba. Ettől függetlenül talán a keplib.asm és a pcxkonv.exe is lekezeli őket.
Viszont ha lehetséges a képnéző program bővítéseLehet, csak adjunk neki valami új nevet, PLUS vagy V2 vagy valami, hogy ne legyen keveredés :-) Az a felső 4 bit felhasználható.
-mode:
7: TVC, 2 szín
8: TVC, 4 szín
9: TVC, 16 szín
17: TVC, 2 szín, interlace
18: TVC, 4 szín, interlace
19: TVC, 16 szín, interlace
-outfmt:
50: TVC, tömörítetlen
51, 56: TVC, epcompress -m2 (51: gyors, 56: max. tömörítés)
52, 57: TVC, epcompress -m0
53, 58: TVC, epcompress -m3
54, 59: TVC, epcompress -mz
55: TVC, RLE (eredeti formátum)
; Formazasi es tomoritesi kodok (3..2 bit a tipusbajtban)
KEPTYPE_NFORM .equ 000h ; nem formazott kep tipuskodja
KEPTYPE_FORM .equ 008h ; formazott kep tipuskodja
KEPTYPE_RLE .equ 004h ; RLE tomoritett formazott kep
KEPTYPE_FMASK .equ 0FCh ; maszk a formatumkodhoz
KEPTYPE_V2_MASK .equ 0F0h
KEPTYPE_V2 .equ 080h
KEPTYPE_INTERLACE .equ 040h
KEPTYPE_PALRES_1 .equ 020h
KEPTYPE_EPCOMPRESS .equ 010h
KEPTYPE_EPCOMPRESS_M2 .equ 010h
KEPTYPE_EPCOMPRESS_M0 .equ 014h
KEPTYPE_EPCOMPRESS_M3 .equ 018h
KEPTYPE_EPCOMPRESS_MZ .equ 01Ch
Egy gyíksága van még a TVC-s a HW-es interlace-nek: a kép szinkronjelek nem tartalmazzák a kiegyenlítő jeleket. Így elméletileg a TV nem tudja, hogy melyik kép a páros és melyik a páratlan félkép. Tehát rossz esetben felcserélődhetnek az egymás alatti sorok.
További lehetőség még a szoftveres interlace, a CRTC regisztereit megfelelő időzítéssel módosítva a VSYNC eltolása fél sorral.Ez akkor tulajdonképpen ugyanaz mint az EP-n? Csak itt nem elég egyszer leírni az LPT táblában, hanem videó megszakításból folyton írkálni kell a regisztereket, a szinkron, meg a megfelelő videólap miatt.
A konvertált képek egyébként működnek a TVC-s képnéző programmal?Nekem nem :oops:
Ez jó így?
-size 32 -240 -quality 9 -mode 8 -outfmt 50 vagy 55
Kell még -palres 0 is a soronként változó paletta tiltására.Így már van kép :-)
Valóban, van még 4 nem használt (?) byte a fejlécben a KEPHEAD_YSIZE után, így a tényleges mérete 16 byte 12 helyett.Igen írta is a leírás:
Mondjuk egy PC-s GUI sem lenne rossz... :-)
Hamarosan elkészül az is, az itt (https://enterpriseforever.com/enterprise-devcompo-2-42/qa-1442/msg60088/#msg60088) látható p4fliconv alapján.
Az epimgconv_gui.exe a grafikus felületű változatEz nagyon-nagyon-nagyon jó! :smt038
preview mindenképp legyen :)
már csak a karakteres konverzió maradt hátra :o)
Az epimgconv_gui.exe a grafikus felületű változatKéne majd még egy jó kis ikon neki :-)
Lesz githubos friss béta?
A TVC-s képekhez kellene még egy továbbfejlesztett képnéző programIgen, ez praktikus lenne :-)
Zozo has the 12000-post mark.We should have a post-record party. :D In Spain, or in Hungary.
Igen, ez praktikus lenne :-)
- debugger nélkül, rendes programként indítható betöltő :oops:Erre két megoldás is használatos, az egyik, a teljes VT-DOS alatt futó, 0100h-ra töltödő .COM file. A korábban felrakott KEPNEZO az ilyen.
org 6639
db 0FH,0AH,0,0DDH
db " USR"
db 96H,"6659"
db 95H,0FFH,0,0,0,0,0 ; 20 byte-os fej
;
macro mops n
rst 30h
defb n
endm
di
ld sp, 2000h
jp main
ds 2000h-$,0
Azt ugye jól vettem észre, hogy még nem mindenféle képpel megy? Elsőre eredeti TVC-s képpel próbáltam de csak kilépett :oops: Aztán csináltam egy m0-ásat.
Továbbfejlesztett képnéző program:Első ránézésre teljesen jól működik valódi gépen is! :smt038
de az így hozzáadott 1-3 sorban szemét jelenhet megValóban. Ha jól nézem az eddigi TVC-s képek közt is van ilyen.
- több képet is meg tud jeleníteni FILE01.KEP, FILE02.KEP, stb. sorrendben, a Space tölti a következőtLehetne még egy visszalépés gomb is?
- soronként változó paletta (-palres 1): az időzítésén még lehetne javítani, valószínűleg 35 karakter szélességig működik megfelelőenEsetleg erre valami teszt ábrákat tudnál generálni? Konvertált fényképeken nem igen sikerült felfedeznem semmi feltűnőt.
- az I és P billentyűkkel be- és kikapcsolható a CRTC interlace, alapértelmezés szerint kikapcsolt, ilyenkor is van interlace, de a páratlan félkép függőleges eltolása nélkülKövetkező képnél ezek visszaállnak alaphelyzetbe?
- az E és O billentyűkkel cserélhető a félképek sorrendje (az E az alapértelmezett) interlace (I) módban, véletlenszerű hogy melyikkel jó a kép :)
Valóban. Ha jól nézem az eddigi TVC-s képek közt is van ilyen.
Esetleg az utolsó pár sort zerofillezni?
Lehetne még egy visszalépés gomb is?
Esetleg erre valami teszt ábrákat tudnál generálni? Konvertált fényképeken nem igen sikerült felfedeznem semmi feltűnőt.
Következő képnél ezek visszaállnak alaphelyzetbe?
Ezekkel tesztelhető az időzítés, és az emulátor is összehasonlítható a valódi géppel:Minimális eltérést látok.
A 12. kép csak a néggyel nem osztható magasságot teszteli.Itt pontosan mit is látunk? Kicsit "szürkepenészes" :-) a négyzetrács. Emulátoron és a gépen is egyformán.
Itt pontosan mit is látunk?
Plusz egy megfigyelés: TVC 37 karakter az kb EP 43-nak felel meg. Átlag TV-n itt már éppen egy csak egy icipici keret marad kétoldalt, eggyel több már keretmentesnek mondható.
Valóban, ezért is alapértelmezett a pixel aspect ratio = 0.878 beállítás TVC-nél, ami a video órajelek aránya (12500000 / 14237536). A 37/43 is kb. 0.86.Ennek akkor az a kellemetlen következménye, hogy ugyan el lehet érni a CPC-s 40x200-as méretet, hogy esetleg CPC-s játékokat lehessen átírni, viszont olyan programot kéne választani, ahol a szélén csak valami nem lényeges van, ami nem baj, ha nem látszik minden megjelenítőn.
Mi lenne ha háttér regiszterek az IRQ rutiné lennének, és akkor 3 pár PUSH/POP helyett csak két EXX kéne?
Azt lenne még érdemes megnézni, hogy milyen mértékű késleltetésnél (extra NOP vagy egyéb utasítások az irqRoutine elején) kezd megjelenni a hiba a kép bal szélén valódi gépen.Ha az elején 4 db NOP van, akkor jelenik meg a bal oldali első oszlopban.
3 db NOP lesz a jó, ekkor a 7. képnél az utolsó oszlop harmadától jelenik meg.A JR-s variáció ugyanez.
Esetleg a 3 és 4 NOP között még meg lehetne próbálni a 13 (pl. OR A, RET C, NOP), 14 (INC HL, NOP, NOP)Mindkét esetben bal oldalt jó, jobb oldalon pedig a 8. képnél jön be.
és 15 ciklust (ADD HL, HL, NOP) isitt már egyes képeknél a bal oldalon is megjelenik.
Tehát a 14 várakozással működik a 7. (kék keretes, 38 karakter széles) kép emulátoron és valódi gépen is? Akkor talán az a legjobb, ha biztosan nem fordul elő hiba a bal oldalon.Igen. A 15-ösnél már néha előjött a bal oldalon a valódi gépen.
Lesz githubos friss béta?
Igen ez praktikus lenne! Nem tudom ki tud oda a wikire írni :oops:
Igen ez praktikus lenne! Nem tudom ki tud oda a wikire írni :oops:Bárki írhat oda, aki regisztrál.
Bárki írhat oda, aki regisztrál.Nem mintha mernék bármit is belepiszkálni, de pusztán érdeklődés szintjén azért megkérdezem: Kinél lehet jelentkezni regisztráció céljából?
Ha mindenkinek fóbiája van a regisztrációtól, írjátok meg pontosan, hova, mit kell írni/módosítani, és beírom. Bár érdemesebb lenne olyannak is regisztrálnia, aki tudja is, mit ír. (Bár a képkonverziót még én is értettem kivételesen.)
Nem mintha mernék bármit is belepiszkálni, de pusztán érdeklődés szintjén azért megkérdezem: Kinél lehet jelentkezni regisztráció céljából?Pedig bárki nyugodtan belepiszkálhat, azért van.
"-outfmt 6 Zozosoft kérésére. Interlace módban egyelőre hibás, a második félkép pixel adata elcsúszik 8 byte-tal."
Ez a hiba még benne van?
biztos volt már szó róla, de olyat kéne csinálni hogy 3 soronként R, G, B színek. ez 2 színű módban, soronkénti palettával lehetne hasznos
Igen, a két félkép közé kiírja a palettát. :oops:
meg hát ügye kevesebb memória. és sokszor talán nem is igényelhet soronkéntit.Miért jó, ha kevesebb memóriát "fogyaszt"?
Miért jó, ha kevesebb memóriát "fogyaszt"?
Kéne előbb egy olyan program, ami a képet használja, és a programnak nagy a memóriaigénye.
amúgy interlace kijelzése vibrál pc-n. nem lehetne szinkronizálni a monitor frekihez? vagy windóz alatt ne álmodjunk ilyesmiről? :)[attach=1]
de úgy nézem ez nem hat az epimgconv-ra (gui-s verzióban preview)Azzal nincs tapasztalatom. A plus/4-es változatban mintha lenne valami hatása az emulátor beállításának, de hogy mennyire mély azt nem tudom.
Esetleg ha az EP fájlokat is feltöltenéd :oops:Szerintem azokat már törölte is. :D De ha jól sejtem, az eredeti képet is feltöltötte, így még tudjuk reprodukálni. Ha mégsem, így jártunk. :D
A leghasznosabb az eredeti kép és a konvertálásnál használt paraméterek, amiket a grafikus felületű epimgconv menteni/tölteni is tud.
áá én mindent attr módra konvertálok, annyi, hogy mostanában rájöttem hogy a random dither az nem kell rá (diffusion = 0)
lehetett volna erre építeni egy demót, megturbózva egyéb effektekkel :)
ha távolról nézzük (vagy úgy fókuszáljuk a szemünket hogy homályos legyen a kép), akkor marilyn monroe, ha közelről akkor meg einstein :)Olyat nem lehet csinálni, hogy ha közelről nézzük, Orbán Viktor, ha távolról, akkor Gyurcsány Ferenc?
Olyat nem lehet csinálni, hogy ha közelről nézzük, Orbán Viktor, ha távolról, akkor Gyurcsány Ferenc?
na így ep képformátumban profi 3d nyomtatásnak tűnik :)Ezt hogyan sikerült megcsinálni? Hol van a kép eredetije? Na, meg az EP kép változata sincs itt, csak a kép.
Ezt hogyan sikerült megcsinálni? Hol van a kép eredetije? Na, meg az EP kép változata sincs itt, csak a kép.Ha minden igaz ez (https://enterpriseforever.com/other-topics/logos-labels-and-other-pics-for-printing-or-editing/msg62725/#msg62725) az eredetije.
érdekes lenne egymáson villogtatni őket, összemosódna több árnyalat.Pont erre gondoltam én is. Ahogy az interlace-s váltogatást meg lehet csinálni, biztos ezt is, három képpel akár.
csak egy kép valami játékból..cpc-n ez a legújabb módi, egy sor 16 szín, egy sor 4, és ez ismetelve, így készült egy mahjong játék, jól megválasztott paletteaval jó.
az jutott eszembe, lehetne olyan funkció, hogy páros és páratlan sorokra más mód lenne megadható :)
pl attr és 4 szín mód érdekes lehet. de különböző felbontások is.
cpc-n ez a legújabb módi, egy sor 16 szín, egy sor 4, és ez ismetelve, így készült egy mahjong játék, jól megválasztott paletteaval jó.
nocsak! ez az?Ez az, a mahjong tábla egyik sora 16 színű, másik sora 4, ez váltakozik az egész képernyőn, a szemet átveri ha nem nézed meg jobban, mert 320x200-as felbontás mellett 16 színnek tűnik első bliccre.
http://julien-nevo.com/mahjong/
a képek alapján mondjuk nem...
de ha van már ilyen, át kell írni :)
Ez az, a mahjong tábla egyik sora 16 színű, másik sora 4, ez váltakozik az egész képernyőn, a szemet átveri ha nem nézed meg jobban, mert 320x200-as felbontás mellett 16 színnek tűnik első bliccre.
tényleg, így jobban megnézve úgy tűnik!Lehet, sőt ott soron belül is lehet palettát váltani, csak CPU igényes, és pontosan kell időzíteni, tehát ha ilyen képernyőt építenek fel, akkor a normál kód csak a képernyőn kívül futhat.
bár azt nem értem miért jó ez itt, cpc-n nem lehet soronként palettát váltani?
egy szépen konvertálható képNagyon elvetemült lehet, aki koponyát tart a polcon. És más dolgokat tartok ott. :D
ötlet az epimgconv-hoz: 2 rasztersoronként ismétlődne a pixel és a raszter adat is. de 1 rasztersorral el lenne tolva egymáshoz képest a kettő. így fele annyi memóriát foglalna és mégis úgy tűnne hogy soronként más az adat.
patrick woodrofe festő képei nagyon jól konvertálhatók :)Az EP-re konvertált kép binárist is tedd fel!
Az EP-re konvertált kép binárist is tedd fel!
hú ez jól néz ki, még c2 és c256 módban isAz utolsó a legjobb (a 4.), aztán az első, de a másik kettő is jó, csak más.
De miért nem töltöd fel az EP-n megnyitható fájlt?
nem szoktam olyat csinálniAkkor ideje rászokni :-)
én szinte mindig alap beállításokat használok, annyi, hogy a dither 0
nem szoktam olyat csinálni
az előbb feltöltötteket egyelőre nem töltötte le senki.Én arra tippelek, esténként van nagyobb idejük az embereknek feljönni a fórumba emulátoros géppel. Mondjuk a legutóbbi zenét is pár nap óta csak 3-an nézték meg, ahol nemrég láttam.
Ezzel már próbálkoztam, de különböző lett a kép.A 16 színű kép, és az attributum módú fasza, a 2 szín módú szerintem nem olyan jó :)
Egyet már sikerült konvertálni a screenshot javítása után GIMP-ben, ez a módszer eredményesebbnek tűnik a beállítások találgatásánál, és az eredeti kép nélkül is működik:
(Attachment Link)
(Attachment Link) (szerk.: még egy kép)
(Attachment Link) (szerk. 2: 16 színű még nem volt, ez új konverzió)
kár hogy nem lehet lekapcsolni benne a tv effektet
A bias színek használatát nem igazán lehet tiltani, a normál paletta színek viszont beállíthatók olyanra, amit valószínűleg nem használ a konverzió (pl. a 109-es szín jó lehet ilyen célra). Ilyenkor a dither "diffusion" paraméterét is célszerű nem túl magasra állítani, mert ha elég nagy hiba halmozódik fel, akkor még a képtől egyébként nagyon eltérő színek is kerülhetnek egy-két pixelre.
újabb epimgconv ötletem: a 8 paletta szín ne lehessen új minden sorban, hanem minden sorban csak 1 változhasson meg. ezzel sok memóriát lehetne nyerni és elvileg jól nézhet így is ki a kép.Elvileg tuti jól nézhetne ki, de hol lenne a memória spórolás?
persze tudom, nem lesz megcsinálva, nem is kell, de szerintem érdekes ötlet :)
Elvileg tuti jól nézhetne ki, de hol lenne a memória spórolás?
ja és a nagy elemek mozgása azért elég látványos, még ha ilyen kis felbontású is.Ahogy elnézem a képeket, simán :)
plusz a c256 mód miatt mindenféle szín effektet is lehet csinálni (pl additív fények).
a kirajzolás is gyors lehet...
meg ha kézzel vannak megrajzolva az elemek, az mindig szebb mint ezek a konvertált képek.
szóval lenne benne lehetőség :)
epimgconv-val lehet valahogy lores képeket csinálni?Itt van (https://wiki.enterpriseforever.com/index.php?title=Epimgconv_le%C3%ADr%C3%A1s) egy kb. teljes leírás az Epimgconv-ról, de én nem találok benne loresre vonatkozó részt...
Itt van (https://wiki.enterpriseforever.com/index.php?title=Epimgconv_le%C3%ADr%C3%A1s) egy kb. teljes leírás az Epimgconv-ról, de én nem találok benne loresre vonatkozó részt...ja, ezt néztem
Talán még a --help-re kiír olyan paramétert, ami nincs a leírásban és lehet vele loresezni.
ja, ezt néztemSzerintem akkor se lesz igazi lores, hanem marad a normál pixel mód, csak kinézetre lesz az, de lehet tévedek.
de szerintem rájöttem: a width-et a felére veszem, és "-scale 1 2" paramétert adok meg
Szerintem akkor se lesz igazi lores, hanem marad a normál pixel mód, csak kinézetre lesz az, de lehet tévedek.lehet, de nekem pont erre volt szükségem :-)
Kép8bitizélő, sokféle gépekre. Kivéve persze az EP-t...Van nekünk saját izélőnk :-)