3D Landscape Texturing Techniques : Powermonger on Amiga?

While planning a clone in Unity, I’m trying to figure out how exactly the landscape texturing might have been done for Powermonger on the Amiga. I’m assuming the terrain was a heightmap of some kind, but as for the texturing I’m not sure since it doesn’t look to me like there’s any obvious tiling pattern. I have no real experience in this area but I’m wondering how else a game from 1990 could realistically do this.

Here’s a gameplay video:

As you can probably see, there doesn’t seem to be an obvious texture repetition. Could it be that the low resolution just hides repeating tiles because the 3D perspective and rotation etc. distorts the final on-screen result enough? I’m still not convinced of that but maybe it’s that simple.
Could it be using some other more “dynamic” way of coloring the terrain in? Maybe as well as a heightmap, a bitmap designating certain terrain types in certain regions and then it’s somehow procedurally textured semi-randomly? Another thing is that the terrain is clearly animated at times. At 8:22 in the video you can clearly see a grey-ish terrain with lighter grey pixels popping in for some reason.
It’s even more obvious in the PC version (which also is a lot clearer, smoother, and IMO looks more like standard tiles than the Amiga version):

So does this look like a simple system of tiles, or something else? I would be willing to assume it was tiles on the PC, but the Amiga one looks suspect to me. Again, it might just look non-tiled because the resolution is so low… but it bothers me that I can’t say for sure what’s going on. Were there likely many other practical ways of texturing such a landscape back then, or is it probably just a tile grid?

Another issue is how terrain texture is applied; if we look at 8:22 again in the first video, we see a small polygonal pool of water surrounded by a similarly shaped grass patch. Does it look like these regions are exactly covering vertices? I would have thought they looked more high resolution than the landscape heightmap appears to allow, but perhaps I’m wrong and the map has more vertices than it looks like, and the water is applied exactly to certain vertices.
In which case, how does the water work? The water pattern definitely never rotates with the landscape and appears as an animated texture that is otherwise static. I suppose it’s some sort of background texture that is only visible when the landscape is marked as water, which acts as a sort of transparency or mask on the terrain allowing the water to show through?
I assume that back in 1990, they must have used some sort of specific hardware functions of the Amiga to do that, but I guess it would be accurate to say that in the modern day the closest equivalent if you wanted to recreate this would be some sort of shader effect? Probably by displaying some special sort of texture at those pixels via a fragment shader? Does that seem about right?

Also in general I wouldn’t mind knowing more about the kind of techniques they used in 3D (and pseudo 3D) games back then. I wonder are there any good sources for that kind of information? Any links to stuff like that would be welcome too…

I don’t have any real knowledge of what’s going on here, but having played lots of games on my Amiga back in the day (this is late 80’s I think?) I’m gonna give you an educated guess and say there is no way there are any kind of texture based tiles here, at least not in the way that you’re thinking of (textures that are looked up in relation to the UV coordinates or in relation to the location of the vertices of the triangles). I mean, these games are running on machines well before 3D graphics cards, years before wolf3d came and gave us super hacky software-rendered textured 3D walls with the vertical axis of the view plane locked at (0,1,0). If you want to see state of the art real-time 3-d polygonal rendering back then, google up gameplay videos of Starglider 2 (a game I dumped hundreds of hours into). No textures, not even light-direction dependent lighting.

Back to Powermonger: if you pause the video at the right times, you definitely can see repeating patterns in the grass, but note that they repeat in screen space (aligned with x/y pixel rows/columns of the monitor), not with the tiles.

My guess is there are a few repeating textures (noisy texture used for grass/sand/snow, repeating cobblestone pattern, water pattern), that the cobblestone texture is probably a simple one (btw notice that the cobblestone texture does not scale with the landscape - it’s clearly just a repeating screen space texture), but the other ones are probably smooth greyscale gradient textures set up for dithering/color cycling lookup. So like for the noisy grass texture there are actually 16 or 64 greyscale levels, and depending on the brightness or content of the “tile” you color the pixel based on the value of the texture and a threshold value. e.g. If it’s a tile facing the sun you color all the pixels with a texture value>12 bright green and all the texture pixels <12 dark green; if it’s facing away from sun you use a higher threshold value. Same with the snow coverage effect; draw white on all pixels where texture value <N, raise N from 0 to 63.

The water is just a (screen space) color cycling texture because color cycling was all the rage back then :slight_smile:

2 Likes

Hard to see, but I imagine the ‘texture’ is in 2D screenspace. I used a similar technique on the Megadrive.
It’s unlikely they’d be thinking in terms of ‘texture’ like we do today.
Per-pixel texturing was very slow using bitplanes, and a cpu which took longer to shift more than one bit at a time. (although, the fewer colors you used, the faster it was. Maybe 2 colors would have been fast enough?)

1 Like

There’s a little bit of information in Glenn Corpes’ 2001 GDCE presentation Procedural Landscapes

The texturing he mentions there is from the next title Magic Carpet. That had 8 ground textures selected on a per vertex basis for the heightfield + fractal polygonization. So each quad can be a blend of 8 x 8 x 8 x 8 textures (32 x 32 pixels) giving 4096 texture variations. Sounds a bit like Megasplat :slight_smile:

I have seen more information on Powermonger somewhere (I remember hearing the smaller playfield in the Amiga version was for performance), most probably in a Story of Bullfrog / Peter Molyneux type video on youtube.

1 Like

Yes, I was wondering about that. It did seem a bit too advanced for it to be done that way, especially given the lack of textures in 3D Amiga games like Frontier or Stunt Car Racer, but what got me was how you can rotate the map unlike in Populous. That seems like a much more advanced functionality (not to mention not 100% necessary for the gameplay) that made me think the simplest explanation was some kind of “proper” 3D.
Booting up WinUAE now just to check, I can see some grassland that does look kinda repeating. Still, it seems strange to me. Especially since there are so many different levels of rotation, and it’s obviously not isometric either, in that the landscape clearly foreshortens into the distance, unlike something like Populous.

So does that mean the tiles themselves are likely just a set of 2D sprites arranged very specifically to make it look like it’s 3D? In other words, just like Populous only with a more realistic pseudo-3D effect because of the foreshortening etc.?
If so, it makes it seem like a lot of work for little benefit when you take into account how smooth the rotation is and how complicated it must be to make 2D tiles rearrange themselves like that. Seems like they’d have to create a very high amount of variations for the tiles when you take into account the different rotations and height variations, not to mention the zoom levels. But I guess the novelty factor of looking 3D could have made it worth it at the time…
Really seems impressive and complex if it’s all just 2D sprites.

How were those kind of racing games done anyway, roughly speaking? Going off on a tangent, but I’ve often wondered about the likes of the Lotus games or Road Rash. There must be some kind of term to describe that style? Know of any sources to hand that describe the general process?
The best I can figure is that obviously the car is basically static, then the track is somehow being generated I assume in “slices” based on some sort of map data. A good example is this video of Lotus 2:

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

The track can go left, right, or up and down. Also there are signs and other features etc. Would it be done by something like this:

  • Store the track in a data structure that we could at least imagine as a bitmap image for the sake of convenience, where each row of pixels represented a “slice” of the track.
  • The track would take up a certain amount of the screen vertically, maybe up to half the screen’s height, how much it actually took up at any one time would depend on the track layout.
  • As you drive along, the game would read each row of the bitmap, and so draw (as well as detect collisions etc.) a certain vertical amount of track onto the screen based on that row.
  • If you were going downhill like in Lotus 2 (could be represented by a certain color in a bitmap image), you would draw more rows ahead of the current position (as well as alter their vertical screen position) in the bitmap onto the screen as track to approximate the perspective, and draw fewer if you happen to be on top of a hill.
  • Signs, streetlights etc. would be represented by certain colors on the side of the road, so it might look like:
    GGSRRRRRSGG
    GGGSRRRRRSG
    GGGGSRRRRRS
    To represent a road going through grass with streetlights at its side. A sloped road might have a different symbol to R, which could represent a level road.
    Am I thinking along the right lines?

Magic Carpet, nice. That’s another game that interests me. Way ahead of its time when you think about it, and it has that weird low-res look of the time that gives it an other-worldly feel. I’ll definitely watch that.
Will try to find that Powermonger video too, could be interesting.

No, I’m sure the actual vertices are 3D transformed - I even wrote a 3D solid-polygon renderer myself in BASIC in ~1990ish that would run at like ~1 frame per second with “way more” vertices than this. Here I think there are only 9x9 verts, so just 81 verts that it has to transform. So transforming the pixels and then rasterizing the polys was doable, but the 3D texturing was not, so I think they are just cheating and filling it the polys with dither textures based on terrain and season and light direction, and that texture lookup is simply done in screen space. Indeed, you can see the texture tiles super clearly when you’re looking at the underside of the map (because there’s no variation in it because it’s not changing with light direction or terrain type):

3152167--239603--pm04.jpg

but it’s also visible in lots of places (but harder to see unless there’s a stretch of identically terrained and oriented tiles):

3152167--239604--pm02.jpg

Note that these tiling patterns are in screen space. In the second video you posted (from the PC version), if you watch from 6:05 to 6:30 roughly, there are a whole bunch of really obvious tiling patterns in the grass. Even when the map rotates you can see some of those patterns (the dark vertical lines are the easiest to spot) flickering on and off, but clearly just staying in screen space.

But basically I think they have a “pretty good” set of randomish looking dither textures, and most of the time it’s hard to see the repetition because lots of things are breaking it up (a tile pointing towards or away from the light will be darker or brighter and simply be reading a completely different texture, for example).

That Megadrive game I linked is a normal filled polygon 3D system, you can view from any angle. As in Powermonger, the ‘texturing’ is faked. Lotus Challenge is completely different, and there are lots of ways to acomplish it. I personally have used both faked and real (ie Matrix multiplied vertices) systems. I’ve got no surviving Amiga / ST code, but I did similar in Flash .
It looks like in Lotus they might have pre-defined blocks defining each corner / hill shape. The road widths don’t appear to change, so that could be a giveaway as to how they do things. That really is a well made game!

The dithers look 1-bit to me. They might have, say, 8 versions of each dither tile pre-stored, each a different shade, so they can quickly simulate light source per-triangle.

I’m not sure on a quick scan if this was the video I was thinking of. It does mention details of the previous title Glenn Copses worked on, Populus, that used a tile based system rather than drawn polygons. This does look slightly different to Powermonger, with a bevelled look to edges in the landscape tiles. So the Powermonger technique is somewhere between Magic Carpet and Populus, it may even be the same as Magic Carpet, just on a smaller scale to reflect the hardware of the time.

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

Between Populus and Powermonger Glenn did read an article in a magazine explaining how Midwinter did it’s 3D graphics on the Atari ST. The screen space dithering is a lot more obvious there.

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

A lot of of these styles look comes from having a limited colour palette, so if you haven’t seen Mark Ferrari’s talk on 8 bit it’s worth a look, and Alex Charlton has done some work on GPU dithering.

I just came across this thread on Mode7 which covers the basics of this affine transformation technique. The vehicles, rocks etc are done as sprites that are scaled for a perspective effect.

Yeah they look 1 bit to me too, but I was guessing that it might be a grayscale with a threshold (or at least that they might have another grayscale w/threshold texture) for when the seasons change and there’s a “smooth” transition as pixels of snow plink in one at a time on top of the grass.

Would it not be sensible to just render a normal unity terrain with isometric camera, on their own layer, with a really short far clip and a high near clip?

then this texture can be used for your main render which is largely gui based at that point. Use shaders and whatnot to pretend it’s crappy looking and so forth.

Hey there HeWasAgainstIt,

I actually spent a few days, earlier this year, looking at the Amiga version of this game, as I have written my own little isometric RTS game (using SDL 2.0, not unity), and I am using the early 90’s Amiga RTS games as my template.

I came to the conclusion that it is a proper 3D engine, using quads not triangles, rather than tile/sprite based, since it has variable heights and proper perspective etc.

Notes:
•The game FPS is around 12 (the 3D landscape isn’t updated every animation frame, only when the player moves the view).
•The 3D map area is quite a small part of the screen (approx 40% in real terms).
•It almost certainly uses the Amiga’s dual playfield feature, so the 3D map can be updated on the front playfield without needing to update the rear “static gfx”.
•If dual playfield is used, then there can only be a maximum of 3 bitplanes (8 colours) for the 3D map - This assumes non AGA chipset.
•Fixed camera, means the precision of the non integer maths (which will be fixed point) can be limited, so sin() and cos() lookup tables can be used.
•Weather effects (i.e. rain) would be drawn to the front playfield, again meaning the rear static gfx won’t need to be updated per frame.
•No Z-Buffer, so I imagine the pixels are drawn back to front.

With this in mind, it would be very easy to do proper real time texture mapping on even a simple A500 without burning up excessive CPU cycles. The question now I suspect there was a small palette of terrain texture tiles (using quads over triangles make this easier for this simple use case) which were randomly selected and then texture mapped in position, possibly with different shading variations to be drawn dependant upon the direction of the facing quad.

The actual game itself (all the data, logic and AI etc) will look like the little map to the left, the 3D map section is just a pretty parasite on the game data, which updates every 250ms (so it has plenty of time to generate the gfx).

The Buildings, entities (people, trees, etc) are just 2D sprites drawn to the 3D space (they don’t even bother to scale them for Z).

I could be wrong about all of this, it was just a quick assessment, which lead me to chose isometric for my game as I wanted to get the game engine logic up and running quickly without spending too much time on the gfx engine… Now that the game logic is working, I might try an implement what I have described above.

-Edit- Looking at the videos you have posted, actually I have noticed that the extreme Y on hills results in the texts being divided into triangles not quads (Also the water texture is clearly a triangle too). So, disregard my comments about Quads, everything else seems legit… Though the frame rate in the video looks like it might even be slower than 12fps, so even more time to calculate the 3D! Also I’m happy share code/design tips etc.