How did games like Starglider 2 get such a high frame rate?

[deimos]

There have been so many changes that it's hard to remember them all, but I think the biggest change was to allow the algorithm that walks down the edges calculating the x1 and x2 values to draw lines between to alternate the order in which is calculates each side, like the difference between a single and a bidirectional dot matrix printer. This means that it has to swap out the contents of the registers holding all the edge information half as often as before.

I'm currently trying to build a system where the results of scanline converting an edge can be reused, taking advantage of the fact that every edge is shared between two faces. If I can get it to work it could result in a saving, at least for bigger polygons.

But at the moment it doesn't work. It's been nothing but Gurus for days now...

Originally Posted by roondar

Getting closer now. It's been fun watching this number go up over the days.
Might I ask what you changed to get the extra performance after the switch to 4 bitplanes?

[alexh]

Any news. I was enjoying this thread

[deimos]

I've spent the last few weeks experimenting with hidden surface removal algorithms, with a few detours around importing / converting .obj files. I've attached a couple of images of what it currently looks like - it's still a long way from anything that could be called a game.

I'm quite pleased with the hidden surface removal method I've settled on, as it can be almost entirely pre-calculated, just relying on face visibility calculations that need to be done in any case.

I want to create at least one more model to display before moving on to my next step, which will be to calculate the horizon so that I can draw the sky and ground correctly as the camera moves. I'm not yet 100% sure how to do that efficiently.

Originally Posted by alexh

Any news. I was enjoying this thread

[roondar]

I do like the model for the plane, looks quite good

[Tigerskunk]

Nice plane, indeed..

Also looking forward to updates in this thread...

[deimos]

Originally Posted by roondar

I do like the model for the plane, looks quite good

Thank you, it wasn’t easy to create as I need to know which polygon is which so that I can draw them in order, I couldn’t get good results with the data imported directly from Blender and had to do a lot of work by hand.

[deimos]

I've been working on this a bit more (see attached image), and I'm having a hard time trying to correctly draw the horizon / sky and ground, and can't find any help online.

At the moment I'm trying to find the intersections of the rectangle of the screen with the ground plane which has the equation ax + by + cz = 0 (i.e. a plane going through the origin with a normal of (a, b, c), where a, b, c is the middle row of my camera rotation matrix. I can get the intersection points for the top, right, bottom and left edges of the screen, which gives me a horizon line, but I need to handle the special cases of no intersection (all sky or all ground) and I need to work out which side of the line is ground and which is sky, which doesn't seem to be as simple as looking at the Y part of the normal.

Does anyone know of any off the shelf solution to this?

Otherwise, my next best idea is to define the screen as a polygon and find some code to clip a polygon to a plane, but I'm not sure what that will look like and whether it will solve my sky vs ground issue.

[deimos]

This is what I'm currently thinking and will try and code up tomorrow unless there's a better answer out there:

The screen is a polygon, a rectangle from xmin, ymin to xmax, ymax and is located at the viewing distance (256) from the origin:

    (-160,  127, 256),
    (-160, -128, 256),
    ( 159, -128, 256),
    ( 159,  127, 256)

The ground plane is defined by ax + by + cz = 0, where a, b, c is determined by the orientation of the camera.

Each point in the screen polygon is above or below the ground plane, which can be determined by plugging in the x, y, z values into the plane equation. Positive numbers mean above the plane, negative means below and zero means exactly on the plane which I'll treat as below.

Assuming the screen in sky colour (not wasted if there's only a single bit to change between sky and ground):

if all the points are above the plane then
    it's all sky, exit.

if all the points are below the plane then
    it's all ground, draw that and exit.

otherwise we have a mix of above and below, so
there must be intersection points.
 
set c (number of points in result) to zero.

for each input point p
    let q be next point in input, wrapping around at the end
    if p is behind the plane
        copy it to result array
        increment c
    if p is behind and q is in front or visa versa
        calculate intersection between line pq and ground plane
        copy it to result array
        increment c

draw ground as polygon in result array

[deimos]

Something like this:

static void drawGround(struct RastPort * rastPort, const Camera * camera) {
    WORD poly[5][2];

    LONG a = ((Entity *) camera)->transformation.rotation.value[1][0];
    LONG b = ((Entity *) camera)->transformation.rotation.value[1][1];

    LONG cz = ((Entity *) camera)->transformation.rotation.value[1][2] << 8; // 2^8 = 256 = viewing distance

    WORD s[4];
    s[0] = a * (DISPLAY_MIN_X - DISPLAY_MID_X) + b * (DISPLAY_MAX_Y - DISPLAY_MID_Y) + cz >= 0;
    s[1] = a * (DISPLAY_MIN_X - DISPLAY_MID_X) + b * (DISPLAY_MIN_Y - DISPLAY_MID_Y) + cz >= 0;
    s[2] = a * (DISPLAY_MAX_X - DISPLAY_MID_X) + b * (DISPLAY_MIN_Y - DISPLAY_MID_Y) + cz >= 0;
    s[3] = a * (DISPLAY_MAX_X - DISPLAY_MID_X) + b * (DISPLAY_MAX_Y - DISPLAY_MID_Y) + cz >= 0;

    WORD c = 0;

    if (s[0]) {
        poly[c][X] = DISPLAY_MIN_X;
        poly[c][Y] = DISPLAY_MAX_Y;
        c++;
    }

    if (s[0] != s[1]) {
        poly[c][X] = DISPLAY_MIN_X;
        poly[c][Y] = DISPLAY_MID_Y - (a * (DISPLAY_MIN_X - DISPLAY_MID_X) + cz) / b;
        c++;
    }

    if (s[1]) {
        poly[c][X] = DISPLAY_MIN_X;
        poly[c][Y] = DISPLAY_MIN_Y;
        c++;
    }

    if (s[1] != s[2]) {
        poly[c][X] = DISPLAY_MID_X - (b * (DISPLAY_MIN_Y - DISPLAY_MID_Y) + cz) / a;
        poly[c][Y] = DISPLAY_MIN_Y;
        c++;
    }

    if (s[2]) {
        poly[c][X] = DISPLAY_MAX_X;
        poly[c][Y] = DISPLAY_MIN_Y;
        c++;
    }

    if (s[2] != s[3]) {
        poly[c][X] = DISPLAY_MAX_X;
        poly[c][Y] = DISPLAY_MID_Y - (a * (DISPLAY_MAX_X - DISPLAY_MID_X) + cz) / b;
        c++;
    }

    if (s[3]) {
        poly[c][X] = DISPLAY_MAX_X;
        poly[c][Y] = DISPLAY_MAX_Y;
        c++;
    }

    if (s[3] != s[0]) {
        poly[c][X] = DISPLAY_MID_X - (b * (DISPLAY_MAX_Y - DISPLAY_MID_Y) + cz) / a;
        poly[c][Y] = DISPLAY_MAX_Y;
        c++;
    }

    if (c) {
        SetAPen(rastPort, FOREST_GREEN);
        AreaMove(rastPort, poly[0][X], poly[0][Y]);
        for (WORD i = 1; i < c; i++) {
            AreaDraw(rastPort, poly[i][X], poly[i][Y]);
        }
        AreaDraw(rastPort, poly[0][X], poly[0][Y]);
        AreaEnd(rastPort);
    }
}

I think I may have to add some tests for the intersections being exactly on the corners, otherwise I may end up with duplicated points, which may annoy the poly fill routine and may result in me having more points than I've allocated space for.

But, it seems to work.

Could it be better?

[Tigerskunk]

@Deimos: Thanks for keeping on. This is really one of the most interesting topics here for me at EAB currently...
I loved Starglider and Elite, and though I am not keen on coding stuff like this myself, it#s interesting to see your progress...

[deimos]

Originally Posted by Steril707

@Deimos: Thanks for keeping on. This is really one of the most interesting topics here for me at EAB currently...
I loved Starglider and Elite, and though I am not keen on coding stuff like this myself, it#s interesting to see your progress...

Thanks for the encouragement. I’ve been working on how to draw the ground detail, focusing on how to define coastlines, urban areas, etc., at different detail levels but without having to calculate and type in thousands of coordinates by hand. I’ve talked about that in another thread and had some helpful pointers there. Hopefully I can build something semi automated that will give the landscape to which I can add details like important buildings, then slice it into 880K chunks to make mission packs.

But, life, huh, gets in the way. It will be a few weeks at least before I get more time to work on it.

[zero]

I came across this blog post today: https://jix.one/pushing-polygons-on-the-mega-drive/

It's about doing 3D on the Megadrive but some of the techniques could be used on the Amiga. For example, their engine renders left to right, so you only need to accurately draw the left edge of every polygon and the right edge can just be rounded up to the nearest 16 pixels, because it will be overdrawn anyway.

[chb]

Originally Posted by zero

It's about doing 3D on the Megadrive but some of the techniques could be used on the Amiga. For example, their engine renders left to right, so you only need to accurately draw the left edge of every polygon and the right edge can just be rounded up to the nearest 16 pixels, because it will be overdrawn anyway.

The demo features some extremely impressive effects (this infinite plasma stuff rotating zoomer is awesome), and the 3D scene is very nice, but is done with a pre-calculated vector anim, like in State of the Art by Spaceballs. The mentioned method does not work well when you draw objects in real-time on top of each other (with generic z-sorting), because then it can only be applied to the inner edges of convex objects. If you, for example, draw a fighter over a landscape, its right-hand edges will not be overdrawn by anything. You'd need to find a way to do what they call the flattening effectively, which is rather hard in real-time (albeit very desirable for a number of reasons).

[zero]

I'm interested in how they did the rotozoomer but there isn't any real info available.

[VladR]

I just watched the YT vid of StarGlider 2 and didn't notice super high framerates. Very often it fell below 5 fps (possibly 2-3). Few things I noticed:

- ~60% of screen is covered in HUD
- of remaining ~40%, half is empty horizon, leaving ~20% for 3D objects
- of the ~20%, about half is mostly empty due to view distance
- leaving about ~25 scanlines where most of 3D object's scanlines are drawn
- and of those 25 scanlines, majority is a checkerboard that only needs 4 vertices transformed, the rest is merely interpolated via bitshifting resulting in an opportunity to write a specialized checkerboard function that gives an illusion of ~64 polygons, when in reality it's just one.

Since most of the time the objects are thin, couple pixels wide, there's no point in spinning Blitter up, just simple SW rasterizing for each scanline (1-6 pixels in distance)

Highly likely, there's several object-specific drawing routines. Noticed several candidates right in first viewing.

[Tigerskunk]

What I noticed with SGII is, that there are usually not more than around 30 polygons displayed, without the floor.

I'd love to see a game with SGIIs aesthetics, but for a bit a faster machine, like a 68060 or even a vampire.

Would look splendid.

[VladR]

Yeah, unfortunately, flatshaded look has not really been pushed anywhere its limits outside of some obscure arcades (but those games look absolutely marvelous - sharp, detailed, super high contrast (no bilinear filter) - very unique look).

I'm actually doing just that on Jaguar - pushing HiRes (640x240), HiColor (65,536) at 60 fps with flatshading. It's quite fun.



68060 should achieve same/better framerate but with lightmapped textures and roughly ~4x polycount I believe.
If we ditched the textures, then it's very hard to estimate what kind of scene complexity is possible. I'd guess ~10-50x ?

You could get floating point transformations done in parallel to integer unit execution - a cleverly written routine could be in parallel feeding floating point pipeline while it's traversing scanlines...

What kind of config is a vampire ?

[Tigerskunk]

Originally Posted by VladR

What kind of config is a vampire ?

Some guys took the 68040, built some stuff on top of it and called it the "68080". They use it within an FPGA.

Those cards with this FPGA are called "Vampire" cards.
See here for a short tour of the standalone Vampire card (others are available for plugging into an Amiga600, and Amiga 500 (works also in a 1000, though).

[ Show youtube player ]

[VladR]

Nice! A rough estimate of 250 MHz 68060 !

That should easily drive HiPoly flatshaded scenes in 640x480.


Wonder how Blitter works there ? Is it blitting at the full RAM bandwidth of 670 MB/s? That would be sweet !

[grond]

The 080 CPU allows 64 bit mem accesses while the blitter does only 16 bit. Since the blitter and CPU memory accesses are serialised in the V4 due to long mem bursts, the blitter always loses when compared with a CPU-only routine regardless of the memory bandwidth.