Neither one nor Many
Software engineering blog about my projects, geometry, visualization and music.
Allegro is a game programming library for C/C++ developers distributed freely, supporting the following platforms: Unix (Linux, FreeBSD, etc.), Windows, MacOS X and Haiku/BeOS. (...) source
wxWidgets is a C++ library that lets developers create applications for Windows, OS X, Linux and UNIX on 32-bit and 64-bit architectures as well as several mobile platforms including Windows Mobile, iPhone SDK and embedded GTK+. (...) source
I include allegro before wxWidgets, not sure if that matters, but what does matter is: the workaround regarding the RGB define, the use of winalleg.h instead of windows.h (needed to avoid conflict between allegro and windows.h); and disabling the 'magic' main() in allegro (wxWidgets' main is used):
#define ALLEGRO_NO_MAGIC_MAIN
#define RGB AL_RGB
#include <allegro.h>
#include <winalleg.h>
#undef RGB
Then I initialize allegro like this in OnCreate() of your wxWidgets application:
install_allegro(SYSTEM_NONE, &errno, NULL);
set_palette(desktop_palette); // example
set_color_depth(32); // example
You could draw allegro BITMAP's to wxStaticBitmap's in the OnPaint() event of the wxWidgets window. But you'll have to decide for yourself what method is most appropriate for your project.
wxPaintDC dc(wxDynamicCast(event.GetEventObject(), wxWindow));
// you probably already have the wxPaintDC
// Found the following code by searching for a very long time in the
// wxWidgets source code ;)
WXHDC wxHDC = wxPaintDC::FindDCInCache((wxWindow*) event.GetEventObject());
HDC hDC = (HDC) wxHDC;
... // do your thing here
draw_to_hdc(hDC, allegroBitmap, 0, 0);
// where allegroBitmap is a valid "BITMAP *"
It took me a while to figure out how I could use draw_to_hdc like this. It's not that obvious (see allegro forums). Others have been struggling with drawing allego bitmaps on wxStaticBitmaps. This method will still yield you quite a high fps count.
wxWidgets eventloop--or apparently random--crashes I have experienced some weird behaviour with using allegro with wxWidgets. There have been cases, that although allegro was initialized, in a separate window allegro seems to fail after calls to save_bmp(). Not in the function itself, but even weirder, after having called save_bmp() more than once, eventually the wxWidgets event handling system crashed, complaining about unhandled events. I guess something really wasn't properly initialized (although everything seemed to work, drawing, saving, etc.)
If you experience this, just initialize allegro in that window's OnCreate(), it should fix the problem. Maybe it has to do something with threading, that would explain why allegro has to be initialized (in that thread).
Assembly optimized {get|put}pixel crashes With _getpixel32() and _putpixel32() assembly, the optimized versions of getpixel() and putpixel(). For me these didn't work properly on 64-bit windows environments. After turning off some compiler optimizations the problem seemed to go away.
Non-assembly optimized {get|put}pixel crashes Continuing on the previous, if you replace _getpixel32 with getpixel, you may need to explicitely set a blending mode for 64-bit environments. Somehow I didn't do that, and as the non-assembly optimized getpixel function does bounds checking and blending modes, this became important.
[Edit 22-nov-2010: Just remembered this, but didn't verify it. It may have
something to do with calling drawing_mode(..)
, and not setting a specific
blending mode like set_trans_blender(..)
. Setting one of those, or instead
of drawing_mode and set_trans_blender a call to solid_mode(), would fix it.]
[Edit 29-01-2012: By the way. Allegro 5 integrates a little easier with wxWidgets, although come to think of it, I had to grep the source, or more specifically the examples directory in order to get the functions needed to render on a wxStaticBitmap though. I'll create a post for it: TODO]