Looking at the thread myself, I'm pretty sure this is the information that Spanish guy (Conker64) was mentioning regarding the hardware:
This pic is the real camera and the actual polygons are sent to be rendered (just the view was zoomed out on the blender for the pic). However these extractions have no back-face culling and may have some polygons out of the screen as well, with a deduction comes close to a bit more 3000-3500 polygons on scene rather than 5000-6000.
It could be a bit weird if a game does not use cull back since it improves performance on most of the conditions (options from early SDK test)
Actually these are pretty common numbers for N64 or PSX, 1000-2000 polys per frame for the first gen games, 3000-4000 for the late ones depending on the framerate targets, (3252 triangles here for reference: its Beattle Adventure Racing but it says Need for Speed on the N64 debugger, interesting
) and yet it may be with or without cull back or clipping, so the numbers per frame on the N64 case always needs some analysis.
This second pic its just a segment of geometry loaded on memory (even backwards camera).
Turok 2 intro probably has one of the highest polycount scenes of the console.
Around 3000 polygons each model, plus other big details like the portal, however as said before, you need to do some analysis of the data.
One of the most complex PSX model is the T-Rex dinosaur of the tech demo, here is the complete model of it (faces/tri on top).
Another example of complete models are Crash Bandicoot.
Snaaaake!..
On the N64, Link.
One random enemy from Goldeneye.
One random enemy of Perfect Dark (200 polys more than Goldeneye that could explain the more common slowdowns when there are many on the screen).
Conker when closer/detailed LOD, a bit uncommon a 1200 poly char for a platform game on that gen.
He has a shadow projection, but other games such as Jet Force Gemini did that as well.
Then you have the fighting games that usually push about 900-1000 polys on the 3D models and very simple scenarios or more complex ones depending if the target is 30 or 60fps. N64 had no stellar projects on that area from a technical standpoint. This is a pic of Tekken 3, Conker64 has removed the OSD and the background, with cull back, and the real number comes close to 1300 rather than 1800-2000 of combined models, with everything else its around 90K performance-wise.
PSX needs more polygons for building the areas, due the lack of perspective correction.
N64 can push giant backgrounds with less polygons (the clipping microcode on Fast3D is actually optimized for that and not really recommended for busy backgrounds as it does way too many checks). Better be a custom microcode (Factor 5, Boss Studios, etc) or good programming, 3D objects on the other side uses a faster reject box. Conker64 believes that exclusive games on the N64 pushes a good amount of polys on chars and enemies as seen on the previous pics.
But it's a matter of choice, Perfect Dark not only has high poly enemies (for its generation), but even the basic walls are plagued of poly work to create static light/shadows or more detailed texture walls.
The PSX screen extractions have back-face polygons already removed, so the numbers are more close to real performance, but note that some polys are out of the screen in some cases. Tobal is probably one of the best examples with around 120K/sec at 512x480 resolution.
A peak performance point found on the snowy level, as any other extraction, these are average numbers and they have to be taken into consideration.
The original PSX specs actually had a more detailed list:
3D
--
Flat
4bit Texture - 200K
8bit Texture - 100K
15bit Texture - 60K
Goraud
4bit Texture - 140K
8bit Texture - 70K?
Depending on the texture depth and lighting, the performance may vary, and these are just theory numbers, we don't even know the size of the poly/texture and which conditions. Tobal uses many flat shaded polys, especially on the chars where the big amount goes, some gouraud shading and very few textures for whole scenes, they obviously will fit the 2KB texture cache in 1 step.
If we look at Tobal 2, it uses less polygons per frame than the first part (about 90K). Why? Because it pushes more textures and gouraud shades into the models, and makes it look better, but slowdowns the process.
Another one, the engine is very clean and sends commands in a very optimized way, Conker64 mentioned that he didn't have to remove any polygons from out of the screen.
A peak performance point of Metal Gear Solid (low res), Conker64 wasn't for sure if the framerate is stable on this spot, some geometry out of the screen have to be deducted.
Some games like Crash Bandicoot can be around 60K most of the time (locked off camera) which gives the impression of detail, while others can be 10K, then 20K, then peak at 60K, even MGS can be pretty low poly-wise due the top camera angle.
Analyzing custom microcodes in World Driver Championship could be great but many tools don't work with this game, and the emulation has been always more focused on emulating libultra than the real hardware.
--
About 2D, Conker64 has done some tests running on real N64 hardware, 8 scroll full layer test (320x240x16bits) with 32x32 tiles.
A sprite test, each Mario here is at a 16x32 texture of 16bits (4bit textures could work faster and 32bit textures or 32bit mode are slower)
The following results:
- 921 sprites max at 60fps
- 1972 sprites max at 30fps
Anyway these tests are coded in C with libdragon and are not optimized at all, TMEM fills each frame with the same data and the framebuffer is fully cleaned and each frame with a RDP has a primitive draw mode. The results could be better for this example or worse if you have to refresh TMEM with more data per frame (like animations or different sprites), but the machine is very capable for 2D.