Bubble Universe

[Hated Moron]

This is a rather nice graphics demo, courtesy of Paul Dunn (author of SpecBAS, a modern take on Sinclair 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).

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

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

[KenDown]

Golly! That is impressive. Just out of interest, which bits are so much faster in SDL - or is it just a case of "everything"?

[Hated Moron]

Just out of interest, which bits are so much faster in SDL - or is it just a case of "everything"?

Well, as you know the BBCSDL interpreter itself (at least, the 32-bit x86 interpreter) is to all intents and purposes the identical code to the BB4W interpreter, so they run at the same speed, all other things being equal. It's input-output, as always, that dictates how performance differs, and it's impossible to give a simple answer: some things are faster, some things are slower. It so happens that with this particular program BBCSDL is around fifteen times faster than BB4W, but that is not typical.

[nvingo]

As A-level students (or it might have been O-level) we assisted our maths teacher getting Mandelbrot to run on the Beeb.
Even so, I struggle to comprehend how so little code can so fill the screen.

[Hated Moron]

On 17/11/2022 00:45, Andrew Cool wrote (cross-posted from discussion group):

In running the intriguing Bubble Universe code, and expanding the window size to 1440x1440, the window produced exceeds the available Y dimension on my 4k monitor (3840,2160). It should only occupy about 2/3 of the Y dimension.

Apart from “Well don’t do that!”, is there a solution to make the Window dimensions behave?

There's nothing in what you describe to suggest that it isn't "behaving". The monitor resolution is irrelevant, what matters is the size of the screen as it appears to BBC BASIC after High DPI scaling; for example the laptop PC on which I am typing this has a screen resolution of 3200 x 1800 but as far as BBC BASIC is concerned (indeed as far as all applications are concerned, by default) it has a resolution of 1280 x 720 pixels.

Of course if you're saying that you have disabled High DPI scaling, and your screen actually appears to BBC BASIC as 3840x2160 pixels, that is another matter entirely and you would have reason to be puzzled. But unless your monitor is enormous (a diagonal dimension of about 46 inches) the DPI value would be much greater than the standard 96 that BBC BASIC assumes.

[Hated Moron]

On 17/11/2022 23:17, Andrew Cool wrote (cross-posted from the Discussion Group):

Is there a setting somewhere to make the reported physical window size in BB4W consistent with other languages, e.g. 3820x2160

I wouldn't know about "other languages" (BBC BASIC is the only language I'm familiar with!) but it's consistent with the default behaviour of all programs in Windows, which is for High DPI Scaling to be enabled. Any application which doesn't want this behaviour has to declare that it is High DPI aware in its manifest, and that generally involves extra work making fonts readable etc.

Anyway High DPI Scaling is particularly important in the case of BBC BASIC, because many programs assume that the default font will be an 8x8 pixel bitmapped font (as on the BBC Micro) which is only comfortably readable at something near to the standard 96 DPI. Indeed BBC BASIC for SDL 2.0 actually uses that same 8x8 font!

irrespective of the Windows scaling factor, or is this best appreciated as a “feature” of BB4W?

It is not a "feature", it is BB4W working correctly, and as it has always done.

Once you have 'compiled' your program as a standalone executable you have complete control over its behaviour, so if you want to disable High DPI Scaling you can provide a suitable manifest (remember to deselect the Use Windows XP visual styles checkbox, or do the same with a compiler directive, to avoid two manifests being included). You can even do it programmatically, although that is not recommended (and is liable to confuse the BB4W IDE). Full details are here.