3D FPS engine for the 2600

[Bit Expander]

Hi all,

 

I've worked for a while on this personal challenge of making a true 3D engine for the 2600 that can turn into a game in 4KB using only the original HW, no ARM, etc.

 

After many false starts, I believe I identified a good direction. However, I'm finding I need peer review and also cannot commit the required time to finish this engine alone.

 

Instead of letting the bits rot on my HD, I'd like to develop the topic in the thread (and share the code). So that the project may come to fruition.

 

I basically separated the problem of creating a 3D game into game logic and engine (nothing new here), the code contains engine only. I decided on a Portal-based 3D engine where each room on the map may be one or more convex zones with portals connecting them.

 

The engine is further split into 2 parts:

1. Taking level data (ROM) and player position and performing Backface culling, Rotation, Translation, Clipping and finally Projection into RAM

2. Drawing up to 21 color-textured polygons on screen taken from RAM using the playfield (textures are 16x16 with 16 colors under limitations). Note that the display is rotated 90 degrees to allow the colorful textures. Note that 16 colors are allowed in the textures as the engine uses 8 shades to perform Gouraud shading.

 

63 bytes of RAM are used to store the 21 polygons, and this list is being refreshed every other frame (30Hz). The blanking time is fully used by the engine every other frame, and left alone for the game logic otherwise.

 

Information about the level information, RAM storage format, etc. is in the source file. Most math is done using 8 bit fixed point (multiply and divide using fast tables, obviously).

 

There's not much to see if you compile and run it. I need to squash a few bugs to get the basic single zone (simple convex room) to work.

 

Clipping to frustum is not working yet. Entering and exiting Portals also not handled (I need to get a single room working properly first).

 

I'm sure the coding Ninjas on the forum can drastically improve the code, allowing more room for the eventual game.

 

If I see you're interested I could go much deeper to explain and work with you on the different parts.

 

Enjoy!

aMAZE4K.asm

Edited March 9, 2014 by Bit Expander

[+Gemintronic]

For the Luddite could you attach a binary or the command line to use to compile this?

 

UPDATE: Kinda got it to compile with this

 

dasm amaze4k.asm -f3 -v0 -oamaze4k.bin

 

..and putting the macro.h and vcs.h from batariBASIC in the same directory as DASM.

 

The result was a scrambled screen that seemed to react to pressing left or right.

[Bit Expander]

You got it right, the display is messed up as the clipping code is messing the polygon list. This is not ready for compile-and-go.

 

The code needs some loving eyes to help me put things in order, I did make some good progress - Looks inside.

 

Controls:

Left - Turn left

Right - Turn right

Up - Move forward

Dn - Move backward

Btn+Left - Strafe Left

Btn+Right - Strafe Right

Future:

Btn+Up - Fire/Open Door

Btn+Dn - special

[Omegamatrix]

It looks like you got a good handle on things already. TJ might be able to give you more insight (amongst others) since he has done 3D rotation before.

 

 

I did notice in your start-up you are doing LAX 0. This translates to LAX CXM0P. There are a lot of undefined bits in there. It's better just to go with LDX #0, and TXA.

 

 

There is another way to save that byte (LXA #0), but it LXA unstable. Also you should clear decimal mode to be safe.

Edited March 9, 2014 by Omegamatrix

[enthusi]

LXA/LAX ist 'stable' (from the result's point of view) when (and only then afaik) the argument is #00.

$ad

Edited March 10, 2014 by enthusi

[YANDMAN]

wow very exciting, Could we see a dungeon crawler?