Update to bsnes v033r08? release.

I wish I could post the new WIP, I really need it tested. But it looks
like vstech.net (cinnamonpirate.com's host) got sucked into a black
hole, literally. You can't even nslookup it. So ... sorry.

What I did today was:
- remove an unnecessary ternary condition in HDMA CPUsync (no visible
effect on emulation or speed.)
- move controller ports from settings to system.
- rewrite SPC7110 decompression engine from scratch.

The last one obviously the most important. I took neviksti's most
recent decompressor code, made the essential variables static, added a
bool init parameter you can use to start a new decompression sequence,
and built up a dual-indexed (read+write cursor) ring buffer to stream
byte sequences. I set the buffer to >= 32 bytes at a time. I also
simplified a few parts, like the swap sequence for pixel ordering; and
I took out the end of each function that computes length, since that's
no longer needed (nor is bot.)

The result is you can stream an infinite number of bytes safely from
decompression, and nothing will ever go out of bounds of the data ROM.

Speed results on Core 2 Duo E6600 @ stock 2.4GHz:
FEoEZ cart riding sequence - 91fps (was 40fps)
MDH title screen - 111fps (was 29fps)
SPL4 title screen with players running across screen - 118fps (was
35fps)

For comparison, Star Ocean in-game gets ~95fps.

I didn't think we would need that many optimizations to get SPC7110
support running at full speed (how complex could a low-cost IC from
1995 be?), good to see I was right.

As soon as vstech comes back (hopefully tomorrow), I'll post the PD /
BSDL source, and get it sent over to GIGO. Hopefully he can add it to
SNESGT.

Speaking of which ... neviksti:
In your updated DecompMode0.c file, you declare NUM_CONTEXTS as 15,
but it should be 30. I'm guessing it runs fine in isolation (memory
initializes to zero and all that), but when mode 2 ran and set
contexts up to 32; only clearing 15 was resulting in corrupted
graphics all over. No big deal, just mentioning it.

> I don't really understand your (or byuu's) point. If the game does
> indeed works on 99.9% of units...on what do you base yourself to say
> their programming suck or that the game is "broken"? I mean, it
> works, it works right?


This is the problem I have with the black-and-white "bug" label ... it
implies a game is broken to a casual observer, or there is at least
noticeable corruption on at least one screen.

In truth, bsnes has a few visible bugs. Street Racer will flicker one
frame on the title screen, but only one time, and only once every ~4-8
runs. Adventures of Dr Franken and Winter Olympics show one black
scanline because the games update OBSEL at very unusual points mid-
frame.

And there are countless "anti-bugs", eg Battle Blaze on the fighter
select screen is supposed to show some garble up at the top due to
mid-scanline PPU writes. Because bsnes renders an entire scanline at
once, you don't see this. Lots and lots of games will have 1-16 pixels
on one scanline at the left (usually not even visible on TVs) that
flicker due to writing PPU regs past the end of hblank.

BoF2 German detects emulators by reading the division register early.
Since no emulator supports that, you don't see the anti-piracy splash
screen.

All of those could be considered bugs to varying degrees.

I suppose what would be nice is a bug severity ranking system.
"Severe" if it's game ruining, "Moderate" if it's more than one
scanline / frame that glitches graphics or something, and "Minor" for
the stuff 95% of people probably won't even notice. Or something like
that. My point is that it doesn't make a lot of sense to work on the
minor stuff. Most of that will probably go away with a cycle-based PPU
anyway, and the rest will probably continually appear and disappear
with infinitesimal timing changes.

[No archive available]
This commit is contained in:
byuu
2008-08-07 13:39:00 +00:00
parent acee547da9
commit bccc5b5a12
Update to bsnes v033r08? release.

Diff Content Not Available
