Re: [AD] Tr: Allegro 5.0's interface with Windowing systems

["Eric Botcazou" <ebotcazou@xxxxxxxxxx>]

> One problem I have with Allegro is creating useful tools using Allegro's
> drawing capabilities. I want to use MFC to write these tools rather than
> the (rather poor) GUI that Allegro provides. But, something like a tilemap
> editor is virtually impossible to implement in Allegro.

I partially disagree: a tilemap editor can be implemented using MFC+
Allegro's GDI routines, given that the blitting performances don't really
matter here.

> The problem is message processing: Allegro wants to use its own message
> processing loop. MFC wants to use its own message processing loop.
> Obviously, only one can function at a time. Therefore, the only way to
> draw into an MFC window with Allegro is to use the horrendously slow
> "blit_to_hdc" method.

You can attach Allegro to your own window by using win_set_window() (see the
docs, section "Windows specifics"), thus keeping control over the message
loop. But the only way to draw onto the window is indeed to use the GDI
routines.

> There is a solution to this delima: enter into a cooperative relationship
> with the user.

Not so easy: DirectDraw doesn't mix very well with Win32, let alone the MFC.

> The user will create a HWND. If Allegro needs to change some of the
> creation parameters before creation, then there should be an appropriate
> function to allow Allegro to modify the CREATESTRUCT. In the window's
> OnCreate handler, Allegro should be called with the HWND to bind that
> HWND to Allegro's system.

See win_set_window().

> This function would be analogous to a call to "alCreateDisplay" (in the
> new graphics API). It would also replace that call. The returned BITMAP
> refers to the window of that HWND.

Do you mean that Allegro should wrap the Win32 DC in one of its BITMAPs ?
If so, I suppose you want the binding to be transparent, i.e any drawing
operation done on the Win32 side must be reflected on the Allegro side, as
well as the converse. Unfortunately, that's not realistic because Win32 DCs
and Allegro BITMAPs are very different objects, hence the need for
translating every drawing operation with the GDI routines.

On the other hand, if you only mean a one-directional mapping of Allegro's
screen BITMAP to the window, so that Allegro's DirectDraw screen surface can
be visible inside the window, that's doable, even with the current Allegro
4.x infrastructure. I'll investigate this problem for the 4.1.x development
versions.

> For any message that Allegro needs to know about, there should be a
> function avaliable that will pass the message data along to Allegro. For
> example, if Allegro needs to process WM_SIZE messages on that HWND, then
> the user program must process WM_SIZE message and call "alWndOnSizeMsg"
> with the HWND and the new width/height.

No need for such a function. Allegro automatically monitors the messages of
the window that it has been attached to by win_set_window().

> The major change in this (besides creation and getting the messages in a
> different fashion) is that Allegro must allow for window resizing. Now, if
> the window was created by Allegro, then it is perfectly reasonable for
> Allegro not to appreciate window resizing and disallow it. However,
> user-created HWNDs should allow for window resizing.

Supporting resizing would require a major overhaul of pretty much the entire
graphics subsystem of the library. That's unrealistic for the 4.x series.

Moreover, I think it would effectively impose a costly paradigm shift to the
way Allegro works. Currently, input and ouput subsystems are independent
entities and every Allegro program works more or less the same: it reads the
input (keyboard, mouse, joystick), processes the datas and changes the ouput
(graphics, sound) accordingly. Now if we allowed to resize the window, the
graphics subsystem would become part of both subsystems, adding much
complexity, both for Allegro ('s programmers ;-) and for the user.

> If you've bound the HWND to either DirectX or OpenGL, neither of them are
> particularly upset at a resize request, so the underlying code need not
> change much. The only thing is that the user must understand that the
> display BITMAP's size can change based on the window resizing.

I don't know OpenGL very well, much more DirectX, and I disagree: DirecDraw
is not particularly well suited to resizing. You have to destroy everything
when you want to resize a DirectDraw surface: first every object attached to
it (palette, clipper, backbuffer), then the surface itself. For example,
resizing on the fly an overlay surface with two backbuffers while triple
buffering would be a nightmare. IMHO resizing is not worth the complexity it
would introduce.

> This will solve the one major hurdle I have in working with Allegro. As it
> stands now, I can't really make functioning WYSIWYG tools in Allegro
> because I can't use the same rendering facilities in a windowed tool that
> I can in a game.

Maybe can you try to following approach: use MFC+Allegro's GDI routines for
the static part of your app (e.g the frame editor), and then use a separate
Allegro window to render the animation. As the GDI routines are independent
from the core library, there will be no conflict between the two sides.

--
Eric Botcazou
ebotcazou@xxxxxxxxxx