Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by desertfish

  1. True about the performance, but the kernal call would not require changes when the rom is rebuilt . Choice depends on what you value more in your use case of course !
  2. Wow that is amazing @Greg King now i remember more, I used Simons basic and Logo as well. But both weren’t compilers.
  3. Yeah I think it’s pretty much impossible to have the same full featured prog8 compiler optimizer and code generator natively. Then again there is a (limited) native C compiler that I also thought not being possible at all. I was using a macro assembler on the Commodore 64 back in the days
  4. Hm, wondering why it is reading the internal variable directly and depending on its location, rather than using RDTIM kernal call?
  5. Ah man, here I was thinking it would come out on the PS3 and the Vita....
  6. @Michael Steil thanks for the work on the roms and the emulator, looking good. Actual bug fixes obviously have priority, but there is one Quality of Life patch on the emulator that currently is quite annoying for me, and probably for other Linux users as well. As it stands, starting and stopping the emulator results in a nasty display flicker and actually causes other applications to freeze or stop updating (most notably, Firefox in my case, it goes totally blank). That patch adds a tiny SDL hint to no longer bypass the display compositor and totally fixes the issue (at least, on my system). It's easy enough (for me) to build a custom emulator with this patch applied, but I think it would be great if the official emulator that is due to be released soon comes with it out of the box.
  7. yeah it was intentional (unfortunately) I'm struggling with the code generator for complex array index expressions. The reason you now see this error is because I reduced the number of automatically generated internal temporary variables to hold expression results. Suggestion for now: add 2 variables yourself for the x and y arguments to setcc(). I think the resulting assembly code will be more optimized that way as well. Maybe this limitation will be lifted again in a future version of the compiler.
  8. Found only 1 issue so far, which turned out to be a bug in my own code (in the file based assembler - fixed now): it was reading $0000 sometimes by mistake, which happened to work before because that used to contain zero. But in v39 it is no longer zero.
  9. I use the Dark Reader browser extension
  10. Sin and cos overlap after .5 pi you can save a few hundred bytes with that
  11. Prog8 6.4 was just released. As always the documentation is here and the git repository is here. It contains fixes for the bugs mentioned above, further optimizations, and the code generator is now finally fully completed. There's also a cx16.vload() function now that is similar to basic's VLOAD. Have a look at the release notes on Github if you want all the details
  12. won't this break when you add non-wall elements such as monsters, projectiles
  13. prog8's textio module is a mess in this regard, some routines use kernal others write directly to Vera. Mostly, the operations that can reasonably be done by a kernal routine are not writing to Vera though. (On the C-64, it is the same, but instead of vera it directly writes into the screen buffer ram locations). In the end, does it matter? It should be a secret for the user of the library how it does its work, as long as you get the desired result The only thing that may be problematic is if you have banked out the kernal rom in your program and try to use the library routines that depend on a kernal routine. A note in the documentation about this should fix that I think (something I haven't yet taken care of for prog8...)
  14. About zero termination, I'm a bit confused then, because I see this : my input buffer at $0920 was fully filled with 20 question marks $3f, I typed my name (and some garbage that I backspaced), and those zeros really did appear
  15. Hm, In the meantime, I've discovered a few bugs in the comparison operators (such as <, >, <= etc). This means I will probably add one more release soon with optimized and fixed code for this. Also with a few other nice things such as a vload() routine that does the same as the VLOAD basic command.
  16. Playing some more with input_str.... : entered string in buffer seems to be terminated by a zero byte (I like this!) ... this probably means you want to allocate 1 byte more in your input buffer to have room for this. Maybe good to document this too after pressing enter, the cursor remains visible. I expected it to disappear i cannot enter petscii symbols (or capitals when in lowercase character mode) ?
  17. the input_str() routine, does it return the input string in petscii or in screencodes?
  18. i love that invaders one
  19. I don't think a raycaster needs special culling because you only render the exact number of vertical pixel columns with the first wall (texture) that is hit with the view ray. So any walls 'behind' others are never seen by the algorithm.
  20. If you make the textures mirrored across the Y axis you can cut the required texture samples in half again, and just mirror the bottom half from the upper half of the screen. Don't know if you wanna do this because it may start looking really ugly if the textures are constrained this way perhaps.... Also for non-wall textures (monster sprites?) this surely is a nasty restriction
  21. That makes sense... I actually don't have a proper way of dealing with screencode strings in Prog8 that require a zero character. It's always the terminator. As for supporting it for converted strings: it would help a bit, but I think it's best to have a consistent API over sometimes supporting it and sometimes not supporting it (which could lead to confusion)
  22. aw... this now means for Prog8, that I have to iterate strings twice to print it (once to determine its length based on 0-termination, and then again in VTUI while printing it). It is what it is, I suppose. At least for constant strings I always know the lengths beforehand.
  23. what RNG are you using to set everything back to random?
  24. the 'full speed' sort runs faster than I expected
  • Create New...

Important Information

Please review our Terms of Use