mirror of https://github.com/bsnes-emu/bsnes.git
e492268025
Ok, I tried converting the switch/case table to a jump table for both
CPU+APU cores. Results? EXE is 70kb larger, compile time is 5-10%
slower, and speed is identical. Needless to say I reverted that change
back. I then tried narrowing down the cause of the PGO error. Found
out it was Dai Kaijuu Monogatari. If I don't run that, I can build
with PGO. Unfortunately, this is the ROM I use to stress optimize
color add/sub. So as a result, this game will run a little slowly now
(sort of like how Chrono Trigger's OPT title screen effects were
before). But, better one game than all, right?
byuu.org/files/bsnes_v016_wip27a.zip
Once again, please do not submit news about this to an emulation
site. The file will be removed if I notice anyone mentioning it
anywhere.
That will be 20-25% faster than wip27, but otherwise
everything is identical.
DSP1: there's either a bug in op02, op06, or in the getSr/getDr/setDr
functions. We have so far been unable to spot the error and correct
it. Help is always welcome, as always. Please consider DSP-1 support
as not being there at all. I doubt any games will work right with it
right now :(
This is how interlace works :
I call each frame a "field", meaning even or odd fields
on your television / monitor.
When interlace is off, I draw to the even fields every
time, so you don't notice anything.
However, when interlace is on, I alternate between which one I draw
to each field. So depending on your frameskip, this can cause serious
problems for interlace mode. I also only physically draw to "half" the
resolution each field, much like a real TV would. This makes 512x448
mode just as fast as 512x224 mode.
I can't think of an easy way to cheat the system with frameskipping.
Luckily, very very few games use interlace at all. Most use hires
512x224 and that's it.
|
||
|---|---|---|
| src | ||
| bsnes.exe | ||
| license.txt | ||