Jump to content

desertfish

Members
  • Posts

    693
  • Joined

  • Last visited

  • Days Won

    19

Everything posted by desertfish

  1. You've really inspired me with this simple color cycle demo and especially the link to that fabulous 256 color cycling images website. I've actually converted the images back to IFF (with color cycling information) and am now building color cycling support in my imageviewer program. Ofcourse the images will be scaled down to half their original resolution, and we lose 12 bits of color palette accuracy, but it will still be quite amazing: Unfortunately those images are copyrighted and I think this means I am not allowed to distribute them even if scaled down. I'm not entirely sure about this yet.
  2. desertfish

    LUNAR

    Pretty bare-bones lunar lander simulator, but I guess that's to be expected from a basic program of that era. I tried for about 15 minutes to land my spacecraft ('hard' difficulty) but this actually is HARD! My best attempt was a crater 18 meters deep at around 340 km/hour impact velocity Maybe I'll give it another go with the easier difficulty. I've played this game on my Commodore 64 too as a kid! I don't remember if I was ever successful at a proper moon landing
  3. Does anyone know of a stand alone IFF image viewer program that is also capable of showing those color cycling animations? The few programs I found that are capable of reading IFF ILBM image files (those Amiga paletted images that sometimes contain color cycling information as well) do not show the color cycling... I'm investigating this now myself in my prototype Python program that parses IFF files Update: my python program can now display IFF ILBM images with Color Cycling. Great Success!
  4. The Final Cartridge 3 for the Commodore64 also had a fairly capable programmable GUI system built into the cartridge (but much simpler than GEOS). However I never actually used it to be honest. For me it wasn't anything more than a gimmick that I didn't really understand the benefits of. I may have used the notepad application once or twice to write and print a letter with in proportional font.... Also from what I can remember that GUI desktop was extensible with programs that you could write yourself, there was an 'sdk' of sorts to go with the cartridge. But I have never seen any user written application for it unfortunately.
  5. Well, that didn't even occur to me that you could be using the default palette! Thanks for explaining.
  6. pretty amazing that you've got hashtables working at all on this 8 bit cpu, what hash function is it using?
  7. Yeah I was searching for those in the source code of the game, but couldn't find them! https://github.com/Dooshco/X16-CrazyBoulders/blob/main/CRAZYBOULDERS.BAS
  8. For the next version I'm trying to add the 16 virtual CommanderX16 registers r0 - r15 to the language itself (or rather, the subroutine declaration syntax), so we don't have to do this anymore: cx16.r0 = x1 cx16.r1 = y1 cx16.r2 = x2 cx16.r3 = y2 cx16.GRAPH_draw_line() but instead can just write this: cx16.GRAPH_draw_line(x1, y1, x2, y2) The funny thing is, that this will also make those R0-R15 'registers' available on the C64 compiler target. So you can also make asm-subroutines there that can take additional parameters, instead of being restricted to just the A, X and Y register. Pretty nice. (on the C64 these 'virtual' registers are not allocated in the zero page as on the Cx16, because there's no room for them there. So they will be slightly less efficient when used)
  9. @DusanStrakl I'm trying to figure out how you are displaying the graphics in this game. I can't find the place where the color palette is set, how do you do this?
  10. I've added a short description on how subroutine calls are done in the code that Prog8 generates (that is, how are parameters and return values processed) https://prog8.readthedocs.io/en/latest/technical.html
  11. Come to think of it, tracker music is basically just a list of instructions for a sound playback Virtual Machine. The playback overhead for this is minimal. I don't know if the same is true for other types of music representation
  12. Isn't the first thing exactly like the 'continue' statement found often? It immediately stops the loop body and continues the loop with the next iteration. You just have to invert the condition? : loop: ? "commander x16 rules" if x>=4 continue ? "say it again"
  13. I haven't seen that video before but am watching it now Ohh, that video in turn links to a GDC talk by Mark Ferrari himself ... don't mind if I link that here too I hope?
  14. Released Prog8 5.4 - added the multi-format image file viewer example for cx16 - removed the rom path argument for launching the x16emu with -emu, should now work again on non-linux platforms - improved several things in the diskio module, such as functions for incremental file loading - implemented workaround subroutine for the FB_set_pixels bug (and made a PR for the ROM to fix it there too) commanderx16/x16-rom#179 - some other miscellaneous bugfixes and improvements. See the releases page on github. Wow, it's been quite a ride to arrive at this version. I'm pretty happy with how everything turned out, but am now going to take a break and not work on Prog8 itself for a while. I think I now want to actually create things with it, rather than creating tools to make things. I really hope others will pick it up as well even if only to try it out for a bit. Feedback is invaluable and very much appreciated
  15. I noticed this too when pasting code from IntelliJ IDEA on this forum, it was the first time I've seen that syntax coloring coming over, it's pretty neat. Not sure how that works. Unfortunately there doesn't seem to be a "code" text style when typing text in or pasting code from 'plain' editors
  16. So you're arguing to leave it as it is now, in the "natural" order. I can agree with that. (Notice that there's also lsb() and msb() functions that extract those bytes from a word, the reverse operation from mkword(). In a sense, they also already abstract the exact underlying byte order.)
  17. Hello @Bones! Ah, I use Linux and while the compiler itself is portable, it seems that for starting the emulator I hardcoded some paths. I'll see if I can make this more OS-friendly in a future versoin, but it's low prio. Yes the emulator executable has to be in your PATH because it's not up to the compiler to figure out where it is installed (could be anywhere). You can omit the -emu argument if you're starting the emulator yourself of course, it's just there for convenience so that you don't have to manually start it after a successful compile. edit: seems like the -rom argument to launch the emulator is no longer necesarray on Linux too, so the next version of prog8 will have it removed. I think this should allow you to launch the emulator on windows then too with the -emu argument.
  18. Query Prog8 has a built-in function mkword(msb, lsb) which creates a 16 bit word value from two bytes In older versions the 2 bytes were in little endian order, analogous to how the word value would be stored in actual memory, so the lsb was first and then the msb. A couple of releases ago however I swapped the arguments around because I then thought it would be more readable like so: mkword($80, $22) = $8022 (in memory: $22 $80). However it somehow doesn't feel right. I'm considering swapping the arguments again back to the old behavior so that would be like this again: mkword($22, $80) = $8022. (in memory: $22 $80) What do you guys think?
  19. @TomXP411 interesting. I was writing down something similar but meant for just images. Also I'm not very familiar with the VERA's display modes yet so it only has raw bitmap data for now like most other image files do. Here's my take on it for now ; offset value ; ----------------- ; HEADER (12 bytes): ; 0-1 'CI' in petscii , from "CommanderX16 Image". ; 2 Size of the header data following this byte (always 9, could become more if format changes) ; 3-4 Width in pixels (must be multiple of 8) ; 5-6 Height in pixels ; 7 Bits-per-pixel (1, 2, 4 or 8) (= 2, 4, 16 or 256 colors) ; this also determines the number of palette entries following later. ; 8 Settings bits. ; bit 0 and 1 = compression. 00 = uncompressed ; 01 = RLE [TODO not yet implemented] ; 10 = LZSA [TODO not yet implemented] ; 11 = Exomizer [TODO not yet implemented] ; bit 2 = palette format. 0 = 4 bits/channel (2 bytes per color, $0R $GB) ; 1 = 8 bits/channel (3 bytes per color, $RR $GG $BB) ; 4 bits per channel is what the Vera in the Cx16 supports. ; bit 3 = bitmap format. 0 = raw bitmap pixels ; 1 = tile-based image [TODO not yet implemented] ; bit 4 = hscale (horizontal display resolution) 0 = 320 pixels, 1 = 640 pixels ; bit 5 = vscale (vertical display resolution) 0 = 240 pixels, 1 = 480 pixels ; bit 6,7: reserved, set to 0 ; 9-11 Size of the bitmap data following the palette data. ; This is a 24-bits number, can be 0 ("unknown", in which case just read until the end). ; ; PALETTE (always present but size varies): ; 12-... Color palette. Number of entries = 2 ^ bits-per-pixel. Number of bytes per ; entry is 2 or 3, depending on the chosen palette format in the setting bits. ; ; BITMAPDATA (size varies): ; After this, the actual image data follows.
  20. Version 2.1

    53 downloads

    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
  21. 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  
  22. 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
  23. @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.
  24. 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.
  25. 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)
×
×
  • Create New...

Important Information

Please review our Terms of Use