Vector games (Wireframe, Elite-like) theory and implementations?

Question

I'm interesting in knowing more about how vector games like Elite and Star Wars Atari were built from grounds up. The question is not how to implement vector graphics with modern 3D APIs like OpenGL and DirectX, since doing it is quite easy and does not require to build a vector/matrix system from scratch like those games did.

Some things I presume about these games:

• They work on an extremely low level and are written in ASM
• They're actual 3D games and not faking it like After Burner. Not like Wolfenstein 3D, either. Afterburner used rotozoom/raster effects and Wolfenstein 3D used raycasting and 2D scaling and it's not really 3D, since you can't move up. Even if you could like the Build Engine that Duke Nukem 3D used, everything except the walls is just a sprite. Star Fox is closer to it, since uses actual 3D models, but the implementation uses SNES' Super-FX chip and probably employs scanline trickery. I know Elite probably uses said scanline trickery as well (at least on some implementations like Elite NES) but I'm not sure about SWA, since it used a custom-built arcade machine; either way, I'd like to know more about it.
• Their 3D models are actual 3D models. They are defined as vectors and transformed according to the position of the camera.

I know the best thing to do would be to disassemble the source of Elite and see how things were done by myself but before doing that I want to know more about how they were made and if there are modern open-source projects that show similar techniques. I don't mean Elite remakes like Oolite (which uses OpenGL and Obj-C) but projects that use similar techniques and avoid using APIs like OpenGL directly - not necessarily low-level projects, though, using 2D library like SDL (without OGL) should be enough, at least for now.

I know that the source code to MESA3D probably contains many of the routines that games like Elite and SWA implemented - I just want to see them in the context of a game. I know that what Elite and SWA basically did was implement Rasterisation, create their format for models and a loader (I'm pretty sure that at least SWA had models built from modelers using tools, although it's not impossible to hard-code TIE-fighters it's hard to do so accurately) and many other things I may be unaware of. But it's really time-consuming to get into and I don't care about much of the stuff that is in it. Keep in mind that games like Elite were very lightweight due to the low ROM and RAM that computers and consoles had at the time.

I'm new to 3D graphics and all my assumptions are based on my limited knowledge of 3D Geometry and school level maths, sorry if I said any bullshit. But I'd really like to know more about how those games work in every detail, and possibly not just "buy X book" since I'm quite broke. Although I'd buy a book about the development of Elite or a similar game, if it existed. Some general suggestions would be enough.

Answer 1

The question is not how to implement vector graphics with modern 3D APIs like OpenGL and DirectX, since doing it is quite easy and does not require to build a vector/matrix system from scratch like those games did.

Vectors are literally just a list of numbers. Matrices are just a grid of numbers. The interesting part is the mathematics you use on them, but that stuff is also trivial - just grab a school-level mathematics book where this sort of thing is explained. This is only about 50-100 lines of code, so don't overestimate the effort here.

They're actual 3D games and not faking it like After Burner. Not like Wolfenstein 3D, either.

Wolfenstein 3D is mostly real 3D, because raycasting is arguably more 'real' than the usual geometric approach we take. Still, you're right in identifying that it's a different model and not one you're interested in here.

I know the best thing to do would be to disassemble the source of Elite and see how things were done by myself

Don't get too hung up on Elite particularly. It's not using anything special - software rasterisation is pretty much the same no matter which piece of software did it. You take each object and transform all its coordinates into world space, then you transform all those world space coordinates relative to the viewer so that they're in view space, and then project them to 2D so they're in screen space. Each transformation is basically just a rotation and a translation, and the projection is usually little more than a division, if you make the right assumptions.

There are some other tricky bits that I can't remember immediately, like how to remove the invisible faces, but I think that can be done just with the order of the vertices - render a line between 2 connected vertices if they are clockwise in screen space, and don't if they're not. (For example.)

it's not impossible to hard-code TIE-fighters it's hard to do so accurately

Most of those models only had about 20 or 30 vertices - easily within the realm of hard-coding. I expect the original authors drew the models on graph paper first and then copied the vertex values into the code.

Answer 2

You are looking for vertex based 3D supporting arbitrary (unrestricted) geometries in 3D space. Raytracing in the original sense is real 3D in that it may support unlimited degrees of freedom (DoF). Raycasting (in the game development sense rather than original sense which is similar to raytracing except for the direction of rays), however, restricts degrees of freedom, eg. height-map based such as that found in Comanche's voxel raycaster, or Wolfenstein which actually has the player moving in a pure 2D space. Any 3D engine that support arbitary geometries without restriction by axis is just a representation in screen space of some sort of model of a 3D world, irrespective of that representation.

They work on an extremely low level and are written in ASM

In Elite's case, as you probably know, yes it was. Parts of other, similar games were cerainly written in ASM or machine code isntructions in every case, considering the demanding mathematical processing without anything like the ALUs we have today. Because there are only small parts of any codebase that are truly performance critical, it is conceivable that some less critical parts of some of these (take 3D Construction Kit and the games it made, for example) were written in C++. However, again, considering the limited resources particularly on pre 16-bit era machines, it is more like to be in a mix of assembler and raw machine code (you could actually enter huge sequences of 0's and 1's and store them to disk as a program -- heaven help you if you made a mistake).

Their 3D models are actual 3D models

Further notes on the process of building such games from scratch:

Math, before anything else. To be authentic, you'd use fixed point math. What you can implement on the math end will determine what kind of game you can make. Period. I can guarantee you this is the philosophy Braben and Bell took to elite. Prototype, optimise, rinse and repeat. See what's possible. Then design your game around what you have made possible. This will not be the case on today's systems, as we already know (the low end of) what is possible. Find (and preferably understand the math behind -- but this is not 100%necessary) implementations of the basic building blocks: 3D vectors, rotation matrices, Quaternions (I think they favoured eulerian rotation back in the day but not certain, anyway Quaternions are cheaper to compute) and the like. Also it's key to find out what the most efficient data structures are for representing these -- do not underestimate the impact and efficient data structure has on performance!

Next, writing the code. Implement these structures and operations (as well as accompanying structures and logic for your broader game, as such) in a higher level language such as C++ or even better (faster), C. Then optimise down into asm blocks from there, as and when required. Since I'm presuming you'll want to do this on x86 or other modern architecture, this should be sufficient for your purposes. If 16 bit era hardware such as Motorola 68000-based systems, use C and refactor into ASM often. If 8-bit hardware, C is doable for limited bits, I'd think, but you will likely be refactoring mercilessly into ASM. If working on 8-bit or 16-bit systems, you ae going to have to get familiar with the architectures, the increasingly obscure tricks used on those platforms, and so on, so I wouldn't recommend this route as it is literally a dark art these days (although surprisingly there are still communities who develop for these mostly defunct systems).

Your thorough investigation of old school techniques is commendable. You're certainly going to end up with an appreciation of just how imaginably much could be done with the hardware we have today.

---

Some similar games I remember aside from 3DCK for you to check out:

• Dark Side
• Starglider
• Interphase
• Virus (superb little game)
• Conqueror (same engine as Virus, used to play this on a single keyboard with a buddy, one guy the tank gunner and one the driver, great memories)
• Mercenary (released just months after Elite)
• Damocles (and other Mercenary sequels and mission disks)
• Novell NetWars for x86 architecture (may even still run on something like Dosbox, though running it networked would require an authentic setup I think)