bsnes v030 released

ShadowFX · Post by **ShadowFX** » Mon Mar 24, 2008 5:21 pm

Verdauga Greeneyes wrote:Is ShadowFX testing on a laptop? I can't remember..

I'm running a desktop. But I've tried my laptop also (same result).
Another note, I have tried an Intel E6420 (2.1GHz) and a GeForce 8600GT (169.21 also) running on Vista and found no slowdowns whatsoever.

byuu · Post by **byuu** » Mon Mar 24, 2008 5:27 pm

Well, I'm at a loss.

It's not the video card, it's not the procesor, it's not the operating system and it's not the desktop bit depth. It's just completely random.

Oh well, nothing I can do about it, then. Hopefully I'll come up with a clever way to handle both 32-bit and 16-bit output in the future. Until then, I guess stick with v028.

Verdauga Greeneyes · Post by **Verdauga Greeneyes** » Mon Mar 24, 2008 5:39 pm

If I can get bsnes to compile again (Windows managed to slowly corrupt the system I had set up...) I might try some things. I definitely need to reformat this laptop, and figure out what's making it so unstable. Might be something hardware related, but I hope not. I'll get back to you if I find something.

Deathlike2 · Post by **Deathlike2** » Mon Mar 24, 2008 5:54 pm

If it is random, consider disabling those performance reducing options for the laptop and see if that makes a difference.

Verdauga Greeneyes · Post by **Verdauga Greeneyes** » Mon Mar 24, 2008 5:59 pm

Don't have any enabled, really. But I can't make sure they're off, as the BIOS is so locked down (i.e. contains almost no settings) as to be completely useless. Stupid ASUS and their modified BIOSes..

Verdauga Greeneyes · Post by **Verdauga Greeneyes** » Mon Mar 24, 2008 7:16 pm

byuu wrote:Max size is ~600x480 output, eg for NTSC filter with interlaced output. I rounded that up to the nearest power of two texture.

I just finished setting up a build environment, and compiled bsnes with 1024x1024 changed to 600x480. Title screen SMAS:

Code: Select all

0.028:        53-54fps
0.028 WIP 03: 35-36fps
0.030:        34-35fps
0.030 custom: 73-74fps!

So there's definitely a huge bottleneck there for my system. Want to give my version a shot, ShadowFX?

byuu · Post by **byuu** » Mon Mar 24, 2008 7:25 pm

Holy shit, why the hell does texture size even make a difference?! I'm only modifying part of the texture buffer in video RAM. It shouldn't be uploading a full 1024x1024 texture to the video card every frame.

Technically, some video cards (probably only older ones) won't support texture sizes that aren't powers of two. Though I can certainly query this and select an appropriate texture size. Either 640x480 or 1024x512.

Verdauga Greeneyes · Post by **Verdauga Greeneyes** » Mon Mar 24, 2008 7:32 pm

Out of interest, I tried setting it to 256x240, and I get 90-91 fps!

Edit: on my desktop this also makes a difference, albeit a small one: the SMB2 title runs about 3 fps faster. Interestingly, at this setting my laptop actually beats my desktop by a frame or two, as you might expect from a Core 2 Duo.

Edit2: with 256x256, my desktop performs a frame or two a second better, my laptop about a frame a second worse. Perhaps systems that don't care so much about the size prefer powers of two, and systems that do care about the size just want it as small as possible..

ShadowFX · Post by **ShadowFX** » Mon Mar 24, 2008 7:51 pm

Verdauga Greeneyes wrote:Want to give my version a shot, ShadowFX?

Please, shoot it this way!!!

FitzRoy · Post by **FitzRoy** » Mon Mar 24, 2008 8:10 pm

Holy crap, that's nearly 75% better than .028. I'd like to try your custom version out on my box, too

King Of Chaos · Post by **King Of Chaos** » Mon Mar 24, 2008 8:25 pm

Yea, same here. I wish to test that too.

Verdauga Greeneyes · Post by **Verdauga Greeneyes** » Mon Mar 24, 2008 8:41 pm

Here you go. Remember though, if you're not effected by the slowdown caused by the colour conversion, you probably won't notice any difference. Like byuu said, it's not -supposed- to matter.

ShadowFX · Post by **ShadowFX** » Mon Mar 24, 2008 9:04 pm

Verdauga Greeneyes wrote:Here you go. Remember though, if you're not effected by the slowdown caused by the colour conversion, you probably won't notice any difference. Like byuu said, it's not -supposed- to matter.

Presenting... a solid 60/60 all the time!

You might want to check the filters in your custom version, not all of them are working properly here. Pressing F11 is resulting in a garbled screen here also.
Again, this version is super fast now with Speed regulation disabled. Masterly

byuu · Post by **byuu** » Mon Mar 24, 2008 9:07 pm

What's the speed with regulation disabled? And what's the speed in v028 with speed regulation disabled? Others feel free to chime in as well.

ShadowFX · Post by **ShadowFX** » Mon Mar 24, 2008 9:12 pm

byuu wrote:What's the speed with regulation disabled? And what's the speed in v028 with speed regulation disabled? Others feel free to chime in as well.

- MK2 character select screen -
With Speed regulation off, frameskip 0 and no filters:
- 0.028 = 66/0
- 0.030c = 77/0

Verdauga Greeneyes · Post by **Verdauga Greeneyes** » Mon Mar 24, 2008 9:14 pm

ShadowFX wrote:You might want to check the filters in your custom version, not all of them are working properly here. Pressing F11 is resulting in a garbled screen here also.

Yeah, you're right. I don't know the exact cause of that, most filters seem to work alright. All I did was change four numbers

Verdauga Greeneyes · Post by **Verdauga Greeneyes** » Mon Mar 24, 2008 11:16 pm

Here's another version that works a bit better, although scanlines are still borked for some reason. You could use my shader for that though, if you really want them. I also compiled it with JMA and GZIP support. You might find it just a little slower as I had to change 600 to 640 (think byuu made a typo earlier) to get the NTSC filter to work.

byuu, I did have a quick look at the scanline filter, but what do 'pitch' and 'outpitch' stand for?

ShadowFX · Post by **ShadowFX** » Mon Mar 24, 2008 11:41 pm

Verdauga Greeneyes wrote:Here's another version that works a bit better, although scanlines are still borked for some reason. You could use my shader for that though, if you really want them. I also compiled it with JMA and GZIP support. You might find it just a little slower as I had to change 600 to 640 (think byuu made a typo earlier) to get the NTSC filter to work.

byuu, I did have a quick look at the scanline filter, but what do 'pitch' and 'outpitch' stand for?

Thanks, works great. Scanlines and 'full screen' are only remaining now to be fixed.

Verdauga Greeneyes · Post by **Verdauga Greeneyes** » Mon Mar 24, 2008 11:53 pm

ShadowFX wrote:Thanks, works great. Scanlines and 'full screen' are only remaining now to be fixed.

full screen works fine for me now, actually.. what are you seeing?

ShadowFX · Post by **ShadowFX** » Tue Mar 25, 2008 12:02 am

It seems I overlooked that both windowed and fullscreen settings can be different (filter used, screen size etc.). I had scanlines on in fullscreen while no filter was loaded in windowed, hence I thought fullscreen was bugged.

So I guess this only leaves scanlines to be fixed (aside from using your shader).

mudlord · Post by **mudlord** » Tue Mar 25, 2008 12:10 am

Though I can certainly query this and select an appropriate texture size. Either 640x480 or 1024x512.

OR 256x256 or 512x512.......

FitzRoy · Post by **FitzRoy** » Tue Mar 25, 2008 12:21 am

Yeah, no performance hit or gain over here with the custom (never had any problems, just wondered if I would gain any fps). NTSC and scanlines filters do break, however. Not seeing any fullscreen problems like firebrand is.

What is the logical reason for using a 1024x1024 size vs 256x256 size to begin with? Is this a safe change for the next version, you think, since it seems to be causing some people problems? Or are the high sizes needed for certain filters to work?

Verdauga Greeneyes · Post by **Verdauga Greeneyes** » Tue Mar 25, 2008 12:29 am

FitzRoy wrote:Yeah, no performance hit or gain over here with the custom (never had any problems, just wondered if I would gain any fps). NSTC and scanlines filters do break, however. Not seeing any fullscreen problems like firebrand is.

What is the logical reason for using a 1024x1024 size vs 256x256 size to begin with? Is this a safe change for the next version, you think, since it seems to be causing some people problems?

Did you get my second version, FitzRoy? NTSC should work in that. 640x480 is the minimum needed to make all the filters work; some (very) old cards have trouble with sizes that aren't a power of two, however, so 1024x512 would be closest; the reason byuu left it at 1024x1024 was for future extensibility and because there's no reason all 1024x1024 should actually be allocated when it's never used - but apparently on some systems, it -does- try to use all of it, hence the slowdown.

FitzRoy · Post by **FitzRoy** » Tue Mar 25, 2008 12:37 am

Thanks for explaining. I guess the mystery now is why some systems use all of it. Even though the custom is pushing you over 60, you really shouldn't have to sacrifice any performance from your real score of 90fps. So the cause is still significant.

I'm posting this now in case byuu makes another emergency release:

byuu · Post by **byuu** » Tue Mar 25, 2008 9:24 am

I'm going to try and start posting WIP news in version release threads, instead of the never-ending "bsnes thread".

That said, new WIP posted.

This version adds the offset-per-tile map caching, which gives a ~25% speedup on games that use the effect (CT title, CT black omen, Contra 3 turtle boss, SMAS: SM2 title, etc), but shouldn't affect anything else.

Testers, please play as many games as you can with offset-per-tile effects and look for errors in them. I'm fairly confident the caching works, but regression testing would be good. Don't want another major release with a serious flaw.

I've also added a new compile-time directive, USE_STATE_MACHINE. When defined (it is by default), libco is bypassed for SMP<>DSP sync. It saves 2.048 million co_switch calls a second, pushing the framerate up by ~5% (it will be more significant with slower libco versions). That's actually rather surprisingly small. That means 20m co_switch calls for a PPU would only be a ~50% slowdown. Much lower than my previous calculations.

The good news about the state machine mode is that the actual S-DSP code is exactly the same for both versions -- it's all #define magic. I really don't like this change, because I like the ideal of having the whole system in separate threads, but since it doesn't affect accuracy at all, and speed has taken a beating lately, I'll let it pass. We can always remove the define when the median processor is a Core 2 or better.

Legend:
left = v030, middle = v030 + OPT caching, right = v030 + OPT caching + S-DSP state machine

Code: Select all

117.0 / 117.0 (  0%) / 123.0 (+ 5%) zelda3
 85.0 / 108.0 (+27%) / 112.0 (+31%) ct1
 81.0 /  98.0 (+21%) / 103.0 (+27%) ct2
 81.5 / ------------ /  90.0 (+20%) mk2

OR 256x256 or 512x512.......

I'm not going to create and destroy textures every time the user changes the video filter or the SNES game toggles hires. Direct3D shouldn't be uploading the entire 1024x1024 texture every single frame. I tell it to lock the video RAM, write the new data in, and unlock it. If D3D is stupid enough to try and cache the whole texture in system RAM to upload, then I don't know what to tell you.

What we need to do is track down why certain systems are getting this major speed hit, not rig in a fix of cutting down on the texture size.

I'm posting this now in case byuu makes another emergency release:

I'd like to get my latest changes out there, but I think I'll wait a while. Probably starting to annoy the news sites again with such quick releases.

The controller graphic looks great. I'll wait until you finish it (or are you done now?) before merging it in, though. Takes quite a while to encode it on my side.