Progress Thread - New demo - Cobra Mk III (18-May-08)

[qarnos]

Just a quick status update.

I've done some more work on the clipping code to get rid of a new bug I discovered. Sometimes I think I should just use the traditional clipping method and to hell with speed. Seems to be working fine for now though.

One major change I have made is a new routine which I call a "mirror transform"... I'm not sure if there is a real name for it. It was inspired by the 3D engine created by Vektor Graphics in the early 90's, which I have been doing some reverse engineering of.

The idea is that most objects are symmetrical about at least one axis. By using some highly abnormal matrix code, it is possible to achieve this mirroring using only addition and subtraction.

The performance benefits vary. There is a slight increase for a single axis mirror. For a 3-axis mirror the execution time drops from ~9000 to ~3000 T-states (!). Though that would only be useful for cubes.

I've done some work on the high-level routines. They give you a great deal of control (such as automatic animation) without being too complex. I'll expand on this sometime soon.

Also still working on improving the source to make it releasable. I've decided to write my own Timendus-style asmdoc utility. It gives me a bit more control by using a more structured format rather than trying to parse comments written for humans. I might post some more on this later to solicit your ideas/opinions.

That's all for now! I'm off to play with my new toy: A Commodore 64

[GuillaumeH]

Nice

[benryves]

Sounds good! Culling any sort of redundancy is a good thing, and I imagine this works very well for lots of models (space ships)?

[kalan_vod]

Great work bro, and the Commodore 64...Where you find one (not that I have looked before).

[qarnos]

Thanks for the comments, guys!

I have been working on the documentation. It is mostly auto-generated, and the conversion program is coming along nicely. The only problem is that I have to make some minor tweaks to basically every routine comment header But it gives me a chance to review things and make sure it's ok.

You can take a look at the documentation so far by clicking here. The index page isn't much, but it's a work in progress. The documentation is also incomplete - half of the engine is missing and some of it is a bit... wrong. But it's getting there.

I am aiming to have an alpha release (just the engine, no game) with source within the next few weeks. Though my record in these things isn't too flash, so don't get your hopes up too much. I feel like a real prick sometimes - I should have had this finished years ago. Let's hope I get it done while I'm on this streak. Though I take some comfort in the fact that I'm not the only one who has a problem finishing projects. Maybe it's a nerd thing.

Great work bro, and the Commodore 64...Where you find one (not that I have looked before).

I bought it from a bloke in the local trading post. When I went to pick it up, we ended up talking turkey about old computers for a good few hours! This guy has everything... even a ZX-81 and Commodore 16! He's selling half of it because he has two of them . It's good to make contacts like that.

Edited to add:

Click here to download the latest demo.

The polygon drawing bugs have been fixed and also the rotations should be a little smoother than before due to enhanced trig resolution.

[kalan_vod]

Wow, thats something! I can just see a airplane sim now ...Btw, the docs look very nice for just starting it

[Liazon]

OMG it's like voxel or w/e that 68k game is called!

[tr1p1ea]

Looking really great qarnos, still running at an incredible speed .

[driesguldolf]

Looking really great qarnos, still running at an incredible speed .

I'm a bit worried about that though... How smooth does it go when you have multiple ... (whatever you call that... surfaces?)

[qarnos]

Looking really great qarnos, still running at an incredible speed .

I'm a bit worried about that though... How smooth does it go when you have multiple ... (whatever you call that... surfaces?)

It's not going to be blazingly fast for any complex scene, especially on 83 standard calcs. I'm hoping it will be able to handle a scene containing maybe a couple of spaceships and some stars at a reasonable framerate. My guess is that you could go as low as 10 fps and still have a playable game. Due to the LCD lag, you probably wouldn't notice it much anyway.

But it really depends on the type of object you are rendering and exactly how you go about it. The mirror-transform can save a lot of time on highly symmetrical objects. BSP trees can be used to aid in visible surface determination. But if the program doesn't take advantage of these features to the fullest, it won't be so fast.

The model format is kind of like a byte-code with different opcodes for performing different actions, so it takes a bit of calculation to work out the fastest way of representing an object. Also, the "fastest" way isn't always the fastest - you just have to aim for the average expected case.

[kalan_vod]

I am glad that not all of us have been on vacation with programming >.>...Keep it going bro, people like you hold the community together!

[qarnos]

Just another status update.

I've changed the method used to calculate which plane to clip a polygon edge against. Instead of turning the fractions 16-bit fixed point values and then comparing them, I am now directly comparing the fractions. Surprisingly, this turns out to be not just more accurate, but actually faster in the most common cases. The only time it will be (marginally) slower is when you are getting up-close and personal with the objects, so that the camera is basically penetrating the object.

While working on my documentation generator, I also hit upon a cool idea. I've been worrying about how to actually create objects. A model editor/importer is not really ideal. Due to the fact that we need to squeeze every cycle we can out of this, there is no way a computer is going to be able to generate the best solution for any particular model. That's why we code in assembler when we want speed, and the same is true here. So I've decided to try a simple modelling language.

Internally, the engine already uses a tokenized language for defining models, so it only makes sense to make a compiler for it.

I am designing the language while simultaneously writing the compiler, so things are a bit all over the place, but if gives me a good way of quickly seeing what is going to work and what isn't.

This is an example of the way I am going with it. This is a short program to create a cube. The exclamation mark is the mirror operator. When used in a transform, it will mirror the vertex across the specified axis'. When used after a vertex identifier, it is used to select a particular mirrored vertex. This way, the example can use v1 to refer to all 8 vertices which were generated in the transform statement.

The mirror can also appear after a face, which will mirror all vertices in the face - hence we only need to define 3 sides of the cube.

Code: Select all

begin

    transform[0..7]!xyz begin // this will create 8 vertices at indices 0 - 7
        vertex v1(64, 64, 64)
        end
        
    normals(clockwise)

    face f1(v1, v1!y, v1!yz, v1!z)  // x-plane ("right" face)
    face f2(v1, v1!z, v1!zx, v1!x)  // y-plane ("top" face)
    face f3(v1, v1!x, v1!xy, v1!y)  // z-plane ("far" face)

    // Note: It is also possible to declare a mirrored face: face f4(f1!x).
    
    /* with each face pair, if the first is front-facing, the
       second can't be, so we won't even bother testing it. */
       
    if not backfacing(f1) draw(f1, alPattern08)
        else if not backfacing(f1!x) draw(f1!x, alPattern28)
    
    if not backfacing(f2) draw(f2, alPattern48)
        else if not backfacing(f2!y) draw(f2!y, alPattern48)

    if not backfacing(f3) draw(f3, alPattern68)
        else if not backfacing(f3!z) draw(f3!z, alPattern88)

end

It's a little bit unsightly, but is makes the job easier while still giving you complete control over how the model is drawn. BSP trees are sure gonna get ugly, though!

[qarnos]

I have new demo today and guess what... no more runway!

I've been playing around with an object conversion tool - something for simple objects which don't need much optimisation, and so I present a demo of a Cobra Mk III from Elite. This object was created from an 3DS file converted to an OBJ file, then converted to my own format followed by some hand tweaking.

You might also notice that the stars are mirrored across the sky - this is for performance reasons.

At last it's starting to look like a real 3d engine

The keys for this demo are:

[2nd] - toggle stars on/off.
[enter] - switch between camera/cobra control
arrows - pitch/roll
1, 3 - yaw
+/- - forward/backward
[mode] - quit

download demo file

[DarkAuron]

Wicked sick!

[qarnos]

Thanks, darky!

I forgot to mention, this is the first version that uses the interrupts to maintain (relatively) constant motion regardless of frame rate. Yes, it's taken me all this time to get around to doing that.

I need to fix up the star rendering code - it was a real last minute hack. When determining the visibility of a star it checks against all 6 frustum planes. Even if one of the tests fails, it still checks the others. I need to transform in into an early-out test. I just tried doing 400 stars (50 stars mirrored across all axis') on my SE, and the frame rate dropped from ~40 to less than 20 when stars were on.

On a side note: whilst debugging I wrote some code to plot the corners of the culling box used to determine the clipping mode. It won't be present in the release version, but it looks kinda cool, so I thought I'd post a screenie of it. If any of points lie off-screen, the object is clipped. If they are all off-screen, it is culled. You can verify this by watching the status of the "DRAW/CLIP/CULL" message at the top right of the screen.