Jump to content

desertfish

Members
  • Posts

    554
  • Joined

  • Last visited

  • Days Won

    14

Everything posted by desertfish

  1. wait... how did you manage that vertical wave effect??? I tried something like that but couldn't get the vera to do what i wanted with the vertical scaling register
  2. ... unfortunately another asm symbol scope issue now cropped up. I'm not done yet
  3. I believe the assembly symbol scoping issue has been resolved.
  4. Yeah okay, so we have several issues with assembly symbol name scoping in the code generator. This is now on top of the list of the remaining things to fix for the final 7.0 release
  5. hm, that looks like a scoping bug in the compiler. I'll see if I can fix that. In the meantime, can you try to replace &rawdata with &main.rawdata ?
  6. Yeah it didn't matter much. I suspect it is taking a lot of overhead somewhere to pickle/unpickle the data passed between the processes. And indeed, switching to multiprocessing.pool.ThreadPool didn't improve things. I see no obvious big improvements to the code as-is. But I think it would be worthwhile to investigate what happens if you split the problem up differently. Rather than dividing it over the tokens to search for, I suggest trying an approach where you split up the source image in strips of 8 pixels high and process each strip in a worker process. So one worker processes one line of characters. I realize this will require quite a bit of rewriting...
  7. Hey, great stuff! Yeah multiprocessing can be a bit iffy, it could be that much time is spent passing the data set across different processes to work on it, and passing the results back. To avoid this, multi threading could help, but then you're sometimes constrained by Python's Global interpreter lock. I want to take a look at your code and see if I can tweak it a bit to make it faster! (for reference it runs in 5 minutes 30 seconds on my Ryzen 2700x)
  8. I've just released a new 7.0-beta2 version of the compiler https://github.com/irmen/prog8/releases/tag/v7.0-beta2 This version will likely be very close to the final 7.0 release because I'm not considering adding or changing anything new from now on (except bug fixes). Some of the most important fixes/changes since the previous beta release: string encoding and string interning bug fixes various compiler crashes fixed %asminclude fixed (scopelabel argument removed as well) repeat loop code gen optimized some more Once again: the CommanderX16 target targets the upcoming "V39" of the cx16 emulator and roms. Programs targeting the cx16 compiled with this new Prog8 version may no longer work on the previous version of the emulator (although if you're not using floating point and bank switching, they will likely still work) Detailed change list will be added when this 7.0 version is finalized, which will probably be shortly after the "V39" of the commanderx16 is officially released as well.
  9. I really have to add a star to my initial review by now....
    Watched Ozyphanto's original version some time ago and was already amazed by that. This is one step beyond even ! Beating an Amiga , who would have thought Doesn't matter that it's only simulating the 3d effect --- it's the end result that counts, and drawing 2d lines / polygons animated this fast, is a feat in itself
  10. When not streaming audio, is the streaming of the polygon draw data realistic to run this fast on actual hardware? Amazing results btw.
  11. Um... the file based assembler has none of those problems. iIt has a few other issues so far, like no macros, no expressions, no includes, but with help, I think those can be fixed?
  12. Yeah I expected a new emulator release for quite a while already... That said, I suspect most of the programs compiled by the new beta version of prog8 can work on the V38 emulator just fine. The V39 changes were mainly in the ram/rom banking and some register changes. If your program doesn't use these it will likely still work on V38 of the emulator. (oh and I think the floating point rom routines were relocated so you can't use floats if you want to do this)
  13. Also you can now mark a variable as 'shared' with assembly code elsewhere, to not have it optimized away if even if you're not using it in prog8 code: ubyte @shared asmvar
  14. Defining a label at block scope (outside a subroutine) is only possible since the 7.0-beta release of Prog8. Either upgrade your compiler or stick to labels inside of subroutines for now (you can still refer to those perfectly fine by prefixing them with the subroutine name)
  15. %asminclude is a bit broken at the moment, I now realize. you could try %asmbinary? if you prefix it with a label in the source code you should be able to refer to it from prog8
  16. Thanks, I am glad it is proving to be useful for others too in the way I intended it. As long as you're not using zeropage locations you should be just fine by "inlining" .byte or .word statements in your asm blocks to reserve some variables space: %asm {{ lda variable rts variable .byte 99 }} I'm still considering a feature of some sort to mark variables to not optimize them away as unused, though. This hasn't been the case anymore since the 6.5-beta version at least, so you may want to upgrade to that (or even better the recently published 7.0-beta version) Yeah I'm not sure if prog8 compiler can be of any help for this for the Cx16 emulator. It does output symbol and breakpoint lists for the Vice C64 emulator, but these are useless for the cx16 emulator. Thanks for the feedback!
  17. just FAR is too confusing IMO , it's a SYS call you're doing after all, just to another Rom bank. Perhaps FSYS? (in the spirit of VPOKE/VLOAD)
  18. I've just released a new 7.0-beta version of the compiler https://github.com/irmen/prog8/releases/tag/v7.0-beta Most important changes are in the CommanderX16 target: we now target the upcoming "V39" of the cx16 emulator and roms. Programs targeting the cx16 compiled with this new Prog8 version may no longer work on the previous version of the emulator. Also the ``struct`` language feature has been removed. (hence the new 7.0 major version because this breaks old programs that use this. Rewrite structs as separate variables). Also the random number generator (used for rnd() etc) has been replaced by a slower but much better one. Detailed change list will be added when this 7.0 version is finalized, which will probably be shortly after the "V39" of the commanderx16 is officially released as well.
  19. @borgar The game is rapidly improving, I'm very impressed !!
  20. oh-- that's a somewhat simpler issue you're referring to now. What about tagging the actual variable declaration instead in prog8? Something like: volatile ubyte testvar or shared ubyte testvar to indicate to the compiler that testvar is used elsewhere that it doesn't know about? However, the question is: why would you even declare the variable in prog8 if your only use of it is inside an assembly block and not in any prog8 code (in this case, why not just define the variable inside the assembly block...)?
×
×
  • Create New...

Important Information

Please review our Terms of Use