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


Here are the emulator settings I use to help reduce shimmer/ficker.

Gopher


Stella

The forum now has a very basic "Like" option at the bottom left of posts.

Here I'll update, somehow, while keeping privacy, how the building and distribution of the 100 copies is going.

Feel free to add your review and/or impressions here in this thread, or on AtariAge. The latter will get much more of an audience, so I don't really mind if you choose that forum. Please avoid creating new threads if one already exists!

Please report bugs in this thread.
I will fix and distribute new binaries to everyone!

Heads-up on a presentation/review of the demo binary on Zeropage Homebrew's show!
Tue May 21, 2024 | LIVE @ 6PM PT | 9PM ET | 1AM GMT+1Day

Zeropage Homebrew twitch stream

I'll try and update the instructions/manual here.

BOULDER DASH DEMO

There are 3 caves (A,B,C).  Each cave has 5 levels which share a basic "architecture" in that the levels look similar - but have different features (walls, creatures) and different goals.  You may select any cave/level from the menu screen.

This game auto-detects the region in which it is being played.  PAL (actually PAL-60) and NTSC are supported. Your TV must be capable of the 60 Hz frame rate. If you have a multi-mode TV, be sure to select the correct region on your TV for your '2600 so that the colours on the TV are correct.

Controls

Here we go.  Instructions are fairly important to read, as the button is overloaded with several functions during gameplay.

Firstly, it uses a new display system by default - Interleaved ChronoColour (iCC). This is an expansion of ChronoColour, but with rolling colours and much more vivid colours. But it's geared to display on a CRT, and there can be significant flicker problems on many displays. Best adjust the CRT for lower brightness to reduce the "shimmer", and if you can stand further back it makes a big difference, too.  But in any case, iCC can be disabled on the menu by setting "iCC SYSTEM" to "OFF". Me, I like it and use it all the time. But there are reports that it's horrible on LCDs, and some people don't like it at all. On emulators, if you turn up the phosphor blend, that can make it look better.

Boulder Dash

If you're not familiar with it, the basic aim is typically to collect a target number of diamonds before the time runs out. You collect diamonds by walking over them, or "grabbing" them using a direction+button.  Boulders and diamonds will fall if nothing underneath them, or roll off "hard" objects. If a boulder or diamond falls on you, you're dead.  There are other objects like butterflies, fireflies, and an amoeba. Drop boulders on butterflies to turn them into diamonds. Enclose the amoeba so that it can't grow, and it will turn into diamonds.  That's the basic gist of it.
 
INSTRUCTIONS

Switching Views

During gameplay, there are three alternate 'views' into the playing area, each with a different magnification (think: zooming).  These are named NORMAL, MID, and OVERVIEW.  Gameplay starts in NORMAL view. As a point of interest, NORMAL uses 4-pixel wide "characters", MID uses 2-pixel wide, and OVERVIEW uses 1-pixel wide (!!) characters.  To switch between NORMAL and MID views, briefly press/release the fire button. To see the OVERVIEW, double-click the fire-button at any time, and from MID or OVERVIEW press/release or double-click to exit back to NORMAL.  You can fully play the game on NORMAL and MID view.

OVERVIEW has dual-function. Firstly it lets you see the whole cave and plan your attack. But secondly, it acts as a pause mode - the timer is halted when in overview. If you press the joystick it will show PAUSED. Press button to return to NORMAL view and continue play.

Controls

This is a "couch compliant" game. After inserting cartridge and powering on (or running the binary in an emulator), you can veg out on the couch and only need your joystick, from that point on, for all game selection/playing.  Power off/on, rage reset, and toggling parallax require pressing console switches.

The game should auto-detect the console type. That is, it is PAL/NTSC compatible.

CONSOLE SWITCHES
Power OFF/ON = start at copyright screen
RESET (held) (during gameplay) = RAGE QUIT abort/boot to menu red screen of shame
RESET+SELECT (held) (during gameplay) = suicide (alternate: hold button for 10 seconds)

RIGHT DIFFICULTY - toggle parallax

CONTROL ON THE MENU SCREEN:
Up/down = choose menu line
left/right = change selection on currently selected menu line

fire button = start game
  After you start a game, you will see a STATS screen just before each cave is shown.
  This stats screen shows the cave and level in numeric form. An icon-view of the cave is drawn to allow you to get a brief idea of how things are organised and what you need to do.
Underneath the icon view is a small text hint that may or may not be relevant to the level.
 
DURING GAMEPLAY
fire button press/release -> switch between NORMAL/MID views
fire button double-click -> switch to OVERVIEW (pause mode)
in MID and OVERVIEW, fire button press/release returns to NORMAL view
in OVERVIEW, fire button double-clik -> switch to NORMAL view.

fire held ~10 seconds = suicide. (== SELECT+RESET held on console during gameplay)
when about to suicide (by button), player changes to skeleton. You can abort by letting go of button. SELECT+RESET suicide is nearly immediate.
RESET = rage quit

U/D/L/R = move through dirt

push against a boulder L/R to push it (if there's space to push into). Moves player to where boulder was. Hold button when pushing a boulder to push it, but NOT move into where the boulder was

button + direction = grab adjacent dirt or diamond in that direction

after you die...
you can still switch views as described above
U/D/L/R to scroll around and see stuff

"short HOLD" fire -> start next life
^^^^. this appears to confuse most users who DON'T READ THE MANUAL.  Remember, the joystick is overloaded. Fire button press switches to MID view. Fire button HELD --> next life.


SCORE LINE
There are several display modes
1) #diamonds required, and time remaining
When diamond counter reaches 0, it will start counting up to show how many extra diamonds you have.This is the default display. When the time is < 10 seconds, the display will lock to this view, even if you score points.

1a) Lives and time.
Number of extra lives left, and time remaining. Usually shown at start of a level/new life.
 
2) score
This will display briefly when you get points, except if the time is < 10 seconds

SPEEDRUN
In speedrun caves, you do not need to get diamonds. You need to get to the exit ASAP before the timer runs out.

Scoring

A bit haphazard, but basically collect diamonds for points. You are NOT CREDITED with extra diamonds you collect (above the required number) until/unless you successfully complete the cave. At that point there is a count-up of diamonds, time, and if you manage to get ALL diamonds on a level then you are awarded a PERFECT BONUS (and all subsequent scores are multiplied by a score multiplier which is initially 2x, then 3x, etc. for each PERFECT level you achieve).

Extra life is every 500 points. When a 500-point boundary is passed, the background of the screen flash and then sparkle for a few seconds.


Serial Number
Your Boulder Dash binary is encoded with a unique serial number generated when the binary was distributed to you. This is a requirement from BBG Entertainment for release of this version. Please do not copy, distribute, sell or otherwise share the binary with others.

I need a PAL playtester who has a Harmony cart and can take some actual TV screenshots for me.
I have a custom PAL set of palettes that do not look great on the emulators but which are considered good on a PAL TV. I would like an extra set of eyes on this.
Benefit to you - you get an early copy of the binary.
Must be a known-reliable member of the community, TY.  Please PM me.

I am delighted to announce the approval by BBG Entertainment of a limited release of my "Boulder Dash Demo" on the Atari 2600. Those who have been following development of this game in this forum will be aware of the astounding graphics and gameplay that this demo shows is possible on the nearly 50-year-old Atari 2600 platform. This demo runs on all Atari 2600 compatible consoles (for example via the Harmony cart).


I have formal approval to release just 100 copies of the demo (in binary form - you supply the cart, or run on an emulator). A binary that can run on Harmony Cartridge or the Stella and Gopher emulators is provided completely free of charge. Full copyright is asserted/maintained by BBG Entertainment - the binary/demo is free to own/use, but not free to copy/distribute/sell. Each copy is individually serial-numbered, so you will receive a unique binary of the game.

This release consists of a binary image with 3 brand new caves, each with 5 challenging levels

If you would like to request a copy, please send me a personal message via this forum and I will add you to the list and announce the lucky recipients (and distribute binaries) shortly after the official release date of 1 June 2024 8 June 2024. Please note; to be fair to real people, I need to be fairly sure you're a real person - so I'll be prioritising those requests from people who clearly are... who they claim to be. To save myself a ton of work, I will not respond individually until after 8 June - but if you have left your name via PM as directed, then be sure I've seen your request.

This Atari 2600 demo version is published with permission of BBG Entertainment GmbH.

Boulder Dash® is a trademark of BBG Entertainment GmbH, registered in the US, the European Union and other countries. Boulder Dash® 30th Anniversary™, Boulder Dash® Deluxe™, the names and likenesses of Rockford™, Crystal™ and Goldford™ are trademarks of BBG Entertainment GmbH. Boulder Dash® 30th Anniversary™ and Boulder Dash® Deluxe™ Copyright © 1984-2024 BBG Entertainment GmbH. All rights reserved. The original Boulder Dash® was created by Peter Liepa with Chris Gray.

Recently I wrote a circular swipe in/out algorithm, which incrementally increases of decreases a masking circle. This effectively uncovers or covers the visible screen depending on if I "or" or "and" the mask with the background.  That's working fine.

As a bit of an experiment I decided to randomly switch between in/out during the swipe process. And to randomly change the radius.  The effect is shown here - which kinda gives me "kaleidoscope" vibes. With a bit more work and a nice animating background maybe there's a potential demo in that.  I thought I'd record this first version just to put the idea "out there"

Technically, division is not possible in the ARMv4T architecture as used in CDFJ bank-switching, and for the longest time I used lookup tables for simple divisions, or repeated subtract loops. But recently I've realised that it's actually possible to do reasonably accurate, extremely quick division simply by multiplying by the reciprocal.

Say you want to divide by 7.  Now if you wrote "x = y/7" you'd have a big fail.  You'd ALSO have a big fail if you wrote "x = y * 1/7", but for a different reason. The GCC compiler will replace 1/7 with a compile-time-calculated value which will effectively be 0 - as we don't have floating point either (at least, I work in integer arithmetic).  But what we CAN do is "x = y * (0x100/7)" -- and that will result in "x = y * 36" being compiled. Well, that's hardly dividing by 7, right?  It's multiplying by 36.  Yes, but if you look closely... the result will be 256 times bigger than we want (because of the 0x100 in the statement).  So if we then shift right by 8 bits, we'll have the answer.  So the full statement would be "x = (y * (0x100/7) >> 8" and what does that give us?  Yep x/7.  Let's work an example.

y = 12345678
so, x = (12345678 * (256/7)) >> 8
 = (12345678 * 36) / 256
 = 1736110

... which, when multiplied by 7 is definitely NOT 12345678.
It's 12152770. The correct answer should be 1763668.285714285714286... (or 1763668 integer).

SO at first glance it's completely wrong. That's because of our inaccuracy in representing 256/7 as 36, when in fact it's 36.57...

Now there's a bunch of round-offs and truncations that happen, so I twiddle the actual value of (256/7) in several ways to make sure my specific use-case works. I might use "(y * (0x10000/7) >> 16" for extra precision, for example. Since that comes to 9362.28... I might round that to 9363. Depends on circumstances/tests. I could use 37, which would give the result 1784336.

In actual use I tend to use the 0x10000 multiplier, so for the given example, we'd have...

x = 12345678 * ((0x10000/7)) >> 16
 = (12345678 * 9362) >> 16
 = 1763614

(remembering the acutal value 1763668.28...) this is certainly good enough for most uses.
Using 9363 would give 1763802 so it's a bit either-or in terms of which is best.


So there we go - a handy tip for dividing by a known constant value in ARM.
It saves heaps of time and space in Boulder Dash, and I use it a lot.

Because Atari 2600 playfield pixels are an odd aspect ratio, it's sometimes difficult to tell in your paint/editing program what things might actually look like. Fortunately, GIMP can work with non-square pixels. Here's how to set it up to do that.

There are two settings to change - firstly in Image/print size, change the horizontal dpi. I change it so that horizontal is 36 and vertical 72. You need to click the chain link to unlock the two from staying in sync. It's these dpi setting that set the relative pixel aspect size. You won't see any change, yet, though... you need to set the following as well...

Go to View/Dot for Dot and make sure that is NOT selected.  Now your image should be shown in an aspect ratio with pixels twice as wide as high. You can of course change the aspect to your desired preference.

This game looks very challenging and quite suited to implementation using my BD engine.
Maybe I'll have a stab at doing this soon...

https://geometrydash.io/lite

I am interested in releasing a small run of stand-alone hardware boards of the skull demo (as seen on ZPH!).  That is, you plug into your '2600 and let this run in a loop for your next Halloween party or Dungeon Fest. Whatever. A small run of, let's say 20 boards. I think they'll cost me in the order of $15 each, give or take, for manufacture and I'd like to make a few $ on top of that. Then there's postage from Oz.  So realistically it would be about US$25 to-your-door for a standard-size PCB that can be inserted into any combat cart and played on any fully Atari-2600 compatible machine.

Here are a few font images/resources which I've used in the past.

This is 'Glacier Belle' - a 3x10 font I designed for the PlusCart.
The name is an anagram of "clear legible", and this is perhaps my favourite '2600 font. It's particularly nice given the 3-pixel width.



Captain Morgan Spice


Trichotomic-12