In commit ec325ef14f I did something stupid from
a performance standpoint, which was to select the shading function on a
per-pixel basis even though it can only change on a per-polygon basis. This
commit uses c++ templates and inline functions to so that the compiler's
constant folding can eliminate the switch statement that selects shading
functions (thus making the choice a per-polygon one). I also did the same thing
for the texture and bilinear filtering checks.
This brings back a little less than half of the performance hit on my PC, so
things still aren't as fast as they used to be.
Benchmark (running a full cycle of Crazy Taxi NAOMI's attract) on my PC:
Before ec325ef14f: 30%
After ec325ef14f: 23%
With this commit: 26%
Regarding the other 4% of the drop, that is coming from the pixel shading.
When I hardcode powervr2 to always use shading instruction 0, performance
jumps up to 29.5%, but when I hardcode it to use shading instruction 3
performance falls a bit down to 25%. Shading instruction 3 is the most
complicated of the four and shading instruction 0 is the simplest, so I think
that proves that the shading instructions themselves are a major bottleneck.
I don't have any ideas about how to make them faster yet.
- Even better hookup for modem RS232 port (including transmission clocks)
- Use ripple counter device for "RTC" and blink timer
- More object finder arrays and devcb3 usage
Out of whatsnew:
Minor clean up:
Correct OKI Clock for wwfwfest sets
Update rom names to MAME convention
minor ROM name corrections
New Clone Added
-----------------------------------------
WWF WrestleFest (US) [SpinalFeyd, The Dumping Union]
-----------------------------------
ibm5150: Math Blaster, Writer Rabbit [darksabre76]
ibm5170: The All In One Boot Floppy 1.0, The All In One Boot Floppy 0.9, The All In One Boot Floppy 0.9 (Lite Version), The All In One Boot Floppy 0.9 (FreeDOS only) [Justin Kerk]
* Eliminates the need for the horizontal/vertical/LCD/SVG layout files
* Screens can now have orientation and physical aspect ratio specified
* RASTER/VECTOR defaults to 4:3, LCD/SVG defaults to square pixels at config time
* System orientation is applied on top of screen orientation
Automatically generated single-screen views and orientation flags in XML
output now work correctly for systems with multiple screens in different
geometries/orientations, e.g. housemnq, rocnms, stepstag, or netmerc.
The "core rotation options" only interact with system orientation.
Allowing multi-screen systems to work well with one monitor per emulated
screen is a complex topic. System orientation also affects the GFX
viewer while screen orientation doesn't. The orientation displayed in
the system selection menu is from the system orientation.
Let me know if I've broken any systems or use cases.
Also, add save state support for std::array/C array nested to any depth.
