Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

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.

share|improve this question
    
It's worth mentioning that Elite and Star Wars worked in very different ways. Elite used software rasterisation of 3D models into pixels, while Star Wars ran on a vector display, which didn't even have pixels; instead, the display beam would directly draw arbitrary coloured lines to the screen, but couldn't fill them. –  Trevor Powell Oct 23 '11 at 7:12
    
Did not they draw Bresenham lines (or DDA lines) for projected points(can be derived on similar triangles)? –  user712092 Oct 24 '11 at 23:47

2 Answers 2

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.

share|improve this answer
    
So my guess for rasterisation was right? If I got what you said right, it's not dissimilar to standard 3D programming using, say, OpenGL. Matrix multiplications and the likes, right? But I'll have to figure out backface culling and Z-buffering. Do you know any good open source implementations of rasterisation? I guess the algorithm isn't that difficult but I like to play around with code to understand things, I don't want to copy anything (also because I'm using a modified Z80 ASM, which is very specific) but it's still nice to have some kind of reference. –  EliteIsAwesome Oct 22 '11 at 13:14
    
Sure, all software rendering of vector graphics is rasterisation by definition. I don't know of any example source code, but once you have the vertices in screen space you can draw the lines using the Bresenham algorithm. As for backface culling and Z-buffering, Elite doesn't have 'faces', just edges, and it certainly wasn't using a depth-buffer of any kind - there just wasn't enough memory for that, and that technique only really started being used for games in the mid 90s. –  Kylotan Oct 22 '11 at 15:46
    
Yes, I knew that Z-Buffering came relatively later, should've said "Z-culling" instead. I guess I'll have to use one of the simpler algorithms. Thanks for pointing me toward Bresenham's algorithm, it looks quite inexpensive. –  EliteIsAwesome Oct 22 '11 at 16:26

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)
share|improve this answer
    
About the ray-casting based engines not being real 3d, I was just referring to the fact that most of them just represented a two-dimentional space. Elite allowed 360° movement and that, to me, is the definition of 3D game. The definition of 3D representation is more flexible, I wholly agree! Edit: I wanted to thank you for your thorough answer. If you interested, I'm developing my little Elite-like demo on Gameboy. Good luck with your voxel engine! –  EliteIsAwesome Oct 22 '11 at 12:26
    
Hey, yep, I refined and re-refined that section, I know what you meant, can tell you've done good research before asking this question. Re your game, I'm very interested, is there a feed or something I can subscribe to? –  Nick Wiggill Oct 22 '11 at 12:27
    
I tried my best. I was already planning to go deeply into math, can you suggest more subjects I should consider aside from the ones you already mentioned? Not afraid of them! –  EliteIsAwesome Oct 22 '11 at 12:29
    
Just re-edited -- description of raytracing vs. raycasting. It's an important distinction to make. Raycasting in the original sense was just an optimisation of raytracing, but later "raycaster" came to mean games implemented in the Wolfenstein/Doom/Duke Nukem 3D style. Re math, mine has never been impressive. But you can do a remarkable amount even with those topics I mentioned. Further to that, check out 3D Math for Game Programmers and Data Structures for Game Programmers. GPU Gems series, and Paul Bourke's webpages for computational geometry. –  Nick Wiggill Oct 22 '11 at 12:30
    
OK, thanks. Although I guess I'm going to have a hard time translating extensive calculations to a bunch of registers and some memory! I don't have any blogs/feeds about my project since I've done very little - the source material is very scarce, but I guess it's why I found it so charming. If I ever make something out of it, I guess you'll hear about it, since I'll most likely have to come here for seconds! Also, to add to your list of vector games, check out www.everyvideogame.com/showthread.php?p=11539 –  EliteIsAwesome Oct 22 '11 at 12:59

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.