Quote from: Al_Nafuur on 02 Sep 2024, 12:25 AMA certain "Andrew Davie" announced this about 5 years ago here:
https://forums.atariage.com/topic/293315-sokoban/?do=findComment&comment=4391823

I am not sure, but I don't recall ever using the name "Sokoboo Plus", and this is what threw me initially. I only have a very very very vague recollection - perhaps a manufactured memory, even - of doing anything related to loading levels from a "PlusStore backend".  I do worry, actually, that I'm starting to forget things as I am getting older. Seriously.

Quote from: Al_Nafuur on 01 Sep 2024, 05:55 AMSokoboo Plus is the version which loads the levels from a PlusROM internet backend in a random order. I am not sure if all levels in the database are solvable

I don't remember this at all.

Quote from: killersquirel on 31 Aug 2024, 03:50 PMIThis game's difficulty totally crushes me though. I think I managed to pass one level once, but that hasn't happened since. Is there something that I am missing, or is this game just brutal?

Um... you must have... accidentally got a.... corrupted version. Only explanation I can think of. Ahem!

Quote from: DirtyHairy on 21 Aug 2024, 06:30 PM

Quote from: Bomberman94 on 21 Aug 2024, 05:28 PMThe last files (elite_ICC1 ... 3) don't run on my light sixer via PlusCart - only black screen.

That's because of the undefined symbol.

TY both for the report. Unusual I didn't notice this via Gopher. I will investigate that later. Part of working with bleeding edge tools/systems. Meanwhile, here are fixed files that hopefully work!

Here I've done a lot of optimisation on the 3D engine - and despite this binary looking similar to previous ones (just a ship viewer), it is running much faster; particularly the triangle draw. It's a real challenge to get any speed in the systems - rendering thousands of pixels per frame (for e.g., a ship up close is rendering around 15K pixels) is time consuming and difficult to do in the overblank area. Very difficult.

So I'm at a bit of a "take a break" phase, thinking about future options. Maybe wait for a dual core alternative hardware option, or possibly try to get interrupts working and have the screen draw interrupt the rendering code. But that may not be as attractive as I first thought, so probably dual-core is the best option. Dunno, we shall see.

Controls:  up/down = move closer/further from ship
left/right = rotation around y axis
button+up/down = rotation around x axis
button press/release with no direction = change ship

This should run on the latest Gopher and PlusCart versions.
Stella will soon have the ability to run it, too.

The attached binaries are different ICC resolutions (ICC1, ICC2, ICC3).  The ICC2 and ICC3 will run without significant slowdown, but ICC1 will probably lag when things are up really close.

OK, not as simple as I thought. Yes, a divide by 0 will cause the problem. But there are other cases.
Like this one. In the following code...

                fpint temp = (p1->x - p0->x) * ymax - p0->y;
                fpint temp2 = (p1->y - p0->y);

                if (!temp2)
                    x = 0;
                else
                    x = p0->x + FPINT_DIV(temp, temp2);

This is the ONLY usage of FPINT_DIV in the entire program.
With the FPINT_DIV there, Gopher will not run - here's the output.

➜  Gopher2600 git:(maintenance_work) ✗ ./gopher2600_darwin_arm64 ../sentinel/source/bin/sentinel.elf
* error in RUN mode: debugger: preview: cpu: starting a new instruction is invalid mid-instruction
➜  Gopher2600 git:(maintenance_work) ✗

That's binary #1. Note I have explicit trap for zero so there's no divide-by-zero happening. Could be an overflow I suppose.

If I replace the FPINT_DIV(temp, temp2) with "temp/temp2" all works OK. That's binary #2.
Note, I did check that "if (!temp2)" and tried "if (temp2 == 0)" just to be sure. No change.

The code is on the fixed-int branch, and pushed.
This problem code is in graphics.cpp around line #368

Quote from: DirtyHairy on 09 Aug 2024, 07:04 AMIf you send me the binary using FPRINT_DIV I can likely tell you what's wrong with it.

Many thanks for the offer, and sorry for the delay in response. A bit of down-in-the-dumps the past few weeks for me, I'm afraid. Haven't had the motivation.  Problem is now found - see my post (just now) responding to JetSetIlly.. See follow-up below.

Quote from: JetSetIlly on 10 Aug 2024, 01:58 AM

Quote from: Andrew Davie on 01 Aug 2024, 03:13 AMI 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.

What does the logging output for Gopher2600 say?

I've just come back to this, and tracked down the issue. It's a divide by zero.
Gopher says

panic: undefined 16-bit thumb-2 instruction (deff)

Essentially the macro/code is...

#define FPINT_DIV(a, b) ((int)((((long long)(a)) << Q) / (b)))

    debug[0] = FPINT_DIV(512/0); // this will crash Gopher
    debug[1] = FPINT_DIV(512,1); // this is OK

Really the FPINT_DIV macro is nothing to do with it.  x = 1/0; will do the trick.  Me bad, I guess. I really don't know what should happen if we have a divide by zero. Perhaps a nicer error message but other than that this is a user error.

Perhaps put some copyright notices and/or licensing/use requirements on future images/posts?

Following with keen interest!

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)