How is a 3D game like Ant Attack implemented?

[Gilberto]

Slightly off topic but strongly related to the artistic techniques employed, I wanted to add this little study me and a friend did to better understand the graphics generation in isometric landscapes.

Well, it's in spanish but it tries to explain graphically; in fact it helped a lot to advance an isometric engine, and moreover, the related inner workings when a limited system is involved.

[RMartins]

And Alien Evolution has a similar style, not sure if it uses the same technique: https://spectrumcomputing.co.uk/index.php?cat=96&id=149

Alien Evolution was "reverse engineered" from Ant Attack disassembly.
Rui Tito (one of the authors) informally confirmed this in an interview, at the ZX Spectrum Museum in Portugal.

[Tommo]

Slightly off topic but strongly related to the artistic techniques employed, I wanted to add this little study me and a friend did to better understand the graphics generation in isometric landscapes.

Well, it's in spanish but it tries to explain graphically; in fact it helped a lot to advance an isometric engine, and moreover, the related inner workings when a limited system is involved.

Alas I can't read Spanish, but to the extent that it's relevant, in each 8x4 block where your document appears to discuss the disadvantages of allocating pixels like:

Code: Select all

MM......
MMMM....
MMMMMM..
MMMMMMMM

I instead used:

Code: Select all

M.......
MMM.....
MMMMM...
MMMMMMM.

Taking the line of The former isn't rotationally symmetrical; the clue is that it doesn't even divide the pixels 50:50 — of 32 pixels total it allocates 20 to the lower portion and only 12 to the upper. The latter is rotationally symmetrical and allocated pixels 50:50, 16 to the top triangle and 16 to the bottom.

As a full diamond it produces:

Code: Select all

.......MM.......
.....MMMMMM.....
...MMMMMMMMMM...
.MMMMMMMMMMMMMM.
.MMMMMMMMMMMMMM.
...MMMMMMMMMM...
.....MMMMMM.....
.......MM.......

Which produces a pattern that tesselates properly across the screen while aligning with the character squares. E.g. putting four of those together into a 32x16 area:

Code: Select all

...............++...............
.............++++++.............
...........++++++++++...........
.........++++++++++++++.........
.......//++++++++++++++__.......
.....//////++++++++++______.....
...//////////++++++__________...
.//////////////++______________.
.//////////////||______________.
...//////////||||||__________...
.....//////||||||||||______.....
.......//||||||||||||||__.......
.........||||||||||||||.........
...........||||||||||...........
.............||||||.............
...............||...............

[Joefish]

In case anyone missed it last time around, you CAN do this in colour on a Spectrum - you just need to double the vertical attribute resolution, that's all!

This editor / demo uses larger blocks but if you look closely you'll see they scroll in 8x4 pixel steps, the same as needed for the blocks in Ant Attack. So you could do colour blocks at that resolution, I just like the chunkier look of Knight Lore / Head-Over-Heels.


https://spectrumcomputing.co.uk/entry/3 ... nts_Attack

[AndyC]

So, you're making colour Ant Attack this weekend then?

[Matt_B]

While you can pull off the landscapes in colour easily enough, you're probably going to have a few issues when you add sprites.

[Joefish]

While you can pull off the landscapes in colour easily enough, you're probably going to have a few issues when you add sprites.

I think we get enough of that sort of thing from Ͼ64 owners thank you very much...

[Art]

This coloured system could work for some types of puzzle games. In any case, it looks very nice.

[Tommo]

In case anyone missed it last time around, you CAN do this in colour on a Spectrum - you just need to double the vertical attribute resolution, that's all!

I had a quick think about this with the way that my code works, and here's a neat thing: if you either used 8x16-sized steps, or restricted yourself to a 128kb machine for 4x8, you could do full colour by writing to the attributes only. No changes to the actual frame buffer are necessary until you introduce sprites.

Given the corresponding implied reduction in map complexity, I'd be confident of getting into the 40s in terms of FPS.

The only disadvantage compared to the picture posted is that the map would still be 2x2x2 cubes, not 2x2x1 cuboids. So vertical placement would be a bit less relaxed.

[Joefish]

Zamok looks fine with sprites, where the floor tile edges just switch to all-PAPER. Particularly where the sprites fill the full width of the character at the join of two colours. And with double the attribute resolution there would be even less blocking. Just a case of not using up all the colours to draw the blocks and save some for the sprites. Either use darker colours for the blocks, or put in a light background so the sprites can be black INK.

[Joefish]

I had a quick think about this with the way that my code works, and here's a neat thing: if you either used 8x16-sized steps, or restricted yourself to a 128kb machine for 4x8, you could do full colour by writing to the attributes only. No changes to the actual frame buffer are necessary until you introduce sprites.

This does only update the attributes. The pixel screen is just a grid full of triangles.



If you press the E key and move the edit cursor around, from it's on/off flicker you can get an idea of the refresh rate; it's pretty quick. But it puts the attributes in a buffer then writes them to the screen synched to the raster, to get the 8x4 attributes. It could be doing 8x2 attributes but that's rather pointless in this case.

Thing is, your 128K routine either has less than half of the running time it had before while the CPU manages the multicolour effect, or you need to write your routine so that it runs in EXACTLY 912 CPU-clock-tick time-slices with no flexibility, and avoids writing to the attribute memory during 128 of every 228 clock cycles to avoid memory contention delays, so that it can swap between the two screen banks bang-on time to get the extra attribute resolution. That would be impressive.

[Tommo]

Thing is, your 128K routine either has less than half of the running time it had before while the CPU manages the multicolour effect, or you need to write your routine so that it runs in EXACTLY 912 CPU-clock-tick time-slices with no flexibility, and avoids writing to the attribute memory during 128 of every 228 clock cycles to avoid memory contention delays, so that it can swap between the two screen banks bang-on time to get the extra attribute resolution. That would be impressive.

And, for the avoidance of doubt, completely beyond me.

I might see how 2x2x2-sized blocks as expressed with regular non-raster-raced attributes and therefore limited to 8x16-step scrolls looks and feels in my little version of an isometric map, but just as a curiosity move. I'm still not doing anything other than demonstrating that a particular algorithmic approach is one of those that is viable.

[Joefish]

restricted yourself to a 128kb machine for 4x8, you could do full colour by writing to the attributes only.

How were you planning on achieving 8x4 pixel precision with your colour-setting function on a 128K machine? The attributes are still 8x8.

[Matt_B]

You could do it by flipping the screen every eight scanlines so the attributes are switched mid-character row.

It's still a bit of a PITA on the timing side, but you don't have to change any attributes so there's consequently room for a lot more useful processing in the wait loops.

[Joefish]

It's still a bit of a PITA on the timing side

Given code that contains an awful lot of conditional checks, and that the results of it ARE attributes so they WILL be written to contended memory, this could well be in consideration for understatement of the year!

[AndyC]

On a 128 surely you'd have enough RAM spare to just preprocess the entire map into a series of coloured triangles in one go? Possibly even for all four viewpoints. Then everything just becomes a 2D render.

[Joefish]

On a 128 surely you'd have enough RAM spare to just preprocess the entire map into a series of coloured triangles in one go? Possibly even for all four viewpoints. Then everything just becomes a 2D render.

Interesting question, and a good point. Assuming you can limit the map to just the squares you need, each byte of the original map occupies four triangles on the new map, which averages out to two 8x4 attribute bytes. So the map now takes up 32K plus a little more for the piles of blocks that stick up off the top of the floorplan. If you want a rectangular map version rather than a trimmed diamond shape then it's 1.4 times that, so maybe a full 48K all-in. So yes, you could pre-process the entire map into 2 x Attributes, and from two different angles as well, but not the whole thing from four angles.

But you could certainly repaint the attribute field fast enough from a whole-map buffer for the fastest possible 50fps update. And since that's a fairly straightforward loop operation, readily keep in step with a raster-timed page-flipping routine to double the attribute resolution. You could also use a store/draw/repair sprite routine to add sprites too.

Of course, then it doesn't matter what algorithm you use to generate the background, as it'd all happen in slow time before the game started. It would be handy to have the original column-bit-map data to hand too, for collision detection for your sprites. And while you're at it, a depth-map of the coloured-in map for knowing when to render your sprites in front or behind any visible block.

[Tommo]

restricted yourself to a 128kb machine for 4x8, you could do full colour by writing to the attributes only.

How were you planning on achieving 8x4 pixel precision with your colour-setting function on a 128K machine? The attributes are still 8x8.

I was at error — I neglected to think about multiway scrolling. I'd need a machine with four screen buffers, not two.

But otherwise, the basic observation is that you don't need to race the raster at all if you're using suitably-aligned 2x2x2 blocks rather than the 2x2x1 of the engine depicted. You can get then get the 8x16 scrolling steps by just altering attributes. So I'm still imagining pretty much essentially the Ant Attack map, but scaled up to 200%.

My error was then thinking that two different versions of the pixel part of that screen would give 4x8 steps, and from there I started talking about the 128k. Clearly I'm an idiot. If scrolling is two-dimensional then you need four.

So: I spoke without sufficient thought, and therefore said something that isn't valid.

[Joefish]

Well, as we've said, you can do it by doubling the attributes, but you need to devote half the CPU time every TV frame to counting clock cycles and swapping between the two screen banks / buffers at the right moment to get that effect.

Or spend an even bigger chunk of your own time to chop your code up into countable precise time slices so it can run in the 'wait-for-it...' phases of the raster-chasing routine.

If you don't have the doubled-up attributes then when you move by four pixels vertically, you get a situation where you might have the right-hand tip of the top surface of a block, the side wall of the block, and the background colour, all in a single character space, and you can't cope with those three different colours. You need to keep it such that all four corners of the top surface of a block align to the corners of attribute squares. You can't have a corner landing half-way up an attribute square.

The game Snodgits had an isometric environment that scrolled in 16x8 pixel steps. It used enormously chunky characters to try and disguise the fact that it wasn't the smoothest of games to watch:

https://www.youtube.com/watch?v=_fUUUYPks1g

And the counter-productive problem is, because it moves in such huge jumps, you don't actually want a very high frame rate, or you'll be moving across the map so fast you'll never be able to keep track of where you are!

If it's any consolation, the C64 version of that game does just the same, and is an eternal embarrassment to that community, accustomed as they are to smooth hardware scrolling and clash-free (though small) hardware sprites. Though if you really want to see some poor choices, just look at the colours on the Amstrad version!

[Joefish]

But what you have hit on, is you should be able to do the chunky style of Knight Lore quite happily in full coloured blocks. Maybe even a push-scroll type of arrangement to move in big jumps when you get near the screen edge, if you still want a big map rather than individual rooms. But no-one did.

Sounds like an ideal opportunity. If not Knight Lore, surely someone could at least knock out a half-decent Congo Bongo? It's practically a 'Sabre-Man' game anyway!

But you can have the source code for my multicolour function for free if you want. It's in the ZIP file offered for download in this thread:
viewtopic.php?f=9&t=2286