AtariAge thread on Cubix (2021)

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.

Cubix

iCC3


iCC1

Spaceships on a Starry Night
with apologies to Van Gogh

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.

A long time ago I wrote a Rubik's cube 3D demo using CDFJ format. I was endlessly frustrated with my hand-drawn attempts to represent the cube rotating at various angles. It occurred to me that a 3D engine should be able to draw a 3D Rubik's cube - and so that's what I'm playing with at the moment. The thing is, to draw a cube correctly - the objects (26 or 27 little cubes) need to be drawn in the correct z-depth order. Currently the 3D engine does not sort the 'objects', and so it's a royal mess.



So this is a good test-bed to get the sorting functional.

I also "found" the cause of previous crashes - it's something to do with "big lines" in the 3D calculations. I limited the lines to 100 pixels just as a diagnostic. Now I don't get the crashes, but I do get the really odd/awful patches of solid colours on the screen; indicative of bad lines. But at least it no longer crashes. Debugging is difficult at the moment because I'm not setup properly with Gopher to examine variables or do profiling. All of this is old-skool with a value or two printed on the screen.

So, next step required for the cubes - a depth-sort of the transformed object position and then to render in that order (painter's algorithm). We should see a dramatic improvement in visuals when I get that up and running in a day or two.

Not really a dogfight. But the single ship in this version every now and then randomly changes direction and speed. It's quite interesting just keeping it in the "crosshairs"; I can definitely see a 1-on-1 dogfight working with this display system. Maybe WWII aeroplanes in the pacific, with an appropriate sky/sea background.  Anyway, just a bit of fun.

This is a .ELF file which will run on Gopher emulator or PlusCart. My process for making .BIN appears to be broken at the moment, but the .ELF works fine.

It will most likely crash if you let the spaceship go offscreen and/or behind you. So, don't do that! Also no need to report any crashes/glitches TYVM.

What is shown in this video works on real Atari 2600 hardware. That is, if you put this on a cartridge, plug it in, then any genuine Atari 2600 will run it. It will work just fine on a PlusCart with latest firmware. Please read my forum for details on implementation - the PlusCart provides an ARM chip on the cart which this demo uses for the 3D calculations. The '2600's TIA hardware chip is doing all the display for the TV; that is, the picture you see here consists of just one colour per scanline, 40 pixels resolution for playfield, and uses the two 8-pixel wide sprites and multiplexing.

Shown here is a few resets and random ships (3 of) while I variously rotate the camera and move forward/backwards. The ship positions change as expected, and all the scaling and rendering appears to be working correctly.

This was a particularly hard task for me and took some time. Although we have an ARM, there's only a small amount of time per frame available for the ARM to do its stuff - and all the code is written as a sort of cooperative multitasking behemoth - for the ARM chip also needs to service the 6507's request for bytes from the ROM. We don't have interrupts running; just a polling system. Timing is critical.  Aside from all that, just getting my head around the correct 3d processing math has taken me some time.

@Piledriver over at AA posted an interesting "x-Ray" image of some ROMs. Neat idea; I asked ChatGPT to write a Python script to do this for me. 20 seconds later, here's Boulder Dash's X-RAY. I jiggled a few pixels so you crafty people can't reconstruct a viable ROM from the image



It's clear that the ROM is totally chokka!

Here's a preliminary sound system. It's clear now where the emulation is slowing down - the sound does vary noticeably. On the plus side, it's pretty cool pressing the button to change ships and the explosion sound triggers.  This should work just fine on hardware, I imagine, without slowdown.

I've also added some diagnostics onscreen - the text at the bottom. This will make debugging things just a little easier.  This video is shown at the highest resolution (ICC1) - it runs much faster with lower resolutions because of less pixels to draw. But the systems are written to cope with whatever resolution you choose (ICC0,1,2,3) and appear to be working correctly.

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!

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

I thought I'd share the "workflow" of installing a new ship. First I grab the raw data, put it through the AI-generated tool to identify the clockwise faces, then do some manual editing of the data to place into structures in my engine. Finally I go through and change the face colours one by one until we have a finished ship. This particular ship has unusual faces so it does show up the fact that I'm not sorting faces at this stage.

Glorious...  this is a "ship test viewer" that lets you cycle between the installed 3D objects (joystick button press) and zoom in/out (joystick up/down).  This is using a newly-rewritten rendering pipeline that works on a poly/face level rather than an object level, giving finer granularity in timing. So, things can now get full-screen (although not fully-tuned so expect an occasional crash)...

This is an extended rendering test with random generation from the (current) 12 spaceship pool of shapes. Emulator (Gopher) was running this mostly full-speed, although I can get extra real speed by a bit more finesse in the rendering code. It's still pretty impressive, though.  Of particular interest to me is that some of the objects (the "death star-like" object) get pretty much full screen and the system is coping well with this.

Cobra

This is the spaceship "ADDER" from the game Elite (1984).  I've colourised it and installed it in my Atari 2600 3D engine as it currently stands.


This is an interesting, if a bit scary, example of the use of modern AI systems to assist programming. Firstly, thanks to Thomas Jentzsch for the copy of the data. It was a fairly straightforward format, but with a twist that was beyond my math...

REM Format
REM : (a colon)
REM  shape1_name
REM  front_laser_vertex_number
REM  qty_vertices, qty_faces
REM "vertices"
REM  vertex1_x, vertex1_y, vertex1_z
REM  vertex2_x, vettex2_y, vertex2_z
REM    ......et al ....
REM  "faces"
REM  face1_colour,face1_normalx,face1_normaly,face1_normalz,
REM  face1_vertexqty,face1_1st_vertex_number,face1_2nd_vertex_number ...

REM  face2_colour,face2_normalx,face2_normaly,face2_normalz,
REM  face2_vertexqty,face2_1st_vertex_number,face2_2nd_vertex_number ...

REM    ......et al ....

REM  "hue-lig-sat"
REM  15 colour definitions

REM  shape2_name .....
REM  ...
REM  Note: &xx denotes a hex number

:
 ADDER
 &00
 &12,&0E
 vertices
 -&12,&00,&28
 &12,&00,&28
 &1E,&00,-&18
 &1E,&00,-&28
 &12,-&07,-&28
 -&12,-&07,-&28
 -&1E,&00,-&28
 -&1E,&00,-&18
 -&12,&07,-&28
 &12,&07,-&28
 -&12,&07,&0D
 &12,&07,&0D
 -&12,-&07,&0D
 &12,-&07,&0D
 -&0B,&03,&1D
 &0B,&03,&1D
 &0B,&04,&18
 -&0B,&04,&18
 faces
 &00,&00,&27,&0A,4,11,10,0,1
 &00,&00,-&27,&0A,4,13,12,0,1
 &03,&45,&32,&0D,3,2,11,1
 &02,&45,-&32,&0D,3,2,13,1
 &04,&1E,&34,&00,4,9,11,2,3
 &05,&1E,-&34,&00,4,4,13,2,3
 &06,&00,&00,-&A0,6,3,4,5,6,8,9
 &04,-&1E,&34,&00,4,10,8,6,7
 &05,-&1E,-&34,&00,4,12,5,6,7
 &03,-&45,&32,&0D,3,10,7,0
 &02,-&45,-&32,&0D,3,12,7,0
 &0B,&00,&1C,&00,4,10,11,9,8
 &0B,&00,-&1C,&00,4,12,13,4,5
 &0D,&00,&27,&0A,4,17,14,15,16
 hue-lig-sat
 &2D,&02,&07
 &00,&00,&07
 &20,&02,&0F
 &1D,&05,&09
 &25,&04,&0A
 &0F,&02,&0F
 &00,&07,&0F
 &00,&00,&07
 &00,&00,&07
 &00,&00,&07
 &00,&00,&07
 &3C,&03,&07
 &00,&00,&00
 &0F,&07,&0F
 &00,&00,&07

The conversion of the vector and face arrays were mostly straightforward. I can ignore the normals - my engine effectively calculates normals (well, it doesn't kinda need them) and the faces must be defined in counter-clockwise format to allow for the backface culling/removal to work. Unfortunately, the above data just has x/y/z normals for each face, but the ordering of the vertices in the faces is... unknown. To me, anyway.

So when I first put up the ship it was a mess. Faces facing you were absent, faces away from you were showing. You could see a vague ship shape, but somehow I had to figure out which faces were defined clockwise (wrong) and flip 'em.  I had no idea how to go from x/y/z normals to "is this face defined counter-clockwise".

So I asked ChatGPT (4.0) to figure it out for me.  Here's my query...

i'm doing a 3d renderer - wireframe and solid faces. I have data that give x,y,z surface normals for faces, but the vertices are not ordered counter-clockwise. given the normals, can I determine if the vertices are correctly oriented?

From that, and then the above data, ChatGPT wrote a python program for me that correctly identified which of the 14 faces needed to be flipped. I flipped 'em - and aside from the still unknown problem in the back/engine area... it got it totally right. The ship looked like the video (but uncoloured of course) the very first go. It's pretty astounding.

Here's the Python program the AI wrote to solve the problem (remember, from that original prompt + the data)...

import numpy as np

def hex_to_dec(hex_str):
    hex_str = hex_str.replace('&', '')  # Remove '&' character
    return int(hex_str, 16) if hex_str[0] != '-' else -int(hex_str[1:], 16)

# Parse vertices
vertices_hex = [
    "-&12,&00,&28", "&12,&00,&28", "&1E,&00,-&18", "&1E,&00,-&28", "&12,-&07,-&28",
    "-&12,-&07,-&28", "-&1E,&00,-&28", "-&1E,&00,-&18", "-&12,&07,-&28", "&12,&07,-&28",
    "-&12,&07,&0D", "&12,&07,&0D", "-&12,-&07,&0D", "&12,-&07,&0D", "-&0B,&03,&1D",
    "&0B,&03,&1D", "&0B,&04,&18", "-&0B,&04,&18"
]

vertices = []
for vertex in vertices_hex:
    x, y, z = vertex.split(',')
    vertices.append((hex_to_dec(x), hex_to_dec(y), hex_to_dec(z)))

# Parse faces
faces_hex = [
    "&00,&00,&27,&0A,4,11,10,0,1", "&00,&00,-&27,&0A,4,13,12,0,1", "&03,&45,&32,&0D,3,2,11,1",
    "&02,&45,-&32,&0D,3,2,13,1", "&04,&1E,&34,&00,4,9,11,2,3", "&05,&1E,-&34,&00,4,4,13,2,3",
    "&06,&00,&00,-&A0,6,3,4,5,6,8,9", "&04,-&1E,&34,&00,4,10,8,6,7", "&05,-&1E,-&34,&00,4,12,5,6,7",
    "&03,-&45,&32,&0D,3,10,7,0", "&02,-&45,-&32,&0D,3,12,7,0", "&0B,&00,&1C,&00,4,10,11,9,8",
    "&0B,&00,-&1C,&00,4,12,13,4,5", "&0D,&00,&27,&0A,4,17,14,15,16"
]

def parse_face(face_str):
    components = face_str.split(',')
    normal = [hex_to_dec(components[1]), hex_to_dec(components[2]), hex_to_dec(components[3])]
    vertex_count = int(components[4])
    vertex_indices = [int(components[i + 5]) for i in range(vertex_count)]
    return normal, vertex_indices

faces = [parse_face(face) for face in faces_hex]

# Function to check if face is clockwise
def is_face_clockwise(vertices, normal, vertex_indices):
    v1 = np.array(vertices[vertex_indices[0]])
    v2 = np.array(vertices[vertex_indices[1]])
    v3 = np.array(vertices[vertex_indices[2]])
   
    # Calculate the normal using cross product
    edge1 = v2 - v1
    edge2 = v3 - v1
    face_normal = np.cross(edge1, edge2)
   
    # Normalize the face normal
    face_normal = face_normal / np.linalg.norm(face_normal)
   
    # Compare the calculated normal with the provided normal
    dot_product = np.dot(face_normal, normal)
   
    return dot_product < 0

# Check each face
clockwise_faces = []
for i, (normal, vertex_indices) in enumerate(faces):
    if is_face_clockwise(vertices, normal, vertex_indices):
        clockwise_faces.append(i)

# Print the results
print("Clockwise-oriented faces:", clockwise_faces)


I then basically said "run it" and it came back with the following...

The faces that have clockwise-oriented vertices are at the following indices:

Face 1
Face 3
Face 5
Face 8
Face 10
Face 12


It's pretty incredible. This is kinda scary, but amazingly useful at the same time.


I'm not doing Elite. Not yet, anyway. This was just an attempt to see if the spaceships could be rendered and recognisable on the '2600. An emphatic YES.

For Sentinel, Zack and I have been working on a generic suite of tools and kernels to display arbitrary images as full-screen "iCC".  iCC is "interleaved chronocolour" - a system that has evolved over a number of years to present full-screen images on the '2600.

I thought I'd start a thread and post some examples as we test and improve.

A game I have admired for some time is "The Sentinel" - a 3D strategy game from 1986.


The Sentinel

I think it can be done on the '2600, and I'm already exploring "what if?" to see how things might work. So far I've been unable to find out who owns the copyright; I'd like to do that.

Here's a concept-pic of what the screen might look like....

Original (BBC)


Converted (40x66 - '2600)


As you probably guessed from the above, my bitmap systems (from BD) have a resolution of 40 across x 66 down x 8 colours).  This game lends itself well to the limited colours. The resolution is marginal... but gut feeling is it will work.

I wonder how many of the "invitations" that I sent out actually resulted in someone downloading and playing the game. My guess would be less than half. That would be my only explanation for so few "thank you" messages, or at least any acknowledgement at all.

In any case, as you may know I expected a few bugs and have been fixing them as I can, as they show up - and then distributing new versions. This is a lot of work for 70+ people as I have to do a new build, rename, upload, send a message for every single person.

So I'm going to do the next round a bit differently.

If you are "one of the 100" and you have an invitation to download, and you want to get the bug-fix versions... then please respond here and leave a short note to say so. I'll only distribute new/bug-fixes to those who are clearly actively interested in having the updates.

Just a quick response in this thread will be sufficient, thanks.


Key: A "YES" beside your name means you're on the update list.
     (sent) means you have the latest version

    2600fish
    2600Gaming
    Al_Nafuur
YES alex_79 (sent)
    amidarman
    Arcadia2600
    Atari7800+
    Bkillar
    BogPanda (sent)
    Bomberman94
YES Bomza (sent)
YES CODEYE (sent)
    Conjurershand
YES Crossbow (sent)
    cubelindo
    cwieland
    D Train
    danreinfeld (sent)
    Darryl1970
    Der_Justy
    devwebcl
    dionoid
    dipppinnn
    Doctor_Scott (sent)
    doug0909
    dravensth
    Ducky
YES EightBitWhit (sent)
    Fierodoug5
    GenXGrownUp
    Giuseppe
YES GlennMain (sent)
    Godzilla
    guppy
    Hjou
    HolmesA8
    hwen
YES imstarryeyed (sent)
    Jason_Atari
    JetmanUK
    Kaboomer
    Kevinmos3
YES killersquirrel (sent)
YES Lazzeri (sent)
    Leepy (sent)
    legeek
    lroby74
YES luminol (sent)
    Marc Oberhäuser
YES markzilla1985 (sent)
    MattelAquarius
YES McCallister (sent)
    mccollumsp
    MGG (sent)
    Miccoli Marco
YES Mike.Littau (sent)
    Mitch.h
    MrZarniwoop
    NISMOPC
    pazuzu72
    philenotfound
YES Philsan (sent)
YES Piotr (sent)
    Poestylr (sent)
    Prizrak
    productof76
    quohog
    radventure
    ramblingdan
    Retro Bliss (sent)
    RetroDean1966 (sent)
    Retro Jason24
YES RickR (sent)
YES scumation (sent)
    silvio mogno
    Sockboy
YES somebooks (sent)
    songbird
YES SpiceWare (sent)
    spspspsp
YES sramirez2008 (sent)
    StLouisRod
    The_Road_Warrior
YES TheRingBearer (sent)
    tlindner (sent)
YES TreatBucket
    TrekMD
    Trifalger
YES UberArcade (sent)
    Vagrant
    Willbert
YES Xkenx70 (sent)
    yurgle
YES Zack (sent)
    ziggystar12