Finally, some on-screen diagnostics. Debugging to date has been complete guesswork and colour flashes; this will make a huge difference. I should also get the symbols included in the gcc build so Gopher can display them. That will make a huge difference. But for now... we have numbers!

Update: I've seen a few overtimes; will reduce my tolerance. No need to report, TY.

Although it seems a while since the last update, a lot has been going on behind the scenes. I spent some amount of effort moving towards matrix math because "that's the right way to do 3D math". Well, that was a poor choice. Yes, it simplifies code - but adds horrendous overhead compared to fine-tuned by-hand coding. The reason is, many of the matrix operations consist of matrices with lots of zeroes - because such elements are unimportant. But to do a full matrix 4x4 multiply by 4x4 you end up doing a LOT of floating point calculations. At one point I believe I counted 192 floating point calculations per vertex. Yeah, of course I'm not super efficient in my code yet, but it was clear that the manual way I was doing it originally was going to be way faster.

So, I reverted.

There have been a lot of behind-the-scenes work done in world-view, object-view, screen-view translations rotations and projections done - not quite ready for the big time yet. I got it working in matrices but as I said - way too slow. I will get that sorted soon.

Other things I've fixed is making sure everyting works and auto-adjusts aspect ratios and various buffer sizes based on the iCC mode used (iCC = interleaved chronocolour). So now I basically need to set a flag to one of ICC0, ICC1, ICC2, ICC3 and it will display in the correct mode.

ICC0 = (original chronocolour) = 160 x 64
ICC1 = 160 x 192
ICC2 = 160 x 96
ICC3 = 160 x 64

There are four binaries attached - obviously named - running the ship viewer in the relevant mode.

Another thing I changed is the fine-tuning on the throttle for drawing. It may still black-screen crash on hardware - but as yet I've not seen any issues running on Gopher.  I pre-count the number of "draw operations", where that means either a pixel write or a "block" write (a block being a group of 8 pixels of the same colour). Essentially the current settings/throttle is to do up to 11000 of these operation per overblank period. the code is highly optimised. When there's not enough time (when things are close, for example) the frame rate may drop - although it's not really noticeable in these demos.

I have the colour "palette" cycling in these binaries - about every second or so.

As before, up/down = move closer/further.
button = switch to next spaceship

Just a clarification - this is currently using a 70 MHz ARM, not 170 MHz.

Quote from: Crossbow on 20 Jul 2024, 01:07 AMThis was using my Unocart I think to test it out as the Harmony wouldn't load them.

Only functional on PlusCart or UnoCart with latest firmware, at this stage.

Quote from: Crossbow on 20 Jul 2024, 01:07 AMNot sure if it was bug with the last released binary for the Elite one, but basically on both my main 7800 and on a vader 2600 I had here that I just sent back, right after the elite ship basically blows up, the entire video would go out and the consoles would hard lock?

Was that a known thing already brought up? It wasn't until I started looking in this forum again that I remembered about this and had meant to mention it earlier. This was using my Unocart I think to test it out as the Harmony wouldn't load them.

Still going overtime sometimes, apparently. These early versions are really just work in progress to get the rendering pipeline working properly. I haven't tuned them to use only the available time. Thanks for the report; I'm not overly concerned about crashes at this point. There's a long way to go, so consider this all a "proof of concept" at this point.

Seconded. It has been my great delight to watch this effort turn from "promising" to "outstanding". It's been a massive help to my programming, and I very much appreciate your responsive fixes and updates to help me out. I also think it's more than deserving of "v1.0" - in my view one of the shining achievements of the '2600 scene. Thanks!

The code can display in 4 different 'resolutions' (iCC1, iCC2, iCC3, CC). These roughly correspond to the vertical resolution, which ranges from 192 pixels (iCC1) down to 64 pixels (iCC3,CC).  Previous videos mostly showed iCC3 (that is, 64 pixels vertical) which is chunky but has fewer pixels and is therefore quicker. More than quicker, the code is less likely to go overtime trying to draw things.

This video shows the reworked display system which now pre-checks avaialable time and only draws triangles/polys if there is enough time in a frame. It seems to work well - the game slowing down when there's a lot on the screen or when we're in a 'high resolution' mode like iC1.  I'm still undecided which to use, but all of the modes work fine so it can be a deferred decision.

This video is showing iCC1 - the highest resolution (triple the resolution of previous videos). It's not rapid by modern standards, but nonetheless I'm happy with the rendering performance shown here. I have 6 spaceships onscreen doing their thing.

Another thing you will notice is the background picture occasionally "shifts". This is a concept/test for some coming work on looking around. The question is; is it better to re-render the entire screen (which may take seconds) or is it better to scroll the visible screen a bit and then re-render the newly blanked part. I suspect the latter. We shall see.

I'm now able to fairly easily select between the four display modes.

Three of them are Interleaved ChronoColour (iCC)

* iCC1 = 192 line resolution


* iCC2 = 96 line resolution


* iCC3 = 64 line resolution


The other is ChronoColour (CC)

* CC = 64 line resolution




I've now completed the pixel budgeting - essentially a triangle draw is given a budget number of pixels (max) that it is allowed to draw. The triangle code pre-calculates the pixels required, and exits if there is not sufficient time/pixels in the budget. Next frame the same triangle will get another look-in.  Once I get the budget value tuned, we should never see overtime crashes.

Of course, iCC1 is triple the "cost" of iCC3. That is, it takes three times longer to draw any given triangle because the vertical resolution is tripled. The budgeting code is working fine, and things just run more slowly in the higher-resolution modes.

I'm really quite undecided yet, which mode looks better. I'm leaning towards iCC3... but only just. Images identified with prefix CC/ICC1/ICC2/ICC3

Quote from: Zack on 19 Jul 2024, 12:18 AMI'm not sure I fully understand which iCC is which. The number after the iCC represents the amount of scanlines spanned by each pixel?

If we assume a screen height of 192 scanlines then the effective resolution for each mode would be:
CC 64
iCC1 192
iCC2 96
iCC3 64

Is that correct?

I think in all cases the color pattern can be RGB repeated across all scanlines with the iCC modes cycling through a different starting color each frame?

Yes, this is correct. I broke the code and was confused. iCC3 worked, iCC2 didn't.
I have since reverted and everything is working as expected. I'm now leaning towards using iCC1.
Dunno, maybe it will end up being switchable.

Since I've settled on CC/iCC3... at least for now... here are the numbers

const unsigned int SCREEN_Y = 192;      // scanlines
const unsigned int SCREEN_X = 160;      // sprite pixels
const unsigned int SCREEN_LORES_X = 40; // playfield pixels

const unsigned int EXTRA_FOR_SCROLL = 1;
const unsigned int SCREEN_Y_TRIXELS = (SCREEN_Y / COLOUR_PLANES);    // 64
const unsigned int BUF_HEIGHT = SCREEN_Y_TRIXELS + EXTRA_FOR_SCROLL; // 65
const unsigned int BUF_WIDTH = (SCREEN_X / 8) + EXTRA_FOR_SCROLL;    // 21
const unsigned int BUF_WIDTH_LORES = (SCREEN_LORES_X / 8);           // 5

unsigned char hires[BUFFER_MAX][COLOUR_PLANES][BUF_WIDTH * BUF_HEIGHT]; // 2 * 3 * 21 * 65 = 8190
unsigned char lores[COLOUR_PLANES][BUF_WIDTH_LORES * SCREEN_Y_TRIXELS]; // 3 * 5 * 64 = 960
unsigned char zbuffer[SCREEN_X * SCREEN_Y_TRIXELS];                     // 160 * 64 = 10240
                                                                        // = 19390 bytes


iCC3 needs 19390 bytes
iCC2 needs 29022 bytes

I'm a bit unclear, actually, how iCC2 actually works insofar as the layout/colours etc.

Quote from: Zack on 18 Jul 2024, 09:49 PM

Quote from: Andrew Davie on 18 Jul 2024, 09:29 PMUnfortunately there are long thin polys which are both far away and very near, and this inevitably screws the z-sort "painter's algorithm".

Maybe you can divide these larger polys into smaller ones to get acceptable results without a z-buffer?

Yes, but not very generic.  The problem is - if we're using a painter's algorithm... drawing further-away polys first... then how do you know if a poly is further than another?  One method (the one I tried) is to average the z-depth of the vertices of the poly. That works, mostly. But completely depending on the orientation relative to the camera, it occasionally fails. Even with small polys it's going to fail sometimes.

I could have a lower-resolution z-buffer - isolate draw issues to small areas, perhaps. For now, though, I'll try and go full-hog just to get it working properly.

Although I have now successfully performed 1) and 2) and 3) above, I now realise things are more complex than I first thought. Although the shown spaceship now renders (somewhat) correctly - I adjusted the outlines to be drawn with each face rather than all together after all faces have been drawn. But there are still situations where things just don't look right. To get the sorting, I averaged the z (depth) values of the vertices of each face and used that as the sort key. Unfortunately there are long thin polys which are both far away and very near, and this inevitably screws the z-sort "painter's algorithm".

A bit of research shows me that the most common way to sort out these sort of problems is to implement a z-buffer. This is going to be a significant slowdown and a fair bit of extra programming. But, especially considering the sentinel's landscape....I think it might be necessary.

So, that's going to take me a few days to get sorted.  z-buffer it is.

This video shows clearly the reason why I need to sort the polygons per-object before rendering faces. Watch the wings of this ship as they appear to go over the front/top when they should go behind. In most objects this isn't a problem because polys don't overlap (at least in my spaceships). But clearly when they do... we get this.  This is what I'm working on fixing next.



Steps
1. implement a quicksort from scratch
2. sort the object faces before rendering
3. sort the objects before rendering (so ships in the background don't go over the top of ships in the foreground).

These things should keep me busy for a few days.

I have 29 ships from the game "Elite" installed, and in this video I just have a random group coming towards the camera. We now have the ability to have full-screen poly rendering without slowdowns or crashes/overtime. You can see from the cursor movement speed this is going quite nicely now - and Gopher seems to be keeping up, too.  I've rewritten a lot of the rendering pipeline to do per-poly rather than per-object and that's made quite a bit of difference.

This could almost be a stand-alone space shoot'em'up if I so desired. I'm going to keep pushing on Sentinel for now, though. That was the original challenge although by now I think we've shown that it's totally do-able.


My YouTube channel has gained a few subscribers recently - now up to 469. That's a big number for me.