Franky wrote:I win at the internet is seriouz bizness!!!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.
bsnes v0.035 released
Does [Kevin] Smith masturbate with steel wool too?
- Yes, but don’t change the subject.
- Yes, but don’t change the subject.
-
- Regular
- Posts: 347
- Joined: Tue Mar 07, 2006 10:32 am
- Location: The Netherlands
-
- ZSNES Shake Shake Prinny
- Posts: 5632
- Joined: Wed Jul 28, 2004 4:15 pm
- Location: PAL50, dood !
You kinda forgot tales of awful and barf oceanFranky wrote:Yep, the following games (and these are off the top of my head) are worthless:
(List)
皆黙って俺について来い!!
Pantheon: Gideon Zhi | CaitSith2 | Nach | kode54
Code: Select all
<jmr> bsnes has the most accurate wiki page but it takes forever to load (or something)
-
- ZSNES Developer
- Posts: 3904
- Joined: Tue Jul 27, 2004 10:54 pm
- Location: Solar powered park bench
- Contact:
7557376677!
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
_____________
Insane Coding
I meant in reagards to the first horizontal line being wrong under the circumstances I mentioned.Verdauga Greeneyes wrote: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)
Core i7 920 @ 2.66GHZ | ASUS P6T Motherboard | 8GB DDR3 1600 RAM | Gigabyte Geforce 760 4GB | Windows 10 Pro x64
-
- Regular
- Posts: 347
- Joined: Tue Mar 07, 2006 10:32 am
- Location: The Netherlands
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.Verdauga Greeneyes wrote: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).
EDIT: I'd also like to point out that I use OSS4, not alsa.
Last edited by ZH/Franky on Fri Sep 12, 2008 7:19 pm, edited 1 time in total.
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 ... >.>
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 ... >.>
-
- ZSNES Shake Shake Prinny
- Posts: 5632
- Joined: Wed Jul 28, 2004 4:15 pm
- Location: PAL50, dood !
Xenophobics find their excuses anywhere, you know. You shouldn't worry about that.byuu wrote:Ugh, I certainly didn't expect my laziness to send that kind of message ... >.>
As if japan was the only country with multibyte charsets, heh.
皆黙って俺について来い!!
Pantheon: Gideon Zhi | CaitSith2 | Nach | kode54
Code: Select all
<jmr> bsnes has the most accurate wiki page but it takes forever to load (or something)
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.
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.
-
- Seen it all
- Posts: 2302
- Joined: Mon Jan 03, 2005 5:04 pm
- Location: Germany
- Contact:
Why are you using fopen anyway? Just write your own functions that take care of these things.byuu wrote: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.
Contact the authors. And maybe the problem can be solved by converting the path into its short equivalent (GetShortPathName / PathGetShortPath).byuu wrote: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.
vSNES | Delphi 10 BPLs
bsnes launcher with recent files list
bsnes launcher with recent files list
-
- ZSNES Developer
- Posts: 3904
- Joined: Tue Jul 27, 2004 10:54 pm
- Location: Solar powered park bench
- Contact:
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.htmlbyuu wrote: 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 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.
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
_____________
Insane Coding
-
- ZSNES Developer
- Posts: 3904
- Joined: Tue Jul 27, 2004 10:54 pm
- Location: Solar powered park bench
- Contact:
OS X is UTF-8 file names, so you can use char * with everything.kode54 wrote:Does any platform besides Windows even special cases for Unicode? Oh yeah, maybe OS X.
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
_____________
Insane Coding