Arkagis Revolution developer Sik has been teasing a new game for the Genesis/Mega Drive over the last few months, and it appears to be a walking mech simulator!
The yet-to-be-named game gives the illusion of piloting a mech in a “3D” space complete with virtual hands operating a simulated control panel.
I'm adding a setting to toggle "smooth rotation" (which is a hack involving scroll) in case it caused motion sickness but I'm starting to think that it's doing the opposite of what's intended… (note: I'm toggling it with a button here). #MegaDrive #homebrew pic.twitter.com/lR57d03RKX
— Arkagis (@arkagis) February 15, 2021
The first person engine uses voxels to simulate a 3D space in addition to other programming tricks to create a smooth scrolling experience.
For more development information, read below. (Credit to developer page)
How does it work?
Warning: heavy use of tech jargon below, knowledge of 68000 assembly recommended.
-
- Uses a basic preemptive multitasking scheduler with a foreground and a background task, each with their own registers and stack. The foreground task is called every frame, the background task takes up whatever CPU time is left. This allows the demo to respond to controller input at 60 FPS while the voxel rendering can take as long as it needs.
- Exploits the same “mode 7” landscape trick used in Gasega68k’s 16KB demos, where coordinates are stored in bits 6-0 and 14-8 of the address offset (i.e. excluding the MSB of each byte). This requires a 128×128 (16KB) heightmap spread over 32KB (the gaps can be reused for other purposes).
X coordinate needs to be byte-swapped due to the above trick, so it uses the addx instruction in order to carry over from the fractional part to the integer part (carry is delayed by one step but it’s easy to notice). - Abuses the 68000’s attempts to keep the stack “aligned” in order to write to every other byte while painting. The 68000 will make the stack advance by two bytes even when doing a byte-sized move.
- Only half of the viewport is drawn, then mirrored vertically. This is what achieves the cave-like appareance of the room.
- Look-up tables are used to determine the direction in which the rays scan the heightmap, to project 3D heights to 2D space, and to compute the color of each voxel. The fog is achieved by changing the colormap at certain steps of each ray.
- Both plane A and plane B are “interleaved” in order to double the size of the pixels vertically for cheap (raster effects would eat up too much CPU time). This requires the use of sprites and window plane to make any sort of HUD.
Some more interesting notes not made obvious by the tech demo: - The viewport is mirrored, but the upper and lower halves are assigned different palettes, so in theory the ceiling and floor can be given different colors by making them different in each palette. This can be used e.g. to make hazards that only appear on the floor.
- There can be up to 128 unique combinations of height and color for a voxel. The demo is only using 16 of the possible values.
Unfortunately, there isn’t much more to share at this time, but with the impressive port of DOOM to the Genesis / Mega Drive, (although that one seems that it will need a Mega Everdrive Pro, this game likely won’t) it looks like fans of 16-bit First Person “3D” games will have some impressive new titles to play in their libraries.
For game development updates, follow Arkagis on Twitter: https://twitter.com/arkagis
