Jump to content

desertfish

Members
  • Posts

    598
  • Joined

  • Last visited

  • Days Won

    16

Everything posted by desertfish

  1. multi format image viewer View File This is a multi-format image viewer program. It supports IFF, PCX, BMP and Koala (c64). It supports full-screen 320x240x256 color bitmap mode and IFF Color Cycling ! Due to emulator restrictions (it seems) It only works when running from an sd-card file, so I've provided a zipped one that contains the program and a few sample images. The source code is here https://github.com/irmen/cx16imageviewer The video below shows the program in action! imageviewer-demo.mp4 Submitter desertfish Submitted 12/14/20 Category Demos  
  2. Right, I'm pretty much done with the image viewer program. It can load iff, pcx, bmp and koala. I'm not going to pursue PNG or my own format. Many image files are too large to be loaded into memory at once. So the program loads them progressively via the kernal's CHRIN routine instead. This only seems to work when the files are on an sd-card image though (in the emulator). I may just upload a compressed sdcard image to the demo section rather than a handful of separate files? Here's a demo of the viewer in action! cx16-2020-12-14_15.15.12.mp4
  3. @Cyber i watched various youtube documentaries about MOnkey Island and such, and also the site @jnewman linked above actually has some information: http://www.effectgames.com/effect/article-Q_A_with_Mark_J_Ferrari.html Here's a youtube video, I think a long part with Mark talking starts at around 33 minutes in, he talks about how he learned to do dithering for Zak McKracken to increase the number of apparent colors. And goes from there. Finally, I think Mark Ferrari also did art in Thimbleweed Park.
  4. oh man, thanks for that website link, I've seen that in the past but totally forgot about it. It's quite interesting to hear the tale of Mark Ferrari the pixel artist for many Lucasarts adventure games such as Monkey Island and how his skills became obsolete overnight once graphics cards got more advanced.
  5. I've got a PCX format viewer up and running now! The RLE decompression was quite simple it turned out. Amiga IFF viewer also working, again, the RLE decompression is pretty simple. BMP viewer also working. If I can get that 6502 DEFLATE routine someone linked to me working, PNG will close the list, however that source code is in a weird assembler format and the various filter processing routines in the PNG standard make it quite complex and slow I think.... Also the decompressed image data has to fit in memory all at once which make it rather problematic to actually show any image of interesting size.... I think I'm going to skip PNG for now. They're all separate programs at the moment, I'll integrate them all into one generic image viewer that supports all formats (except PNG for now)
  6. Directory opus I used that for so many years until I switched to Linux. . Starting way way back on Amiga. ... what a fantastic tool.
  7. I never heard of LZSA before reading about it in the Cx16's documentation. I was thinking of using LZSA compression for my own image format, but I'm not gonna pursue that any time soon. I'll look at the existing image formats unchanged first. Those netpbm files look horribly inefficient
  8. Oh, Targa, it has been a VERY long time since I last heard about that format! Thanks for reminding me. At a glance it looks simple enough. Maybe I'll add it to the list of decoders that I'm trying out .
  9. I agree it is mostly out of interest and for me to learn how to display images in various formats on the cx16. Maybe I shouldn't put too much energy into "my own" format (although it's a fun exercise) and instead try to make a decoder for one or more of those existing formats. It could be useful if you want to avoid a manual conversion step and just want to display images you've downloaded on the Cx64 for instance I have 1 finished decoder, for the C64's Koala format. A demo of that is in the download section!
    Wowzers! Raytracing still is black magic for me and seeing this done by a basic program of all things. Very cool. Does take a lot of your patience hence 4 stars instead of 5.
  10. While delving into routines to load and show various image file formats (koala, pcx, png, iff, bmp) it occurred to me that none of them particularly suits the Cx16. Koala images are very specifically tied to the way the Vic-II in the C64 does graphics, and require a lot of conversion logic Bmp contains a lot of Windows clutter and is always large and uncompressed Pcx is always compressed and requires cpu power to decode (although that looks to be simple and the file format has little other overhead) Png is a complex beast and requires a zlib deflate uncompressor IFF is almost universally tied to the Amiga's bit-plane graphics and requires bit fiddling logic to decode So I thought why not create a new image file format that is optimized for images that are meant to be displayed on the Cx16? Currently I'm leaning towards the almost universal approach of having one file consisting of a header with meta data about the image, then the palette data, followed by the actual bitmap data. This looks to be convenient and with the appropriate fields in the header can be quite flexible as well to allow for various sizes, color depths and such. However there are a few issues with this approach: it does require the file to be loaded sequentially byte-by-byte, and this process is relatively slow compared to reading whole files at once using the LOAD kernel routine or the VLOAD basic command. Also unfortunately, reading the file sequentially only seems to work in the emulator when the file is on an sdcard image, which is a bit inconvenient compared to just reading it from a directory. So I was thinking: you could either VLOAD the file but taking into account that the bitmap data is preceded by several hundred bytes of header and pallette, and so use an adjusted load adress (but potentially overwriting other memory with that data). Or perhaps split the file in three parts: metadata, palette, bitmap. Each can then be loaded as desired with just a regular LOAD/VLOAD call. Any thoughts about the above ideas? Could the difference in loading times perhaps be explained by the fact that I am using the emulator with its tweaked load routines? VLOAD of an image is only possible when the image is exactly the width of the screen I think? If it is smaller or larger it will be displayed scrambled I suspect PS. I'm currently only investigating pure bit map images. I have zero knowledge about the VERA's tile based display capabilities but would very much like to include them into this format if at all possible.
  11. That sounds like it doesn't deal properly with bucket overflow? Which means it will drop collisions. That can be scary? I haven't looked at the code so it could very well be something else.
  12. In the spirit of “eat your own dog food” im finding those issues and tweaks (still am, currently) because I’m attempting to write some actually useful programs with it now. The text-elite game was one of the larger ones before, and currently I’m building an image file viewer. I even ran into a bug in one of the kernel functions that puts pixels on the screen so it is already pretty useful even if in the end nobody is going to use my image file format if possible I also want to convert those image viewers that I mentioned in the koala demo topic. It would be pretty awesome if I can not only show those c64 koala picture, but also those nice Amiga IFF ILBM image files created by DeluxePaint And perhaps even other image formats. I want to see where the limits of this 8 bit system lie. Undoubtedly I’m also going to find more issues in Prog8 so no boredom for me
  13. I've just released Prog8 5.3 Once again a bunch of important bugfixes have been made as well as various additions to the library modules.
  14. in Prog8 it's a bit of a hodge podge, sometimes I use inline operations to work on 16 bits if they're trivial, sometimes I simply JSR into a library subroutine... In the end it seems to work but the resulting assembly code is not very consistent. That's not really a problem because usually you're not supposed to read it I think what I meant is the same what Paul said above; there is not a single best solution ?
  15. That is correct! Prog8 indeed is designed to be a cross-compiler (it is way too large and too slow to fit on it). This means that you develop on a different system (= modern PC) and create an assembled program for the target machine there, which you then transfer to the target machine. (Having an emulator on the PC makes that last step very easy, but still not as convenient as edit-run-compile on the target system itself)
  16. I think you're experiencing the problem I ran into recently as well: Basically, file loading from sd card images is broken at the moment
  17. @AndyMt ooh thanks for that link!! Actually, it's PNG that can be unpacked using zlib, which is even better!
  18. I'm going to take this a step further, and implement a sort of library to load various image formats. So currently we have: Koala paint C64 multicolor image (fixed size 160x200, 16 fixed colors) I'm busy investigating: BMP (windows bitmap image files, various sizes, up to 256 colors, uncompressed), have a Python prototype working PCX (paintbrush image files, various sizes, up to 256 colors, very simple compression), have a Python prototype working GIF (up to 256 colors, compressed) would be nice but perhaps the decompressor is too complex? I don't yet know how it works. PNG (up to 256 colors, DEFLATE compressed) requires zlib to decompress. Have a Python prototype working. 6502 decompressor: see Andy's link below IFF ILBM (Often used on the Amiga) Have a Python prototype working. No HAM support though
  19. Thank you for clearing that up! I did look on github a bit for issues that might be similar but didn’t look through the pull requests...
  20. Tweaking the Vera's color palette was easier than I thought. I've uploaded a new version that changes the color palette to the well-known 'pepto' Vic-II palette and the images look a lot better now
  21. Hi, when putting files on an Sdcard image, I discovered some problems when loading them, that do not occur when loading files in the emulator from a host directory. Most notably, it seems that when loading a file from an sdcard image, the kernel (?) ignores the reallocation address passed to the LOAD call and always seems to load the file at $0000 I think this also manifests itself in Basic when using the VLOAD command, for instance: working, loading a file from a host directory, ends up at $2000 or about halfway down the screen ram: not working, doing the same with the exact same file but this time loading from an sdcard image, it loads at $0000 no matter what you do: Net result is that any program or game that is loading data files, doesn't work when copied onto an sd card image.... (I've tried my own image viewer demo program and three other games, all refuse to work from an sd card image but work fine when loading from a shared host folder in the emulator) Is this a known issue? Could it be a KERNAL bug or a bug in the Emulator itself somewhere?
  22. C64 image file viewer (koala format) View File I wrote a program that loads Commodore-64 multicolor pixel art images in the "koala" file format, and displays them to a regular Commander X16 320x200 graphics screen. The C64 uses a fixed palette of 16 colors for all its graphics. I do find that the saturation of the default colors in de c64 palette in the Cx16 emulator is not very good though: when the images are displayed on a C64 or in an emulator like Vice for instance, they look much better in my opinion. So the program sets a custom palette (the "pepto" Vic-II colors) to make the images look closer like they would on a C64. This program has been integrated in a multi-format image viewer now, the source code of that is here https://github.com/irmen/prog8/tree/master/examples/cx16/imageviewer Submitter desertfish Submitted 12/02/20 Category Demos  
  23. Version 1.0.2

    97 downloads

    I wrote a program that loads Commodore-64 multicolor pixel art images in the "koala" file format, and displays them to a regular Commander X16 320x200 graphics screen. The C64 uses a fixed palette of 16 colors for all its graphics. I do find that the saturation of the default colors in de c64 palette in the Cx16 emulator is not very good though: when the images are displayed on a C64 or in an emulator like Vice for instance, they look much better in my opinion. So the program sets a custom palette (the "pepto" Vic-II colors) to make the images look closer like they would on a C64. This program has been integrated in a multi-format image viewer now, the source code of that is here https://github.com/irmen/prog8/tree/master/examples/cx16/imageviewer
  24. I've just released Prog8 5.2 It contains a few important bug fixes (some value comparisons were done wrong, for instance) and the silly YSCROLL screen issue for graphics bitmap screen mode on the C64 that crept into the 5.1 release, is also fixed. Note: starting with this release, you now require Java version 11 to run the compiler.
×
×
  • Create New...

Important Information

Please review our Terms of Use