The Sentinel (1986)

[Andrew Davie]

I have 6 "complex" 3D objects being rendered in this demo. I'm rendering 2 per frame, and the bullets/dots on a frame by themselves. I will soon move to a per-poly render rather than per-object, which will allow me to more optimally use the available processing time in the overblank. For now, though, we can see how well the system fares "under load"

All of this realtime rendering will disappear soon, as what I'm leading towards is rendering the actual landscape (which is currently a static image) in full 3D. That will get me 75% of the way towards an actual functional implementation. All this hooraw about rotating/shootable 3D objects is just a pleasant aside from the real purpose of this engine.  That is, "The Sentinel".

[Andrew Davie]

It just occurred to me that because emulation of the above is running at about 45Hz, the same thing on hardware will be running about 33% faster.

[Andrew Davie]

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.

[Andrew Davie]

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.

[Andrew Davie]

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.

[Zack]

Unfortunately 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?

[Andrew Davie]

Unfortunately 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.

[Andrew Davie]

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

Code Select Expand

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.

[Zack]

I'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?

[Andrew Davie]

I'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.

[Andrew Davie]

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

[Andrew Davie]

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.

[rnr3ill]

This is so rad! Years ago, before the Christmas cart was released, you sent me some demo ROMs of Chronocolor. It's amazing what you have accomplished along the way and since!

[Crossbow]

Not 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.

[Andrew Davie]

Not 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.