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

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


On March 21, 2002 04:25 am, you wrote:
> ----- Original Message -----
> From: Jason McKesson <jmckesson@xxxxxxxxxx>
> To: <ebotcazou@xxxxxxxxxx>
> Sent: Thursday, March 21, 2002 5:11 AM
> Subject: Allegro 5.0's interface with Windowing systems
>
>
> Hello, I'm an Allegro user, and I have a suggestion for the next release of
> Allegro. I understand that you are responsible for the Win32 port of
> Allegro, and my suggestion was referred to you by Bob.
>
> 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. Allow me to clarify
> the problem.
>
> 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.
>
> There is a solution to this delima: enter into a cooperative relationship
> with the user.
>
> 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. 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.
>
> 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. I don't know exactly which message
> Allegro needs to know about, but I'm sure you do.
>
> 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. 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.
>
> Note that virtually all of this likely applies to X-Windows. It may require
> a few different function calls, but you can probably create the same effect
> under X as you can under Win32.
>
> 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.
>
> Thank you.
> -------------------------------

Sounds like an awesome idea.
But Allegro is supposed to be a library for creating cross platform tools, so 
why use MFC? I can't use MFC apps here but I can use wx-Windows and fltk.
(both are platform independent gui class libraries, and I belive both have 
gui editors. I would also suggest using QT http://trolltech.com)

-- 
Thomas Fjellstrom
tfjellstrom@xxxxxxxxxx
http://strangesoft.net



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/