bsnes v0.038 released

Archived bsnes development news, feature requests and bug reports. Forum is now located at http://board.byuu.org/
Locked
byuu

Post by byuu »

So, if I'm reading it correctly, Qt-based open-source software can use a non-GPL license just as long as it's one of the licenses listed there. So you probably can't use a custom license, but at the very least it doesn't have to be GPL.
Yes, it just has to be a license others can convert to the GPL, acts just like the GPL (CDDL et al), or transfers ownership to the Q continuum.

Eh, maybe one of these days I'll write an elaborate inter-process communication wrapper to use Qt in closed source apps. Eg custom app speaks daemon API to daemon. Public domain daemon translates between its API and Qt, and forwards to Qt itself.
85cocoa
Hazed
Posts: 55
Joined: Sat Jul 22, 2006 8:43 pm
Location: USA

Post by 85cocoa »

Quick question about the forum: Shouldn't the "bsnes v0.038 to-do list" thread be unstickied and closed?
[url=http://en.wikipedia.org/wiki/Pocky]Pocky[/url] & [url=http://en.wikipedia.org/wiki/Rocky]Rocky[/url]? [url=http://en.wikipedia.org/wiki/Pocky_%26_Rocky]Pocky & Rocky[/url]? [url=http://en.wikipedia.org/wiki/Sonic_the_Hedgehog_%28series%29#Animals.2FMobians]Pocky & Rocky[/url]?
franpa
Gecko snack
Posts: 2374
Joined: Sun Aug 21, 2005 11:06 am
Location: Australia, QLD
Contact:

Post by franpa »

or renamed to "bsnes v0.039 to-do list" and updated? :)
Core i7 920 @ 2.66GHZ | ASUS P6T Motherboard | 8GB DDR3 1600 RAM | Gigabyte Geforce 760 4GB | Windows 10 Pro x64
Verdauga Greeneyes
Regular
Posts: 347
Joined: Tue Mar 07, 2006 10:32 am
Location: The Netherlands

Post by Verdauga Greeneyes »

funkyass wrote:should it not be

(x-a)³ = (x³ - 3ax² + 3a²x - a³)
Aah, you're right, I made a typo. Sorry, it was very late - I've fixed my posts.
King Of Chaos
Trooper
Posts: 394
Joined: Mon Feb 20, 2006 3:11 am
Location: Space

Post by King Of Chaos »

franpa wrote:or renamed to "bsnes v0.039 to-do list" and updated? :)
*smacks Frampa for actually having a good idea for once*

Nice work Byuu, the new release is working fine here, no problems whatsoever. =)
[url=http://www.eidolons-inn.net/tiki-index.php?page=Kega]Kega Fusion Supporter[/url] | [url=http://byuu.cinnamonpirate.com/]bsnes Supporter[/url] | [url=http://aamirm.hacking-cult.org/]Regen Supporter[/url]
FirebrandX
Trooper
Posts: 376
Joined: Tue Apr 19, 2005 11:08 pm
Location: DFW area, TX USA
Contact:

Post by FirebrandX »

byuu wrote:
I did some testing and the speed hit was about 8%, though the lowest FPS was still well above 90, so I'm well in the clear of the 60 minimum I like to have.
Darn, only 90. At least v036 or so's S-DSP state machine approach boosted it 10% before this hit; so we're back to the same performance as then. And hopefully the delta queue method will pan out for some extra speed.
To be clear, the 95ish fps was the lowest point in the test. I just used the full intro loop to Chrono Trigger and compared FPS at various points in it. The highest point was over 150fps.
Rhapsody
Rookie
Posts: 23
Joined: Wed Jul 02, 2008 3:35 pm

Post by Rhapsody »

byuu wrote:Eh, maybe one of these days I'll write an elaborate inter-process communication wrapper to use Qt in closed source apps. Eg custom app speaks daemon API to daemon. Public domain daemon translates between its API and Qt, and forwards to Qt itself.
I'm pretty sure Trolltech (well, Qt Software now, but I still call them Trolltech) wouldn't be happy about that. The whole reason Qt isn't under the LGPL is because then everyone could link their closed source apps to it (just like with GTK+), meaning they wouldn't have to purchase one of Trolltech's commercial licenses. That would be bad, since it's the primary way they make money off Qt. They'll probably not consider any license changes as long as Opera and Google are willing to pay them.

To me though, this seems like a bizarre way of getting around a problem that you invented for yourself. I really don't think anyone's going to try and fork bsnes at this point, and it's well-known enough that the users that actually matter to you wouldn't pay any attention to one now.
belegdol
Hazed
Posts: 68
Joined: Tue Dec 07, 2004 10:24 am

Post by belegdol »

Thanks for the new release! I tested the new PulseAudio driver with Fedora 10 x86_64 (pulseaudio 0.9.13) and the results are strange. The sound quality is definitely better than the other PA option (openal -> sdl -> PA), but the emulation is not smooth. That is, it stops for a moment every few moments. I tried both PAL (Super Metroid) and NTSC (Lost Vikings II). It is also present in the other case, but in a lesser extent. I did not observe that behaviour when using OSS (alsa emulation) or ALSA. Can something be done to improve the situation?
byuu

Post by byuu »

I'm pretty sure Trolltech (well, Qt Software now, but I still call them Trolltech) wouldn't be happy about that.
They chose the GPL, not me ;)
Seriously, too much work anyway. More of a joke post than anything.
Can something be done to improve the situation?
Sure. Either fix the PulseAudio daemon, or find the bug in my driver:

Code: Select all

    device.spec.format   = PA_SAMPLE_S16LE;
    device.spec.channels = 2;
    device.spec.rate     = settings.frequency;
    device.handle = pa_simple_new(
      0,                   //default server
      "ruby::pulseaudio",  //application name
      PA_STREAM_PLAYBACK,  //direction
      0,                   //default device
      "audio",             //stream description
      &device.spec,        //sample format
      0,                   //default channel map
      0,                   //default buffering attributes
      &error               //error code
    );
    //buffer.offset holds how many samples are in the buffer now, obviously
    pa_simple_write(device.handle, (const void*)buffer.data, buffer.offset * sizeof(uint32_t), &error);
That's it. Two API calls, and it isn't working right. What do you suggest I do to fix the fifth Linux audio API driver? :P
Last edited by byuu on Wed Dec 17, 2008 5:44 pm, edited 1 time in total.
belegdol
Hazed
Posts: 68
Joined: Tue Dec 07, 2004 10:24 am

Post by belegdol »

OK, I'll try to make PA gurus look into it.
byuu

Post by byuu »

Cool. Wanna try making it into a sine wave generator app so they have an easier test case?

I mean, it's not as if it needs to be any simpler (you'd think they'd have debugged the one function I call to output audio ...), but yeah.

I don't have PulseAudio, so stabbing in the dark here ... if you could, please tweak this to actually compile and run on your side, if you don't mind.

Code: Select all

#include <stdint.h>
#include <pulse/simple.h>
#include <pulse/error.h>

//PulseAudio simple test -- no error handling
int main() {
  pa_simple *handle;
  pa_sample_spec spec;
  uint32_t buffer[64];

  spec.format   = PA_SAMPLE_S16LE;
  spec.channels = 2;
  spec.rate     = 32000;

  int error = 0;
  handle = pa_simple_new(
    0,                   //default server
    "ruby::pulseaudio",  //application name
    PA_STREAM_PLAYBACK,  //direction
    0,                   //default device
    "audio",             //stream description
    &spec,               //sample format
    0,                   //default channel map
    0,                   //default buffering attributes
    &error               //error code
  );

  while(true) {
    for(unsigned i = 0; i < 64; i++) {
      int16_t sample = sin(i * 2 * M_PI / 64) * 0x2000;  //may need tweaking
      buffer[i] = (sample << 16) | sample;  //left and right
    }
    int error = 0;
    pa_simple_write(handle, (const void*)buffer, 64 * sizeof(uint32_t), &error);
  }

  pa_simple_flush(handle, &error);
  pa_simple_free(handle);
  return 0;
}
If you can get that to work; then it should work in bsnes, too.

(EDIT: fixed)
Last edited by byuu on Wed Dec 17, 2008 8:53 pm, edited 1 time in total.
belegdol
Hazed
Posts: 68
Joined: Tue Dec 07, 2004 10:24 am

Post by belegdol »

I made that compile by changing buffer[buffer.offset++] to buffer, and it makes noise. Why bsnes stops every few secs then? To make myself clear, sound is perfectly fine, it's video that stops.
belegdol
Hazed
Posts: 68
Joined: Tue Dec 07, 2004 10:24 am

Post by belegdol »

More info: I ran strace bsnes just in case, and the stops problem was gone. Due to increased CPU demand bsnes was not able to run 50/50 fps all the time, but the visible framerate was much more steady.
Verdauga Greeneyes
Regular
Posts: 347
Joined: Tue Mar 07, 2006 10:32 am
Location: The Netherlands

Post by Verdauga Greeneyes »

Have you tried running any NTSC games? If you're syncing to video it's probably just duplicating a lot of frames because your refreshrate is higher than the framerate. Disabling sync to video will make it tear (by drawing outside VBlank) instead of duplicating frames, but the more closely your refreshrate matches the framerate of the game, the better it'll look.
belegdol
Hazed
Posts: 68
Joined: Tue Dec 07, 2004 10:24 am

Post by belegdol »

I tried, and turning the sync option on and off does not seem to influence this behaviour.
Nach
ZSNES Developer
ZSNES Developer
Posts: 3904
Joined: Tue Jul 27, 2004 10:54 pm
Location: Solar powered park bench
Contact:

Post by Nach »

Rhapsody wrote:
byuu wrote:Eh, maybe one of these days I'll write an elaborate inter-process communication wrapper to use Qt in closed source apps. Eg custom app speaks daemon API to daemon. Public domain daemon translates between its API and Qt, and forwards to Qt itself.
I'm pretty sure Trolltech (well, Qt Software now, but I still call them Trolltech) wouldn't be happy about that. The whole reason Qt isn't under the LGPL is because then everyone could link their closed source apps to it (just like with GTK+), meaning they wouldn't have to purchase one of Trolltech's commercial licenses. That would be bad, since it's the primary way they make money off Qt. They'll probably not consider any license changes as long as Opera and Google are willing to pay them.
They actually did change the license, they now are under GPL3 too.

Unless my reading of GPL3 is way off, they now have a loophole which allows linking a library to a closed source app - yes the GPL3 sucks.

Oh and BTW, under GPL2, many open source programs in fact violate the license. You can't link to DirectX or anything that links to DirectX since you're merging with a closed source library. Basically ZSNES on Windows and a slew of other programs are illegal.
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
Rhapsody
Rookie
Posts: 23
Joined: Wed Jul 02, 2008 3:35 pm

Post by Rhapsody »

Nach wrote:They actually did change the license, they now are under GPL3 too.

Unless my reading of GPL3 is way off, they now have a loophole which allows linking a library to a closed source app - yes the GPL3 sucks.
What part are we talking about here? I've heard lots of talk about the GPLv3, but this one is new.
Nach wrote:Oh and BTW, under GPL2, many open source programs in fact violate the license. You can't link to DirectX or anything that links to DirectX since you're merging with a closed source library. Basically ZSNES on Windows and a slew of other programs are illegal.
I thought section 3 covered that.
The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.
Unless you actually include DirectX with the program, this exception should cover ZSNES perfectly well as DirectX is a part of Windows.
Nach
ZSNES Developer
ZSNES Developer
Posts: 3904
Joined: Tue Jul 27, 2004 10:54 pm
Location: Solar powered park bench
Contact:

Post by Nach »

Rhapsody wrote:
Nach wrote:They actually did change the license, they now are under GPL3 too.

Unless my reading of GPL3 is way off, they now have a loophole which allows linking a library to a closed source app - yes the GPL3 sucks.
What part are we talking about here? I've heard lots of talk about the GPLv3, but this one is new.
I'll reread it and get back to you.
Rhapsody wrote:
Nach wrote:Oh and BTW, under GPL2, many open source programs in fact violate the license. You can't link to DirectX or anything that links to DirectX since you're merging with a closed source library. Basically ZSNES on Windows and a slew of other programs are illegal.
I thought section 3 covered that.
The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.
Unless you actually include DirectX with the program, this exception should cover ZSNES perfectly well as DirectX is a part of Windows.
You're looking at the wrong part, yes you don't have to include DirectX in your source package because it comes with the OS. However, you're still forbidden to link to it via the rest of the GPL.

Also under this section, you're required to ship with the source, the source to any libraries you use which aren't standard with the system, meaning that technically ZSNES must ship with libao source. Or that every Qt program has to ship with Qt source.
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
Nach
ZSNES Developer
ZSNES Developer
Posts: 3904
Joined: Tue Jul 27, 2004 10:54 pm
Location: Solar powered park bench
Contact:

Post by Nach »

Here it is:

Code: Select all

A compilation of a covered work with other separate and independent works, which are not by their nature extensions of the covered work, and which are not combined with it such as to form a larger program, in or on a volume of a storage or distribution medium, is called an “aggregate” if the compilation and its resulting copyright are not used to limit the access or legal rights of the compilation's users beyond what the individual works permit. Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate.
Translation:
If one wishes to compile a GPLv3 licensed component into another product which isn't an extension of the GPLv3 product (meaning the GPLv3 product is only used as a backend of sorts), then this other product is now called an "aggregate" IFF the other product doesn't add any restrictions to the use of each component it is built upon than those components originally came with, or to the user that they had prior to using the product.
Once deemed an aggregate, the GPLv3 does not infect the other parts of the other program.


Under this, I can now use any GPLv3 licensed product as a library, so long as I'm not extending the library, and merely using it as a backend for something. Provided I don't have my new product tell the user they have additional restrictions on using any GPLv3 backends or any other libraries I use beyond what those libraries come with, as a result of them using my product, or any global restrictions, such as by using this product you agree to never sue company X.
If the GPLv3 component was a backend alongside other interchangeable backends, then it is guaranteed that the inclusion of the GPLv3 component doesn't make the program any larger (i.e. additional capabilities) than it already is. In our case, using it as a method to draw to the screen, alongside other backends which do the same thing (although not necessarily on the same platforms).


My guess is, that the FSF in trying to close off using software patents in a product, define the GPL in embedded hardware, and wanting to link with other licenses, they somehow let this sneak in.

The original intention of this paragraph probably was intended to allow a GPLv3 program to ship alongside another program on an OS, or with some hardware, but they weren't careful enough with the wording.

This section also adds in new issues regarding GPL applications. If I want to buy a computer for my daughter, and have GPLv3 applications on it, I can't tell her that I'm giving her this computer on the condition she goes to bed every night at 9PM until she's in 6th grade, and stops arguing with her mother whether she can get earings or not. Unless it is clarified that these conditions I'm placing on her aren't legal restrictions, and there is no additional laws and governing system within the household, which isn't the case, as one can place restrictions on others for living on their property.

Which also means, that thanks to the GPLv3, I should only get my kids computers with Windows on it, and make sure no GPLv3 applications are in the mix of software I preinstall for them.
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
byuu

Post by byuu »

and which are not combined with it such as to form a larger program
That was pretty much my work-around suggestion for GPLv2: make the library not "part" of the program at the time of distribution, but very easy to make it one through simple user action.

Static linking through user compilation:

Let's say I were to support GTK+ and Qt inside my UI library, hiro. Inside the makefile, there's a line that says windows = "hiro.win", linux = "hiro.gtk".

User replaces ".gtk" with ".qt" and magically gets a Qt interface.

Could be tricky, as having Qt may make all of hiro GPL instead of PD. If that were the case, I'd have to make hiro a base PD lib that supports only Win32+GTK, and then make a "forked" project called hiro++ that has Qt support and is GPL. User would have to replace the hiro folder in my source archive before compiling.

Dynamic linking through library naming:

I distribute my app with hiro.gtk.so and hiro.qt.so. Inside the UI, there's a simple search for hiro.*.so, and it uses whatever it finds. The user simply installs the qt.so instead, and gets a Qt interface.

In fact, I really couldn't stop the latter if my UI lib were a dynamic link library. Anyone could make said wrapper.

Best part would be that its completely legal, as GPLv2,3 are distribution licenses, and do not govern usage in any way.

Again, hypothetical. I looked into a Qt port anyway, not to do this, but just to offer it, eg for my UPS patcher. Compiling Qt code was too much of a pain for me to bother. I'm sure Nach will disagree.
Nach
ZSNES Developer
ZSNES Developer
Posts: 3904
Joined: Tue Jul 27, 2004 10:54 pm
Location: Solar powered park bench
Contact:

Post by Nach »

The library isn't part of the program if you don't extend it.

Although we can argue if it somehow makes the program larger. However, it doesn't make the program larger if it's one of multiple backends.

Therefor for hiro, if the Qt part of hiro didn't include anything from the rest of hiro, it can be a stand alone backend, and not infect the rest of hiro to be GPL.

However, the workaround for GPLv2 won't work, as GPLv2 doesn't allow linking against non GPLv2 code, unless it can be virally "upgraded" to GPLv2.

However with GPLv2, I don't think anything prevents you from making it try to dynamically load GPLv2 objects during run time and make use of them.
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
wertigon
Rookie
Posts: 46
Joined: Sat Aug 07, 2004 7:20 pm

Post by wertigon »

Might just be me being sleep depraved and everything, but, isn't this corner case also true for win32 or am I missing something here?
Nach
ZSNES Developer
ZSNES Developer
Posts: 3904
Joined: Tue Jul 27, 2004 10:54 pm
Location: Solar powered park bench
Contact:

Post by Nach »

wertigon wrote:Might just be me being sleep depraved and everything, but, isn't this corner case also true for win32 or am I missing something here?
If you're referring to the licensing thing, then yes there are issues with using GPLv2 with the Win32 API.

Technically, most GPLv2 programs violate the GPLv2. However if you tell them that, they'll run away screaming.
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
byuu

Post by byuu »

bsnes' source is getting really annoying to work with. If you look at src/interface.hpp, you'll see a carefully ordered list of header files, needed to get all of the various functions to inline across file boundaries. Look at ppu/counter.hpp and you see where I've resorted to wrapping functions I can't inline in headers that can't be included yet (circular dependency issues) so that the bulk of the functions can be inlined.

Why do I do this? Take this small example:

Code: Select all

int compute(int x, int y) { return g(f(x, y), g(x, y)); }
int f(int x, int y) { return (x * 8) - (y * 4); }
int g(int x, int y) { return (x * 2) + y; }
If f,g are in a different source file, and you benchmark calls to compute(), it's literally ~15-20x slower.

But putting all of these speed-critical functions in header files is increasing compile time, hurting maintainability, etc. Not to mention all the benefits I could be getting if I inlined even more functions.

The solution to this problem is obvious, and Intel + Microsoft solved it five years ago: Link-time optimization. That is, compile each object to an intermediate language, then do all the machine translation inside the linker.

Visual C++ calls it LTCG, Intel C++ calls it PGO. Naturally, GCC only has --combine for pure C89, so I'm screwed.

... or am I? What if I were to make a special "release" target for GCC in my Makefile ... take all of the source files, spit them out into a file called lto.cpp, then compile and link that as if it were one gigantic object.

It would eat an insane amount of memory, take an eternity to compile, etc; but I think it could work. And, if we're lucky and GCC catches up in the next ten years, we can just convert that back to a compiler switch like the modern compilers have (/LTCG et al.)

Thoughts?
Therefore for hiro, if the Qt part of hiro didn't include anything from the rest of hiro, it can be a stand alone backend, and not infect the rest of hiro to be GPL.
That's excellent news. Encourages me to take another stab at hiro::qt sometime.
However, the workaround for GPLv2 won't work, as GPLv2 doesn't allow linking against non GPLv2 code, unless it can be virally "upgraded" to GPLv2.
Yeah. For this at least, it's Linux we're talking about. The user would be doing the linking themselves. And since it's a distribution license, so long as they keep it for personal use, they aren't violating anything. And even if they were, who cares? Nobody will know.
DataPath
Lurker
Posts: 128
Joined: Wed Jul 28, 2004 1:35 am
Contact:

Post by DataPath »

Try compiling it in LLVM instead of gcc.

I think the two relevant features are:

1. "Front-ends for C and C++ based on the GCC 3.4 and 4.0.1 parsers. They support the ANSI-standard C and C++ languages to the same degree that GCC supports them. Additionally, many GCC extensions are supported. "

2. "It supports a life-long compilation model, including link-time, install-time, run-time, and offline optimization."
Locked