Warp Engine V1.0 Readme ----------------------- This engine is a tiny 3D engine in the style of games like System Shock. Essentially, a level is made up of 64x64 pixel grids, with arbitrary topology cells constructed from polygons that are not allowed to overlap the cell boundary. This allows for easy HSE by a breadth-first traversal of the map from the player position. Clipping is done in camera space before the actual projection. Each cell is convex, so that each cell may be rendered in any given order (a more complex cell layout would be easy to achieve, although this would require some kind of depth sorting like BSP trees). Textures are "borrowed" from the source code distribution of Alien Breed 3 - Killing Ground. I have converted some of them into PNG format, which the engine can load. The "data/" directory contains the level and font, the former being a simple text file which is also commented, just in case you are mad enough to try and modify it a bit, although this is tedious work without a level editor. Source is also included in the developer archive. I intended to write a game with this, but I now have something better in mind (more in the line of Quake), so I release this source code as a kind of tutorial on Warp3D programming (and perhaps also as a tutorial on 3D programming, although much of the stuff could be improved). Much of this was inspired (in style and technique) by the two programs "Descent" and "QMap", the former being a first person shooter by Parallax software (and ported to the Amiga by my brother and me), the second being a Quake Level viewer by Sean Barret, which I studied while investigating 3D rendering techniques used by Quake. Although my code does not contain actual code from those, it was in places heavily inspired by them :-) If you want to use the code, go ahead, just don't sell it, and give me credit. To compile, you will need SAS/C (StormC should also do, GNU C with minor modifications) and GNUMake. I only provide a GNU makefile, SMake is far too limited for my taste. To use the makefile you will also need a fairly well installed ADE/Geek Gadgets distribution, namely the fileutils and binutils. In the demo, press the right mouse button and roll your rat to move the view. The 's' and 'x' keys move forward/backwards, there are also some other keys mapped (play around a bit). No collusion detection is done yet, so you can actually walk through walls. Also, the depth sorting is a bit broken, since I use a recursive call, and hence a stack, for traversal, which is of course utter bullshit, since it should use a queue. The net result is that there might be overhanging polygons in certain places, but I won't fix that (try if you like). Hey, if you do a bigger level, please let me have it, too (although I doubt that anyone will do that!). The FPS counter in the lower console will only update every five or so seconds, so give it a few moments to come to live - the first FPS reading will be too low, because the startup and loading is also measured. Also, when you change one of the features (mapping, filtering), ignore the first measure, as it will also be unnprecise. Moving the mouse pointer to the top of the screen reveals a menu. Click a title with the left mouse button, keep it pressed and release it over your choice to select. Finally, press ESC to quit. Note that this is a very simple engine, yet it serves as a small hint at what is possible with 3D hardware. The window at the cell in front of you is transparent, and the color can be toggled in the second menu. The red flashlight is dynamically implemented as gouraud shading, this comes almost for free on 3D hardware (the overhead can be neglected). On my machine, I get about 34 FPS with all features enabled, about 70 when everything is switched off. This is on a Z2 machine, an Amiga 2000 with Blizzard 2060/50, and it shows what 3D Hardware can do for a Z2 based machine (of course, it's hard to beat such speeds on a Z3 machine too). On the topic of speed, this demo might or might not run a bit slower on Picasso96. This is mostly due to the fact that Picasso96 seems to sync the ScrollVPort to the Screen updates, so that some time is actually "wasted" on waiting for the sync. While this gives a slight impact on performance, it also makes the thing look a bit cleaner. In fact, the ScrollVPort should no longer be used for Double buffering, alas, I've done it in this demo for a number of reasons: - Not all CyberGraphX installations can really do V39 Multi-Buffering. - The Multi-Buffering code I've actually written is buggy, and I just didn't have the time to look after it, and since it works with the ScrollVPort, I didn't bother to look after it. After all, we wanted to get Warp3D on the road. I have included a screen mode requester, so that you can try out different screen modes. I get around 34 FPS in 320x240, 13 FPS in 640x480 and around 1.9 FPS in 1024x768... If you have a 320x400 15 bit mode, try this, it's still quite usable. Note however, that the engine does not take the aspect ratio of the screen into account, making the 320x400 mode look a bit streched. This would be easy to fix, I just didn't have the time. The whole engine was the work of about a week or so, but I knew pretty well what I was doing from the start.