Bubble Universe - incredible 16 line demo - needs porting!

[scruss]

Thanks for that! Saved me some time porting it to Processing myself. For me, Processing has the same feel as if BASIC had been invented this century.

My OpenProcessing / p5js port of your code is a bit dismally slow: Bubble Universe - OpenProcessing. It runs faster on my phone than on my desktop!

[mike12f]

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

It's running really smoothly for me under the latest version of Matrix Brandy.

Great demo! Where did this come from?

[BigEd]

Great demo! Where did this come from?

It's from Paul Dunn - he has more demos here:
https://github.com/ZXDunny/SpecBAS-Demo ... r/Graphics

[scruss]

It's running really smoothly for me under the latest version of Matrix Brandy.

For me - latest Matrix Brandy, 64 bit Linux, on an i7 4 GHz - it renders one frame every 10 seconds or so, and only in yellow on black

[Soruk]

@mike12f and @scruss - please can you post the git tag on the window title bar, and what OS you're running on. Then I might be able to track down what's going on here.

[mike12f]

I've added a couple of lines to boost the brightness of each dot:

Code: Select all

            GCOL i+50,j+50,99+50
            REMPLOT 69,u*s,v*s
            CIRCLE FILL u*s,v*s,2

I'm getting about 18FPS on Matrix Brandy:


The whole code is here:

Code: Select all

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

VDU 29,640;512;
*REFRESH OFF
TIME=0
frame_counter%=0
REPEAT
    CLS

    FOR i=0 TO n STEP 2
        FOR j=0 TO n STEP 2
            u=SIN(i+v)+SIN(r*i+x)
            v=COS(i+v)+COS(r*i+x)
            x=u+t
            r%=(i/200+0.5) MOD 2
            g%=(j/200+0.5) MOD 2
            c%=r%+g%*2
            IF c%=0 c%=4
            REMGCOL 0,c%
            GCOL i+50,j+50,99+50
            REMPLOT 69,u*s,v*s
            CIRCLE FILL u*s,v*s,2
        NEXT j
    NEXT i
    t+=0.025
    frame_counter%+=1
    PRINT"fps:";(frame_counter%/TIME*100)
    *REFRESH
UNTIL 0

I'm running on Ubuntu Mate 22.04LTS.
Kernel Linux 5.15.0-53-generic x86_64
AMD A8-5600K APU with Radeon(tm) HD Graphics × 4
AMD ARUBA (DRM 2.50.0 / 5.15.0-53-generic, LLVM 13.0.1)

@scruss try it with my code, and try commenting out all of the graphics statements to see if it's the SIN and COS calculations which really are slowing this down.

[Soruk]

In Matrix Brandy, I'm getting about 18fps on my virtual machine, 64-bit AlmaLinux 8 on VirtualBox, hosted on a 2.6GHz Xeon E5-2650v2 (about 8 years old) with the host also running AlmaLinux 8. I get about 3fps on my RasPi 3B+.

If I change the code above to use MODE 640,512,24 instead of 73 (equivalent to MODE 1024,576,24), the RasPi gets about 4.9fps, and about 34fps on the Xeon. (I also changed *REFRESH OFF to *REFRESH ONERROR but that won't affect the speed, it just means *REFRESH flips back to ON when the program is stopped with Escape.)

Edit 2: I've committed a change (563c3c2) that gets me 50fps on the Xeon, 5.67fps on the RasPi3B+.

[BigEd]

I'd be very interested to see differences (in the first frame) between different Basics or Basics running with different floating point hardware, but running the same code and displaying at the same resolution. I'm wondering if this code, or code like this, could serve as a diagnostic, like Richard's scarab program. (In particular, 64 bit vs 80 bit floats.)

[BigEd]

Yesterday Dave and I did a bit of pair programming over a zoom call - I was in the copilot's seat, as usual.

The idea was to make use of a Pi, specifically using PiTubeDirect's Native ARM model for a very fast BBC Basic, and also use the Pi VDU Driver which uses the HDMI output and can plot more speedily (and at higher resolutions) than the Beeb. Or in this case, the Master.

We stuck with MODE 2 though, because more pixels means slower frame rate.

We end up with two versions of Chris' code from upthread: on the one hand a straightforward version using CLS, GCOL, and PLOT, and on the other hand a version which pokes pixel values into some DIMmed memory and then block-moves the new frame into the VDU buffer.

Interestingly, there's little difference in the performance between using the VDU system and using block moves: but with the block moves it's very smooth and fluid whereas with the VDU system there's horrible flicker, because the CLS happens at the end of a frame and it takes a while to draw the contents of the next frame.

An alternative and perhaps more portable approach would be to store the VDU bytestream into an array during the calculations, then spool it out to the VDU system in one go.

Here's the block move version:

Code: Select all

    10 *PIVDU 2
    20 MODE 2
    30 S%=VDU &94
    40 DIM M% 160*256
    50 N=200
    60 R=PI*2/235
    70 X=0:Y=0:V=0:T=0.22
    80 S=240
    90 VDU 23,1,0;0;0;0;
   100 VDU 29,640;512;
   105 TIME=0
   110 FOR F%=1 TO 100
   130 FOR I=0 TO N STEP 2
   140 FOR J=0 TO N STEP 2
   150 U=SIN(I+V)+SIN(R*I+X)
   160 V=COS(I+V)+COS(R*I+X)
   170 X=U+T
   180 R%=(2*I+1) DIV (N+1)
   190 G%=(2*J+1) DIV (N+1)
   200 C%=R%+G%*2
   210 IF C%=0 C%=4
   220 ?(M%+16+(U+2)*32+160*INT((V+2)*64))=C%
   230 NEXT J
   240 NEXT I
   250 T=T+.025
   300 FOR I%=0 TO 40960 STEP 4
   310 S%!I%=M%!I%
   320 M%!I%=0
   330 NEXT
   340 NEXT
   350 PRINT TIME

and here's the more conventional (flickery) version

Code: Select all

   10 *PIVDU 2
   20 MODE 2
   30 N=200
   40 R=PI*2/235
   50 X=0:Y=0:V=0:T=0.22
   60 S=240
   70 VDU 23,1,0;0;0;0;
   80 VDU 29,640;512;
   90 TIME=0
  100 FOR F%=1 TO 100
  110 CLS
  120 FOR I=0 TO N STEP 2
  130 FOR J=0 TO N STEP 2
  140 U=SIN(I+V)+SIN(R*I+X)
  150 V=COS(I+V)+COS(R*I+X)
  160 X=U+T
  170 R%=(2*I) DIV (N+1)
  180 G%=(2*J) DIV (N+1)
  190 C%=R%+G%*2
  200 IF C%=0 C%=4
  210 GCOL 0,C%
  220 PLOT 69,U*S,V*S
  230 NEXT J
  240 NEXT I
  250 T=T+.025
  260 NEXT
  270 PRINT TIME

You'll notice the Y coordinates have got reversed between the two, but there you go.

On a pi zero W, running the hognose release, running at the default 1000/400MHz, the block move version draws 100 frames in 10.97s; the VDU version runs a tiny bit faster: 100 frames in 10.71s. So that's about 9fps.

(If we run without the first line then the VDU commands go to the Master for rendering, and that's very much slower; 10 frames in 188.59 seconds, so about 19 seconds per frame.)

Running on the pi 4, at stock speed we get 100 frames in 3.30 sec, so that's 30fps. (This time the VDU version - the one without the block move - runs 100 frames in 3.51s so a tad slower, but not much.)

(Running without the *PIVDU, rendering on the Master, we get 10 frames in 188.59s which is exactly the same - we must be throttled by the host's rendering, not too surprising.)

As an experiment in authenticity I removed the two STEP 2 qualifiers, so we get 4x the pixels. Now the pi 4 does 100 frames in 11.95s, which is about 8fps.

[scruss]

Edit 2: I've committed a change (563c3c2) that gets me 50fps on the Xeon, 5.67fps on the RasPi3B+.

oooh, that's more like it! 130+ fps with mike12f's code on a fairly old i7 4GHz with no graphics card. This is on 563c3c2.

I had assumed that MODE settings were portable between BBC BASIC for SDL and Matrix Brandy, but alas no.

[Soruk]

I had assumed that MODE settings were portable between BBC BASIC for SDL and Matrix Brandy, but alas no.

Matrix Brandy follows RISC OS rather than BBCSDL for stuff that is traditionally handled by the OS.

You could do something like:

Code: Select all

IF INKEY(-256) AND &DB = &53 THEN MODE 73 ELSE MODE 640,512,24

Edited to reflect the BB4W and BBCSDL catch-all method from BeebWiki.

[mike12f]

Edit 2: I've committed a change (563c3c2) that gets me 50fps on the Xeon, 5.67fps on the RasPi3B+.

Wow, a great update. It's doubled my speed. Keep doing that Soruk, and BBC Basic will be taking over the world, and put Intel and C out of business.

[Soruk]

Edit 2: I've committed a change (563c3c2) that gets me 50fps on the Xeon, 5.67fps on the RasPi3B+.

Wow, a great update. It's doubled my speed. Keep doing that Soruk, and BBC Basic will be taking over the world, and put Intel and C out of business.

I wish... Matrix Brandy is written in C! Anyway, checked in an update which basically reimplements memcpy(), it results in an approx 10% speedup on my 64-bit kit, and no worse than memcpy() on 32-bit x86 or ARM. (64-bit ARM is untested...)

[mike12f]

I wish... Matrix Brandy is written in C!

Ah, that's the problem then. We should write a C compiler that spits out BBC Basic code instead of machine code, and then we can have the whole world running on BBC Basic. Matrix Brandy could then also be written in BBC Basic, an interpreter which runs BBC Basic.

[Soruk]

I wish... Matrix Brandy is written in C!

Ah, that's the problem then. We should write a C compiler that spits out BBC Basic code instead of machine code, and then we can have the whole world running on BBC Basic. Matrix Brandy could then also be written in BBC Basic, an interpreter which runs BBC Basic.

Haha, my head hurts being tied in knots with that one!

[scruss]

Nice updates to Brandy! I've got a version with basically the same parameters as the Processing version, but running in a smaller window as I don't see how to make a 1024 px high window in Brandy. It runs as ~ 36 fps on this i7, and quite amazingly, at 6.6 fps on a Raspberry Pi 4 running 64-bit Debian. The Pi 4 has a pi-top screen, which is a Retina-resolution touchscreen. It's so crisp, with tiny bright pixels!

Cleaned up code, with Processing constants:

Code: Select all

REM Bubble Universe - but with Processing parameters
REM see: https://stardot.org.uk/forums/viewtopic.php?f=54&t=25833
n%=255
r=PI*2/235
dt = PI/400
IF INKEY(-256) AND &DB = &53 THEN MODE 73 ELSE MODE 640,512,24
t=0
s=240
OFF
ORIGIN 640,512
*REFRESH OFF
TIME=0
frame_counter%=0
REPEAT
  x=0:v=0:u=0
  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
      GCOL i%,j%,n%-(i%+j%)/2
      CIRCLE FILL u*s,v*s,2
    NEXT j%
  NEXT i%
  t+=dt
  frame_counter%+=1
  PRINT "fps:";(frame_counter%/TIME*100)
  *REFRESH
UNTIL 0

[Soruk]

....but running in a smaller window as I don't see how to make a 1024 px high window in Brandy.

Use: MODE <x>,<y>,<colourdepth>

e.g. MODE 1280,1024,24
(Indeed, 24-bit is fastest as colours can be plotted "as is" rather than being shifted to the nearest in the palette.)

[iainfm]

This is such a lovely effect.

FWIW: My ROS3.5+ version (for RPC(Emu)/RPi etc):

Code: Select all

ON ERROR REPORT:PRINTERL:END
MODE0:MODE "X640Y480C16M":OFF
GCOL0,0,0,0:CLS
n=200
r=2*PI/235
x=0:y=0:t=0:v=0:sz=200
ORIGIN640,512

REPEAT
FORi=0 TO n
FORj=0 TO n

u=SIN(i+v)+SIN(r*i+x)
v=COS(i+v)+COS(r*i+x)
x=u+t
GCOL0,i,j,99
POINT u*sz,v*sz
NEXT
NEXT
t=+0.025
UNTIL0

Can't help wondering if the line t=0.025 line should be t+=0.025 but I'll do some experimenting!

[BigEd]

Very nice! Yes indeed, t should get slightly larger each time around.

[iainfm]

Yeah, just read the original post again and saw the '+' I didn't see the first (or second, or third) time I looked at it

[BigEd]

I just added it! (Thanks for the bug report!)

[iainfm]

I just added it! (Thanks for the bug report!)

Thought I was going loopy (no pun intended)

[iainfm]

Quick and dirty animated version. Uses system sprite area which needs approx 250Kb/screen.

Code: Select all

REM Needs system sprite memeory of ~250Kb/screen
ON ERROR REPORT:PRINTERL:END
MODE0:MODE "X480Y352C32K":OFF
GCOL0,0,0,0:CLS
n=200
r=2*PI/235
x=0:y=0:t=0:v=0:sz=150:screens=40
ORIGIN480,352

FOR s=1 TO screens:CLS
PRINTTAB(0,0);s;"/";screens
FORi=0 TO n
FORj=0 TO n

u=SIN(i+v)+SIN(r*i+x)
v=COS(i+v)+COS(r*i+x)
x=u+t
GCOL0,i,j,99
POINT u*sz,v*sz
NEXT
NEXT
t+=0.02
MOVE-352,-352
MOVE352,352
OSCLI"SGET "+STR$(s)
NEXT

REPEAT
FORs=1 TO screens
OSCLI"SCHOOSE "+STR$(s)
WAIT:PLOT &ED,-352,-352
NEXT
UNTIL0

[marcusjambler]

Colour Maximite 2 version

Code: Select all

10 n=200
20 r=pi*2/235
40 x=0:u=0:v=0:t=0.22
50 s=120
60 do
70 cls
80 for i=0 to n step 5
90 for j=0 to n step 5
100 u=sin(i+v) + sin(r*i+x)
110 v=cos(i+v) + cos(r*i+x)
120 x=u+t
150 c=i+j
180 pixel (u*s)+400,(v*s)+300,255*c
190 next j
200 next i
210 t=t+0.025
220 loop until 0

[Soruk]

Edit 2: I've committed a change (563c3c2) that gets me 50fps on the Xeon, 5.67fps on the RasPi3B+.

Wow, a great update. It's doubled my speed. Keep doing that Soruk, and BBC Basic will be taking over the world, and put Intel and C out of business.

Just committed a change which got my VM running on the ageing Xeon to touch 68fps, and 12.8fps on my RasPi 3B+.

[mike12f]

Just committed a change which got my VM running on the ageing Xeon to touch 68fps, and 12.8fps on my RasPi 3B+.

The code I ran on the previous test I quoted here (18.37fps) is now doing 60fps. So a (more than) three-fold increase.

I looked at your update, it just replaces

for (lptr = 0; lptr < scrsz; lptr++) *(dptr+lptr) = *(sptr+lptr);

by

for (lptr = 0; lptr < scrsz; lptr++) *(dptr++) = *(sptr++);

so hardly any difference for such a big improvement. (I thought modern compilers would handle both cases the same perhaps, but obviously not here.)

Well done!

[Soruk]

The code I ran on the previous test I quoted here (18.37fps) is now doing 60fps. So a (more than) three-fold increase.

I looked at your update, it just replaces

for (lptr = 0; lptr < scrsz; lptr++) *(dptr+lptr) = *(sptr+lptr);

by

for (lptr = 0; lptr < scrsz; lptr++) *(dptr++) = *(sptr++);

so hardly any difference for such a big improvement. (I thought modern compilers would handle both cases the same perhaps, but obviously not here.)

Well done!

I am guessing it requires far fewer instructions to increment the pointers on each iteration than to perform pointer addition twice each time round. Not forgetting that pointer addition includes a hidden multiplier by the size of the data type! Which is why I divide the 32bpp screen size by 2 as I'm using a 64-bit data type to copy the memory to minimise the number of iterations and, while that may seem to be less optimal on 32-bit hardware it balances out between using a non-native type vs doing twice as many iterations.

[mike12f]

Cleaned up code, with Processing constants:

Scruss - I like your colour scheme and code improvements.

I made some further changes to the code:

Code: Select all

#!/usr/bin/env brandy
REM Bubble Universe - but with Processing parameters
REM see: https://stardot.org.uk/forums/viewtopic.php?f=54&t=25833
num_curves%=255 : REM this is the number of iteration "curves" to plot on the screen simultaneously
iteration_length%=512 : REM this is the "length" of each iteration "curve"
r1=1
r2=PI*2/235
dt = 0.025/4/4
IF INKEY(-256) AND &DB = &53 THEN MODE 73 ELSE MODE 640,512,24
t=0
s=240
OFF
ORIGIN 640,512
*REFRESH ONERROR
TIME=1
frame_counter%=0
REPEAT
  CLS
  FOR i%=0 TO num_curves% STEP 4
    v=0:u=0
    ang1_start=r1*i%+t
    ang2_start=r2*i%+t
    FOR j%=0 TO iteration_length%
      ang1=ang1_start+v
      ang2=ang2_start+u
      u=SIN(ang1)+SIN(ang2)
      v=COS(ang1)+COS(ang2)
      GCOL i%/num_curves%*255,j%/iteration_length%*255,255-(i%/num_curves%+j%/iteration_length%)*128
      RECTANGLE FILL u*s,v*s,2
    NEXT j%
  NEXT i%
  t+=dt
  frame_counter%+=1
  PRINT "fps:";(frame_counter%/TIME*100)
  *REFRESH
UNTIL 0

The main insight I've made is that I've considered the use of x in these lines to be confusing:

Code: Select all

100 u=sin(i+v) + sin(r*i+x)
110 v=cos(i+v) + cos(r*i+x)
120 x=u+t

The confusing aspect was that x was not reset ever to zero. So it looks like each iteration depends on the end state of the previous iteration. But actually, resetting x=0 after every iteration does not seem to make the patterns any worse, so I've made that change for clarity.

Now this is done, we can understand the there is only one iteration going now - we just have to think about the j% loop. Hopefully this is clearer to understand now. The i% loop merely sets the starting state for the iteration (i.e. [ang1_start, ang2_start]) and then the iteration in [u_t,v_t] is given by:

Code: Select all

[u_{t+1}, v_{t+1}]=[sin(ang1_start+v_t)+sin(ang2_start+u_t), cos(ang1_start+v_t)+cos(ang2_start+u_t)]   

where t is represented by the loop counter j%. This seems to make this neat piece of code easier to understand (to me at least).

I've also made the following changes:

1. It now plots filled rectangles instead of filled circles, for speed.
2. We can set the length of the iteration in j% independently of the length of the i% loop. The length i% loop sets the number of curves shown in the screen simultaneously. So I've lengthened the length of the j% loop and shortened the length of the i% loop.
3. Now we have a faster fps (due to Soruk's amazing code updates for MatrixBrandy), I've lowered the time step dt by a factor of 1/4. To make the animation smoother.
4. I've introduced the variables r1 and r2, to make the formulae for "starting angles" for each iteration more explicit.

[mike12f]

Following on from my post above, it is the "starting angles" that govern how each iteration is going to roll out. We can explore the space of possible pairs of start angles, [ang1_start and ang2_start] using the mouse pointer.

This program does this. Move the mouse around the screen to see the iteration dictated by the mouse pointer's location roll out:

Code: Select all

#!/usr/bin/env brandy
REM Universe Mouse-Driven "starting angles" Explorer
REM see: https://stardot.org.uk/forums/viewtopic.php?f=54&t=25833
n%=255
r1=1
r2=PI*2/235
dt = 0.025/4/4 :REMPI/400
IF INKEY(-256) AND &DB = &53 THEN MODE 73 ELSE MODE 640,512,24
t=0
s=240
OFF
ORIGIN 640,512
*REFRESH ONERROR
TIME=1
frame_counter%=0
REPEAT
    CLS
    v=0:u=0
    MOUSE X%,Y%,B%
    ang1_start=X%/640*PI
    ang2_start=Y%/512*PI
    PRINT "ang1_start=";ang1_start
    PRINT "ang2_start=";ang2_start
    FOR j%=0 TO n%
        ang1=ang1_start+v
        ang2=ang2_start+u
        u=SIN(ang1)+SIN(ang2)
        v=COS(ang1)+COS(ang2)
        GCOL 255,255,n%-(j%/n%)*255
        RECTANGLE FILL u*s,v*s,2
    NEXT j%
    frame_counter%+=1
    PRINT "fps:";(frame_counter%/TIME*100)

    *REFRESH
    WAIT :REM this line will cause a crash unless you have the latest commit of matrix brandy!
UNTIL 0

Here is the program output for one particular mouse-pointer position:


I think this shows quite well what is going on in this bubble-universe demo, i.e. that it is all about this central iteration of two variables u and v:

Code: Select all

[u_{t+1}, v_{t+1}]=[sin(ang1_start+v_t)+sin(ang2_start+u_t), cos(ang1_start+v_t)+cos(ang2_start+u_t)]   

[Soruk]

I've pushed an update to Matrix Brandy, that speeds up the SDL build by about 15-25%, simply by moving the ESCAPE polling to its own thread.