Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by desertfish

  1. To put certain things into perspective, the page just listing all the keywords alone takes up more than 7 kilobyte... It looks to be a very powerful basic (just look at the number of keywords) and from what I see the compiler itself is also written in Freebasic itself. Remarkable.
  2. My mission is complete. You can watch the results in the second demo video that is included in the comment on this topic:
  3. I've updated it with a new version that now can use 320x240 full-screen mode instead of truncated at 200 pixels, and it also can show IFF Color Cycling images to add a sense of animation!! The movie included with the download shows the program running with the included images on the SD card. I found and included a few basic IFF images with color cycling. The real amazing thing is that there are a few extremely high quality color cycling images available to view on-line here http://www.effectgames.com/demos/canvascycle/ as mentioned in the topic here: https://www.commanderx16.com/forum/index.php?/topic/770-new-demo-uploaded-basic-color-cycling-demo/&tab=comments#comment-5197 I've managed to convert these on-line images back into IFF files with color cycling information. Additionally I've halved their resolution to 320x240 (and lost 12 bits of color palette accuracy) but these images can now also be displayed by my image viewer program on the CommanderX16, including their color cycling animation! Unfortunately the images are copyrighted and I think we are not allowed to share them, so instead here is a video of them being displayed on the emulator: ccycle-demo.mp4 It's a pretty long video because there are many images and the loading is not very fast (because they have to be streamed from disk due to being larger than the available memory). A lot of detail is lost because of 12 bit color banding and the resolution reduction (some blending/dithering patterns are wiped out completely), but I still think they are amazing to watch. Watch the video first and then the Effect Games web site link above to admire them in all their original high res detail. You won't be disappointed.
  4. A 2d physics multi-object collision engine on an 8 bit system, that's actually pretty darn nice even though it's not entirely realistic behavior. I always find it fun to play around with anything having physics simulation. It's always more fun when it's less realistic !
  5. While dealing with pointers is still a bit iffy in Prog8. There is however memory mapped variables and the direct memory access operator '@'. &ubyte BGCOL0 = $d021 ; screen color register on the C64 BGCOL0 = 7 ; set color to yellow @($d021) = 7 ; set 7 directly to memory location color = @($d021) ; read value directly from memory location I'm still kinda new at language design, but I find it interesting that we're coming up with more or less the same concept here!
  6. 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.
  7. desertfish


    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
  8. 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!
  9. 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.
  10. Well, that didn't even occur to me that you could be using the default palette! Thanks for explaining.
  11. pretty amazing that you've got hashtables working at all on this 8 bit cpu, what hash function is it using?
  12. 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
  13. 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)
  14. @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?
  15. 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
  16. 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
  17. 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"
  18. 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?
  19. 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
  20. 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
  21. 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.)
  22. 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.
  23. 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?
  24. @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.
  25. Version 2.1


    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
  • Create New...

Important Information

Please review our Terms of Use