Informed optimisation

[DanScott]

You could look at combining the edge calc with the horizontal span filling, by working downwards from top to bottom

Currently you are writing to memory, then reading back in the 2nd phase.. this will have some overhead.

There are other optimisations you could do too with regards to the rendering (ie. removing any loop from the longword writing, and having code that jumps in at the correct point to write out the required number of longs etc..)

[Ernst Blofeld]

I have fixed the bug that caused tanks to calculate their shadows the hard way, I now have an extra 0.1 fps.

So, now to concentrate on the long division bit:

        if (transformed->x >= viewingDistance)
            *projected = (LongPoint3D) {
                transformed->x,
                transformed->y * viewingDistance / transformed->x,
                transformed->z * viewingDistance / transformed->x
            };
        else
            *projected = *transformed;

First, to explain, my x,y,z are not the same as you may expect, as I tried to follow the standards used in aeronatics where x is the axis you look down. This may have been a mistake, but it's where we are - x is away from you, y to the right, and z is down, all right handed.

viewingDistance is currently fixed to 256, and (as the code says) the divisions only happen if the point is at least that far away. Why do I copy the transformed values over to projected in the else part? It seems the only reason is so that there are values in there for my IsFacing test later on. This logic may be flawed.

Ok, I have two goals,

1: make the maths stuff that will fit into words, and
2: replace the division with a look up and multiplication of 1/x.

Both seem to rely on getting the range of values for x down to something reasonable. and setting my draw distance in line with that. If I use a look up table I need to keep that to a reasonable size. I think I want the draw distance to be around 2km, beyond that object are just a few pixels big and everything breaks down anyway.

Anyway, trying to get the divisor to fit into a word, rearranging the calculations gives me:

            *projected = (LongPoint3D) {
                transformed->x,
                transformed->y / (transformed->x / viewingDistance),
                transformed->z / (transformed->x / viewingDistance)
            };

This results in values which are normally the same as the original (can be out by up to 2 pixels), but should, I think, allow for transformed->x values of up to 8km.

To use a table, with a 2km draw limit and the resolution given by transformed->x / viewingDistance (which is effectivly ">> 8") I think I need a table with 8,192 values, or 16K. Would 16K be considered large for a look up table?

Edit:

Just replaced the divisions with inline assembly:

        if (transformed->x >= viewingDistance) {
            WORD x = transformed->x >> 8;
            *projected = (LongPoint3D) {
                transformed->x,
                Div32_16(transformed->y, x),
                Div32_16(transformed->z, x)
            };
        } else
            *projected = *transformed;

For a minute improvement.

inline WORD Div32_16(const LONG a, const WORD b) {
    WORD result;

    asm(
        "   move.l  %[a], %[result]         \n"
        "   divs    %[b], %[result]         \n"

        : // outputs
            [result] "=&d" (result)

        : // inputs
            [a] "g" (a),
            [b] "dm" (b)

        : // clobbers
            "cc"
    );

    return result;    
}

Edit 2: Started on an inverse table in Excel, but I'm not sure about using it as I'll be multiplying a long by a word then shifting the bits around, which sounds more expensive than a divide?

[Ernst Blofeld]

Originally Posted by DanScott

You could look at combining the edge calc with the horizontal span filling, by working downwards from top to bottom

Possibly, but this makes the edge calculations a lot more complicated as I then need to find the top of the polygon and work down both sides at the same time.

Originally Posted by DanScott

There are other optimisations you could do too with regards to the rendering (ie. removing any loop from the longword writing, and having code that jumps in at the correct point to write out the required number of longs etc..)

I have done that, but only my runway is wide enough for it to make any difference.

I can post my polygon code up later.

[NorthWay]

BTW, are you triple-buffering?

[Ernst Blofeld]

Originally Posted by NorthWay

BTW, are you triple-buffering?

Yes, I am. I'm a firm believer in triple-buffering.

[Ernst Blofeld]

This is what it looks like now:



There's a big overhead in the profiling code. Not much I can do about that, just need to be cautious with the values.

With the profiling disabled I now get 3.25 fps, which is an improvement over the 2 fps I was getting a week ago.

I'm now working on different drawing code depending on the distance the object I'm drawing is, i.e. for aircraft:

    if (this_Entity3D->transformedCentre.x > 512 * 1024)
        this_Entity->drawingMode = ENTITY_DRAWING_MODE_NONE;
    else if (this_Entity3D->transformedCentre.x > 256 * 1024)
        this_Entity->drawingMode = ENTITY_DRAWING_MODE_DOT;
    else if (this_Entity3D->transformedCentre.x > 32 * 1024)
        this_Entity->drawingMode = ENTITY_DRAWING_MODE_MODEL_FAST;
    else if (this_Entity3D->transformedCentre.x > -32 * 1024)
        this_Entity->drawingMode = ENTITY_DRAWING_MODE_MODEL_SLOW;
    else
        this_Entity->drawingMode = ENTITY_DRAWING_MODE_NONE;

[Ernst Blofeld]

3.5 fps now with the above code in place and a simpler rendering process for objects that can be guaranteed to not need near plane clipping.

Does anyone know what FPS the better 3D games used to get (on standard A500s)?

[DanScott]

Originally Posted by Ernst Blofeld

3.5 fps now with the above code in place and a simpler rendering process for objects that can be guaranteed to not need near plane clipping.

Does anyone know what FPS the better 3D games used to get (on standard A500s)?

I would think at least 10-12 FPS minimum for anything to be playable. Any slower, and things feel really sluggish (or changes in viewpoint become too drastic from one frame to the next)

[Ernst Blofeld]

Originally Posted by DanScott

I would think at least 10-12 FPS minimum for anything to be playable. Any slower, and things feel really sluggish (or changes in viewpoint become too drastic from one frame to the next)

Best I can do is 3.6.

[roondar]

I'm not actually sure that the average Amiga 3D game ran at 12FPS on the A500 though. That seems a bit high to me.

[DanScott]

Originally Posted by Ernst Blofeld

Best I can do is 3.6.

most games had a cut down screen size though too... usually some large status panel, and oftern a 16 or 32 pixel wide panel around the side of the screen too

[DanScott]

Originally Posted by roondar

I'm not actually sure that the average Amiga 3D game ran at 12FPS on the A500 though. That seems a bit high to me.

There were definitely some that ran at that frame rate though... look at Interphase, that seems to run up to 17fps at points.. obviously, all the old A500 3D games seem to start chugging when scenes get busy, polygons get large etc..

[LaBodilsen]

Originally Posted by Ernst Blofeld

Best I can do is 3.6.

Maybe look at model complexity. I tried to remodel the plane from F18 interceptor, by looking at screenshots, and it came out to about 37 Vertices, and 25 faces.

Compared to the 52 vertices and 49 faces of your model, it might give you some small fps. improvement.

[Ernst Blofeld]

Originally Posted by LaBodilsen

Maybe look at model complexity. I tried to remodel the plane from F18 interceptor, by looking at screenshots, and it came out to about 37 Vertices, and 25 faces.

Compared to the 52 vertices and 49 faces of your model, it might give you some small fps. improvement.

That's in the plan, to make at least one more version of the plane and the tank with less detail, and only use the current ones for extreme close ups.

But, making a decent looking model with less detail is a very hard thing to do.

[DanScott]

for extreme distance, you could just use a pixel plotter.. and maybe plot 1 pixel for various parts of the plane.. the wing tips, 3 dots along the fusalage(the nose, the middle, the end), and one at the top of the tail fin.... you would probably get the similar"scintilation" effect that you'd get rendering polygons at that distance

[roondar]

Originally Posted by DanScott

There were definitely some that ran at that frame rate though... look at Interphase, that seems to run up to 17fps at points.. obviously, all the old A500 3D games seem to start chugging when scenes get busy, polygons get large etc..

That does beg the question: what were the developers of old games doing different than the current polygon-3D engine coders on EAB (Ernst, Deimos and also VladR though he is clearly aiming at higher spec machines)?

Both Deimos and Ernst got fairly low FPS on A500 compared to these numbers and do so consistently. As they both seem to be quite capable coders, it seems to me there's some "missing ingredient" regarding the old-school vs new-school performance difference. No idea what it is, but if older games consistently ran much smoother there must be something going on

[DanScott]

I would say that most of the old 3D games were probably written in 100% hand oprimised 68k.

Might be interesting to disassemble something like Interphase. The Assembly Line had a really good 3D engine. I was talking to Andy Beverage about it some time around 1991 when he was in town for a UK game developers conference. They also used the same engine for Cybercon III, and added the ability to draw curves, convincing ellipses and cylinders

[Ernst Blofeld]

Originally Posted by roondar

That does beg the question: what were the developers of old games doing different than the current polygon-3D engine coders on EAB (Ernst, Deimos and also VladR though he is clearly aiming at higher spec machines)?

Both Deimos and Ernst got fairly low FPS on A500 compared to these numbers and do so consistently. As they both seem to be quite capable coders, it seems to me there's some "missing ingredient" regarding the old-school vs new-school performance difference. No idea what it is, but if older games consistently ran much smoother there must be something going on

I've never played Interphase, in fact I'd never heard of it until yesterday. It's had to judge its frame rate by YouTube videos, but my impression is it's around 8, but I may be wrong.

The draw distance is very small, objects are constantly "popping in", and it's about 2/3 of the screen once you take the borders into account? It's also very 2D, there's no real height, and apart from the camera, objects don't really seem to rotate 3Dly, so they might be a bit like my tank, only moving around in one plane, which allows you to drop some of the calculations. The lack of height may mean they don't have to do any clipping, they can just ignore bits that fall off the screen as they rasterise the polygons.

Also, I'm sure they were better coders than me and not afraid of assembly.

Edit:

After thinking a bit, I don't think they are doing the traditional full object + camera transform, I think they are moving the objects to their location relative to the camera and then doing something like the 6 multiplication rotation that was in Jobbo's thread the other day to rotate the camera. If I'm right (sometimes it happens) then their calculation phase is about 1/3 of mine

[Ernst Blofeld]

Originally Posted by DanScott

for extreme distance, you could just use a pixel plotter.. and maybe plot 1 pixel for various parts of the plane.. the wing tips, 3 dots along the fusalage(the nose, the middle, the end), and one at the top of the tail fin.... you would probably get the similar"scintilation" effect that you'd get rendering polygons at that distance

Probably a good idea. I need to extend my model format to understand that though. At the moment it only knows polygons, I'd planned to add lines, I may as well add points too.

[Ernst Blofeld]

Originally Posted by DanScott

Might be interesting to disassemble something like Interphase

I wouldn't know where to start.