Bubble Universe - incredible 16 line demo - needs porting!

[BigEd]

Unless I'm very much mistaken, this very short program runs on the Spectrum Next (nope, it's Sinclair Basic but on a PC) and produces marvellous output. So we need a BBC Basic version! Any takers?

Code: Select all

10 CONST n=200,r=TAU/235:
x, y, v, t=0, sz=200,sw=SCRW/sz,sh=SCRH/sz:
WINDOW DEPTH 0,32:
ORIGIN -sw,-sh TO sw,sh:
SCREEN LOCK:
DO:
  CLS 0:
  FOR i=0 TO n; j=0 TO n:
    u=SIN(i+v)+SIN(r*i+x),
    v=COS(i+v)+COS(r*i+x),
    x=u+t:
    PLOT INK RGBTOINT(i,j,99);u,v:
  NEXT j;i:
  t+=.025:
  WAIT SCREEN:
LOOP

Edit: fixed a typo so t will increase each time

Credit to ZXDunny (where you can see the result)

[danielj]

That needs some compiled beefyness to run - no way it'll play ball on a beeb

d.

[BigEd]

But we have PiTubeDirect with Native ARM and VDU output to HDMI!

Also, we have Archimedes - is that fast enough?

Edit: I suspect what we need is really fast SIN and COS here...

[julie_m]

If you just want fast sine and cosine, you can do worse than solve by numerical approximation the differential equations for simple harmonic motion, relying on the identities d/dx(sin x) = cos x and d/dx(cos x) = -sin x, beginning with x=0 and adding a small amount Δx each time, where Δx is small enough for the slope of the curve not to change much between x and x+Δx:

Code: Select all

P% = P% + V% * M% DIV D% : REM POSITION => SIN
V% = V% - P% * M% DIV D% : REM VELOCITY => COS

where P% starts at 0, V% starts with its maximum value and M% and D% are such that ΔX = M%/D%; choose them based on how many values you want in your table. It is quite accurate over the interval from 0 to PI/2 (or should that be 355/226? ) but tends to become less so with each successive quarter circle; but you really only need to calculate the first anyway, as you can always fill in three more values by symmetry.

[ChrisB]

Simplistic conversion to BBC Basic for SDL. Runs at around 8 frames per second on my PC.

Code: Select all

      n=200
      r=PI*2/235
      MODE 4
      x=0:y=0:v=0:t=0
      s=240
      VDU 23,1,0;0;0;0;
      *REFRESH OFF

      ORIGIN 640,512
      REPEAT
        CLS
        FOR i=0 TO n
          FOR j=0 TO n
            u=SIN(i+v)+SIN(r*i+x)
            v=COS(i+v)+COS(r*i+x)
            x=u+t
            COLOUR 1,i,j,99
            PLOT 69,u*s,-v*s
          NEXT j
        NEXT i
        t+=.025
        *REFRESH
      UNTIL FALSE

Edited to invert coordinates. Image not updated.

[ChrisB]

And with some basic colour mapping in owlett. Standard beeb draws one frame in about 20 minutes....

https://bbcmic.ro/#%7B%22v%22%3A1%2C%22 ... %5Cn%22%7D

[dp11]

Didn't owlet use to have rocket mode?

[scruss]

Simplistic conversion to BBC Basic for SDL. Runs at around 8 frames per second on my PC.

OooOoh, that's very nice indeed. I think it looks prettier if you take out the CLS.

It runs very slowly/badly under Matrix Brandy, where it absolutely should be faster than BBC BASIC for SDL

[IanS]

Didn't owlet use to have rocket mode?

From another thread,

You can get access to 'rocket mode' in owlet by putting in ?experimental=true before the hashmark, and get JIT performance:

[scruss]

video of ChrisB's code running at about 15 fps: https://www.youtube.com/watch?v=uGO2Dgoqhxg

[BigEd]

Most excellent porting fun! Thanks ChrisB! 20 mins a frame isn't too bad for a 2MHz 6502...

Here's that first frame in Owlet:

Thanks for the video too scruss - here's a snapshot of that:

Not only is this demo very pretty but the movement is mesmerising too.

[tricky]

I wonder how fast beebjit could run it.

[ChrisB]

It is considerably faster on a Master with the improved SIN/COS functions and there are optimisations to be made as well. The animation loops after 2*PI so here's a render (not real time) using a small step speed from BBC Basic for Windows played back at 30 FPS of the whole thing.

http://www.youtube.com/v/RJl8MQy3wXw

[TobyLobster]

Takes about 2 seconds for beebjit on my machine.

BUBBLE.ssd

(200 KiB) Downloaded 62 times

[scruss]

It is considerably faster on a Master with the improved SIN/COS functions and there are optimisations to be made as well. The animation loops after 2*PI so here's a render (not real time) using a small step speed from BBC Basic for Windows played back at 30 FPS of the whole thing.

http://www.youtube.com/v/RJl8MQy3wXw

Ooh, thanks. Wish I'd noticed the 2*PI loop thing - I must've got so close to rendering all the frames, but saving them all to BMP was getting kind of huge

[ChrisB]

Takes about 2 seconds for beebjit on my machine.

Here's a couple of minor optimisations for the colours and removing one of the calculations outside of one of the loops - not approached the SIN/COS as yet.

https://bbcmic.ro/#%7B%22v%22%3A1%2C%22 ... %5Cn%22%7D

However no matter the optimisation the code is still plotting 10,000 points per frame so it's not going to be rapid.

Times:
My original code - 21.5 minutes/frame
Partially optimised coded above - 19 minutes/frame
BBC B with Second processor - 12 minutes/frame
Master - 10.5 minutes/frame
BBC Master with second processor - 6.5 minutes/frame

Having said that I've been looking at the code in a bit more detail. I put in a couple of STEP 2s as a quick optimisation but looking back that will actually miss quite a lot of detail as the code iterates on it's position. This is what it should look like which takes 25 minutes on a Master with second processor and a staggering 75 minutes on a straight B.

[BigEd]

Very interesting... I have a couple of thoughts...

What's the effect of changing the 200, either for the number of points or the number of iterations, or both? At Beeb resolutions it might be invisibly different.

I do wonder (idly wonder) what the effect of floating point precision might be - our 8 bit BBC Basics use five byte floats, the ARM Basic can (I think) use eight byte floats, and Richard Russell's BBC Basics can, on an Intel PC or using Rosetta 2 on an ARM Mac, use ten byte floats. (And some MS Basics have only four byte floats.)

For the Brandy Basic performance question: I think we're taking SIN and COS of relatively large numbers, so the speed (and accuracy) of the range reduction is going to be important. I wonder if that's worth looking into.

[ChrisB]

The problem is these three lines:

Code: Select all

u=SIN(i+v)+SIN(r*i+x)
v=COS(i+v)+COS(r*i+x)
x=u+t

u and v are calculated from two SIN/COS - but then x is calculated from u and v is also used so there is a feedback loop going on here. Reducing the number of iterations therefore dosen't have quite the expected effect of simply "thinning" the pattern.

[TobyLobster]

Just for fun, I created a video from the individual frames generated then saved out of beebjit:

https://www.youtube.com/watch?v=hWB0dCsy_j8

EDIT: YouTube isn't doing a very good job at preserving the details though.

[BigEd]

Splendid!

[elkrepair]

My mind implodes just trying to understand how someone determined that this code would produce that output. Amazing.

[julie_m]

OK, I've altered ChrisB's code a little to come up with this monstrosity.

It seems a little quicker on a Model B. I'm sure there are a few more cunning stunts we can pull, but I've already bust one taboo!

EDIT: It says 371 seconds .....

[TobyLobster]

There's a couple of expressions that are calculated twice so we can bring them out

Code: Select all

q%=(I%+v)*z:w%=(i+x)*z

we can use a larger scale factor (I'm assuming this is no slower, maybe it is?) for more accuracy, and redefine the palette so we don't need to treat colour 0 as a special case. I took out the STEP 2s also for a more complete image. The result is this.

[dudleysoft71]

I thought I'd have a go at porting it to the ARM co-processor, and see what sort of performance it was possible to get out of PiTubeDirect and BeebEm with the ARM7TDMI co-processor enabled. I used beebScreen to help speed up the porting process, I can't imagine sending 40,000 plot commands over the tube for the host to plot would be particularly fast.

I set the resolution to 120x240 in mode 2, which allows for double buffering on a Model B (28,800 bytes needed for both screens), by converting the sin/cos calls into a lookup table I was able to get it running at a surprising speed in BeebEm, we're talking about a frame per second rather than multiple seconds per frame, it pretty much runs as fast as it can transfer the screen over on the native ARM co-processor on PiTubeDirect.

I borrowed the palette settings used for the native BBC Basic version, so it uses colours 1-4 in mode 2, so it probably looks very similar to the BASIC version, however since I have more memory I have created a 65536 entry sine/cosine table (because I can use an unsigned short as the index and get free wrapping of the index).

I've attached an SSD image that contains the program, simply type

Code: Select all

*BUBBLE

to run the program (with an ARM7TDMI or NativeARM co-processor enabled).

Here's a video of it in action on the PiTubeDirect: https://youtu.be/FAj-eaU-S2s

I may have another pass at it to see if I can reduce the number of floating point operations, currently everything is done in doubles and then converted to integer when required, this isn't really an issue on the PI, but in BeebEm there is no FPU so it's all in software, which is going to cost a lot more than pure integer would.

[BigEd]

Splendid!

I notice that the 5- or 6-armed green whirligigs have gone, or turned into fuzzy circles, somewhere along the way - is that perhaps the table-based trig?

[dudleysoft71]

Splendid!

I notice that the 5- or 6-armed green whirligigs have gone, or turned into fuzzy circles, somewhere along the way - is that perhaps the table-based trig?

It's quite possible, I chose 65536 entries to try and keep as much precision as possible, but there's definitely scope for things to drop off because we no longer have the same level of precision, and since it's a feedback loop those errors will accumulate for every position it calculates as it goes round the loops.

[iainfm]

Someone (RTR?) posted this in the BBC Basic Facebook group the other day:

https://fb.watch/gSpOD_ykct/

I think it's the same thing anyway!

[BigEd]

Very nice, very smooth. Looks similar but I think it's actually different from the original... is that the algorithm or the precision?? Edit - oh, I see STEP 2 in the loops. Maybe that's it.

Post text for reference:

Here's a rather nice graphics demo, courtesy of Paul Dunn (author of SpecBAS, a modern take on Spectrum BASIC). It's a good example of how a complex image can be generated from a simple algorithm. Although it's compatible with BB4W, it needs BBCSDL to run at a sensible speed (and shows how much faster it can be).

Code: Select all

n=200:r=2*PI/235
u=0:v=0:t=0:sw=512:sh=512
VDU 23,22,sw;sh;16,16,16,0:OFF
ORIGIN sw,sh:sw/=2:sh/=2
*REFRESH OFF
REPEAT
CLS
FOR i=0 TO n STEP 2
k=r*i+t
FOR j=0 TO n STEP 2
p=i+v:q=k+u
u=SINp+SINq
v=COSp+COSq
COLOUR 7,i,j,99
PLOT u*sw,v*sh
NEXT
NEXT i
t+=.025
*REFRESH
UNTIL FALSE

[julie_m]

I notice that the 5- or 6-armed green whirligigs have gone, or turned into fuzzy circles, somewhere along the way - is that perhaps the table-based trig?

Those whirligig patterns could well have been an artefact of my original sine table, which only contained 512 values. With a bit more work, I could up that effectively to 2048 values using symmetry ....

[TobyLobster]

Code: Select all

double t = 0.0;
int n = 255;
int counter = 0;

void setup() {
  size(2048,2048);
}

void draw() {
  background(0);
 
  double r=PI*2/235;
  double x=0;
  double y=0;
  double v=0;
  double u=0;
  
  double s=width/4.5;
  int index = 0;
  for (int i=0; i < n; i++) {
    for (int j=0; j < n; j++) {
      u=Math.sin(i+v)+Math.sin(r*i+x);
      v=Math.cos(i+v)+Math.cos(r*i+x);
      x=u+t;
      index++;
      stroke(i, j, (n-i/2 - j/2)*255/n);
      rect(width/2 + (float) (u*s), height/2 + (float) (v*s), 2, 2);
    }
  }
  t=t + PI/400;
  counter += 1;
  if (counter <= 800) {
    saveFrame("bubble#####.png");
  }
}

HD video using the Processing code above to generate and save the images, then ffmpeg to join them together:

https://www.youtube.com/watch?v=JggP_Q0g6HY

Toby