-
Rajzoltam a Paintben egy 64x64 képpontos képet.
Ezt elmentettem mint 16 színû kép (save as... és utána lent ki lehet választani a típust)
Megvizsgáltam milyen adatok vannak a BMP kép fejlécében, és írtam egy BASIC programot, ami kirajzolja.
A BMP rôl azt kell tudni, hogy az adatmezô elsô bájtja a képen balra lent kezdôdik. Így a képet alulról felfelé rajzolja ki.
Mellékletben van a floppi fájl, amin a BMP kép és a basic program található.
A basic programot elindítva betölti a fájlt a lemezrôl.
Ha valakinek van kedve rajzolgatni, akkor figyelembe kell venni, hogy maximum 720/8=90 magas lehet a BMP kép és 1200/8=150 széles. Ha lehet ezek az x/y méretek legyenek 2-vel oszthatóak. (nem tudom mi van, ha páratlan)
A BMP képen megnyitva alul van a paletta amibôl lehet választani. A Paint enged mindenféle színt, de a mentés után (16 szín miatt) már rotnani fog, és nem úgy fog kinézni. Ezért az alsó sorból lehet "mintát venni".
Érdemes felnagyítani a képet és úgy rajzolni.
Megjegyzés: Az emulátor amin dolgoztam fel van turbózva 80 MHZ-re ezért nálam gyorsan rajzol.
-
Nem rossz ötlet ez arra, hogy basic programokba is rakhassunk képeket. Még valami tömörítést kéne kitalálni hozzá.
It is not a bad idea, we could insert pictures into basic programs too. Some compression should be invented for this.
Das ist eine gute Idee, um Bilder in Programme, die in basic geschrieben wurden, einzufügen. Eine Komprimierung sollte noch dafür erfunden werden.
Es una buena idea para poner imágenes en programas escritos en basic. Alguna compresión debería ser inventada para ello.
-
Ha kicserélem a töltő rutint gépi kódra, akkor nem lesz olyan lassú.
Tömörítéssel nem vesződnék, mert akkor elvész az egyszerűsége a dolognak.
-
Érdekes dolgot vettem észre.
Graphics 2-ben a pixelek soványak. 1:2 arányú szélesség:magasság méretnél.
Graphics 4-ben a pixel pont arányosan négyzet.
Graphics 16-ban pedig lapos 2:1 arányú.
A Microsoft Paint csak arányos 1:1 pixelt támogat.
Emiatt hogy a kép hasonló legyen, Graphics 2 ben minden pixel mellé kell tenni egy másikat. Graphics 16-ban pedig fölé.
A Graphics 2-ben mellérakott pixel máris Graphics 4-et eredményez, akkor viszont már 4 színt is lehet használni.
Vannak olyan rajzolóptogramok amik támogatják az aránytalan pixelméretet, de ennek a témának a mélyére nem akartam menni.
Graphics 2 esetén interlace móddal lehetne arányos pixelt csinálni, de annyira körülményes az interlace, hogy ezzel nem foglakozom.
Nagyon érdekes a dolog az is ha az EP nem monitorra hanem tv-re van kötve és PAL Composite jelátalakítás miatt bizonyos színeket összemos/összekever, a "dithering" (pöttyösítés) miatt akár új színnek jöhetnek létre. Ennek oka, hogy a színátvitel sávszélessége elég keskeny, a gyors színváltoztatást csak átmenettel tudja kijelezni.
Az jutott eszembe, hogy az emulátorból pont ez a funkció hiányzik, amikor a képpontokat elkeni mint egy TV képernyő. Az elkenésnek köszönhetően lesz szebb a kép.
-
Az jutott eszembe, hogy az emulátorból pont ez a funkció hiányzik, amikor a képpontokat elkeni mint egy TV képernyő. Az elkenésnek köszönhetően lesz szebb a kép.
Szerintem az a kép nem szép, hanem borzalmasan homályos vacak, hál'Istennek, már vagy 30 éve sikerült megszabadulni tőle, amikor megvettük az első SCART-os tévét.
Amúgy meg ha képminőség rontással akarsz játszadozni, van az ep128emuban: Options/Display/Configure
-
Majd megnézem, köszönöm a tippet.
Akkor értettem meg az általad említett "homályos vacak" dolgot amikor valamelyik retro youtube tartalomkészítő kitért erre a témára, és összehasonlított játékokat kompozit ill. RGB bemeneteken. Mondta, hogy sok játéknak azért olyan furcsa a színválasztása, mert compozit jelre volt optimalizálva. Megmutatta a két képet összehasonlítva.
Szerintem a Playstation 1-nél is azért volt, hogy TV-n szebb mint emulátoron, mert sok szűrést-simítást elvégzett a kompozit konverzió.
Én az RF jelet tartom homályos vacaknak. A compozit jel hozzá képest nagyon szép.
-
Tömörítéssel nem vesződnék, mert akkor elvész az egyszerűsége a dolognak.
Ha fel is akarjuk használni a képeket basic programokban, akkor szerintem kellene tömörítés. Például a képen, amelyet az első hozzászólásodban mellékeltél, elég lenne a nem fekete részek koordinátáit és színeit adni meg, sokkal kisebb lenne, mint ha pixelpontonként az egész képet tároljuk.
Bár lehet olyat is, hogy egyszer betölti fájlból a képet egy videolapra, és az a videolap úgy marad, nem változik. A játékok screen-je is ilyesmi, és talán tömörítés nélkül sem nagy, kb. 7 KB lehet.
If we want to use the images in basic programs, I think compression is necessary. For example, in the image you attached in your first post, it would be enough to give the coordinates and colours of the not-black parts, it would be much smaller than storing the entire image per pixel.
Although it is also possible to load the image from a file onto a video page once, and that video page remains unchanged. The screens of the games are also like this, and maybe it is not too big even without compression, it can be about 7 KB.
Wenn wir die Bilder in BASIC Programmen verwenden wollen, ist meiner Meinung nach eine Komprimierung nötig. In dem Bild, das du in deinem ersten Beitrag angehängt hast, würde es besser, die Koordinaten und Farben der nicht schwarzen Teile anzugeben, es wäre viel kleiner, als das ganze Bild pro Pixel zu speichern.
Es ist jedoch auch möglich, das Bild aus einer Datei einmal auf eine Videoseite zu laden, und diese Videoseite wird unverändert bleiben. Die SCR Dataien der Spiele sind auch so, und vielleicht sind sie auch ohne Komprimierung nicht zu groß, sie können zirka 7 KB sein.
Si queremos usar las imágenes en programas escritos en basic, creo que la compresión es necesaria. Por ejemplo, en la imagen que adjuntaste en tu primer post, bastaría dar las coordenadas y colores de las partes no negras, sería mucho más pequeño que almacenar la imagen completa por píxel.
Aunque también es posible cargar la imagen de un archivo en una página de video una vez, y esa página de video permanece sin cambios. Los SCR archivos de los juegos también son así, y quizás no sea demasiado grande aún sin compresión, puede llegar a ser de unos 7 KB.
-
15-20 évvel ezelőtt lehet hogy gondolkodtam volna tömörítésen. De manapság már amikor terrabájtokat tárolunk otthon, és az EP is bővíthető 3 Megabyte-ig gond nélkül, nem hiszem hogy a 10kb / 1kb probléma akkora gond lenne.
Létezik EP-re SD-kártyás floppy emulátor is. Merevlemez is. Az emulátorban meg úgyis mindegy.
Onnan indultam, hogy a legegyszerübb programmal (Microsoft Paint) összedobok valami grafikát, elmentem és amott betöltöm. A paint BMP-t nem tud úgy tömöríteni. Ha pedig egy harmadik programot kell használni, akkor az egész már túl bonyolult.
Már Photoshoppal is beleestem a problémába, hogy nem nagyon támogatja a kevés színnel való munkát.
-
Már Photoshoppal is beleestem a problémába, hogy nem nagyon támogatja a kevés színnel való munkát.
Vannak direkt pixelart-ra szánt grafikus programok is és böngészőből használható online eszközök is, pl. első találat: https://www.pixilart.com/
Vagy letölthető program mint pl az mtPaint (https://mtpaint.sourceforge.net/). A magam részéről én szinte mindenre a GIMP-et használom.
-
15-20 évvel ezelőtt lehet hogy gondolkodtam volna tömörítésen. De manapság már amikor terrabájtokat tárolunk otthon, és az EP is bővíthető 3 Megabyte-ig gond nélkül, nem hiszem hogy a 10kb / 1kb probléma akkora gond lenne.
Létezik EP-re SD-kártyás floppy emulátor is. Merevlemez is. Az emulátorban meg úgyis mindegy.
De még mindig lehetnek olyanok, akik egy szál magnóval rendelkeznek csak, és nincs memóriabővítésük sem! Ne kelljen már egy basic programot két kazettáról tölteni be! :D
Az is kérdés, mi a cél. Ha csak rajzolsz valamit és utána EP-n megnézed, hogy milyen érdekes, arra jó így is. Csak arra gondoltam, akkor már a gyakorlatban is fel lehetne használni ezt, pl. új basic programokat (amiket Zzzippel is lefordítunk) fel lehetne dobni ilyen képekkel.
Meg hát nem is az emulátorra fejlesztünk, hanem igazi EP-re, az emulátor csak segédeszköz. A terabájtok a PC világára igazak, de az EP nem PC, ezt ne felejtsük.
A midi zenék is tömörítve vannak, hogy ha valaki esetleg magnóról töltené őket, vagy floppyra venné fel őket, akkor kevesebb gond legyen velük.
But there may still be people who only have one tape recorder and no memory expansion! A basic program shouldn't be loaded from two cassettes! :D
The question is: what is the goal? If you just draw something and then look at it on an EP how interesting it is, that's fine. I just thought, this could be used in the practice, e.g. new basic programs (also compiled with Zzzip) could be embellished with such images.
We do not develope for the emulator, but for a real EP, the emulator is only an auxiliary tool. Terabytes are true for the PC world, but the EP is not a PC, let's not forget that.
The midi songs are also compressed - if someone were to load them from a tape recorder or store them on a floppy disk, there would be less problems with them.
Aber es mag immer noch Leute geben, die nur ein Tonbandgerät und keine Speichererweiterung haben! Ein BASIC Programm sollte nicht von zwei Kassetten geladen werden! :D
Die Frage ist: Was ist das Ziel? Wenn du einfach etwas zeichnest und es dir dann auf einer EP anschaust, wie interessant es ist, ist das in Ordnung. Ich dachte nur, in der Praxis z.B. neue BASIC Programme (auch mit Zzzip kompiliert) könnten mit solchen Bildern verschönert werden.
Wir entwickeln nicht für den Emulator, aber für eine echte EP. Der Emulator ist nur ein Hilfsmittel. Terabytes sind wahr für die PC-Welt, aber die EP ist kein PC, vergessen wir das nicht.
Die Midi-Songs sind auch komprimiert - wenn jemand sie von einem Tonbandgerät laden oder auf einer Diskette speichern würde, gäbe es weniger Probleme damit.
¡Pero aún puede haber personas que solo tengan una grabadora y no tengan expansión de memoria! ¡Un programa escrito en BASIC no debe cargarse desde dos cassettes! :D
La pregunta es: ¿cuál es el objetivo? Si simplemente dibujas algo y luego lo miras en un EP, qué interesante es, está bien. Solo pensé, esto podría usarse en la práctica, por ejemplo los nuevos programas escritos en BASIC (también compilados con Zzzip) podrían adornarse con tales imágenes.
No desarrollamos para el emulador, pero para un EP real, el emulador es solo una aplicación auxiliar. Los terabytes son ciertos para el mundo de la PC, pero el EP no es una PC, no lo olvidemos.
Las canciones midi también están comprimidas: si alguien las carga desde una grabadora o las almacena en un disquete, habría menos problemas con ellas.
-
If the first color of the palette is black, you can skip drawing black pixels to speed up output process with these extra lines:
Ha a paletta első színe fekete, kihagyhatja a fekete képpontok rajzolását, hogy felgyorsítsa a kimeneti folyamatot ezekkel az extra sorokkal:
[attach=1]
-
IDK how IS-BASIC really works, so maybe I'm asking something stupid. Could you replace the GOTO in lines 545 and 565 with NEXT? That may add a bit to the speedup if syntax allows it.
Nem tudom hogyan működik igazából az IS-BASIC, szóval lehet hogy ostobaságot fogok kérdezni. Ki lehetne cserélni a GOTO-t NEXT-re a 545-ös és 565-ös sorokban? Ha a szintaxis engedi az még adhat egy keveset a gyorsításhoz.
-
Could you replace the GOTO in lines 545 and 565 with NEXT?
Ki lehetne cserélni a GOTO-t NEXT-re a 545-ös és 565-ös sorokban?
In this algorithm it only possible for the second line, but this should also speed up the program a bit (-1 line to interpret).
Ebben az algoritmusban ez csak a második sornál lehetséges, de ez is felgyorsítja egy kicsit a programot (-1 sor az értelmezéshez).
-
Very interesting in other programming languages you cannot place the nesting-function-end (NEXT/LOOP etc) multiple places in a program code.
If you want to end the cycle in the middle, you have a special command for example "EXIT DO", "EXIT FOR", or in other language "break;".
Probably because the interpreter parsing algorithm must find easily the start and end of the nest, cannot be placed after an IF statement.
Hun:
Nagyon érdekes, hogy más programnyelveknél nem teheti az ember akárhová a ciklus záró kulcsszavakat (NEXT/LOOP stb).
Ha arra van szükség, hogy a ciklus közepén kilépjen az ember, akkor erre van egy külön parancs "EXIT DO", "EXIT FOR" vagy más programnyelvben a "break;".
Ez valószínűleg azért van, mert a fordító kiértékelő algoritmusának biztosan tudnia kell, hogy hol kezdődik és végződik egy ciklus, nem lehet feltételhez kötni.
-
[attachimg=1]
-
I was wrong: "Exit For" and "EXIT DO" and "break;" means jump out from the cycle completely. In C language "continue" instead of "break" means, jump to the nest end, and start again.
Hun:
Rosszul írtam. Az EXIT FOR és EXIT DO meg a "break;" parancs hatásására kilép a ciklusból. A C nyelvben a "continue" parancs való arra, hogy menjen a ciklus végére és kezdje újra.
-
:( I thought it could work.
[attach=1]
-
*** Statement not allowed after THEN.
Ha hex editorral belemászunk a basic programba, és a THEN utáni utasítás kódját átírjuk a NEXT tokenjére, akkor működik. (De a Zzzip valószínűleg nem fordítja így le, de lehet, nem is ez most a cél.)
If you open the basic program with a HEX editor and replace the datas after THEN with the token of NEXT, it will work. (Although the Zzzip won't compile it but maybe that's not the goal right now.)
Wenn man das Basic-Programm mit einem HEX-Editor öffnet und die Daten nach THEN durch das Token von NEXT ersetzt, funktioniert es. (Obwohl Zzzip es nicht kompilieren wird, aber vielleicht ist das gerade nicht das Ziel.)
Si abres el programa BASIC con un HEX-editor y reemplazas los datos después de THEN con el token de NEXT, funcionará. (Aunque Zzzip no lo compilará, tal vez ese no sea el objetivo en este momento).