bsnes v0.034 released

[byuu]

The MinGW4 builds with PGO I make are only ~10% faster (compared to ~30% for MSVC), and they crash periodically when the non-PGO code does not.

But if you have an alternate method, it's certainly worth a try. Any speedup helps with the sysreqs I have now.

[Nach]

Are there any particular CPUs to market for?

Or are there any CPUs which it would be okay to lock out from optimized PGO builds?

Using various instruction sets makes a difference here.

As regards to not getting as much of a PGO speed up. MSVC is slower for general code, but optimizes a lot of things by seeing what is used. Since GCC out optimizes the general code, there's less to gain by making the more likely branch first.

[byuu]

Are there any particular CPUs to market for?

I do all of my bug fixing on a P4 1.7GHz, so I'd like it to work on that. But we really only need to target CPUs that can get ~55fps in the first place for an optimized build. Nobody's going to really use the emulator if they can't get 60fps without frameskipping. We can release an unoptimized version for that case, anyway.

Using various instruction sets makes a difference here.

Probably would want to stop at SSE2 at the very most.

As regards to not getting as much of a PGO speed up. MSVC is slower for general code, but optimizes a lot of things by seeing what is used. Since GCC out optimizes the general code, there's less to gain by making the more likely branch first.

Yes, very true. I get ~10% faster code with GCC4 -O3 than with MSVC /O2. I suppose they would be pretty close to equal with GCC4 PGO. Perhaps if you can get it working without the program crashing randomly afterward, that'd be great.

PGO kind of sucks for making new releases, but I'll deal for the free speedup.

[Fes]

Have example expressions that trigger the warning?

Here's the full list of the warnings of this type I encountered.

Code: Select all

src\ui\interface.cpp(34) : warning C4805: '==' : unsafe mix of type 'intmax_t' and type 'bool' in operation
src\ui\settings/videosettings.cpp(94) : warning C4805: '!=' : unsafe mix of type 'intmax_t' and type 'bool' in operation
src\ui\settings/videosettings.cpp(102) : warning C4805: '!=' : unsafe mix of type 'intmax_t' and type 'bool' in operation
src\ui\settings/videosettings.cpp(110) : warning C4805: '!=' : unsafe mix of type 'intmax_t' and type 'bool' in operation
src\ui\settings/videosettings.cpp(118) : warning C4805: '!=' : unsafe mix of type 'intmax_t' and type 'bool' in operation
src\cart\cart_file.cpp(155) : warning C4805: '==' : unsafe mix of type 'intmax_t' and type 'bool' in operation
src\ppu\bppu\bppu_render_bg.cpp(105) : warning C4805: '==' : unsafe mix of type 'intmax_t' and type 'bool' in operation
src\ppu\bppu\bppu_render_oam.cpp(5) : warning C4805: '==' : unsafe mix of type 'intmax_t' and type 'bool' in operation
src\chip\spc7110\decomp.cpp(115) : warning C4805: '&' : unsafe mix of type 'unsigned int' and type 'bool' in operation
src\chip\spc7110\decomp.cpp(208) : warning C4805: '&' : unsafe mix of type 'unsigned int' and type 'bool' in operation
src\chip\spc7110\decomp.cpp(315) : warning C4805: '&' : unsafe mix of type 'unsigned int' and type 'bool' in operation

These next two are in templates, reported each time the template is instantiated:

Code: Select all

src\cpu\cpuregs.h(6) : warning C4804: '-' : unsafe use of type 'bool' in operation
src\smp\smpregs.h(6) : warning C4804: '-' : unsafe use of type 'bool' in operation

It will error out with an internal compiler error, advising you to contact Microsoft.

Heh, wow. One would have hoped stuff like that would have gone out with msvc6, but alas. Even the C# compiler in 2k5 had a problem like that where the grammar was wrong and you could apply post-inc/dec to function calls, which of course makes no sense. Compiling it would succeed, but the the compiler actually generated incorrect code that underflowed the stack machine and killed the CLR with InvalidProgramException. That was some comedy there.

[I.S.T.]

Test all B games up to but not including the BS games. They work fine.

However, I've found another problem.

The way I've been testing is loading up the game, waiting to hear or see something, unloading it via unload cartridge, opening the load game menu, deleting the game I just tested and starting up the new one. After doing this for a while, my folders start acting weird. I can't access the folder that has the roms, and I can't access the User folder on my C drive(Using Windows Vista SP1 X64).

After a while, it wears off, and things are OK. I'm gonna wait for it to wear off, then load and unload games using that method on an earlier version of bsnes.

Edit: semi-false alarm. It looks like my userpage on Vista got corrupted and was only being triggered by bsnes. I deleted it, redid it and everything's working fine now.

Tested up to and including BS Fire Emblem - Akaneia Senki Hen - Dai-4-wa - Hajimari no Toki (Japan). I've noticed bugs on several different games, with some starting but staying at a black screen(The speed goes up to 150-178 FPS with speed regulation turned off on these). I take it that's due to the buggy nature of BS dumps?

Edit: Tested up to and including BS Kodomo Chousadan Mighty Pockets Chousa 3 - Kyakusen Queen Patra no Nazo (Japan). Also, BS Ikari no Yousai has the coolest intro ever.

[tetsuo55]

Test all B games up to but not including the BS games. They work fine.

However, I've found another problem.

The way I've been testing is loading up the game, waiting to hear or see something, unloading it via unload cartridge, opening the load game menu, deleting the game I just tested and starting up the new one. After doing this for a while, my folders start acting weird. I can't access the folder that has the roms, and I can't access the User folder on my C drive(Using Windows Vista SP1 X64).

After a while, it wears off, and things are OK. I'm gonna wait for it to wear off, then load and unload games using that method on an earlier version of bsnes.

Edit: semi-false alarm. It looks like my userpage on Vista got corrupted and was only being triggered by bsnes. I deleted it, redid it and everything's working fine now.

Tested up to and including BS Fire Emblem - Akaneia Senki Hen - Dai-4-wa - Hajimari no Toki (Japan). I've noticed bugs on several different games, with some starting but staying at a black screen(The speed goes up to 150-178 FPS with speed regulation turned off on these). I take it that's due to the buggy nature of BS dumps?

Edit: Tested up to and including BS Kodomo Chousadan Mighty Pockets Chousa 3 - Kyakusen Queen Patra no Nazo (Japan). Also, BS Ikari no Yousai has the coolest intro ever.

Most of the BS games should work in some way, but there are quite a few that have corrupt graphics or black screens.

[FitzRoy]

The way I've been testing is loading up the game, waiting to hear or see something, unloading it via unload cartridge,

If a game is getting mapped wrong, it usually still functions, but with odd graphics glitches. There was a time way back when lots of fighting games did this because they were hirom and bsnes was seeing them as lorom. So this method of testing is not the best strategy, I'm guessing.

[byuu]

If a game is getting mapped wrong, it usually still functions, but with odd graphics glitches.

I would be surprised if that were very common ... bad mapping means it's reading bad opcodes right from the start.

There was a time way back when lots of fighting games did this because they were hirom and bsnes was seeing them as lorom.

That was because I was mapping SRAM to the wrong areas, and mirroring incorrectly in some cases, IIRC.

Still, I won't argue with more testing :)

Do you either of you recall that issue with the "A" game IST listed above?

[tetsuo55]

Do you either of you recall that issue with the "A" game IST listed above?

I think I found a bug. Aryol's first screen(The one that shows who published it) has part of a letter in the upper left corner of the screen. It's the same font as either the word Presents or the first letter of the company's logo.

I forgot to mention I'm using the dump found on No-Intro's list and there's only one version of the game(unless it was renamed when released anywhere other than Japan.).

I don't recall that one, its very sneaky(almost slipped passed me as "part of the logo screen") i just confirmed it on version .17
It's definately one that is invisable on correctly calibrated televisions though, It's in the exact same place as the sim-city garbage tiles would be

It also doesn't look like a timing issue because its static and consistent

[byuu]

It's definately one that is invisable on correctly calibrated televisions though

What about on incorrectly calibrated ones, where you can see all of the top left "overscan" area? :/
And .017? Heh, last version with range-based IRQ testing. Don't blame you for using that one.

[Nach]

Okay, I looked into sound a bit.

Be warned that I'm not at home on the moment, and the PC here has a junky sound card and speakers, so it was hard to hear the difference.

I had to run SPL4 under ALSA/OSS/AO and OpenAL a few times to clearly hear the difference, but yeah, I noticed it.

In openal.cpp, delete all this:

Code: Select all

        //disable unused 3D features
        alSourcef (device.source, AL_PITCH, 1.0);
        alSourcef (device.source, AL_GAIN, 1.0);
        alSource3f(device.source, AL_POSITION, 0.0, 0.0, 0.0);
        alSource3f(device.source, AL_VELOCITY, 0.0, 0.0, 0.0);
        alSource3f(device.source, AL_DIRECTION, 0.0, 0.0, 0.0);
        alSourcef (device.source, AL_ROLLOFF_FACTOR, 0.0);
        alSourcei (device.source, AL_SOURCE_RELATIVE, AL_TRUE);

I forgot where I noticed those lines in an example, but apparently we are using those 3D features.

Once doing so, there is no noticeable difference anymore (on this junky setup anyway). If it still sounds a bit off for you afterwards, let me know.

I'm not not sure if these should stay or not:

Code: Select all

        alListener3f(AL_POSITION, 0.0, 0.0, 0.0);
        alListener3f(AL_VELOCITY, 0.0, 0.0, 0.0);
        ALfloat listener_orientation[] = { 0.0, 0.0, -1.0, 0.0, 1.0, 0.0 };
        alListenerfv(AL_ORIENTATION, listener_orientation);

I can't hear a difference here with or without those 4 lines. If you can't either byuu, leave them.

As for ALSA, I quickly looked over the file included in the latest source, and noticed one issue right away, you commented out the code that prevents a crash if the sound ever locks out during play for too long.

Code: Select all

  /*if(i < 0) {
      if(buffer.data == buffer_ptr) {
        buffer.length--;
        buffer_ptr++;
      }
      memmove(buffer.data, buffer_ptr, buffer.length * sizeof(uint32_t));
    }*/

Thus if the sound fails to play for a while, buffer.length is never decremented, ending up that buffer.length will index past the end of buffer.data, and crash.

I can recreate the crash here on this bad sound card when I change the speed of bsnes to some values that it seems unable to play at.

Something else about what you changed also looks wrong, but I can't quite put my finger on it, I'll look more later.

[I.S.T.]

>.> Sorry it took me a while, but I finished off all of the B games. I'll start on the C games in about an hour. Because of all of the fucking BS dumps, there were nearly twice as many as the C games. It's at least 50% higher...

After that, I guess I'll do like half a letter a day or something.

Edit: Got up to but not including Ci on that. Will get more later.

[ShadowFX]

Dutch translation updated for v0.034:

Download!

[byuu]

Thus if the sound fails to play for a while, buffer.length is never decremented, ending up that buffer.length will index past the end of buffer.data, and crash.

Ah, I didn't understand that bit at all, was meaning to ask you about it first.

I wasn't sure how dropping a single cycle would do much to help with a freeze, instead dropping speed to ~1fps or so. Wouldn't it be better to perhaps flush the buffer when this happens?

[Josh]

Is there a way to see all 240 vertical pixels, instead of just 224?

[Nach]

Thus if the sound fails to play for a while, buffer.length is never decremented, ending up that buffer.length will index past the end of buffer.data, and crash.

Ah, I didn't understand that bit at all, was meaning to ask you about it first.

I wasn't sure how dropping a single cycle would do much to help with a freeze, instead dropping speed to ~1fps or so. Wouldn't it be better to perhaps flush the buffer when this happens?

Dropping the whole buffer too could also work.

However, it if only locks up for a frame or two, should we really dump all the audio?

Also consider that if it's all dumped, when it unlocks (if it ever does), sound will be empty, as opposed as being able to play a bit, when sound comes back on.

[FitzRoy]

Is there a way to see all 240 vertical pixels, instead of just 224?

Video Mode(Resolution) > PAL

[I.S.T.]

All C games tested. Only one didn't work, and it was a Sufami Turbo cart. I have no idea how to proper load those(Three carts needed to use a game? WTF?).

I'd say that means the new header detection should be fine. I'll continue to test, however.

[King Of Chaos]

Only one didn't work, and it was a Sufami Turbo cart. I have no idea how to proper load those(Three carts needed to use a game? WTF?).

System > Load Special > Load Sufami Turbo Cartridge.

Set the Base Cartridge (Sufami Turbo BIOS (J).smc) and load the Slot A and Slot B cartridges and it should work well.

[byuu]

Posted a new WIP. Another public one:

Code: Select all

http://byuu.cinnamonpirate.com/temp/bsnes_v034_wip04.zip

See the "bsnes vsync" thread for the details.

Once doing so, there is no noticeable difference anymore (on this junky setup anyway). If it still sounds a bit off for you afterwards, let me know.

It does, I didn't hear any difference after removing those lines. I also tried setting the two orientation values (-1 and 1) to 0.0, no effect there, either. Still open to ideas.

I also un-commented the buffer shift thing as-is, since you said it matters. Thanks for explaining it.

Something else about what you changed also looks wrong, but I can't quite put my finger on it, I'll look more later.

Hmm, let me know if you spot anything, please.

[ShadowFX]

Posted a new WIP.

I'm not sure but maybe you missed my updated Dutch translation just a couple of posts above. Just a heads up

Edit: I see that there are modifications in progress. I guess I'll hold off until the final arrives.

[Josh]

Is there a way to see all 240 vertical pixels, instead of just 224?

Video Mode(Resolution) > PAL

Does that change any other aspect of emulation or the effects of any other options, other than being able to see all the pixels?

[I.S.T.]

Only one didn't work, and it was a Sufami Turbo cart. I have no idea how to proper load those(Three carts needed to use a game? WTF?).

System > Load Special > Load Sufami Turbo Cartridge.

Set the Base Cartridge (Sufami Turbo BIOS (J).smc) and load the Slot A and Slot B cartridges and it should work well.

So, load the same ROM in slot A and B?

I'll go try that...

Edit: Nevermind, it's already been deleted. Fuck >.<

[henke37]

Pal has a different framerate for the display.

[I.S.T.]

All d games work.

Also, reobtained that set(Yes, let's call it that...) and got the two ST games back. Both work when properly loaded.