This past few weeks we've been taking a retrospective look at some of our heritage software on the Amiga platform. The Amiga was an incredible system for it's time, packing a punch far exceeding it's price tag. It's considering by many, as the system responsible for bringing many now standard operating system features to modern home computers. Unfortunately though, the parent company died before the platform could reach it's full potential. Which is an all too common story in this industry.
During the mid 1990's Underware Design was focused on developing Amiga software, primarily Amiga Video games. As an Indie developer, this was tough time trying to compete with the radically evolving 2D to 3D industry. With various projects being caught up in the hysteria of the 'Doom' shockwaves on the rival PC platform. A good example for us would be, our Thesius XII project. Thesius was side scrolling shooter, built out of a personal love of such game genres at the time, still do. But in 1994 / 1995, 2D games were quickly being labeled as the past, dead even in the 3D era.
To further set the scene, not only was the PC landscape rapidly making it's transition to 3D texture mapped games, but arcade franchises like Sega's Virtual Fighter and Daytona were going gang busters. Then comes the introduction of first generation of 3D capable home consoles. So you soon find yourself caught become a rock and hard place, were you make the transition to 3D or die, at least that's what it felt like then. Today, I think it was probably a mistake to try and compete with them on the same terms. But we live and learn.
Making the jump into the 3D realm on the Amiga was tough, very tough. Information was scarce, and just much like the 2D era, programmers tended to hold onto their secrets. Which meant getting even the simplest things off the ground, felt like climbing Mount Everest. One of the hurdles when doing software texture mapping on Amiga, wasn't just clock speed of the cpu, but rather how the video hardware represents the screen. Amiga chip sets use bit planes. While bit planes are efficient in terms of memory, they're not ideal for rendering texture mapped pixels. To counter this, programmers would render 3D scenes in chunky (byte per pixel) format, then convert this data into bit planes (planar) on the fly, commonly referred to as C2P. As efficient as the process can be, it placed a sizable bottle neck of what the low end Amiga systems could achieve.
Thus started a long journey of discovery for us, which in can summarized into two engine tech demo's, the first was called Reality and the second was Metal Combat. The Reality project was our attempt to bring a hybrid Wolf 3D / Blane Stone styled engine with polygon characters on the Amiga A1200/68020 machines with fast memory. At that time, this was perhaps the most ambitious (ie. see insane) thing I've ever attempted. Setting the bar so high meant that failure was not only likely, but virtually guaranteed. That didn't stop me from trying though. Bellow is a short video of an older version of Reality running under WinUAE.
Unfortunately, it's been so long since I was actively working upon this project some key files have been lost. So unless I can find them, or another more update version of the demo surfaces, then this is perhaps the only glimpse to it's existence. While not in this version of the demo, the objective was to have texture mapped walls and floors, and use the 1D wall z buffer, to clip the the flat shaded triangles into. Which meant drawing the polygons in vertical, but was a fairly easy to cull objects from the scene.
While Reality wall about texture mapping, another concept we'd spoken about internally was the idea of doing a Street Fighter clone for AGA Amigas a year or so before. Fighting games were hot and it seemed that if you render a pair of low polygon flat shaded characters, it might be feasible to game a 3D fighting game on for AGA Amigas. This is where the Metal Combat tech demo originated from, much like the Reality engine, it was series of render tests trying to hit minimum polygon count at playable rate, on the bare bones Amiga A1200 system. The render engine is CPU based, rendering only flat shaded triangles. The scene is drawn in 16 colour planar to a fast memory buffer, which is copying into chip memory. The idea was to use dual playfield for the backdrops/ground. So the characters would have been 3D, but the scene was to be mish mash of 2d/3D.
Seeing this demo again, I can't help but feel this was an area where we should have tried to exploit more, given everybody else was trying to make a better Doom game. But it was the 90's and tools and information just weren't what they are today. A version of the tech demo's source code is available on the our Amiga Source Codes page. Perhaps somebody will take it and make something cool out it one day.
A lot of byproducts occurs either directly or indirectly during the development of such projects. Such as a number support tools and libraries. If you're going to create a 3D game, then you need a way to edit 3D models. There was no tool chains like today, so we knocked a simple conversion / colouring tool for Imagine 3D. The tool let the user import / colour / set normals etc of the model. Along with that came some libraries that were released on Aminet, things like the AGE & PllbC2P come to mind. The latter is a library of precalc based routines to convert chunky to planar on 68020 cpu's.
PllC2p has been re-released. The code was originally written in AsmOne V1.20 (or there abouts), but it couldn't really be used in modern assemblers due to various syntax issues, like case sensitivity. So that library has been updated to assembly with the PhxASS assembler. While there are no doubt superior C2p methods today, hopefully the concept will be useful for somebody. Here's some tech demos that use it.
PllC2p has been re-released. The code was originally written in AsmOne V1.20 (or there abouts), but it couldn't really be used in modern assemblers due to various syntax issues, like case sensitivity. So that library has been updated to assembly with the PhxASS assembler. While there are no doubt superior C2p methods today, hopefully the concept will be useful for somebody. Here's some tech demos that use it.
A.G.E was a flow on project from the all the previous work. It's a graphic library that can be wrapped from high level languages, namely AMOS BASIC. The library supports AGA chipset, therefore given AMOS users long awaited AGA support. The idea for the project came from a previous Amos example written to demo how to display AGA pictures with just standard Amos. The library was originally released in 2000, but that version was almost impossible for users to decipher. So what i've done, is clean up the Amos wrapper to simplify the process for you. The library isn't a perfect though, there's a number of niggles, but even so, you can certainly have some fun with it. For example, here's a gouraud shaded demo written in little old Amos with AGE for rendering.
Well, that about completes our round of nostalgia, thanks for indulging me :). Sadly my real Amiga 1200 died long ago, and all the remains is an image from my hard drive. If you're an Amiga fan at heart, then I'd absolutely recommend firing up WinUAE sometime and have a mess around. It's amazing how much fun programming those machines actually is, and if you tire of that, then check out what we're doing with www.PlayBASIC.com for a Windows fun..
