Commander X16

This Commander X16 Basic program is based on the "Bubble Universe" Sinclair Basic program at https://stardot.org.uk/forums/viewtopic ... 3f1ab9981f.

If you're using the emulator I recommend starting it with the -warp option.
#R42

Incredible. How does that even work, for such a tiny program???

edit: omg, it animates https://www.youtube.com/watch?v=FAj-eaU-S2s

I really like that.

Gives me sort of fractal planet vibes.

Pity about the render speed, even in warp mode.

Amazing what can be achieved in just a few lines of code.

We need a secondary BASIC interpreter that handles integers as integers for operations other than Boolean.

I find it mesmerizing.
Here's the prog8 port. It runs faster, but not very much, due to the heavy use of floating point math in both cases.
%import graphics %import floats %import math %option no_sysinit ; Bubble Universe ; see: https://stardot.org.uk/forums/viewtopic ... 54&t=25833 main { sub start() { graphics.enable_bitmap_mode() const ubyte n = 200 const float r = floats.TWOPI/235 const ubyte s = 60 float t uword[] palette = [$000, $000, $00f, $f0f, $0ff, $fff] cx16.FB_set_palette(palette, 0, len(palette)) repeat { graphics.clear_screen(1,0) ubyte i for i in 0 to n { ubyte j float ang1_start = i+t float ang2_start = r*i+t float v=0 float u=0 for j in 0 to n { float ang1 = ang1_start+v float ang2 = ang2_start+u u=floats.sin(ang1)+floats.sin(ang2) v=floats.cos(ang1)+floats.cos(ang2) ubyte c=2 if i>=100 c++ if j>=100 c+=2 graphics.colors(c,0) uword a = 40 + ((2+u) * s) as uword uword b = ((v+2)*s) as uword graphics.plot(a,b) } } t+=0.025 } } }

desertfish wrote: ↑Fri Mar 24, 2023 1:05 am I find it mesmerizing.
Here's the prog8 port. It runs faster, but not very much, due to the heavy use of floating point math in both cases.

bubbleuniverse.prg

%import graphics %import floats %import math %option no_sysinit ; Bubble Universe ; see: https://stardot.org.uk/forums/viewtopic ... 54&t=25833 main { sub start() { graphics.enable_bitmap_mode() const ubyte n = 200 const float r = floats.TWOPI/235 const ubyte s = 60 float t uword[] palette = [$000, $000, $00f, $f0f, $0ff, $fff] cx16.FB_set_palette(palette, 0, len(palette)) repeat { graphics.clear_screen(1,0) ubyte i for i in 0 to n { ubyte j float ang1_start = i+t float ang2_start = r*i+t float v=0 float u=0 for j in 0 to n { float ang1 = ang1_start+v float ang2 = ang2_start+u u=floats.sin(ang1)+floats.sin(ang2) v=floats.cos(ang1)+floats.cos(ang2) ubyte c=2 if i>=100 c++ if j>=100 c+=2 graphics.colors(c,0) uword a = 40 + ((2+u) * s) as uword uword b = ((v+2)*s) as uword graphics.plot(a,b) } } t+=0.025 } } }

I was thinking about porting to C, but cc65 doesn't support the floating type, and it'd be a bit of a pain to use the kernel math library. I wasn't aware of prog8 which does support the floating type, so thanks for the comment. Your pre-compiled bubbleuniverse.prg program file does seem to run a bit faster, but I was wondering if you move all of the variable declarations from the three inner loops to the beginning of start() if it would run even noticeably faster. However, when I compile the source file you posted and run the generated .prg program file I just get a blank screen rather than the output generated by the pre-compiled bubbleuniverse.prg program file you posted. I'm new to prog8 so I'm not sure if I did something wrong, but I compiled it with "java -jar prog8compiler-8.10-all.jar -target cx16 bubbleuniverse.p8". I get a couple of "integer implicitly converted to float" warnings on the two loop variables i and j, but no errors, and it does successfully generate a "bubbleuniverse.prg" file, but when I run this .prg file I just get a blank screen as I mentioned above.
Top

Thank you for taking the time to check out Prog8!

You're right that you get a blank screen with the latest official prog8 release.
I actually discovered a bug in the pixel plot routine, during porting of this program.
This fix hasn't yet been published in an official release (8.11) but you can get a development version of the compiler here at the build artifacts on the bottom. I think you need to have a github account to access it.

Moving variables around in prog8 almost never makes a difference by the way. Prog8 allocates everything statically and all variables are put on a big pile no matter where you declare them.

Moving variables around in prog8 almost never makes a difference by the way. Prog8 allocates everything statically and all variables are put on a big pile no matter where you declare them.

But if they're in the loop, doesn't the declaration happen over and over again each time you go through the loop?

desertfish wrote: ↑Fri Mar 24, 2023 4:49 pm Thank you for taking the time to check out Prog8!

You're right that you get a blank screen with the latest official prog8 release.
I actually discovered a bug in the pixel plot routine, during porting of this program.
This fix hasn't yet been published in an official release (8.11) but you can get a development version of the compiler here at the build artifacts on the bottom. I think you need to have a github account to access it.

Moving variables around in prog8 almost never makes a difference by the way. Prog8 allocates everything statically and all variables are put on a big pile no matter where you declare them.

Thanks for the clarification. I do have a github account. I started to download the code from https://github.com/irmen/prog8, but then I figured it's be easier to just download the latest official release from https://github.com/irmen/prog8/releases/tag/v8.10. I may wait until the fix has been published in an official release before playing around with prog8 a bit more.

kelli217 wrote: ↑Fri Mar 24, 2023 5:27 pm

Moving variables around in prog8 almost never makes a difference by the way. Prog8 allocates everything statically and all variables are put on a big pile no matter where you declare them.

But if they're in the loop, doesn't the declaration happen over and over again each time you go through the loop?

I suspect prog8 just allocates local variables statically at startup and then retains them for all invocations of the related context. The other approach is to allocate local variables when a context is entered and de-allocate them when a context is exited in which case moving the variables to a more global context would perhaps provide some performance improvement.