NEON-optimised metaball demo

A couple of months ago I said that I’d like to write a metaball demo, and after working on it on and off for a few weeks I can now say that I have. Grab it over here. The demo bounces 8 pixel-accurate metaballs around the screen, with simple lighting applied.

Note that you’ll need an ARMv7 machine and BASIC 1.49 or newer (for the VFP/NEON assembler; anyone running RISC OS 5.18+ should have it). You also need to run the demo in a 32bpp screen mode. By default it tries to render the balls in a 512×512 area of the screen, but it will shrink the area down (in powers of two) if you’re in a lower resolution mode. On an 800MHz BB-xM it’ll run at a pretty consistent 33fps if it’s rendering at 512×512, or 100+fps at lower resolutions.

Implementation-wise it’s using floating point math for all the calculations, and the only bit that’s done in parallel is the fn_sum routine which calculates the sum of the blob influences at a given point. So there’s a good chance the performance could be improved by converting some/all of the code to fixed-point or making better use of parallelisation. Some improvements could also be made to the main loop in order to avoid wasting time processing blank areas of the screen, and to avoid clearing pixels which are already blank. A possible non-performance related enhancement would be a different rendering mode for the blobs, e.g. soem kind of reflection mapping, which isn’t too hard to add to the existing code (I’ve already got a pure-BASIC prototype for it). Also the current code only renders blobs on a 2D plane, so having them float around in 3D would be nice.

For anyone who wants to have a fiddle there are a few variables at the start of the file which can be tweaked. ‘t’ and ‘scale’ are the most interesting ones since they’ll change how the blobs look, and ‘log2size’ can be bumped up to 10 if you want to see the demo crawl along at 1024×1024.

For more metaballs, it’s worth cehcking out all the demos that were on AU CD 6. There’s k2 and zero from the Evolution competition(both using 3D polygonal reflective metaballs), along with ArmOric’s EmbryonWar and EmbryonWav demos (which aren’t exactly metaballs, but use the same basic concepts – and make good use of integration and lookup tables to allow them to run at a decent speed on ARM2/ARM3). Plus probably some other demos which I’m not aware of.

Now, who wants to write the next demo?

…working on it ;-) Nice metaballs ! I got several unfinished ideas (like I guess any coder) on my BB/PB and I’ll see how and when my small amount of spare time will produce some results that are not too ugly to be shown to public ;-)

As a small teaser I wrote some kind of Mandelbrot-Zoom-Feedback-Thingy as a spin of from my NEON benchmarks. It was done some time ago with ExtASM, now I will try to convert it to Basic Assembler. It’s not quite fast (3-4 FPS,6-8 FPS) and still needs some tuning. It zooms different Mandelbrot’s at 300 × 300, Iteration depth 192 and feedbacks and fades out the previously drawn ones. Here’s the Link

you’ll need an ARMv7 machine and BASIC 1.49 or newer (for the VFP/NEON assembler; anyone running RISC OS 5.18+ should have it).

I have 5.18 rc2 (16 Jan 2012) which has BASIC 1.48

I believe that 5.18 won’t have the updated BASIC in the end because it was missing extended helptexts etc that one would expect for a formal OS release. Disappointing, I know :(

Oh, come on! It’s not as if BASIC’s help is exactly verbose. Surely it shouldn’t take more than half an hour or so to knock up a quick reference for the new instructions?

Of course, I’d argue that we really shouldn’t be dumping all assembler help into the same “HELP [” command, and it’s about time it was split up into separate entries, but that’s another job altogether.

+1¹

I agree with Martin. TBA’s extended BASIC is well documented – if (for the moment) that’s missing from the actual HELP command, who cares? Can’t we just include the text file(s) in the disc image as an interim measure?

If we want to encourage coders to use features, why add the obstacle of sending them off to download a separate version of BASIC?

¹ Retrospectively, and more concisely than my initial comments above!

+1

+1

I’m in agreement with Martin too (except for the half an hour bit – there’s about 150 new instructions which have been added!)

“HELP [” is already an indecipherable mess, it would be foolish to add anything else to it without first splitting it into several entries.

If we want to encourage coders to use features, why add the obstacle of sending them off to download a separate version of BASIC?

Or, more importantly, if we want to encourage users to use programs, why add the obstacle of sending them off to download and correctly install a seperate version of BASIC?

For the record, I’d also like to see it in ASAP, but I’m just reporting what I’ve been told. I rather assumed it was a “corporate” decision?