A more stationary version - gameplay will be more like this with the cube in a fixed orientation...

I got the face rotations working!


This was the bit that I said last video would be "daunting".  In this video - which is obviously very rough - I have the first working version of "face rotation". That is, spinning parts of the cube just like you would a real cube. I'm just manually cycling through the 9 possible rotation 'planes' here and looking at what glitches show up. And yes. there are a few - particularly caused by the draw ordering and overlap. Nonetheless, it's a big step forward for this effort, and I'm very pleased with how it's going. Except for the speed.

Note, there's a bit of a "scramble" every time I change which face is rotating - that's due to the sort order being screwed up and not updated for a short while. As always, these videos are just a video diary of work in progress, so these things are to be expected.  Next major step will be to actually reposition the cubes as the rotation completes - and then we'll have a fully functional cube.

Here's an update - about 2x speed improvement. I'm struggling to find any more speed, though.
This one is fairly stable (no overtimes).  There's a binary at the bototm of this post. Will run on Gopher and PlusCart. Stella - not yet - but coming soon!!

The cube faces just change colour randomly ever now and then. Just to show the colour "sticks" and it's not purely randomly generated during draw.  UP/DOWN to zoom in and out.

Mmh. Disappointing, to say the least.

#define FPINT 0

#if FPINT
typedef int fpint;

#define Q 8
#define FIXED_ONE (1 << Q)
#define FLOAT_TO_FIXED(x) ((int)((x) * FIXED_ONE))
#define FIXED_TO_FLOAT(x) ((float)(x) / FIXED_ONE)
#define FPINT_ADD(a, b) ((a) + (b))
#define FPINT_SUB(a, b) ((a) - (b))
#define FPINT_MUL(a, b) ((int)(((long long)(a) * (b)) >> Q))
//DOESNOTWORK #define FPINT_DIV(a, b) ((int)((((long long)(a)) << Q) / (b)))

#else

typedef float fpint;

#define FLOAT_TO_FIXED(x) ((x))

#define FPINT_ADD(a, b) ((a) + (b))
#define FPINT_SUB(a, b) ((a) - (b))
#define FPINT_MUL(a, b) ((a) * (b))
//#define FPINT_DIV(a, b) ((a) / (b))

#endif

#define N(a) FLOAT_TO_FIXED(a)

I hit upon a "neat idea" as to how to go about converting from floating point calculations to fixed-point. I'd make macros for all of the math operations and for the type (float/int) and start with my working floating-point version and replace all the math with the macros. That is, where in floating point I had

float x = a * b;
I would replace this with

fpint x = FPINT_MUL(a, b);
The neat thing about this, so I thought, as that I don't have to add new lines, or change things (other than using the macro). If FPINT is defined as 1, then we get the fixed-point implementation, and if it's 0 we get the original floating point version.  After a fair bit of debugging I got all of this working pretty much perfectly - I could switch between floating point implementation or fixed point implementation just by changing "FPINT" to 1 or 0. And they both work!

The disappointing thing is there's no speedup noticeable. This is likely because of a couple of factors. Firstly, there aren't actually all that many floating point operations in the pipeline after all. But secondly, mostly, my architecture which tries to do things in small parts so that it all fits into the overblank -- is probably not efficient.  So, negligible speedup.

I did find one bug in *somewhere*.  The FPINT_DIV does not work for the fixed-point code. There's something fundamentally broken because Gopher will not even load/run a binary with this macro used *anywhere* in the code; even when the code is unreachable. Very strange, but a lot of testing indicated to me that the (long)(long) division just doesn't work. So, I left one single floating point divide in the fixed point implementation.

Anywho... it was a road worth travelling. Fortunately I did all this in a branch so I can switch back and forth easily enough - but for now I'll go back to the earlier code (without fixed point) and soldier on.  I'm not shattered, but I am surprised and a bit disappointed.

AtariAge thread on Cubix (2021)

This image shows 400 spaceships, which takes about 6 seconds to render. I push much further than this and I'm overtime in the overblank. I could, if required, do some rewrites to allow even more polygons (around 3500 actually drawn in this image)!

Quote from: DirtyHairy on 30 Jul 2024, 07:53 AMThere still is a bit of cleanup to do, but it is working on my "ELF" Stella branch now.

@Andrew, it seems that you are dereferencing an array that points to zero somewhere (reading 8bit elements from there). That's where the vector table dwells on a real Cortex. I've added a temporary hack to stub those as zero (which probably should become a dev vs. player setting like other "strictness" settings), but you might want to to fix this

OK; TY. Some of those found/fixed recently. I will shoot you a new binary to test, if you are willing.

Now that the 3D engine is approaching "maturity" and I have a pretty good idea where the bottleneck is, it's time to bite the bullet. I've used floating point calculations so far and it's now time to move to fixed-point instead. This will take me some time, but I expect the results to be dramatic. The stm32g070 uses software libraries for floating point operations (!!) and does not have a floating point unit (FPU). Imagine how much processing power is sunk into the 3D calculations - no wonder it's slow.  Clearly the bottleneck, and I predict a... let's say 10x speedup in the pipeline when I'm done. That would mean I could, say, run 100 space ships at 60Hz. Well, that's the dream. Watch this space, I guess.

In the end, it wasn't the dot-product that was backwards; it was the orientation of the faces of the cube data. Instead of defining in counter-clockwise order, I had defined the cube faces in clockwise order. I blame chatGPT for that.

Here's an updated video. It's still slow, but looking nice.
The face colours change when I press the button. Only the visible faces are coloured - and this helps the black borders between be a bit more defined. The real big task coming up is how to rotate the various groupings/faces together. It shoud be simple-ish, but I'm finding combined rotations and offsets hard to get my head around.

Cubix

iCC3


iCC1

Spaceships on a Starry Night
with apologies to Van Gogh

There is a bug in quicksort - so I'm actualy using *gasp* bubble sort *gasp* in this version. Here I'm running 12 ships. A few issues still with the screen/polys, but getting there.

Well, proof of concept.  It shows how the cube would look at various sizes - near has too many issues with the lores/hires areas, but mid-distance it all looks rather good. I think a workable 3D Rubik's cube would be perfectly functional/possible. The frame rate is a bit slow, though - 27 cubes being rendered ehre and all those 3D calculations are a killer.

In this rather long video I'm demonstrating the much improved stability of the 3D engine. Here it's running 10 spaceships. Previously I had been displaying only the back-faces (!!!) of the objects, so things were kind of warped and weird. Now that's fixed -- I kind of stumbled on this issue and am glad to have it working.  I have also found/fixed an issue with crashes which was caused by trying to render pollys that had been classified as "off screen". This lead to infinitely long lines being drawn and consequent overtimes.  There really isn't a lot of time available to do all this stuff - it all happens in the overblank (overscan+vertical blank) of a TV frame.