Discussion: Windows MKXP

[hanetzer]

been fiddling with building mkxp on windows, after catching a stray uint and trying again, it seems the main issue regarding building on windows is a gmtime_r conflict that occurs upon inclusion of ruby's win32.h

The exact error generated can be found in this gist: https://gist.github.com/ntzrmtthihu777/e81aaa9cd95277bf9991#file-gistfile1-txt Note: compiled with clang/clang++ for more verbose error output.

[hanetzer]

Yep, recompiled and I get debug output of nanosleep failed. errno: 22 ticks: ********** and the super zoomed up speed issue.

[Ancurio]

Here's a patch ontop of the previous one that just disables the nanosleep and uses the fallback, should work decently well: https://gist.github.com/Ancurio/238eeddf89d058947eb1

I'll have to investigate why nanosleep is failing another time. Also, ticks: ********** are those really *s or is it printing actual numbers?

[hanetzer]

Actual numbers, counting up it seems. Also, I'm not on my main machine again so I can't test yet, sorry, but thanks for helping me out all this way.

[hanetzer]

seems to actually do pretty nicely, considering. Its an even 40-ish fps and not freezing up.

[hanetzer]

still doesn't launch outside of a msys shell though :/

[hanetzer]

Recompiled with debugging symbols, thought it may be of more help: https://gist.github.com/ntzrmtthihu777/723ff275bd37e6b88d47

[Ancurio]

Thanks, but to fix this I'd have to look at the whole stackframe of that function to see which variables have out of place values =P

If you want to give it a try: select the frame with thread 9, then select the ::delayTicks frame with frame 2, and finally dump the variables with info locals.

Edit: Oh, a print *this would also be helpful!

[Ancurio]

Btw. I have pushed some commits that do more or less what the patches I posted earlier; if you want to pull these new commits, you'll have clear the temp changes with git checkout src first. You can do that later though.

You might get spammed with "nanosleep failed" messages in the console, but mkxp should still continue to run at 40FPS.

[hanetzer]

gladly, but I'm not sure how to do that thread 9 and so on :P

[Ancurio]

those are just commands into gdb, you input them the same as the thread apply all bt call.

[hanetzer]

hrm. On that note, do I need something in mkxp.conf for this exercise?

[hanetzer]

#4  0x00000000004326e8 in FPSLimiter::delayTicks (this=0x29f1d98, ticks=0)
    at mkxp/src/graphics.cpp:353
353                     while (nanosleep(&req, &req) == -1)
req = {tv_sec = 9223372036, tv_nsec = 854775808}
nsec = 9223372036854775808

Hope I did that right, lol.

[Ancurio]

Yep, that's exactly what I needed. Can you do a print *this as well?

[hanetzer]

#4  0x00000000004326e8 in FPSLimiter::delayTicks (this=0x2d51d98, ticks=0)
    at mkxp/src/graphics.cpp:353
353                     while (nanosleep(&req, &req) == -1)
req = {tv_sec = 9223372036, tv_nsec = 854775808}
nsec = 9223372036854775808
$1 = {lastTickCount = 66755790824, tpf = 85451, tickFreq = 3418056,
  tickFreqMS = 3418, tickFreqNS = 0, disabled = false, adj = {
    last = 66755790826, idealDiff = 0, resetFlag = true}}

This?

[Ancurio]

Yeah, perfect. I pushed a potential fix for this entire issue, can you pull that and try again?

[hanetzer]

will do. Seems to have done the trick regarding the whole shebang; I can run fine without any mkxp.conf tricks, though I still can't make it run with a double-click using the -Wl,-subsystem,windows or -mwindows flags... that's a bit annoying, lol.

[Ancurio]

Great to hear that this annoying issue is finally gone =P

I'm not really a MinGW expert, so I can't help you much with the shell window issue though..

[hanetzer]

yeah, thanks though. Walking through this bit has given me a bit more info to work with as far as how to go about debugging something :P

[hanetzer]

Think I may try to build via code::blocks... this cmake stuff is killing me, what ever happened to good ol' ./configure && make && make install :/

[khkramer]

Did you get this to build correctly in the end?

I'm currently trying to cross-compile for windows also, but I'm not having much luck yet (moreso because pkg-config is not finding my libs compiled with mingw)

[sorlok]

Are you using the cmake build or the ./configure based build?

[khkramer]

I'm using cmake

[sorlok]

CMake only uses pkg-config in certain cases to help "guess" where the library is located. You can provide these hints yourself with, e.g. for Boost, BOOST_INCLUDEDIR and BOOST_LIBRARYDIR. If your goal is simply to get this compiled on Windows, setting these variables for each library manually (to point to your MinGW install directory) is probably the easiest way to get it working.

Edit: When you say "cross-compile", do you mean compiling on Linux for Windows, or compiling on Windows for Windows? My comment was for the latter; if it's the former, there's a different way of doing that with cmake.

[hanetzer]

@khkramer I got it to work, I have a working windows binary in both 32 and 64 bit. You can pass PKG_CONFIG_PATH to point at the mingw pkgconfig folder in lib, but that's location depends on what distro you are using.

[khkramer]

@sorlok

I tried compiling on Linux for Windows first, I'm now trying on windows with cygwin. The only problem now is getting it to properly detect boost, I'm pointing it towards the right directory but it says It can't read version.hpp.

@ntzrmtthihu777

Would you mind sending me your binaries? They might work for my project, if they do it would save some time.

[hanetzer]

@khkramer You don't want the binaries I currently possess, they're still a bit buggy. I'll recompile once I resetup msys2 (you should really use this instead of cygwin/msys :P) on my winxp virtual machine.

[khkramer]

I actually got it to correctly find boost now with -DBoost_USE_STATIC_LIBS=ON However It's still missing OpenAL and I don't know which version of OpenAL it wants, I've googled and I've find varying implementations of OpenAL, which one should I build? And I'll try out Msys2, thanks for the suggestion.

[hanetzer]

the one from http://www.openal.org

[Ancurio]

However It's still missing OpenAL and I don't know which version of OpenAL it wants, I've googled and I've find varying implementations of OpenAL, which one should I build?

OpenAL Soft

[khkramer]

Got it.

My next question might be a slightly stupid one but would I be able to build with Ruby 1.9 instead of 2.0?

[Ancurio]

My next question might be a slightly stupid one but would I be able to build with Ruby 1.9 instead of 2.0?

I haven't worked at all with 1.9 before, so I can't say. At a minimum, it would have to produce a library-fied version (libruby.so), I'm not sure when they added that. If errors you encounter are sufficiently trivial, we can patch mkxp to work with 1.9 as well.

[khkramer]

CMake finally made me some makefiles. When I try building I get this error:

make[2]: XXD_EXE-NOTFOUND: Command not found

At first I thought I had to install xxd but that didn't fix it.

[Ancurio]

xxd is a (more or less) standard unix tool; I think any mingw/msys installation should ship with it. Now, as to how cmake finds it on windows.. I don't know (I didn't write the CMake script).

You probably have to explicitly pass the path to your xxd binary to cmake, @ntzrmtthihu777 should know how to do this.

Edit: Nvm my first sentence, xxd is actually part of vim, so you will need some form of vim package for mingw to get it.

[khkramer]

I was able to set it with -DXXD_EXE. Here comes another error C:/CygWinDeluxe/home/Klaas-Hessel/mkxp/binding-mri/binding-mri.cpp: In function ‘void showExc(VALUE)’: C:/CygWinDeluxe/home/Klaas-Hessel/mkxp/binding-mri/binding-mri.cpp:377:28: error: expected ‘)’ before ‘PRIsVALUE’ VALUE ds = rb_sprintf("%" PRIsVALUE ": %" PRIsVALUE " (%" PRIsVALUE ")", ^ C:/CygWinDeluxe/home/Klaas-Hessel/mkxp/binding-mri/binding-mri.cpp:381:32: error: expected ‘)’ before ‘PRIsVALUE’ rb_str_catf(ds, "\n\tfrom %" PRIsVALUE, rb_ary_entry(bt, i)); ^ C:/CygWinDeluxe/home/Klaas-Hessel/mkxp/binding-mri/binding-mri.cpp:393:36: error: expected ‘)’ before ‘PRIsVALUE’ VALUE ms = rb_sprintf("Script '%" PRIsVALUE "' line %" PRIsVALUE ^ C:/CygWinDeluxe/home/Klaas-Hessel/mkxp/binding-mri/binding-mri.cpp: In function ‘void mriBindingExecute()’: C:/CygWinDeluxe/home/Klaas-Hessel/mkxp/binding-mri/binding-mri.cpp:401:13: error: ‘ruby_setup’ was not declared in this scope ruby_setup(); ^

Might It have used a wrong version of ruby perhaps?

[cremno]

PRIsVALUE and ruby_setup were added with 2.0.0.

Fixing the first one is possible, but I don't like the required changes.

Using ruby_init instead of ruby_setup is okay. But it exits the program without any message in case of an error. Also, as of now mkxp would most likely crash, because it doesn't check the return value of ruby_setup.

Do you really want to see 1.9.3 supported? There are only a few incompatibilities between 1.9.3 and 2.0.0 (or 2.1).

[Ancurio]

Ah, thanks for chiming in cremno, I was going to ask you :D

Yeah, this mindset of ruby 1.9 that it's the main executable code and can just exit() on error is really problematic. I mean, you could probably still run games with it, but getting any decent error messages would be impossible, not to even speak of all the unreleased resources at the end.

If you still want to go with 1.9, you might want to try commenting out the entire body of showExc() and replacing ruby_setup with ruby_init as cremno suggested. I'm not sure as to how far I could integrate such changes upstream though..

[hanetzer]

@Ancurio Not really, I'm rather unexperienced with using cmake (I'm an autotools guy myself); its simply the fact that msys2 simply 'just works' regarding stuff packaged for it. Sets up a standard FSH in duplication of archlinux, good buildscripts for things that dont yet exist, its the closest thing I know of you can get in windows to using actual *nix without a virtualmachine/reboot.

[hanetzer]

The main issue I had getting mkxp compiled against ruby-2.1.2 is a conflict with some posix macros conflicting from winpthreads and ruby; a patch to the former and commenting out of the latter and all was well.

[The-J-Person]

If it's working, could someone put up a windows binary pack? It would be especially useful for packing games with a custom soundfont and fluidsynth for a similar MIDI experience across all systems.

[hanetzer]

I'd have to recompile, the version I worked together was prior to the MIDI inclusion. Currently I'm working 6-7 12 hour shifts a night and studying for my CompTIA A+ cert exam, so my spare time for this sort of thing is rather scarce.

[Ancurio]

@ntzrmtthihu777

In case you do find the time, it shouldn't be very difficult as the dependencies between back then and now didn't change at all I believe.

[hanetzer]

@Ancurio sup man. Yeah, I suppose so, though I do recall having severe issue getting fluidsynth to compile on windows (needs something from the direct* sdk, and I really don't wan't to download the entire thing [smartphone internet, 500mb 4g/month] for one header file...). Also, I never solved the issue of compiling it for windows without it opening a cmd.exe window when ran (did all the -Wl,-subsystem,windows crap in various forms. It 'runs' without opening the window, but immediatly goes into not responding mode). I assume it has something to do with the fuckery that SDL does to int main.

[Ancurio]

@ntzrmtthihu777 I see, no need to sweat it. I think in theory one could just download a random prebuilt fluidsynth.dll from the interwebs and it should work ok (you don't need the headers).

And yeah, that console window stuff was really unfortunate. I actually tried a cross compile with mingw today just for funzies, got all dependencies compiled pretty effortlessly except for boost which is a really strange beast with the weirdest build system on earth.

[hanetzer]

What distro are you on? Boost was not an issue on my end at all (BTW, I know you use it for Program Options, have you considered instead GNU GetOPT? What else is boost doing for you?)

[Ancurio]

I'm on Fedora (19). I think I'm just too stupid to read the boost documentation, no matter how I setup the config file it won't even start the build, maybe I'll get back to it some later time.

I actually also use the unordered hash and set containers from boost, but they're header only. Program options is kinda nice because it parses both config files (mkxp.conf) and command line arguments, and transparently merges them. There's a few games using mkxp on Steam right now, and it's really neat when players don't have to navigate folders and edit mkxp.conf (which might be overwritten by Steam) because I can just tell them to set a few launch parameters for the executable in the Steam settings instead.

I took a quick look at getopt, but it seems to do cmd line args parsing only?

Edit: Just noticed that my distro has prebuilt mingw packages for boost, awesome! Gonna give them a try.

[hanetzer]

AFAIK yes, getopt is command line only. I'm an Arch user myself, fully updated (even using the linux-git kernel 3.18-rc4) as of a few days ago.

[Ancurio]

So, using the nice precompiled libs from the Fedora repos, I managed to link a mkxp.exe in the end. There's one problem (potential bug) in SDL2 that I have worked around for the time being, and for some reason jpeg decoding fails every time, but other than that, most things seems to work nicely (as far as I can tell). Testing is just really annoying because my WinXP VM doesn't do OpenGL 2.0, so I have to reboot into my Vista partition to actually run anything graphical.

Once I get the jpeg problem sorted out, I'll upload the binary if you want to play with it @The-J-Person, although I give no guarantees as to bugs, and probably won't be able to debug any further (and more intricate) problems ;D

[The-J-Person]

Thanks a lot :D I actually use Debian and Mint myself, and normally use WINE to see if windows executables work rather than a VM - close enough methinks.

Really though, thank you for your hard work and responsiveness - it is much appreciated!

[hanetzer]

@The-J-Person @Ancurio yeah, generally opengl based games tend to work very well under wine, my own mkxp.exe ran under wine fine, but upon using it in windows I still get the cmd.exe box... irksome.

[Ancurio]

@ntzrmtthihu777 I think that's because wine just pipes through the raw OpenGL driver it finds on LInux (eg. GL_VENDOR and such still show Mesa even under wine). Btw. I can link my exe with -mwindows and it hides the cmd window just fine.. I'm using mingw-w64 btw., not sure if that's related.

Got the SDL2 and libjpeg issues sorted out properly, but now OpenAL is giving me huge troubles with its mmdevapi backend, hopefully I can make it always default to DirectSound because I have no clue what's going on haha. I really hope it's not related to me linking libOpenAL statically though.