wx failed assertions
Opened this issue · 15 comments
Thank you for the wonderful utilities, however I'm getting a lot of errors while trying to run camoto:
ASSERT INFO:
../src/generic/imaglist.cpp(66): assert "(bitmap.GetWidth() >= m_width && bitmap.GetHeight() == m_height) || (m_width == 0 && m_height == 0)" failed in Add(): invalid bitmap size in wxImageList: this might work on this platform but definitely won't under Windows.
BACKTRACE:
[1] wxGenericImageList::Add(wxBitmap const&)
[2] Studio::Studio(bool) /home/andoru/sources/camoto-studio/src/studio.cpp:113
[3] CamotoApp::OnCmdLineParsed(wxCmdLineParser&) /home/andoru/sources/camoto-studio/src/main.cpp:197
[4] wxAppConsoleBase::OnInit()
[5] wxEntry(int&, wchar_t**)
[6] wxEntry(int&, char**)
[7] main /home/andoru/sources/camoto-studio/src/main.cpp:229
[8] __libc_start_main
[9] _start
ASSERT INFO:
../src/gtk/bitmap.cpp(923): assert "IsOk()" failed in GetWidth(): invalid bitmap
BACKTRACE:
[1] wxBitmap::GetWidth() const
[2] wxGenericImageList::Add(wxBitmap const&)
[3] Studio::Studio(bool) /home/andoru/sources/camoto-studio/src/studio.cpp:113
[4] CamotoApp::OnCmdLineParsed(wxCmdLineParser&) /home/andoru/sources/camoto-studio/src/main.cpp:197
[5] wxAppConsoleBase::OnInit()
[6] wxEntry(int&, wchar_t**)
[7] wxEntry(int&, char**)
[8] main /home/andoru/sources/camoto-studio/src/main.cpp:229
[9] __libc_start_main
[10] _start
ASSERT INFO:
../src/gtk/bitmap.cpp(626): assert "image.IsOk()" failed in wxBitmap(): invalid image
BACKTRACE:
[1] wxBitmap::wxBitmap(wxImage const&, int)
[2] Studio::Studio(bool) /home/andoru/sources/camoto-studio/src/studio.cpp:114
[3] CamotoApp::OnCmdLineParsed(wxCmdLineParser&) /home/andoru/sources/camoto-studio/src/main.cpp:197
[4] wxAppConsoleBase::OnInit()
[5] wxEntry(int&, wchar_t**)
[6] wxEntry(int&, char**)
[7] main /home/andoru/sources/camoto-studio/src/main.cpp:229
[8] __libc_start_main
[9] _start
ASSERT INFO:
../src/gtk/bitmap.cpp(923): assert "IsOk()" failed in GetWidth(): invalid bitmap
BACKTRACE:
[1] wxBitmap::GetWidth() const
[2] wxGenericImageList::Add(wxBitmap const&)
[3] Studio::Studio(bool) /home/andoru/sources/camoto-studio/src/studio.cpp:114
[4] CamotoApp::OnCmdLineParsed(wxCmdLineParser&) /home/andoru/sources/camoto-studio/src/main.cpp:197
[5] wxAppConsoleBase::OnInit()
[6] wxEntry(int&, wchar_t**)
[7] wxEntry(int&, char**)
[8] main /home/andoru/sources/camoto-studio/src/main.cpp:229
[9] __libc_start_main
[10] _start
Those are just some examples, as I keep getting a lot of different errors similar to these, so I won't post them all.
OS: Debian Sid
wxWidgets GTK toolkit: 3.0.2
These errors are from when the GUI icons are being loaded. Are you sure they are available in the standard location? If you are running the Studio without installing it, then you'll have to run ./configure with the --datarootdir option to specify another location (e.g. --datarootdir=/home/user/camoto) as the default is in /usr/local/share. The folder you specify here must have a subdirectory in it called camoto-studio and this must contain the contents of the data directory. Using the above example, you would have a file /home/user/camoto/camoto-studio/icons/grid.png.
I've tried installing with --prefix=$HOME, and with no prefix at all, with the former I get different errors (I did not get to save the backtraces, and now I can't reproduce those), but with the latter it's the same as not installing camoto (you were right by the way, I did not install camoto previously as I didn't want to clutter the OS with stuff)
I've tried to set the --datarootdir parameter to the folder with the source files, but that didn't work, even upon making the source all over again...
Setting the --datarootdir to the source folder will not work as the source folder does not contain a directory called camoto-studio, the directory there is named data instead. If you set --datarootdir to the source folder then you will need to create a symlink in the source folder like this: ln -s data camoto-studio. Then it will work. Sorry this is so confusing, but it's a limitation of the way the GNU autotools handle the additional data files.
You also do not have to worry about cluttering the OS with files - everything goes into /usr/local unless you change --prefix and you can run make uninstall from the source directory to remove all the files again.
Setting the --datarootdir to the source folder will not work as the source folder does not contain a directory called camoto-studio
My bad, I wasn't clear enough. As you might have saw from the previous backtraces I posted that the source folder is under ~/sources/camoto-studio (I cloned this git repo, so it inherited the same name), so I used --datarootdir=/home/andoru/sources/.
Now I've tried a clean compile with no parameters at configure, and installing the executable in the default path, and I get this:
ASSERT INFO:
../src/unix/glx11.cpp(86): assert "xid" failed in SetCurrent(): window must be shown
BACKTRACE:
[1] wxGLContext::SetCurrent(wxGLCanvas const&) const
[2] wxGLCanvasBase::SetCurrent(wxGLContext const&) const
[3] Studio::Studio(bool) /home/andoru/sources/camoto-studio/src/studio.cpp:192
[4] CamotoApp::OnCmdLineParsed(wxCmdLineParser&) /home/andoru/sources/camoto-studio/src/main.cpp:197
[5] wxAppConsoleBase::OnInit()
[6] wxEntry(int&, wchar_t**)
[7] wxEntry(int&, char**)
[8] main /home/andoru/sources/camoto-studio/src/main.cpp:229
[9] __libc_start_main
[10] _start
Then it gives me this:
Unable to load OpenGL. Make sure you have OpenGL drivers available for your video card.
[glewInit() failed: Missing GL version]
When running glxgears, I get this:
GL_VERSION = 2.1 Mesa 10.5.5
As you might have saw from the previous backtraces I posted that the source folder is under ~/sources/camoto-studio (I cloned this git repo, so it inherited the same name), so I used --datarootdir=/home/andoru/sources/
This still won't work because per my first comment, the program will be looking for /home/andoru/sources/camoto-studio/icons/grid.png which can't be found. It's easiest in this case to set --datarootdir=/home/andoru/sources/camoto-studio then create the symlink per my previous comment (ln -s /home/andoru/sources/camoto-studio/data /home/andoru/sources/camoto-studio/camoto-studio). You can confirm you have set the directory correctly by running ls $DATAROOTDIR/camoto-studio/icons/grid.png (substituting $DATAROOTDIR with the value you passed to --datarootdir) and you will get a file-not-found error if the datarootdir is incorrect.
This has caused enough trouble for yourself and others that I have abandoned this idea for specifying the data directory at compile time, and the rewrite of Camoto Studio I am working on now will use some other method for finding its data files.
For the OpenGL error, I've seen it before but was never able to come up with a solution, as I have been unable to reproduce the error myself. I am currently working on a replacement for Camoto Studio which ditches wxWidgets and glew in favour of GTK+ and Cairo, so if you're unable to get this version of Studio working, hopefully v2.0 when it is available will be much easier to get up and running.
This still won't work because per my first comment [...]
Alright, my bad.
as I have been unable to reproduce the error myself.
Although I guess it's moot to say this at this point, but if you need me to do any debugging, let me know what commands to run. But I'm guessing you don't plan to solve the issue as you're migrating to other frameworks.
hopefully v2.0 when it is available will be much easier to get up and running.
Any clues when that will happen?
If you're interested in investigating then by all means - I will happily commit a fix if you are able to find one, but yes, I'm not spending too much time on it myself as my focus is the rewrite.
Current status is libgamecommon, libgamearchive and libgamegraphics have been rewritten to clean up the API and make use of C++11 features, libgamemaps is about 75% done, and libgamemusic is still to do. The new camoto-studio currently has a shell GUI and can open projects, but it doesn't have any editors yet so you can't open any files. I'm guessing it's still going to be a few months or more until the new Studio is comparable in functionality to the current release (this all started four months ago), so if you are able to fix this problem in the meantime it won't be a waste!
If you're interested in investigating then by all means - I will happily commit a fix if you are able to find one, but yes, I'm not spending too much time on it myself as my focus is the rewrite.
In that case, please let me know what I need to do.
I'm afraid I don't know! I have no idea what's causing it. The key error is:
../src/unix/glx11.cpp(86): assert "xid" failed in SetCurrent(): window must be shown
However from the forum thread I posted above, we confirmed the window is visible when SetCurrent() is called, so it could be a bug in wxWidgets, or in your video drivers, or somewhere else. I wasn't able to get any further than this as it doesn't look like the bug is within the Camoto code.
Okay, I'll try to ask the wxWidgets devs first, then if they don't know I'll file a bug report against the intel open source driver and see where it goes from there. Will keep you posted.
EDIT: I forgot to suggest (since you're re-writing some aspects of the tools) the possibility to disable certain features from the studio. For my particular case I just wanted to test out if the music in Raptor sounds more accurate than playing the .mus files through the ms-dos MUS player, and to achieve this simple task, I wouldn't need the rest of the editing parts of the studio just to achieve this small task. Also some might just want to see certain graphics from a game, and not need the rest of the functionality. So, would it be possible to make the studio a bit more modular?
For me I had to get over 30 new packages, just to be use a small fraction of the app's features. It's not the end of the world, but it would be great if this could be improved :)
I'm also using the Intel open source driver, so in that case, it's probably not the video driver at fault - good to know. Hopefully the wx devs have some ideas.
If you are only interested in music, you can use the command-line tool gamemus included with libgamemusic (which only needs Boost, libgamecommon and portaudio as a dependency. Portaudio can be omitted if you don't want playback and only need to convert. The other libraries have similar programs.) This program can play music and convert to/from other formats, so that should be all you need. However MIDI support is still lacking somewhat, and .mus support isn't polished yet, so .mus isn't really playable without jumping through some hoops at the moment.
I'll give some thought to compiling out features from the Studio that are unused, however this is a lot more complex than you'd think. Even just making portaudio optional for libgamemusic was quite a headache, so with the limited developer time available it's somewhat of a low priority - but of course patches are always welcome. Having said that, I have been trying to keep dependencies to a minimum, and I'm hoping that the new Studio will only require GTK+ in addition to what the libraries themselves use (png++ and portaudio). All the dependencies are a pain when trying to compile for Windows so I'd also be quite happy to see as many of them go as possible :-)
I'm also using the Intel open source driver, so in that case, it's probably not the video driver at fault - good to know. Hopefully the wx devs have some ideas.
I'm thinking it could be since I think I'm using the same driver as the guy mentioned in the forum posts. Since the guy wasn't using Debian, it's safe to assume that there's no bugs introduced from their packages, so I shouldn't go near their bug mailing lists.
But anyways, will keep you posted.
.mus support isn't polished yet, so .mus isn't really playable without jumping through some hoops at the moment.
What are those hoops exactly? This all applies to the GUI too, right?
The GUI supplies some data (such as which files you need to play a song) so generally it's more straightforward, whereas you have to manually list any needed files/patch banks/etc. with the command-line tools.
However the real issue here is that .mus files are reported as having MIDI instruments, and for technical reasons MIDI instruments aren't handled that nicely in the library. If a song uses two different MIDI instruments then it is handled as having two instruments, one might be MIDI #0 (a piano) and another MIDI #40 (violin). This means instrument #2 is a violin which maps to MIDI patch #40. If you load a GM patch bank to play the song through the FM synth, then instrument #2 will be a piano, not a violin. So I need to handle MIDI a bit differently for that reason as you get entirely wrong instruments at the moment. This issue does go away if you convert to MIDI though, as you don't need to load a patch bank to do that.
Aside from that, looking at the .mus code, I can't actually get it to correctly read a Raptor song! I'm not sure what's going on as I had it working at one point (I remember the Raptor songs playing too quickly and having to add a second file type to handle the different tempo) so I don't know what has broken since then. I'll see if I can fix it, but the best this will get you is conversion to MIDI. If you're looking for accurate playback, I don't think we have support for the MIDI patch bank included with the game yet, which is what you'll need if you want it to sound remotely like what the game does.
Ah, that's rather unfortunate :(
What about the other Apogee/id titles? Do those have the same problem?
In that case camoto-studio isn't very much useful to me at this moment, so I guess I'll stop here. I'll still keep an eye on the OpenGL issue on wxWidgets trac and report anything useful.
You can also take a peek if you wish: http://trac.wxwidgets.org/ticket/17036#ticket
There seems to have been someone who replied.
Interesting, looks like it was a bug and they fixed it. Odd because I'm running wx 3.0.2 as well and don't have the problem, but under Arch Linux instead.
Most of the other Apogee titles use IMF format and those are all fine. I think I've worked out why Raptor isn't working but I won't be able to fix it until the v2.0 release, and hopefully that will come with proper MIDI support. Hopefully you can keep an eye out for that and then playing/exporting Raptor music should at least be the same as the other MUS to MIDI converters. Hopefully as good as the original players if someone documents the OPL patch format used by the games in the meantime.