Quote:
Originally Posted by no9
Sorry, I didn't read the whole thread. i just want to add one more 030 demo example on the topic
|
Demos are not a good example of what the machine can do:
- not interactive
- lots of precaculated content
- 100% of the CPU + Blitter available for rendering
A game:
- reacts to user input and computes opponent AI
- runs gameplay logic and physics (if any)
- cannot precalculate massive amounts of data
Quote:
Originally Posted by roondar
I'll be honest, that is a disappointingly low figure.
Out of interest, how do we determine these figures? Is this just "common knowledge", or do have we some sort of 3D benchmark somewhere I'm just not aware off? I'm asking because I've always found Amiga 3D performance to be a particularly nebulous area. I've never found a clear result for any Amiga really and there seems to be a lot of misinformation out there.
|
Well, just list the operations a 3D game must go through:
1- hierarchical polygonal model animation
-> this is many times more expensive than 3D projection
-> forget it, too many matrix multiplications, the Amiga 030 must use Quake-like animation (pre-stored positions)
2- Culling
-> Determine which objects are visible on camera, essentially a bunch of bounding sphere visibility computations, not too expensive and for a 2 players fighting game we can make sure they are always visible and avoid that
2- 3D-2D project polygon vertices
-> these are essentially matrix multiplications, it is easy enough to benchmark it: write a 4x4 matrix multiplication routine and see how many times you can run it per frame (fixed point obviously)
3- Clipping
-> Looks like nothing but one must determine which polygons intersect the edges of the screen and clip them appropriately.
This is not free but for Virtual Fighter it may be possible to cheat (compute the camera to ensure fighters are never clipped).
4- Hidden face removal
-> one scalar product per polygon
5- Z sort
-> must be done object by object, then polygon by polygon -> O( n log n + m log m) (n = objects, m = polygons per object)
You can cheat by storing lists of draw order as a function of angle to the camera.
(Crash Bandicoot did that on the PS1 nto save CPU time.)
6- Polygon rasterization.
-> I will leave that to you
The cost of each of these passes in terms of multiplications and additions can be estimated as a function of the number of objects drawn and their number of polygons.
The two biggest steps will be:
- projection (= matrix multiplication)
- rasterization
The latter is a bit tricky to benchmark but here are a few things one can do:
- assume an average screen pixel count per polygon
- assume an average screen height per polygon
- determine the number of mults+adds necessary to determine the span of each rasterized line
- determine the number of 16 bit words writes needed per polygon
Doing that should give a relatively useful cost estimate per polygon.
And do not forget that this is for a bitplane architecture, so polygons must be rasterized on n bitplanes at a time.