Allegro 4.2.x and prior versions had a function, "win_set_window". This was, obviously, a Windows-specific function. It allows the user to create their own window and have Allegro bind itself to it. You can't use graphics calls, but you can use things like Allegro's sound and input drivers.
I know in 4.2.1, the last version of Allegro I used, it didn't work very well. It was buggy and Allegro's functionality didn't seem to work well.
Allegro 5, as far as I can tell, does not have similar functionality. Will there be some way to use Allegro 5 without it having to own the window?
]]>The only trouble I had with this in 4.2.2 was that you had to make sure the window had focus when using graphics functions. The windows API sends messages to the window when it gains and looses focus. I had to use a 'focus' variable to check whether the game ran or not (it just skipped the major parts of the loop).
All in all its only useful if you want a customized window or to use the windows GUI. Perhaps there is another way to do what you want? 
What I want is to use Allegro's sound and input systems while I do what I want with graphics and other things.
Allegro 4.2.1 didn't seem to work very well. I haven't tried a more recent version on the 4.2/4.4 branch. I was wondering if Allegro 5 was going to provide some equivalent to this functionality.
]]>We'd add it if someone sent in a patch; we have al_win_get_window() already. I'm not sure how it should work. Maybe you can propose a design.
]]>The design is exactly how win_set_window works in Allegro 4.2/4.4:
Registers an user-created window to be used by Allegro. This function is meant to be called before initialising the library with allegro_init() or installing the autodetected system driver (SYSTEM_AUTODETECT). It lets you attach Allegro to any already existing window and prevents the library from creating its own, thus leaving you total control over the window; in particular, you are responsible for processing the events as usual (Allegro will automatically monitor a few of them, but will not filter out any of them). You can then use every component of the library (graphics, mouse, keyboard, sound, timers and so on), bearing in mind that some Allegro functions are blocking (e.g. readkey() if the key buffer is empty) and thus must be carefully manipulated by the window thread.
Some modification of the details is understandable in order to make the whole thing work. But the main thing is that input, sound, and other non-graphics components function as normal.
]]>So al_create_display() could only succeed once? Or maybe the user should set a new display flag to tell it to use the user-supplied window.
]]>I'm not sure a display flag is the right way to go here. Creating an ALLEGRO_DISPLAY object isn't right because the user will assume that they can, you know, use it.
Functions like al_get_backbuffer, al_flip_display, and such should fail when using this mechanism. This is because Allegro should not modify the HWND in that way. That means no initializing OpenGL or D3D (or any other graphics driver).
I did notice a display flag called "ALLEGRO_COMPATIBLE_DISPLAY". What exactly does this mean, and when would it be used currently? If this means that an ALLEGRO_DISPLAY object could be made such that the user knows that Allegro rendering is not available, then using a display flag/setting to do this is just fine.
]]>Huh, I never noticed ALLEGRO_COMPATIBLE_DISPLAY before.
It seems to be for situations like if you only have OpenGL < 1.2 available. Then al_create_display() will not succeed in creating a display, as the rest of the graphics routines depend on OpenGL >= 1.2.
Back to al_win_set_window(). It sounds like you wouldn't have used al_create_display() at all. I think the problem with that is the `display' fields in keyboard/mouse events would have to be NULL, so you wouldn't have an indication which window was focused.
What about `ALLEGRO_DISPLAY *al_win_create_display(HWND wnd);'?
]]>That could work.
]]>