christos wrote:Only amiga makes it (and some other people) possible!!!!
calimero wrote:I am looking at this crazy count of polygons in Quake 2 maps and compare them to number of polygons in best demos (Eko / Exa demos have scenes with most flat polygons). It is not fair comparison since demos are "controlled" environment but number of polygons in quake is insane!
calimero wrote:if you try to compare dougs Quake to best ST 3D games... there are like 10 times more polygons than in any ST game.
it is amazing how much you manage to pull out from F030!
AdamK wrote:It looks like screen counter now counts FPS and not VBLs/Frame am I right?
calimero wrote:It is not fair comparison since demos are "controlled" environment but number of polygons in quake is insane!
Q1/Q2 use a write-only zbuffer mode for the scenery, and a read/write zbuffer mode for objects.
dml wrote:Demos which pre-calculate the view (no keyboard/mouse input possible - always run the same sequence) can obviously trade memory and setup time for faster drawing.
Zamuel_a wrote:How did they manage to get the texture routines so fast? Even if only writing to the zbuffer, it feels like it should take a lot of time and not be so fast. I remember when I tried to make a Quake type engine back in the 90s and used most "tricks" I could find regarding texture mapping. All written in ASM code, Subdivision, doing the div with the FPU while the CPU do other stuff in parallel, even using the MMX registers to get more registers and so on, but I was never able to get close to the FPS rate of Quake and I didn't use a Z buffer at all.
dml wrote:Zamuel_a wrote:How did they manage to get the texture routines so fast? Even if only writing to the zbuffer, it feels like it should take a lot of time and not be so fast. I remember when I tried to make a Quake type engine back in the 90s and used most "tricks" I could find regarding texture mapping. All written in ASM code, Subdivision, doing the div with the FPU while the CPU do other stuff in parallel, even using the MMX registers to get more registers and so on, but I was never able to get close to the FPS rate of Quake and I didn't use a Z buffer at all.
Are you sure it was a fillrate problem? Writing the pixels on PC wasn't a major overhead iirc, especially if to the right kind of memory and with textures on page/cache boundaries etc. There are lots of other things which could hurt speed if rendering the same types of scenes.
It is much harder to compare performance of un-alike scenes.
For example - Quake generates a lot of tall, thin or near-degenerate polygons as a result of overdraw management, so optimizing for fillrate isn't necessarily the best option. You also need a fast path for ultrashort spans and small faces.
So if you do crazy things to the polygon filler to maximize the divide scheduling, you can actually make this worse for tall thin polys without realizing.
There are many other things involved which can cause performance problems - overdraw itself, clipping performance (early rejection of scene content) and the grain of the stuff being drawn (face-at-a-time, or somehow optimized e.g. shared edges, triangle strips etc.).
It's hard to compare two different engines but if you did all the same things in the same way it might be possible to find the answer by just looking at their code?
calimero wrote:and yet you manage to put most polygons onscreen with really good framerate!
calimero wrote:how do you fill flat polygons?
there was lot of talk about F030 blitter here on AF... do you use blitter for filling polygons in this engine?
You can toggle between CPU / Blitter with the 'c'/'b' keys but it doesn't make a big difference tbh. The fill rate is less important than the amortization of edge overheads in this engine. That is the only reason the blitter can be faster in some cases because there is a tiny bit of parallelism with CPU cache.
Zamuel_a wrote:How do you use the blitter for filling? There was a thread here a couple of years ago about using the blitter to fill polygons on an STE, but the conclusion was that there is not any good way of doing it.
Zamuel_a wrote:I guess you can copy data with a solid color in it to use as a span, but that's a bit slow. But as far as I know, there isn't any way to define a fill color to use without copy? Or do you do it bitplane by bitplane and use the "all set to zero or one" operation?
Zamuel_a wrote:One problem with your DOOM and Quake project is that when I see some of the FPS games that was made for the Falcon and that I thought was nice once, are not impressive at all to look at anymore.
dml wrote:I used to do this on STE by code-generated blitter initializers, with a lookup based on xo:xw, so the span setup time was very, very low. Most of the table entries mapped to a single routine for longer spans, but short spans had special treatment. This was really fast IMO. However there are so many ways to do things - I don't claim to know what the best way is on STE.
For fills, halftone is your friend. And for bitplane mode, endmasks are your friend.
Zamuel_a wrote:For fills, halftone is your friend. And for bitplane mode, endmasks are your friend.
But how to use the halftone for the colors? You don't draw the span in one pass?
Zamuel_a wrote:What is the best way to draw polygons?
Calculate the edges and save the left and right X in a table and after this, loop through the table and draw the spans, or calculate and draw at the same time? It's much easier to save in a table first since the edges can be treated as individual lines without thinking about other lines at the same time, but of course there is one more loop involved.
Since you seems to be the expert on this, you probably have a good answer.
Zamuel_a wrote:I guess it might depends on if it's done on a ST or Falcon because of the cache.
Users browsing this forum: No registered users and 2 guests