While digging through my old Amiga stuff recently I came across the work-in-progress of AMRWolf, a Wolfenstein3D-style raycasting engine I worked on a long time ago.  it was written in a combination of AMOSPro and assembly language, with the assembly routines inserted into AMOS procedures.

The display was a “Copper Chunky” screen, which gives a low-resolution 128 x 53 pixel 12-bit true-colour display, but has the advantage of being very fast.

I uploaded an early version to Aminet many years ago, but the project did progress a little further since then, before I dropped it and moved onto other things.

Compared with the original demo released in 1996, this version has a couple of extra levels, a map editor and comes with full source.  (Note, however, that the source is not well organised, and I’ve completely lost track of which assembly routine goes in which procedure, so if anyone wants to hack on this, it’s going to be a bit of a puzzle!)

In order to run the game from Within AMOSPro, you’ll need the GameSupport extension in slot 23, which is mentioned in another post, and can also be found on Aminet under /dev/amos.

Download: Latest version of AMRWolf, with complete source and map editor.

Back in 1985 when the Amiga was first released, the HAM (Hold And Modify) screenmode was revolutionary. It allowed 4096 colours to be displayed simultaneously, meaning near true-colour images could be displayed while only using the amount of memory that a normal 64-colour screen would use.

HAM does have its disadvantages, though – while a regular bitplane image can be faded out very easily by simply fading the palette, this trick doesn’t work for HAM images.

Fading out a HAM image can be done, however, using the Blitter.

This AMOSPro program uses some “evil” trickery to fade a HAM image to black, using the Screen Copy command with blitter modes, peeks and pokes to shuffle bitplanes around between screens, and what amounts to a ShadeBOB routine over the entire screen.

Step by step, the theory of operation is something like this:

• Logical OR the two control planes together to make a mask plane.  This mask plane is “0” wherever pixels use the base palette, and “1” wherever a direct R, G or B level is being specified.
• Use the mask plane to perform binary subtraction on the four data planes, using another spare plane to hold carry data.
• Check for overflow, and zero the image wherever overflow has occurred.

This is done simultaneously with fading out the palette, and the end result is quite a nice fade-out of a HAM image.

Download: Compiled HAM fading slideshow, including AMOSPro source code