bsnes v0.035 released

[funkyass]

That's absurd. Every single SFX and SA-1 game is 1000 orders of magnitude better than all other SNES games combined. It's not even worth having SNES emulation without SFX or SA-1 support, as not a single plain SNES game is worthwhile in the slightest.

I win at the internet is seriouz bizness!!!

[franpa]

Hey, was there ever an issue with vsync when only syncing to audio, fullscreen and scale 5x under Windows?

[Verdauga Greeneyes]

Well, I don't know what you mean by 'an issue', but bsnes didn't respect VSync at all in the past (if you forced it to, this lead to audio crackling)

[grinvader]

Yep, the following games (and these are off the top of my head) are worthless:
(List)

You kinda forgot tales of awful and barf ocean

[Nach]

7557376677!

[franpa]

Well, I don't know what you mean by 'an issue', but bsnes didn't respect VSync at all in the past (if you forced it to, this lead to audio crackling)

I meant in reagards to the first horizontal line being wrong under the circumstances I mentioned.

[Verdauga Greeneyes]

Bsnes now synchronises with video and audio (assuming you enabled both options, of course). What this means is that it will wait for video to enter VBlank before Presenting, thereby avoiding randomly bisecting the screen with the next frame (the tearing you'd see on previous versions). However, this means it only has a small window (~0.5ms) to present the Video, and especially if it's still busy synchronising audio as VBlank begins, this means it might be just a little too late. This means the monitor has already begun drawing, and the data it's using will change suddenly near the top of the screen, leading to the effect seen with max scaling (if the image fills only a part of the screen, bsnes has more time to present the image before the monitor starts to draw it).

[ZH/Franky]

Bsnes now synchronises with video and audio (assuming you enabled both options, of course). What this means is that it will wait for video to enter VBlank before Presenting, thereby avoiding randomly bisecting the screen with the next frame (the tearing you'd see on previous versions). However, this means it only has a small window (~0.5ms) to present the Video, and especially if it's still busy synchronising audio as VBlank begins, this means it might be just a little too late. This means the monitor has already begun drawing, and the data it's using will change suddenly near the top of the screen, leading to the effect seen with max scaling (if the image fills only a part of the screen, bsnes has more time to present the image before the monitor starts to draw it).

I still have bsnes .034 (which doesn't have vsync), and on linux+xv, I get no tearing whatsoever. xv itself is basically a vsync option.

EDIT: I'd also like to point out that I use OSS4, not alsa.

[byuu]

Linux sound APIs tend to handle buffer under-runs much more gracefully than Windows / DirectSound, but v035 will still sound better by (hopefully) not having any.

[byuu]

Well, this is bad ...

http://pc11.2ch.net/test/read.cgi/software/1218035650/

Post #110 mentions the bug where bsnes crashes when you have multi-byte characters in the path name. The poster mentions, "…bsnesの作者、日本嫌いになったか？" -- "... does the bsnes author hate Japan?"

Ugh, I certainly didn't expect my laziness to send that kind of message ... >.>

[SmartOne]

They should use the language of success: English.

[grinvader]

Ugh, I certainly didn't expect my laziness to send that kind of message ... >.>

Xenophobics find their excuses anywhere, you know. You shouldn't worry about that.

As if japan was the only country with multibyte charsets, heh.

[byuu]

What's worse is it's the second or third time I've seen that now.

You'd think my name, the old site bitmap with Japanese in it, and the Japanese locales would make it pretty clear that I have no qualms with Japan. Now the French, however ... heheh, just kidding ;)

Anyway, I kind of sort of have a workaround now, but it's pretty nasty.

GetOpenFileNameA does me no good at all. I get back ???s for Unicode. Can't open the file, can't display the name.

With GetOpenFileNameW, I get the name properly in wchar_t, and I can read files with it using _wfopen. But hiro was designed to work with UTF-8 only.

So, the only thing I can think of is to wrap all instances of fopen() with a special routine that converts UTF-8 to Unicode/UTF-16/UCS-2/whatever the fuck, and use _wfopen. But only on Windows.

The next problem is that ZIP / GZ support uses fopen() internally, and JMA uses std::ifstream internally. Both expect const char* filenames. The former can use _wfopen, and the latter std::ifstream foo(_wfopen()). Both extremely non-portable.

I really don't want to dig into those libraries to patch them. And I don't have permission to modify JMA, anyway.

But ... I can at least stop the crashing on loading the config files and uncompressed ROMs.

I'll put a release together with that and the HDMA fix, I suppose.

[creaothceann]

With GetOpenFileNameW, I get the name properly in wchar_t, and I can read files with it using _wfopen. But hiro was designed to work with UTF-8 only.

So, the only thing I can think of is to wrap all instances of fopen() with a special routine that converts UTF-8 to Unicode/UTF-16/UCS-2/whatever the fuck, and use _wfopen. But only on Windows.

Why are you using fopen anyway? Just write your own functions that take care of these things.

The next problem is that ZIP / GZ support uses fopen() internally, and JMA uses std::ifstream internally. Both expect const char* filenames. The former can use _wfopen, and the latter std::ifstream foo(_wfopen()). Both extremely non-portable.

I really don't want to dig into those libraries to patch them. And I don't have permission to modify JMA, anyway.

But ... I can at least stop the crashing on loading the config files and uncompressed ROMs.

Contact the authors. And maybe the problem can be solved by converting the path into its short equivalent (GetShortPathName / PathGetShortPath).

[gllt]

Buy them hooked on phonics.

[Nach]

The next problem is that ZIP / GZ support uses fopen() internally, and JMA uses std::ifstream internally. Both expect const char* filenames. The former can use _wfopen, and the latter std::ifstream foo(_wfopen()). Both extremely non-portable.

I really don't want to dig into those libraries to patch them. And I don't have permission to modify JMA, anyway.

I'm making a class to handle all kinds of issues. When using libstdc++, it'd be possible to use any built in OS function that returns a FILE * or file descriptor to build the class: http://gcc.gnu.org/onlinedocs/libstdc++ ... 2ch38.html

I could easily add for Windows to use a wchar_t * / wstring open call which wraps to using _wopen() to get an fd to build upon.

The issue is how to make it work on all kinds of other OSs, and having it wrap around other source classes when not using libstdc++. Most C++ libs though offer some kind of way to use a file descriptor to initialize the stream. I'd be happy to make my lib around all the other popular stuff out there, given I can test it.

[kode54]

Does any platform besides Windows even special cases for Unicode? Oh yeah, maybe OS X.

[Nach]

Does any platform besides Windows even special cases for Unicode? Oh yeah, maybe OS X.

OS X is UTF-8 file names, so you can use char * with everything.