Schpune for Mac OSX / *nix systems.

Schpune for Mac OSX / *nix systems.
by B00daW on 2008-02-11 (#30792)

If I wasn't stuck on Windows for all of my music development, I'd be using this Schpune.

Latest development:

Parasyte wrote:

Version 0.1.2 (2/7/2008):
* Fixed Unicode issues. Unicode builds should now work. (Disch)
* Added patch to fix Unicode build with g++. (Parasyte)
* Added support for --enable-unicode and --enable-debug in configure
script. (Parasyte)

If Disch or Parasyte were ever so kind to mirror the developments into this thread, it would be neato, fresh, keen, l33t. K?

by mattmatteh on 2008-02-14 (#30898)

fails to compile using wxGTK 2.6 with ansi:
configfile.cpp:35: error: 'class wxStandardPathsBase' has no member named 'GetExecutablePath'

fails to compile using wxGTK 2.6 with unicode:
mapperdlg.cpp:84: error: conversion from 'const ch_t*' to 'const wxString' is ambiguous

fails to compile using wxGTK 2.8:
mapperdlg.cpp:84: error: conversion from 'const ch_t*' to 'const wxString' is ambiguous

matt

Re: Schpune for Mac OSX / *nix systems.
by Disch on 2008-02-14 (#30900)

B00daW wrote:
If Disch or Parasyte were ever so kind to mirror the developments into this thread, it would be neato, fresh, keen, l33t. K? :D

I don't really want to post on dozens of different messageboards every time I update something. The fact of the matter is it's still a very early WIP, so I didn't even really want to make a thread about it at all (I just kind of piggybacked Parasyte's thread on that board).

It seems like other people are more interested in advertising the emu than I am. =P personally I think I'd rather wait until it's something more substantive before hyping it up.

But anyway I don't mind other people posting things about it.

Quote:
configfile.cpp:35: error: 'class wxStandardPathsBase' has no member named 'GetExecutablePath'

It should. Perhaps you need v2.8 for that.

I'm currently using 2.8.7

Quote:
mapperdlg.cpp:84: error: conversion from 'const ch_t*' to 'const wxString' is ambiguous

Parasyte was having these same problems with unicode builds. The problem was that I was typedefing as 'unsigned short', but he needed 'wchar_t'. See line ~60 of nes_types.h. Perhaps wchar_t isn't working for you... or perhaps UNICODE is not being defined (there is no #define in the code anywhere, it should be a compiler option)

I didn't want to include any hint of wx in the emulator core (which is where ch_t is used). But apparently there are typedefing nightmares when converting to wxString. I'm open to suggestions on how to avoid these problems. The only thing I can think of would be to conditionally typedef ch_t to whatever the compiler needs with a barrage of #ifdefs -- but that's insanely ugly.

Re: Schpune for Mac OSX / *nix systems.
by tepples on 2008-02-14 (#30903)

Disch wrote:
I didn't want to include any hint of wx in the emulator core (which is where ch_t is used). But apparently there are typedefing nightmares when converting to wxString. I'm open to suggestions on how to avoid these problems. The only thing I can think of would be to conditionally typedef ch_t to whatever the compiler needs with a barrage of #ifdefs -- but that's insanely ugly.

That's what a project's config.h is for.

by mattmatteh on 2008-02-14 (#30904)

i dont understand why there is a conversion needed. could you just use wchar_t or char as decribed here http://www.wxwidgets.org/manuals/2.8/wx_unicode.html ?

seems like you are using char when you should be using wchar_t ?

matt

by Disch on 2008-02-14 (#30905)

mattmatteh wrote:
i dont understand why there is a conversion needed.

The emu core uses C-style strings (char or wide char pointers). The GUI uses the wxString class. A conversion is required to build a wxString object from the core's C-style strings.

This is not a conversion from ANSI to Unicode or vice versa. Such a conversion should never take place.

Quote:
could you just use wchar_t or char

I am. See line ~60 of nes_types.h

wchar_t if UNICODE is defined
char otherwise (ANSI)

Quote:
seems like you are using char when you should be using wchar_t ?

If it's using char in a unicode build, then UNICODE isn't being defined by your compiler. I'm still a MSVS boy so I'm not sure how to go about defining this in other compilers -- I thought Parasyte had already taken care of it in his support files.

by mattmatteh on 2008-02-14 (#30906)

i see

#ifdef UNICODE
typedef unsigned short ch_t;

that looks wrong, i was thinking it should be wchar_t ?
------------------------------------
i looked on wxwidgets site and that function chagned from 2.6 to 2.8.

but in either version i think you should be using wxstring instead of
const ch_t* szToggleTitle;

the compiler is doing conversions and failing. perhaps you could just use string ? or if you want to keep the core separate, write a class or function to handle transitions ?

matt

by Disch on 2008-02-14 (#30907)

mattmatteh wrote:
i see

#ifdef UNICODE
typedef unsigned short ch_t;

that looks wrong, i was thinking it should be wchar_t ?

That must be an older version. I thought Parasyte uploaded the newer one with a fix:

Code:
/*
* For strings
*/
#ifdef UNICODE

#ifdef _MSC_VER
typedef unsigned short       ch_t;
#else // _MSC_VER
typedef wchar_t             ch_t;
#endif // _MSC_VER

#define shT(t)             L##t

#else // UNICODE (not unicode)

typedef char             ch_t;
#define    shT(t)          t

#endif // UNICODE

The _MSC_VER check may not be needed. I had problems compiling with wchar_t... but that might have been due to how I built wx. I'll rebuild my wx again later and see if I can get Schpune working with wchar_t all the time.

Quote:
but in either version i think you should be using wxstring instead of
const ch_t* szToggleTitle;

That is not an option. I want the emu core to be free of any and all external libraries. There may come a time in the future where I want to build this for a platform wx or whatever aren't handling... or maybe I'll want to drag and drop the emu core into another program. Having unnecessary bindings to wx would require me to gut and redo large portions of the code in order to accomplish that.

Not to mention it would kill compile times if I'm including wx in everything. Compile times are already long enough.

Quote:
the compiler is doing conversions and failing. perhaps you could just use string ? or if you want to keep the core separate, write a class or function to handle transitions ?

Well wxString should be doing the conversions. It has ctors to convert from the appropriate source. It's just a matter of getting the types right.

by tepples on 2008-02-14 (#30908)

Is there an advantage of using wchar_t (in UTF-16 encoding) over using char (in UTF-8 encoding)?

by mattmatteh on 2008-02-14 (#30909)

well, ill let you work on that. let me know if you want me to test again.

i agree with what tepples said, all those ifdef's belong in src/config.h

and i keep them to a minimum.

matt

by Disch on 2008-02-14 (#30910)

tepples wrote:
Is there an advantage of using wchar_t (in UTF-16 encoding) over using char (in UTF-8 encoding)?

Some APIs don't take UTF-8 encoded strings. Apart from that, I don't think so. I think using Unicode ultimately boils down to using the format your API uses.

Quote:
well, ill let you work on that. let me know if you want me to test again.

After rebuilding wx with fixed settings, wchar_t works fine under VS as well. I was just silly before.

Quote:
i agree with what tepples said, all those ifdef's belong in src/config.h

and i keep them to a minimum.

Will do. That part in nes_types.h was the only #ifdef I had in the entire source before Para made his adjustments (I think, anyway).

Anyway yeah I'll move that all around.

by mattmatteh on 2008-02-14 (#30911)

is there a new link for the source so i can try the lastest ?

src/config.h i think should only have #define, no ifdef or what ever. the configure script determins all that.

matt

by Parasyte on 2008-02-14 (#30912)

Using config.h would probably hurt compatibility with MSVC, which is what Disch is stuck with. Complain about it enough, and maybe he will come over to the light side.

And the configure script already handles unicode with --enable-unicode

by mattmatteh on 2008-02-14 (#30913)

you can still use config.h with windows, you just need something to configure it correctly like the configure script does.

and if the configure script handles unicode correctly, then in config.h you would define HAVE_UNICODE 1 and in the code

#ifdef HAVE_UNICODE
wchar_t *mystring;
#else
char * mystring;
#endif

matt

by tepples on 2008-02-14 (#30918)

Disch wrote:
tepples wrote:
Is there an advantage of using wchar_t (in UTF-16 encoding) over using char (in UTF-8 encoding)?

Some APIs don't take UTF-8 encoded strings.

Which APIs are you talking about? Windows NT supports both 8-bit code units ("ANSI build") and 16-bit code units ("Unicode build"). If you build your program using the ANSI APIs, you can tell Windows that your ANSI strings are in UTF-8 by giving it "code page 65001".

Disch: Is it true that you are stuck with Microsoft Visual C++ and not, say, MinGW?

by B00daW on 2008-02-15 (#30928)

leax0r:

[19:29:49] <Disch> http://disch.arc-nova.org/schpune-0.1.3.zip <--- buh-dwap @ ParaMAC I guess

Shh... Don't let Disch know.

by Parasyte on 2008-02-15 (#30936)

mattmatteh wrote:
you can still use config.h with windows, you just need something to configure it correctly like the configure script does.

and if the configure script handles unicode correctly, then in config.h you would define HAVE_UNICODE 1 and in the code

#ifdef HAVE_UNICODE
wchar_t *mystring;
#else
char * mystring;
#endif

matt

Currently the --enable-unicode arg just adds -DUNICODE to the compiler arg list, which has the same effect. nescore/nes_types.h already had its "#ifdef UNICODE" lines, which apparently is defined by Visual Studio when you switch to its Unicode build behavior.

I attempted to use config.h in autoconf when I was first beginning the porting process, but dropped it for some odd reason. I suppose using it would not cause many (any?) problems with compatibility, due to the use of additional compiler defines to include config.h, in the first place. It would make console output slightly cleaner, as well. Perhaps I will re-implement it for version 0.1.3.