Lunchtime Atic Atac

Snap taken using “Retrotechys Speccy Graphics Viewer/Editor”

After a few boring lunchtimes at work with nothing to do, I started tinkering around with a ZX Spectrum .sna file of Atic Atac, the aim being to be able to read some sensible data from the file and display some atic atac screens, using Blitz3D.


Prep Work:

  • firstly I obtained a 48kB .sna file of Atic Atac. I figured that as I have paid for the game twice in my life (ZX Spectrum and Xbox One Rare Replay), I was entitled to peep at the code.
  • I downloaded a decent free Hex Editor.
  • I had a good look at Icemarks Atic Atac data format page, as this gives a lot of guidance on specific areas of the data that pertain to drawing the screen.
  • I added 16kB of padding onto the front of the .sna file so that Icemarks memory offsets matched the file that I had.


Dev Program 1 – Find enough data to draw the outline of each type of room.

Atic Atac has 13 different room types, including the last room when you escape the haunted house, and the room when you are falling down a trap door.

The actual X and Y points for drawing each room are stored in two sections for each type room. The first part lists each X and Y co-ordinate for every line required to draw the room and the second part is a list of points so that these X and Y co-ordinates can be connected using lines to draw the room.


The First part of data looks like –  186,42,186,186,42,186,42,42. It is read as Point 1 X co-ord = 186, Point 1 Y co-ord = 42, Point 2 X co-ord =186, Point 2 Y co-ord=186 and so on.

The second part of the data looks like – 1,2,255,3,2,4,255,255. This i read as “Go to the X and Y co-ords of point 1 and draw a line to the X and Y co-ords of point 2. Then 255 means end of that draw function. Next go to the X and Y co-ords of Point 3 and draw a line to the X and Y co-ords of point 2, then go back to the X and Y co-ords of point 3 and draw a line to the X and Y co-ords of point 4.” Then two 255’s in a row means end of drawing that room.

Dev Prog 1 Input:

Type in which type of room you want to draw (0 to 12) and what scale factor you want to use (1 to 4, 1 being original size)

Dev Prog 1 Output:

Room Type 2, Scale Factor 4

Room Type 1, Scale Factor 3

It all looks pretty good with the exception of room type 7 which has an X co-ordinate error on one of the draw points. After some looking it turns out that room type 7, a sideways stairway, isn’t used in the game so the error wouldn’t ever have shown up.


Dev Program 2 – Draw the outline of each game room with room attributes.

Rather than just calling up a type of room, I wanted to be able to call up a room number from the game itself and have it display the correct type of room in the correct colour.

The Atic Atac .sna has a table in it with each room listed as room colour and type, so the data looks like 66,3,68,0,64,5 and is read as:

  • Room 0, Colour 66, Room Type 3
  • Room 1, Colour 68, Room Type 0
  • Room 2, Colour 64, Room Type 5

The room numbered order itself is a bit haphazard to say the least. Room 0 is the start screen, Room 1 is the screen above, Room 2 is screen left of that… and so on through the various rooms/floors.

Dev Prog 2 Input:

Type in which room from the game you want to draw (0 to 148) and what scale factor you want to use (1 to 4, 1 being original size)

Dev Prog 2 Output:

Game room 33, Scale Factor 4

Game room 69, Scale Factor 4


Dev Program 3 – Add Room objects to the each room rendered.

The game has an object table. This lists all of the objects in the game along with varous object attributes including the type of object the room number its in, the X and Y position it should be drawn in the room and its orientation.

This object table doesn’t seem to be in any specific order so if you walk into room two, you have to scan the entire table to list what objects are in room 2.

Once you have confirmed that the object belongs in the room that you’re in and you have  the object type, you can then jump to the offset of that specific object which contains the X width of the object in bytes, the Y height of the object in pixel rows and then the bitmap of the object itself, and start to draw it in the correct X, Y and orientation.

Dev Prog 3 Input:

Type in which room from the game you want to draw (0 to 148) and what scale factor you want to use (1 to 4, 1 being original size)

Dev Prog 3 Output:

Game Room 0, Scale Factor 4

Game Room 3, Scale Factor 4

Game Room 6, Scale Factor 4

So with all of this dev work done… “WHAT IS IT GOOD FOR… ABSOLUTELY NOTHING!!” but fun nerdiness all the same.



3D Isometric game engine in Blitz 3D – Building Blocks and Film Sets


So previously I had entertained a few concepts for the isometric game engine I was working on, however everything started to look a bit flat.

I decided to make the move from building worlds with flat cube tiles to building out of blocks to make things a bit more 3D.


I made a simple cube block with 45 degree bevelled edges and corners. Each surface had its own set of vertices and its own surface to allow for multiple textures. I then stretched for a long block and stretched and rotated for a tall block. I then designed a quick routine to add the blocks randomly to a wall and allow for spaces. It was a disaster… The amount of vertex’s on screen came in at around 12000+ and the FPS slowed down to 30. Also the bevels in the stretched blocks weren’t at 45 degrees any more and didn’t match the cubes in the wall.

I quickly realised that in an isometric world, you only see a max of 3 sides of the block at any one time so by making six blocks with some surfaces missing and using the correct one for correct circumstance I managed to reduce the vertex count to less than a third, even with the floor being 3D bevelled cubes.

The result, from the ISO camera view, all looks good, 3D and solid. But if you walk around to the back of the wall, like every good film set you find out that its just a plywood mock-up.


Again, planting the camera in a standard Isometric position gives you a stretched curved effect meaning that some parts of the screen are out of shot, so moving the camera a long way from shot and using the zoom function flattens out the image to a more regular looking isometric view.



3D Isometric game engine in Blitz 3D – Generating Shadows

Whilst Blitz3D has a number of easy to use lighting effects, it lacks any built in shadow functionality.

An easy way to add a suggestion of a shadow is to use sprite shadows, a simple dark coloured sprite with some alpha set will cast a reasonable shadow effect.

Also with a bit of geometric knowhow, you can have shadows across the floor and up the walls.


In a room as in the picture above, if you have a single light source in the room, you would need to set up three potential shadows:

Shadow 1 – stretches across the floor between that man and the wall at the angle the man is to the flame. Dynamics for the shadow are positioning the centre of the sprite half way between the man and the wall at the flame to man angle, stretching it the correct length so that it reaches from man to wall and finally rotating it as the man moves in relation to the flame.

Shadow 2 – is on the east wall. Dynamics for this shadow are positioning it at the correct position on the wall so that its in line with the angle between flame and man and stretching it to the correct height so that its in line with the flame height to man height.

Shadow 3 – is on the north wall. Essentially its the same as shadow 2. Its far easier to have a north and east shadow so that when you reach the corner of the room, east shadow disappears into north wall as north wall shadow emerges out of east wall creating a nice shadow round the corner effect.


To add some atmosphere, animate the flame on the candle and in time with the animation:  increase/decrease the light range on the candle light to simulate some flame flicker, adjust your shadow angle by a couple of degrees left and right and slightly decrease/increase the alpha of the shadows.


The general lighting on all of the rooms above is biased towards blue. In order to set the general background lighting to a moonlight style colour, you need to up the blue in a big way. If you turn all of the lights off, you get a very heavy red/green biased low ambient light. To remove the red/green biasing you add blue light, but then you end up with a blue room…. so you up red green and blue but make blue double what red and green is to try and even the ambient light biasing out.

BBC Micro Screen Viewer

I’ve Finally got my BBC Micro screen viewer working…mostly…ish. Whilst it’s not really massively useful to anyone, it was a brain exercise for me to understand how the Acorn Beeb got the 1s and 0s from the memory to the screen and made an interesting lunchtime project.


I started with a Beebem .uef snapshot/memory dump of BBC Micro game and then I read lots of webpages about where the screen info is stored in the Beebs memory.


Next I knocked up a simple proof of concept black and white bit viewer where you could manipulate the column width and row height of all of the 1’s and 0’s in the Beebs 32kb memory dump with the .uef header still attached.
I stepped through the memory until I found an area with something that looked like a black and white distorted version of the screen of the game that I’d taken the snapshot of.


I then did a lot of reading up on the Beebs memory map and on the different screen modes the Beeb had.
After finding out that the screen mode that the Beeb is running the game in is stored in the memory and which memory location it was, I made several different snaps of beebem in the same screen modes.
I wrote a program to step through each byte and list all of the locations that contained the same number as the screen mode the snapshot was in. Comparing this with the other snaps in the same mode, I was able to narrow the screen mode location down to one byte. As I knew where this byte was in the Beebs memory, I was able to then trim off the UEF header and leave just the 32kb of Beeb memory.


Whilst doing my research, I saw that the Beebs memory contained a lot of data in various locations about the screen properties and reading these properties from the snapshot, I was able to get a screen that looks spot on using a lot of different game snapshots.



There are still some issues with this program though.

1. It wont do multi mode displays.
2. Despite the screen start location being clear in the memory, the actual screen doesn’t always start here and sometimes some manual bit/byte stepping is required to get the screen correct.

Some very clever programmers of the day used some neat tricks to make a decent looking display fit into a smaller amount of memory so that the saved memory could be used for more game code and learning these tricks is taking a while….
e.g. the atic atac title screen displayed above uses double width pixels, so that you get a full screen full colour display but only use half the memory normally required. It was easy to spot this as normally a character is 8×8 pixels, 64 in total. You can calculate this from Beeb memory locations using “bytes per character” x “pixels per byte(+1)”. If the pixels are normal this will come out at 64. In the case above, it comes out as 32 and means that the pixels are stretched.
Ultimate used the stretched pixel method in several of their title screens however sometimes its easy to spot with the method above, other times a different method has been used to stretch them, one that’s not so obvious…

Anyway, good nerdy fun all the same and an interesting lil lunchtime coding project. Thats BBC Micro and ZX Spectrum memory to screen decodes done. Next…. Might take a stab at the Commodore 64…..

3D Isometric game engine in Blitz 3D

Having not written any code of any great interest in recent months, or writing code for games that start to suck… I have gone back to an old idea of writing a 3D Isometric game engine in Blitz3D. The basic idea was for anyone to be able to write a simple text file and provide some specifically names textures and sprites and have an Isometric game running. Large task!


Initially I experimented with a tiled floor drawn at an Isometric angle, as in all floor times rotated and span to provide a correct isometric projection.


The first issue was flattening the screen. Using Blitz 3D to view the floor, you get a curved mirror perspective style view of the screen which doesn’t look particularly isometric. This can be flattened out by moving the view camera a long distance off, and then using the camera zoom function to zoom back in to what you are viewing. This flattens the screen out nicely. I then did a bit of maths to work out tile separation and fiddled with the camera position and zoom and finally superimposed a picture from Knightlore over the top to see if the angles for the Iso view were good.




Looked pretty good angle wise when compared to the original legend of an Iso game!


Almost immediately after this I had a “Slaps Head” moment… Why am I individually twisting each tile and making things thoroughly difficult when I can just render in standard 3D box shape and move camera to an isometric angle…..Would make things a shit load easier….


So I changed it to just render straight lines of tiles in a square. Then I read up on the maths of Isometric projection to get camera angle spot on, and then did the usual camera at a distance and zoom in to flatten out. This should be a true Isometric view, but with the Knightlore slide superimposed again, the angles of the floor didn’t seem to match up…


This could be due to Blitz3Ds render engine, or it could be that Knightlore wasn’t 100% spot on Isometric projection. Still the results are a bit better. I threw in some wall bricks too just for effect.




As you can see, the two angled lines on the Knightlore screen are at a different angle to my Isometric box, despite my camera being positioned mathematically correct for iso projection.


After a bit of messing with the camera, I decided that the true Isometric view was a bit sheer and adjusted to a not quite Isometric projection with a shallower height and viewing angle that matches the Knightlore Isometric projection.




Now I could get on to some more important stuff…


Firstly I borrowed Werewulf from Knightlore as a test character for the game engine.
Next I added some data lines to allow options to be selected in the game. This will eventually become a data file for each game rather than data lines within the game.
One of these is the option for which type of Isometric game you are building. Either a flick screen small room game (Knightlore, treasuretrap, Alien8 etc), an Isometric game with larger scrolling rooms (Escape from Colditz) or a large Isometric adventure in a single large scrolling environment (Gunfright, Nightshade etc).
Choosing this assigns how the camera reacts to the player movement. flick screen small room game has camera fixed to centre of room. Either of the scrolling land games has the camera fixed to the movement of Werewulf.


Pic above is of flick screen small room game. Camera view fixed on centre of screen while the character moves around it.


Pick above is of scrolling environment. Camera moves with the character so that rather than character moving round the room, its more a room moving around the character effect.


Next I tried coming up with some standard effects that can be applied.
First up is Underwater with animated water caustics.


And have done some playing with light effects. Flickery animated candle light for above water castle style shenanigans…



And tried a textured underwater floor rather than a flat one for games like Hydrofool


Will update this post as/when/if the project progresses….

Castle Quest – Micropower – BBC Micro – Remake in Blitz3D

After a while of inactivity, I’ve been tinkering with a 2D in 3D remake of Castle Quest using the now free Blitz3D. It all started when I was playing around with Blitz 3D’s different lighting effects. A flaming wall torch and a brick wall was all it took.


This has been going on for a bit to be honest, but Blitz 3D’s abysmal 3d object collision detection routines really put a stall on it, in that they either work badly or not at all. I even used the full tutorial example program to try and understand my errors, only to find out that that didn’t appear to work properly either. Anyway after some frustration I built my own collision routines and they actually seem to work so can crack on with the game. At this stage have an old vs new screenshot. Will post more if the project continues…





Retrotechy Speccy Graphics Viewer / Editor

I’ve been tinkering with this ZX Spectrum graphics viewer/editor for a while now so I thought it was time to put it up for download. You can find it here.


The last thing that has been added is the TV screen view mode.
Basically you would normally rip graphics by arranging the bits in the file into rows of 8 bits / 16 / 24 / 32 etc. until you find the right width column to display the stored graphics as in the picture below:



You can see that the rows have been adjusted to 24 bits wide and the graphics become evident hidden within the file. When the programmer wants to use the graphics they are written into the display area of the memory in a certain way and they come up on your TV screen.


However the display part of the memory writes the graphics onto the screen in a unique way. If you consider a ZX spectrum with attached TV screen with the top row of pixels displayed being row 0, it will stream the bits linearly from the display area however it will draw on screen row 0, row 8,16,24,32,40,48 and 56. It will then jump back to row 1,9,17,25 etc etc. Once its done 8 rows of 8 pixels depth it then starts on the middle of the screen in the same fashion and then the lower part.


So thats just a monochrome screen of pixels on a background. It then reads the colour info from the attributes part of the speccies memory which follows straight after the display area.


Starting from the top left of the screen, each 8pixel by 8pixel block has a byte of attribute info associated with it that is only relevant for that 8×8 square. This byte of attributes contains Paper colour (background colour), Ink Colour (Pixel Colour), a bright bit and a flasher bit, both of which are either off (0) or on(1).


The speccy actually has a 15 colour pallette, not 8 as I thought. It has black, white, Yellow, Blue, Green, Red, Cyan and Magenta however it can also display all but one of these colours in two different levels of brightness, the exception of course being black. Total of 15 colours.


Each 8×8 square has a single foreground colour, a single background colour and both colours must be either from the bright pallette or the less bright pallette, not one from each.


The flasher bit… is a waste in my opinion. If its set to one then the ink and paper colours in that 8×8 square will swap themselves every half second or so. Personally I think having a bright bit for both the paper and the ink would have been a better use for it.
Using this method you can store a whole screen of coloured graphics in a small amount of memory, leaving more memory for better games. On the other hand you can see where the colour clash (Also named attribute clash for the now obvious reason) that the Speccy was infamous for came from.


Anyway you can now switch the display from bit mode to TV mode:



To be fair, the TV screen mode is probably only really useful to look at title screens Looking at the rest of the Speccy file is likely to show you colourful blocky garbage!

Berzerk PC

Whilst I was messing around with Berzerk 3D, I knocked up a Berzerk port of the original arcade shooter for PC in Blitz Basic.
The robot AI still needs a bit of tweaking as they seem to be avoiding each other / corners of walls.
I think the code needs one last going over, a good clean up and some minor tweaks. But for now it seems good, functional and bug free! (Famous last words…)
Can be downloaded from here.

Berzerk 3D Remake…

Have done some work on a Berzerk 3D remake. I felt that while other remakes were good, they kind of lost the original frantic gameplay somewhat. My goal was to remake without affecting the gameplay.
Unfortunately it’s become a Frankenstein’s Monster mish mash of various ideas that when mixed together just don’t look good or work brilliantly.
It’s not been a completely wasted effort as have learnt a lot about 3D coding and found a lot of new stuff out about Blitz3D and I’ve enjoyed doing the work on it but as a completed game I think that it would suck!
Whilst the maze was fine I had trouble integrating a protagonist that matched to the background.
The idea then changed to having a 3D background but kind of using this as a background and then adding actual game graphics similar to the original over the top.
When this didn’t match up will I tried adding sprites that were more animated than the originals.
However overall 3D berzerk just doesn’t work for me, no matter how it’s tackled it takes too much gameplay away from the source material. The only way to make a decent Berzerk remake is to stick to the source material and sharpen it up some, that means 2D or 2D in 3D.
I will keep what work has been done up for download and anyone interested in the source code give me a shout and I’ll happily share.
There is a runnable version available for download here.