Bit Expander

You don't need pointers, if you put the bits entries in a vector. So for example, if you have 4 bits on in the first entry for letters A, C, F and G, you'll know that the next entries are coming immediately afterwards, first for A then for C, etc. It means you'll need to go through uninteresting data, just to find the relevant part without the ability to efficiently skip ahead, but it's much more compact

I believe you could use a bitwise trie with 26 bits per entry. So the first 26 bits represent the first letter (e.g. if the first letter is A the first bit will be on) Then, for every case of 1 bit, you have another 26 bit entry to represent the possible second letters. This means you can represent all possible 2 letter words in maximum of 27 entries (each entry just over three bytes). However, not all combinations are valid words, it will quickly reduce. In the two letter example, if you have 10 real words, you'll need at worst 11 entries, and that's if none of the words start with the same letter. So for 5 letters, I believe you'd be able to encode all valid words in about 4KB. The challenge is reading this efficiently...

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

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

VERY impressive, and fast! How did you decide on the optimal base colors, order of replacement and usage of SAX? I found it hard to define an algorithm, as I kept finding optimizations when trying to encode by hand...

I made another attempt to maximize the ability of the 2600 to display a picture. My current "achievement" is a picture 19x192 in resolution (single frame) with each line having 13 different colors. The hard part is to take an image and encode it optimally for the display, I'd appreciate any help... What I basically do is use the sta, stx, sty, sax... type of speed-code mentioned earlier, but I added 3 loads that allow changing base colors and color "mixes" (SAX). The 3 loads are "masked" by bars of P0, P1 and PF color (P0, P1 and BL) that contribute 3 independant colors as well. I attached a randomized data screenshot +source. 16bitmap.zip

Thought of that, easier that a RAM kernel and all. The problem is the ROM size, assuming we are limiting the discussion to 4KB ROMs. Say I want to do what you suggest, I get 4 bytes per color setting (LDA + STA) times 11 colors per line => 44 bytes. I want the high resolution: 44 bytes times 192 lines => 8448 bytes I want to interleave 2 frames: 8448 times 2 => 16896 bytes , clearly a NO GO. Even going for 1/2 the resolution, still too much ROM. This is why I'm suggesting a table with tight, self-modifying code.

I have a different proposal, would be happy to hear your thoughts. The idea is to create a RAM kernel (code attached) that can display 8 colors per line for 192 lines in a frame (from a table, not speed code). Then, do the same for the next frame, but shift the picture 1/2 a color column width (around 10 color clocks) horizontally. This will gain us two advantages: 1. Apparent 16 columns x 192 lines resolution 2. Ability to mix colors together, achieving 8-9 bits of color (simulated) The main challenge, from my perspective, is to correctly convert a full color RGB picture in 16x192 resolution into an optimal set of colors for the 2 frames. Nothing to see in the picture yet, since I did not do a proper conversion. Any thoughts? Adam 9bitmap.zip