bsnes v0.039 released

[byuu]

Damn, I guess the Qt DLLs I built didn't include support for JPEGs. It works on Linux, and JPEG cuts the size down to ~60kb instead of ~270kb.
Not going to worry about it for now. Need to switch to Qt 4.5 anyway for the official release. We'll make sure those DLLs have JPEG support, or I'll try statically linking if that's allowed.

belegdol, I'm unable to help then. I can't spot any bugs. I will need either someone with a joypad that SDL detects hats on to help fix it or donate their controller.

[kick]

I think he just doubled the width of the image. Halving it makes it look very similar to my bog-standard 16:10 LCD.

16:9
It's 32:9,no wonder it looks like a 16:9 when you halve the width.

P.S. I didn't stretch the image at all. Just squished it vertically
(just for lulz)

The panoramic view looks extremely cool (looks like 3-monitor SurroundView done right) It just needs a slight curvature like those 'total immersion' displays and you have a winrar

The Samsung logo and whatever that is in the lower left of the picture both look stretched to me

That 's very easy to 'fix'. I was just too lazy to give it a proper photoshop treatment

[byuu]

Out of things to work on. Killed some cruft in the Memory class, fixed a typo Mednafen pointed out in the Mode7 code.

For today, I didn't update the posted WIP, but I changed the class names to object names for easier style-sheet customization. I then tweaked the panel title names a bit (smaller, less in-your-face).

Oh, I don't know if I mentioned it yesterday, but wip21 adds the full name of the button you're assigning, eg:
ID: Controller port 1 :: Joypad :: Select

http://byuu.cinnamonpirate.com/images/b ... 090302.png

[FirebrandX]

byuu, its a good think the image didn't work yet. I wasn't fully happy with it just yet You may also prefer a different background to the wood. PM me and we'll work something out for making the image the right size and style for the emulator.

[belegdol]

FYI, Qt 4.5 is now out, licensed under LGPL 2.1 or GPL 3.0

[byuu]

Thanks. Before I build the new library, I need fixes for it to work on GCC 4.3.2.

That taken care of, I'll probably post a new release either this weekend or next. Going to forego localizations for a while. I wasn't happy with the old system of requiring the user to download them (with instructions only in English), and having them appear much farther after the official releases. So I'm not sure what I'll end up doing there. Qt Linguist is kind of a hassle, too.

[belegdol]

Thanks. Before I build the new library, I a) need fixes for it to work on GCC 4.3.2, and b) need to know if I can statically link against the DLLs ala gambatte.

I'm not sure, sorry.

That taken care of, I'll probably post a new release either this weekend or next. Going to forego localizations for a while. I wasn't happy with the old system of requiring the user to download them (with instructions only in English), and having them appear much farther after the official releases. So I'm not sure what I'll end up doing there. Qt Linguist is kind of a hassle, too.

On the other hand, you wouldn't need to reinvent the wheel. Also, qt translation files are just xml so they can be translated with notepad if someone does not like qt linguist. Just a little more complicated than the old way.

[byuu]

Since you responded (thanks for the quick response, not complaining), I'll just reply below it:
--------------------

We can statically link Qt 4.5 with bsnes*. No need for DLLs. That'll give us the v039-style one single EXE file, and it'll be much smaller ala gambatte @ 1.8mb. Mine would probably be ~2.4mb or so, as I have a lot of images and such in my application.

* http://www.gnu.org/licenses/lgpl-2.1.html
5. However, linking a "work that uses the Library" with the Library creates an executable that is a derivative of the Library (because it contains portions of the Library), rather than a "work that uses the library". The executable is therefore covered by this License. Section 6 states terms for distribution of such executables.

6. As an exception to the Sections above, you may also combine or link a "work that uses the Library" with the Library to produce a work containing portions of the Library, and distribute that work under terms of your choice, provided that the terms permit modification of the work for the customer's own use and reverse engineering for debugging such modifications.

Bla bla bla ... Also, you must do one of these things:

a) Accompany the work with the complete corresponding machine-readable source code for the Library including whatever changes were used in the work (which must be distributed under Sections 1 and 2 above); and, if the work is an executable linked with the Library, with the complete machine-readable "work that uses the Library", as object code and/or source code, so that the user can modify the Library and then relink to produce a modified executable containing the modified Library. (It is understood that the user who changes the contents of definitions files in the Library will not necessarily be able to recompile the application to use the modified definitions.)

My license fulfills 6a. It allows the user to make their own binaries, just not to distribute them without approval.

[belegdol]

What's the problem with gcc-4.3.2 btw? Both qt and bsnes compile with 4.4, so 4.3.2 shouldn't be any.

[byuu]

What's the problem with gcc-4.3.2 btw?

http://www.qtcentre.org/forum/f-install ... 16697.html

Trolletch and Nokia are acting like they don't have problems in their Windows port and refuse to get it compiling with a version of GCC less than six years old.

I had to apply a series of patches, and then #pragma GCC system_header a bunch of files for Qt 4.4.3. I don't want to try and figure out the needed Qt 4.5 patches on my own, if at all possible.

[Killa B]

I wasn't happy with the old system of requiring the user to download them (with instructions only in English), and having them appear much farther after the official releases.

You could always add functionality to the program to download the translations from a Language menu.

I see where you're coming from with the instructions only being in English, though, I might have an idea, but I don't know how painful it will be to code.

Here it is: You could execute some code the first time bsnes is run that checks the locale, and if it isn't English (en-US, en-GB, etc.), it automagically downloads the appropriate translation.

I've also considered that this idea might be hell to your server. In that case, maybe have built-in notifications in each supported language, asking the user whether he wants to download the translation or proceed in English. They won't all need the translation; there's always the European dudes who speak English fluently, and of course the native English speakers that either switch locales for whatever reason or just happen to be residing in China.

[byuu]

Everyone downloads new releases very quickly. A major spike right upon the first release.

And people also go apeshit when programs access the internet. Especially with those scareware 'firewalls' :P

The best way to do it would be to somehow have all the translations before release, and somehow let users change language via a menu. Detect the OS language and pick that one by default.

A lot easier than it sounds. Maybe with a really stable UI where strings aren't changed for every release, we could reasonably rely on previous version translation files for new releases ...

[Verdauga Greeneyes]

The best way to do it would be to somehow have all the translations before release,

If you can get in touch with all the translators, you could let the final WIP bake for a while until you have all the translations/can't wait anymore.

[byuu]

I can't sit still like that. In the one week waiting I'll end up changing 100 strings :P

[Verdauga Greeneyes]

Hehe, I figured as much. But you could still freeze the release version (barring any major bugs found) and work on the next version in the meantime.

[byuu]

New WIP.

Softened the panel titles a lot, they take less space but still stand out well enough.

Should I add a checkbox+global hotkey to toggle the cheat code system itself on and off? Ala the flip switch that's on the real Game Genie. Not sure if it's as important anymore now that it's easy to group multiple cheat codes together and toggle them with just one checkbox. If so, I need a caption for the checkbox widget, eg "Enable cheat code system", but something more descriptive.

Rewrote a couple chunks of the nall::string library. I had a lot of problems with casting due to things like this:

Code: Select all

int strdec(const char*);
string strdec(int);
string::operator int();
string::operator const char*();
string::operator=(int);
string::operator=(const char*);
string::operator<<(int);
string::operator<<(const char*);
string::string(int);
string::string(const char*);

It couldn't implicitly determine if string() << 0 should refer 0 as const char* or int. So I started by dropping the string->integer implicit conversions, no need for those, use the strTransform(string) functions instead. More verbose of the format you want anyway (eg signed or unsigned integer).

Next, rather than try and implement signed+unsigned+signed short+unsigned short+signed char etc etc for string::operator= + string::operator<<, I instead wrote them to use templates. Worked around the limitation that classes can't use explicit template specialization by using global thunk functions. operator<<, operator= and lstring::operator<< all share one set of template specialization functions to perform conversion of any supported type to a string for assignment or appending. Pass an unsupported type and it will throw a "template function undefined" error and fail to compile. No run-time surprises.

I was careful to implement the copy constructor and copy operator= to stop the compiler from generating its own functions that copy around the raw pointer (which would lead to memory leaks + double memory frees.) So it should be 100% leak proof.

I also split strdec(int) into strsigned(signed) and strunsigned(unsigned); and updated all the other stuff that used the lib for that (eg nall::config et al), so you can now perform unsigned->string conversions on UINT_MAX without getting back -1.

Only thing I'm debating now is if I want to trade C compatibility for speed and store the string lengths inside the string class for O(1) length + append functions, compared to their O(n) now. Multiple chained appends raise that to O(n^2), but with ~20 appends at most per string, it's hardly a bottleneck right now.

I'm hesitant to do this, because if I do, I'll have to remove char* operator()() to give a raw handle to the string pointer. I use that for quick libc const char*->string& wrapper functions, and it's also nice for other functions to use. And char& operator[](size_t) would take a hell of a speed hit for having to check for '\0' writes to adjust the length internally.

Not going to allow storing '\0' directly ala std::string, and make string::c_str() require memory allocation. Fuck that. Use an appropriate binary container if you want '\0' inside a block of memory. The whole idea of nall::string is to maintain 100% compatibility with C89 strings and their functions.

[creaothceann]

I'm hesitant to do this, because if I do, I'll have to remove char* operator()() to give a raw handle to the string pointer.

When you create a string you could store the length in front of it, but return the address of the first character (address of the block + length(int)). As long as the standard functions only do read accesses...

[byuu]

With a class it'd be trivial to do:
{ unsigned length; char *data; };

But my last two paragraphs preclude that :/

And actually I made one mistake there.
char& operator[](size_t) can't work at all. I would need operator[]= which doesn't exist, to properly change the length value if someone tried to store a terminator directly in a string (and I do that a lot, actually.)

I want C compatibility so making it string::set(index, value) is not an option.

[Verdauga Greeneyes]

With a class it'd be trivial to do:
{ unsigned length; char *data; };

But my last two paragraphs preclude that :/

And actually I made one mistake there.
char& operator[](size_t) can't work at all. I would need operator[]= which doesn't exist, to properly change the length value if someone tried to store a terminator directly in a string (and I do that a lot, actually.)

I want C compatibility so making it string::set(index, value) is not an option.

You could return a 'string_elem' or something for operator[], I suppose, which has an explicit cast to char and updates its parent string where appropriate..

[byuu]

Okay, just installed Qt 4.5 w/MinGW GCC 4.3.2. They fixed the subauth issue, but the other two bugs still need to be patched before compilation.

4.5 exposed an issue where the resource file was including QtCore/qglobal.h before my main Qt #defines and includes, which was giving bizarre auto relocate errors and such. Fixed that by moving the resource down some. Good news is the lack of QtCore/qglobal.h was what caused the millions of warnings I was patching with #pragma GCC system_header before, so that's not even necessary for someone to build bsnes with no warnings now.

Other than that, it seems to work great. Binary is much, much smaller than I imagined. Without zlib or libjma, but with the PNG logo and JPEG controller, the binary is 328kb (can probably kick another ~50k with ultra-brute UPX mode), and requires no run-time DLLs to be included. Not sure why gambatte is so much bigger, but it's not important.

So in the end, the primary disadvantage of Qt has been effectively eliminated.

Okay, this will be the last post before the official release:
---

If everyone could test that, it'd be appreciated. Want to verify it works on systems with Unicode usernames (eg Japanese, Korean, etc) too.

Binary should be 100% legal, but I'm going to embed the LGPL reference in the license info section before release.

If the controller graphic still doesn't show up on some systems (it does on mine), then let me know if the about logo does. If so, I'll just go with the PNG controller at a cost of +150kb.

EDIT: damnit, still asking for the DLLs. Looking into it now ...

[gllt]

Everyone downloads new releases very quickly. A major spike right upon the first release.

And people also go apeshit when programs access the internet. Especially with those scareware 'firewalls'

The best way to do it would be to somehow have all the translations before release, and somehow let users change language via a menu. Detect the OS language and pick that one by default.

A lot easier than it sounds. Maybe with a really stable UI where strings aren't changed for every release, we could reasonably rely on previous version translation files for new releases ...

How about just the installer, like some programs fetch dictionaries and stuff when they install

[byuu]

Okay, got it to build statically. What a major pain in the ass.

First, you have to add linker flags:

Code: Select all

  link += -mwindows  -mthreads -enable-stdcall-fixup -Wl,-enable-auto-import -Wl,-enable-runtime-pseudo-reloc -Wl,-s -Wl -Wl,-subsystem,windows

Next, you have to add your libraries: QtCore4 -> QtCore and QtGui4->QtGui. And the fun part, these have to be in exactly the right order, or the entire thing will give you thousands of undefined references:

Code: Select all

  link += $(call mklib,mingw32)
  link += $(call mklib,qtmain)
  link += $(call mklib,QtGui)
  link += $(call mklib,gdi32)
  link += $(call mklib,comdlg32)
  link += $(call mklib,oleaut32)
  link += $(call mklib,imm32)
  link += $(call mklib,winmm)
  link += $(call mklib,winspool)
  link += $(call mklib,msimg32)
  link += $(call mklib,QtCore)
  link += $(call mklib,kernel32)
  link += $(call mklib,user32)
  link += $(call mklib,shell32)
  link += $(call mklib,uuid)
  link += $(call mklib,ole32)
  link += $(call mklib,advapi32)
  link += $(call mklib,ws2_32)

Good thing the documentation doesn't tell you this. The compiler tells you to add --enable-auto-import, but the proper syntax is: -Wl,-enable-auto-import. And most Google matches use -W1 (W one) instead of the correct -Wl (W lowercase L). They also mostly have an extra -.

I only found out about the ordering thanks to a PyQt post where someone noticed he got less errors re-ordering the libs.

Code: Select all

$ upx --ultra-brute bsnes.exe
                       Ultimate Packer for eXecutables
                          Copyright (C) 1996 - 2008
UPX 3.03w       Markus Oberhumer, Laszlo Molnar & John Reiser   Apr 27th 2008

        File size         Ratio      Format      Name
   --------------------   ------   -----------   -----------
  10529792 ->   3178496   30.19%    win32/pe     bsnes.exe

Working out how to get JPEG support statically linked in, then I'll post a binary.

[henke37]

Or you could just repeat the libraries twice. That should make all the linking problems go away. It can't make things worse.

[franpa]

It makes the code amateurish in appearance.

[adventure_of_link]

It makes the code amateurish in appearance.

Got a better suggestion? otherwise..