Allegro.cc - Online Community

Allegro.cc Forums » Programming Questions » Resizing window

Credits go to Dennis, Matthew Leverton, and Richard Phipps for helping out!
This thread is locked; no one can reply to it. rss feed Print
Resizing window
Inphernic
Member #1,111
March 2001

I have a need for a resizable Allegro/DX window, but I just can't get it to work. I can resize the doublebuffer and window without any problems, but I'm not sure if surface resizing is working OK. At any rate, the drawing area does not resize.

Has anyone done this before? Have I just missed something? Any ideas? I already searched the forums, and that didn't help very much (save for a few mentions of existing patches, but no downloads). I don't mind if the solution is ugly and/or hacky, as long as it works.

And oh, I attached modified versions of some Allegro DDraw code (all files go into src/win), which replace the used DDraw 2 (DX2?) interface with DDraw 7 (DX7) interface. Modifications made to 4.20 RC2.

Dennis
Member #1,090
July 2003
avatar

My untested suggestion:
Use SetWindowPos, which is a Win32 API function, and pass Allegro's win_get_window as the first parameter.

Inphernic
Member #1,111
March 2001

That will not work. If only it was so easy! :'(

Richard Phipps
Member #1,632
November 2001
avatar

Inphy: What if you modified the create_window part of Allegro to set the actual buffer created to be the same size as the desktop. That way you could alter the window size without having to expand or shrink the buffer. You would have to modify the shutdown window part too of course.

Inphernic
Member #1,111
March 2001

That is one solution (M. Molhanec also used that), but I'm still debating whether having 3-5MB of buffer (for the surface, not counting the doublebuffer) is OK or not. I'm leaning on "no", since I want this application to be quite lightweight.

Richard Phipps
Member #1,632
November 2001
avatar

But if you maximise the window aren't you going to be using that size buffer anyway?

Matthew Leverton
Supreme Loser
January 1999
avatar

Quote:

What if you modified the create_window part of Allegro to set the actual buffer created to be the same size as the desktop. That way you could alter the window size without having to expand or shrink the buffer.

What about dual display? I have 1024x768 and 1280x1024 displays. You'd have to create a buffer (1280x1024)*2 for that to work, even though I'd probably never use more than 1280x1024 at a time.

Inphernic
Member #1,111
March 2001

Problem solved - switched to SDL for this one. :P

Thanks anyway. I'm not sure if the DD7 interface above is directly of any use to anyone, but at least it exposes some extra interface which may be useful (in Allegro?).

Richard Phipps
Member #1,632
November 2001
avatar

Is SDL opensource? If so, can we use the code in Allegro?

Inphernic
Member #1,111
March 2001

It is open-source, but changing the behaviour of Allegro takes a bit more than just copy/pasting. Besides, there is a license clash (SDL's LGPL vs. Allegro's giftware).

Richard Phipps
Member #1,632
November 2001
avatar

So I take it SDL can resize the 'screen' buffer on the fly and update the width and height structures?

Inphernic
Member #1,111
March 2001

It sends me a SDL_VIDEORESIZE event (which is likely to have been generated from Windows' WM_RESIZE), which I then catch and call SDL_SetVideoMode again with the parameters given in the event. That's all there is to it, it rebuilds all the buffers/surfaces/whatnot for me.

Richard Phipps
Member #1,632
November 2001
avatar

Ok. It sounds like something similar could be done with Allegro then. But I'm not knowledgeable enough about the internals, so I could be wrong.

Thomas Fjellstrom
Member #476
June 2000
avatar

So you can't use win_set_window or win_set_wnd_create_proc and just catch WM_RESIZE yourself, and recall set_gfx_mode? It seems that'd be the same as what SDL does.

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

Evert
Member #794
November 2000
avatar

Quote:

Ok. It sounds like something similar could be done with Allegro then.

Yes, but with the current way teh graphics drivers work, any attempt to making resizable windows will be an ugly hack. The graphics drivers will need to be replaced and rewritten to accomodate this cleanly (which is one of the things for 4.3).

Inphernic
Member #1,111
March 2001

Quote:

So you can't use win_set_window or win_set_wnd_create_proc and just catch WM_RESIZE yourself..

I didn't use those two, I just modified Allegro's wndproc when I started working on this.

Quote:

..and recall set_gfx_mode?

Allegro (the latest RC) dies for me if I do more than one set_gfx_mode in one application. :P

But anyway, calling set_gfx_mode alone would (afaik) 1) destroy the window, 2) destroy the surface, 3) destroy the window thread, 4) destroy something more? - and then recreate them all again. That doesn't seem to be something that would work in real-time.

Richard Phipps
Member #1,632
November 2001
avatar

What about a seperate function that created a new bitmap, copied the old data to the new one, deleted the old one. Then updated the screen pointer to use the new one and updated all the line and other data attached to it and redrew the window?

Evert
Member #794
November 2000
avatar

Quote:

Allegro (the latest RC) dies for me if I do more than one set_gfx_mode in one application.

?!
What is the earliest version where you noticed this?

EDIT:

Quote:

What about a seperate function that created a new bitmap, copied the old data to the new one, deleted the old one. Then updated the screen pointer to use the new one and updated all the line and other data attached to it and redrew the window?

Careful, the screen bitmap is not a normal bitmap!

Inphernic
Member #1,111
March 2001

Quote:

What is the earliest version where you noticed this?

Actually, I just tried it again, and now it works properly. Sorry for the false alarm. :)

But now that I look at my old code, it looks like I first resize my doublebuffer, then call set_gfx_mode and right after that, draw_sprite. IIRC Allegro (at least the video thread) waits for a WM_TIMER after the window has been modified, in order to eliminate WM_RESIZE feedback (afaik creating and resizing a window both generate WM_RESIZE). Due to the timer, there may be a race hazard (calling draw_sprite before set_gfx_mode has properly finished)..?

Tomasu: Which also reveals that set_gfx_mode does at least destroy the window, and that's not really cool when one just wishes to resize the window by dragging its edges. Kind of like the MS joke - "you have moved your mouse - the system has to be restarted". :P

Go to: