Rendering

From AlephWiki

Graphics Rendering

Return to History

Ben Thompson

The ideas and opinions I will raise in this email are just that... opinions... although I am going to provide both a logical and factual basis to those comments. What is the difference between the hardware rendering and the software rendering? This topic is very important! It involves the capabilities of both hardware accelerated and software driven 3D engines. Both have downsides although hardware accelerated 3D renderings advantages outway its disadvantages. If you are interested in upgrading the Aleph One software rendering code, good luck! You would be better off re-writing it. The Marathon code 3D code base is formulated with certain things assumed:

a) floors and ceilings are always a plain in the x and z coordinates (they are horizontal) b) walls are always vertical c) there is always a ceiling and a floor to each polygon d) there is only one possible portal between to polygons at any given edge.

I am sure I missed a lot of things, but you get the idea.

With those limitations pre-assumed they constructed the primary drawing routines to draw those surfaces in a pseudo 3D fashion. 6-DOF 3D engines are capable of showing polygons in any x,y,z location and any p,y,r (pitch, yaw, roll) rotation in 3D space. For a given model, vertices are rotated around an origin with math functions for 3D space. This usually involves allot of math computation. This is where the Marathon development team started hacking. They took the limitations and assumptions made earlier and simplified the correct functions down into much simpler forms.

I am sure some of you are aware of the concept of "perspective". This is the idea where things get smaller as they are further away. So, in order to find a point in 3D space you must take the x and y components and divide them by the z component. This adds the most basic form of perspective. This assumes that all the vertices are already translated so that the origin is at the viewer's location and rotation.

Now, lets assume that the viewer can only rotate in one dimension (around the Y axis)! this means that for each vertex in the scene... we will only have to perform 1 rotation. Now given that there is sine and cosine functions involved, the Marathon development team used approximations for these in the construction of a "hash" table of values, where they can quickly look up the value of sin(36°). This is one of those performance optimizations which allowed for 3D to be even possible on the 68k machines. This also accounts for some visual artifacts that appear in software rendering.

Texture mapping is a method of taking a 2D image and mapping it onto a surface. Well, if you have ever played with Photoshop, you know that it is pretty easy to distort and repeat a texture to make it look like a wall going off into the distance! Texture mapping is very similar. In fact, because the Marathon engine is limited to vertical walls and horizontal with rotation only around the Y axis things are even easier! The walls and floors are actually rendered separately. This is because they simplified the texture mapping ideas into functions that only handle 2 cases: vertical textures with a Y rotation and horizontal textures with a Y rotation! Stretch the texture and add a little clipping and you might have a textured polygon. That isn't all there is to it, but we aren't going to get into this... you can actually figure this out by digging around in the code and keeping all the limitations discussed in mind.

Now this didn't cover all of the components in the rendering engine of Marathon, but I hope it was fairly accurate in theory if nothing more. The point is that if you want to maintain software rendering, this game is never going to progress beyond these limitations unless you re-write most of the software rendering engine! Unless somebody here is a professor of 3D software rendering and raytracing/raycasting techniques, I don't know of too many people capable of writing a fully featured software rendering engine to do this! Now there are some engines available that could be taylored to do it, in fact Screaming Cabala is an exellent example. It features 6-DOF, texture mapping, and point based lighting. I think there are several more features, but unfortunately, the project got cut off as the company writing it crumbled.

Look at [ http://www.antennahead.com/cabala/] (now a dead link).

We could add some translucent textures, a bit of cool effects, and maybe some new in game map mutation methods; but as it is, the maps won't be able to become any more complex because of the limitations set before us! With this limitations we can maintain software rendering and hardware rendering as a bonus with a little eye-candy. But, if we remove these limitations, we have a whole world of possibilities (granted software rendering would be left behind).

5 years ago, I would have said, "There is no way we can afford to ditch software rendering!" But, things changes, and fortunately computers have at a very rapid pace! Today we can do all and more than the software rendering of marathon at higher resolutions, with more eye-candy, and at higher frame rates using hardware acceleration.

Marathon was a great game and will always be one of my all-time favorites, but it doesn't even compare to the games of today! I am sure some of you might pose the argument that none of them have any story, but sorry for you, you probably haven't played "Deus Ex". You might not even have a machine capable of running it. Again, I wish I could put a G4 in front of everybody on this list; but we shouldn't have to focus on maintaining software rendering for people with a 66Mhz legacy either. You can put $130 dollars into a machine that has a PCI bus and be able to handle many features we need in order to bring Aleph One up to par.

Conclusions:

Lets look at alternative 3D engines that have 6-DOF, Alpha Blending, and Lighting (like Screaming Cabala) if the software based rendering is absolutely necessary. Or we need to re-write or upgrade the 3D software rendering to handle 6-DOF.

The thing that needs to happen is we need to break away from the limitations and re-write some of this game engine to take advantage of the OpenGL 3D API we have in front of us! We can't look behind us all the time if we want to move forward.

Responses:

Please don't send me hate mail because of the any of the harsh ideas I have presented here. Unfortunately, some of these ideas are the plain truth. I am very interested in hearing some more of your ideas.