More ST-V emulation progress

I meant more like VDP1-VDP2 interaction which depend on the MSB of the pixel being set or cleared. Don't the VDP1 transparencies depend on that as well?
 
The priorities are involved also in this interaction : you can have a display pattern like this one :

VDP2 plane -> some sprites -> VDP2 plane -> rest of sprites

or even

some sprites -> VDP2 planes -> rest of sprites.

Right now in Saturnin I display the VDP2 planes first with their correct priority, and then I draw the sprites. So the priority isn't correct, and the resulting MSB calculations aren't correct also.

I'm thinking of a way to display the sprites at the correct moment in the framebuffer, but the performance may decrease ... (and I don't need that right now 😉 )
 
The main reason MAME is so slow is that a major goal of the project is to be not only accurate, but also portable, readable, consistent, and maintainable, i.e. a "reference implementation" of sorts. The kinds of speed hacks that made emulators like NeoRAGE X and Callus kicky fast are somewhat incompatible with this goal. There are still some protection and oddball patches around, but for instance I'm told that the entire system16/18 drivers are being rewritten because they were too full of ugly hacks.

It's also worth noting that MAME runs Psikyo's SH-2 games well by using pretty straightforward (but game-specific) idle loop detection, which offers a huge speed boost. I remember dropping Strikers 1945 III into the driver and being floored by how slow it was compared to Sol Divide. I have no doubt that Saturn emulator authors are pursuing this sort of optimization in a more generic way.
 
Originally posted by ExCyber@Oct 31, 2003 @ 03:30 AM

There are still some protection and oddball patches around, but for instance I'm told that the entire system16/18 drivers are being rewritten because they were too full of ugly hacks.

Roll on 2006. 🙄
 
Back
Top