Allegro game programming library

> i run my allegro app in windowed mode.
> using the 'DirectX Windowed' driver.
>
> i get an unhandled exception error when  i hit the msWindows task bars
> 'show desktop' icon (that one near the Start button).
> __colorconv_blit_16_to_32:

I also get this error, but I get it if I press Alt+Tab when the game window
is overlapped by the alt+tab popup window. This is a pretty long-standing
bug, so it's nothing the latest WIP has caused, but it seems no-one has
managed to find the cause yet. Windows 2000 here too.

At 07:28 PM 29/10/2002 +0000, you wrote:
> > i run my allegro app in windowed mode.
> > using the 'DirectX Windowed' driver.
> >
> > i get an unhandled exception error when  i hit the msWindows task bars
> > 'show desktop' icon (that one near the Start button).
> > __colorconv_blit_16_to_32:
>
>I also get this error, but I get it if I press Alt+Tab when the game window
>is overlapped by the alt+tab popup window. This is a pretty long-standing
>bug, so it's nothing the latest WIP has caused, but it seems no-one has
>managed to find the cause yet. Windows 2000 here too.


well i think we found the crash point..... somewhere in 
__colorconv_blit16_to_32
can we not find some guru to  look-into it...

aj.

> I also get this error, but I get it if I press Alt+Tab when the game window
> is overlapped by the alt+tab popup window. This is a pretty long-standing
> bug, so it's nothing the latest WIP has caused, but it seems no-one has
> managed to find the cause yet. Windows 2000 here too.

It doesn't occur when you simply put another window on top of the Allegro 
window, does it  ?

-- 
Eric Botcazou

> > I also get this error, but I get it if I press Alt+Tab when the game
> > window is overlapped by the alt+tab popup window.
> It doesn't occur when you simply put another window on top of
> the Allegro window, does it  ?

I only get the crash if the game window gets overlapped by the alt+tab
popup. If I move the window to the side of the screen so that Alt+Tab
doens't pop up over it, it works fine. Similarly, I can move other windows
over it with no problem.

I'm using 16-bit colour for my game, and the desktop is at 32-bit colour,
and I also get the crash in colorconv_blit_16_to_32.

Is there some problem with allegro trying to refresh the screen just when it
loses the focus, and therefore the screen isn't valid any more?

Cheers,
Chris

> I only get the crash if the game window gets overlapped by the alt+tab
> popup. If I move the window to the side of the screen so that Alt+Tab
> doens't pop up over it, it works fine. Similarly, I can move other windows
> over it with no problem.

Ok.

> I'm using 16-bit colour for my game, and the desktop is at 32-bit colour,
> and I also get the crash in colorconv_blit_16_to_32.

Does it happen on a 16-bit desktop too ? Does it happen or crash at another 
place if you put
        disable_direct_updating = yes
in the [graphics] section of allegro.cfg (which must be visible by the 
program) ?

> Is there some problem with allegro trying to refresh the screen just when
> it loses the focus, and therefore the screen isn't valid any more?

That's clearly the problem. From the point of view of Allegro, there is 
currently no difference between a normal overlapping window and the 
overlapping Alt+Tab window: when Allegro wants to refresh the screen, it 
first locks the DirecDraw surfaces it is going to use, then does the refresh 
and eventually releases the lock.

Allegro seems to crash in _colorconv_blit_16_to_32 because it can't access 
anymore the surface it has just locked, as though Alt+Tab was able to 
overrule the lock.

-- 
Eric Botcazou

> Does it happen on a 16-bit desktop too ?

Hmm, this is interesting, it doesn't work at all if I change the desktop to
16-bit. I just get the window on screen but it's filled with pink. The game
is going on in the background because I can hear the music, and can quit if
I type blindly, but I don't see any graphics at all.
However no, it doesn't crash if I Alt+Tab in this configuration.

> Does it happen or crash at another place if you put
>        disable_direct_updating = yes
> in the [graphics] section of allegro.cfg (which must be visible by the
> program) ?

I created a text file called allegro.cfg, put it in the game folder, and
added:
[graphics]
disable_direct_updating = yes

to it. It made no difference, I still got the crash in
_colorconv_blit_16_to_32. How can I tell whether it's using the config file
or not?

HTH,
Chris

> Hmm, this is interesting, it doesn't work at all if I change the deskto=
p to
> 16-bit. I just get the window on screen but it's filled with pink. The =
game
> is going on in the background because I can hear the music, and can qui=
t if
> I type blindly, but I don't see any graphics at all.

Your desktop, albeit reported as 16-bit by Windows, is probably a 15-bit =
one.=20
Try to change the color depth of your game to 15-bit.

> > Does it happen or crash at another place if you put
> >        disable_direct_updating =3D yes
> > in the [graphics] section of allegro.cfg (which must be visible by th=
e
> > program) ?
>
> I created a text file called allegro.cfg, put it in the game folder, an=
d
> added:
> [graphics]
> disable_direct_updating =3D yes
>
> to it. It made no difference, I still got the crash in
> _colorconv_blit_16_to_32. How can I tell whether it's using the config =
file
> or not?

You can add a dummy entry in the [graphics] section, for example:
=09dummy =3D 50

and add the following test in your code:
=09
=09char tmp1[64], tmp2[64];
=09if (get_config_int(uconvert_ascii("graphics", tmp1),
                        uconvert_ascii("dummy", tmp2), 0) !=3D 50)
=09   abort();

But I think your test is already pretty conclusive.

Could you try the attached patch ? Does it modify the crash point ?

--=20
Eric Botcazou

> Your desktop, albeit reported as 16-bit by Windows, is probably
> a 15-bit one.  Try to change the color depth of your game to 15-bit.

Hmm, I just tried that, and if I set the game to 15-bit, then set_gfx_mode
fails when I try to create a window. 16-bit succeeds but the window is
covered pink.
If I switch my desktop back to 32-bit, then both 15- and 16-bit windowed
modes work fine (except the alt+tab crash, obviously).
This is a bit worrying, I've never tried with a lower desktop depth before -
but I guess most people run their desktops at 32-bit these days so it
doesn't really matter.

One question - is there no way to detect the pinkness problem? I'd much
rather set_gfx_mode failed, then I could use a fullscreen mode instead,
rather than the player being presented with a pink window and assuming the
game doens't work on their system.

> Could you try the attached patch ? Does it modify the crash point ?

I tried the patch - unfortunately using it cuts the frame rate to about 20%,
making the game unplayable. And unfortunately it still crashes in
_colorconv_blit_16_to_32 (not sure whether it's in the same place but it's
still in that function) when I alt+tab.

Incidentally, I'm using WIP 4.1.3, because when I type make with 4.1.4, it
tells me:
Missing djgpp package! You need to install djdev203.zip (or whatever the
latest version is). Download this from wherever you got djgpp, and unzip
it into the root of your djgpp directory.

Strange that, because all the other versions compile just fine.

Anyway I'm running DirectX 8.1 on Windows 2000 if that helps.

Hope this helps in some way to clear up the bug,
Cheers,
Chris

> Hmm, I just tried that, and if I set the game to 15-bit, then set_gfx_mode
> fails when I try to create a window. 16-bit succeeds but the window is
> covered pink.

Then I lied to you: your desktop is really a 16-bit one. Sorry.

> This is a bit worrying, I've never tried with a lower desktop depth before
> - but I guess most people run their desktops at 32-bit these days so it
> doesn't really matter.

A bit problematic though.

> One question - is there no way to detect the pinkness problem? I'd much
> rather set_gfx_mode failed, then I could use a fullscreen mode instead,
> rather than the player being presented with a pink window and assuming the
> game doens't work on their system.

Could you try to play with the test program (in the tests/ directory) on your 
16-bit desktop ? It lets you choose whatever driver, color depth and 
resolution you want.

> I tried the patch - unfortunately using it cuts the frame rate to about
> 20%, making the game unplayable. And unfortunately it still crashes in
> _colorconv_blit_16_to_32 (not sure whether it's in the same place but it's
> still in that function) when I alt+tab.

Ok. On a side note, I didn't expect such a drop in performance <shrug>.

> Incidentally, I'm using WIP 4.1.3, because when I type make with 4.1.4, it
> tells me:
> Missing djgpp package! You need to install djdev203.zip (or whatever the
> latest version is). Download this from wherever you got djgpp, and unzip
> it into the root of your djgpp directory.

Did you run "fix mingw32" or 'fix msvc" ?

-- 
Eric Botcazou

> Could you try to play with the test program (in the tests/ directory) on
> your 16-bit desktop ? It lets you choose whatever driver, color depth
> and resolution you want.

Hmm, the pinkness seems to be caused by the DirectX Overlay driver - if I
manually switch it to DirectX Window, it works. What is the performance
advantage of the overlay driver - is it worth just hardcoding the dxwin
driver into my game instead of letting it use the overlay?

> Did you run "fix mingw32" or 'fix msvc" ?

*ahem* sorry about that, my bad :-)

Cheers,
Chris

> Hmm, the pinkness seems to be caused by the DirectX Overlay driver - if I
> manually switch it to DirectX Window, it works. What is the performance
> advantage of the overlay driver - is it worth just hardcoding the dxwin
> driver into my game instead of letting it use the overlay?

The overlay driver is theoretically as fast as the fullscreen one, perhaps 
without acceleration though. Much faster than the windowed one.

-- 
Eric Botcazou

>  And unfortunately it still crashes in _colorconv_blit_16_to_32 (not su=
re
> whether it's in the same place but it's still in that function) when I
> alt+tab.

I've attached another tentative fix.

--=20
Eric Botcazou

> I've attached another tentative fix.

Sorry to report, it still crashes. If it helps, the line that causes the
crash is line 827 of icolconv.s:

movd (%esi), %mm0    /* mm0 = 0000 0000  [rgb1][rgb2] */

ie. it seems to be reading the source bitmap, rather than writing the
destination, that causes the problem.

Cheers,
Chris

Chris Jones wrote:

> >I've attached another tentative fix.
>
>
> Sorry to report, it still crashes. If it helps, the line that causes the
> crash is line 827 of icolconv.s:
>
> movd (%esi), %mm0    /* mm0 = 0000 0000  [rgb1][rgb2] */



You wouldn't happen to have the value of %esi at that point, would you?

> > movd (%esi), %mm0    /* mm0 = 0000 0000  [rgb1][rgb2] */
> 
> You wouldn't happen to have the value of %esi at that point, would you?

Well, it was 0x017E7000, not that that really means much. 

Incidentally, if I disable MMX it crashes on the line:

 movb (%esi), %al

instead, so it's definately not an MMX problem.

Cheers,
Chris

> Well, it was 0x017E7000, not that that really means much.
>
> Incidentally, if I disable MMX it crashes on the line:
>
>  movb (%esi), %al
>
> instead, so it's definately not an MMX problem.

Indeed. Thanks for these detailed informations. %esi points to the source data 
passed to the color converters, which come from the first backbuffer.

Here's the background:

- when the color depth matches that of the desktop, the driver uses a unique 
internal backbuffer (a DirectDraw video surface). Refreshing is done by 
blitting the backbuffer to the primary surface with IDirectDrawSurface2_Blt()

- when the color depth doesn't match, the driver uses a first backbuffer (a 
DirectDraw system bitmap) whose color depth is that of Allegro and a second 
backbuffer (a DirectDraw video surface) whose depth is that of the primary 
surface. Refreshing is done by converting-blitting from the first backbuffer 
to the second one with the asm color converters, then blitting from the 
second backbuffer to the primary surface with IDirectDrawSurface2_Blt()
[actually in safe mode only; in direct updating mode, the driver directly 
converts-blits from the first backbuffer to the primary surface].

In the first case, Allegro doesn't crash probably because the blitter 
IDirectDrawSurface2_Blt() can handle being interrupted when performing its 
task. In the second case, we lock the surfaces (IDirectDrawSurface2_Lock) 
before starting to convert-blit; so once the lock is obtained, the code can't 
handle being interrupted (i.e the surfaces can't become invalid).

-- 
Eric Botcazou

> In the first case, Allegro doesn't crash probably because the blitter
> IDirectDrawSurface2_Blt() can handle being interrupted when
> performing its task. In the second case, we lock the surfaces
> (IDirectDrawSurface2_Lock) before starting to
> convert-blit; so once the lock is obtained, the code can't
> handle being interrupted (i.e the surfaces can't become invalid).

Makes sense - the question is, why does this only seem to happen to allegro,
and how do other games get around it? Could any tips be taken from the SDL
source code, for example?

If all else fails, how about the nasty kludge of wrapping the
_colorconv_blit function in a _try..._except clause, to catch the exception
and abort the blit if the surface has been lost?

Cheers,
Chris

> Makes sense - the question is, why does this only seem to happen to
> allegro, and how do other games get around it? Could any tips be taken from
> the SDL source code, for example?

Does SDL feature a behind-the-scene color convertion mechanism as ours ? 
Moreover, SDL is structurally simpler than Allegro; in particular, I think 
only one thread typically draws onto the screen. In Allegro, two threads draw 
onto the screen in windowed mode.

I now think that the second thread (which automatically repaints the window on 
demand) may be the culprit, because the crash only occurs when the Alt+TAB 
window overlaps the Allegro window. Could you try to disable it ? Simply 
comment out line 297 in src/win/wwnd.c:

    win_gfx_driver->paint(&ps.rcPaint);


> If all else fails, how about the nasty kludge of wrapping the
> _colorconv_blit function in a _try..._except clause, to catch the exception
> and abort the blit if the surface has been lost?

Gosh! I'd rather advertise Microsoft products than use such an ugly hack ;-)

-- 
Eric Botcazou

> I now think that the second thread (which automatically repaints the
window
> on  demand) may be the culprit, because the crash only occurs when the
> Alt+TAB window overlaps the Allegro window. Could you try to
> disable it ? Simply  comment out line 297 in src/win/wwnd.c:

I tried that, and yes, it fixes the crash! Thanks!

However, the problem then is that on switching back into the game, the image
isn't restored, so the window is only redrawn once the game does a repaint
itself - which if you're using dirty rectangle updating, gives a rather odd
look :-)

Cheers,
Chris

> I tried that, and yes, it fixes the crash! Thanks!

Ok, we've found the culprit. Now we only have to devise a mechanism in order 
to prevent him from commiting his crime :-)

> However, the problem then is that on switching back into the game, the
> image isn't restored, so the window is only redrawn once the game does a
> repaint itself - which if you're using dirty rectangle updating, gives a
> rather odd look :-)

Of course. It was by no means a fix, just a proof of concept. I'll try to 
think about a true fix tomorrow.

Thanks for the quick feedback.

-- 
Eric Botcazou

> I tried that, and yes, it fixes the crash! Thanks!

Sorry about the delay...

Could you try the 4.1.5 WIP and see if the problem is still there ? If so, 
could you try to replace src/win/wddwin.c by the following one:

http://www.multimania.com/ebotcazou/dev/wddwin.zip

and recompile/reinstall the library. Does that help ? If no, try again to set 
disable_direct_updating = yes in allegro.cfg .

Thanks in advance.

-- 
Eric Botcazou

> Could you try the 4.1.5 WIP and see if the problem is still there ?

Tried it, no luck.

> could you try to replace src/win/wddwin.c by the following one:
> http://www.multimania.com/ebotcazou/dev/wddwin.zip

Yes! Tried this one out and it fixes the crash, thanks! One minor thing -
when I tried to compile it, it said "unable to open include file 'wddraw.h'"
and I had to copy that header file into the include folder to make it work,
but maybe that's just my setup being wonky.

Anyway, I alt+tabbed quite furiously and was unable to crash it, so nice
work :-)

The only thing now is that I can't see the alt+tab window, as the game seems
to redraw itself on top immediately, so I have to guess what application I'm
selecting.

I didn't need to do the disable_direct_updating trick, by the way.

Cheers,
Chris

> > could you try to replace src/win/wddwin.c by the following one:
> > http://www.multimania.com/ebotcazou/dev/wddwin.zip
>
> Yes! Tried this one out and it fixes the crash, thanks!

OK. I switched from a DirectX call to a GDI call, which is probably safer in 
that situation.

> One minor thing - when I tried to compile it, it said "unable to open
> include file 'wddraw.h'" and I had to copy that header file into the include 
> folder to make it work, but maybe that's just my setup being wonky.

Weird! Did that happen with previous versions ? Could you post the command 
line that makes the compiler choke ?

> The only thing now is that I can't see the alt+tab window, as the game
> seems to redraw itself on top immediately, so I have to guess what
> application I'm selecting.

I'm going to investigate.

> I didn't need to do the disable_direct_updating trick, by the way.

That's fortunate, because the normal updating mode is now 3x slower (up from 
2x slower) than the direct updating mode.

Thanks for the quick feedback.

-- 
Eric Botcazou

> > One minor thing - when I tried to compile it, it said "unable to open
> > include file 'wddraw.h'" and I had to copy that header file into the
> > include  folder to make it work, but maybe that's just my setup
> > being wonky.
> Weird! Did that happen with previous versions ? Could you post
> the command line that makes the compiler choke ?

The problem didn't occur with WIP 4.1.5 itself - it was only when I replaced
the wddwin.c file with your new version and typed 'make' again, that the
'unable to open include file' message came up. But, it was probably
something I did wrong so I wouldn't worry too much.

Cheers,
Chris

> The only thing now is that I can't see the alt+tab window, as the game
> seems to redraw itself on top immediately, so I have to guess what
> application I'm selecting.

Do you run your game in SWITCH_BACKGROUND mode ?

I'm unable to reproduce the problem on Win98 SE, but that's not very 
surprising because I wasn't able to reproduce the crash either...

-- 
Eric Botcazou

> The problem didn't occur with WIP 4.1.5 itself - it was only when I
> replaced the wddwin.c file with your new version and typed 'make' again=
,
> that the 'unable to open include file' message came up. But, it was
> probably something I did wrong so I wouldn't worry too much.

I posted the file from my Linux box, so it may be in Unix text encoding=20
format. Do you have the DJGPP utod conversion utility ? If no, I've attac=
hed=20
an equivalent source code.

--=20
Eric Botcazou

> Do you run your game in SWITCH_BACKGROUND mode ?

No, I use SWITCH_PAUSE.

btw I tried using utod on the source file and it didn't make any
difference - but if I delete the whole obj folder and rebuild the full
allegro it seems to work, so I wouldn't worry about it.

Cheers,
Chris

> No, I use SWITCH_PAUSE.

Ok, I'm now able to reproduce the problem. Not very nice indeed, but still 
better than a crash. I put it on the todo list.

> btw I tried using utod on the source file and it didn't make any
> difference - but if I delete the whole obj folder and rebuild the full
> allegro it seems to work, so I wouldn't worry about it.

Hmm... wrong phase of the Moon I'd say :-)

-- 
Eric Botcazou

Here's the sample output of my problem:

[cut]
obj/mingw32/runner.exe gcc -s  -Wl,--subsystem,console -o tools/dat.exe
obj/mingw32/alleg/dat.o lib/mingw32/libaldat.a
lib/mingw32/liballeg.a -lkernel32 -luser32 -lgdi32 -lcomdlg32 -lole32 -ldinp
ut -lddraw -ldxguid -lwinmm -ldsound
'?gcc' is not recognized as an internal or external command,
operable program or batch file.
make[1]: *** [tools/dat.exe] Error 1
make[1]: Leaving directory `C:/code/allegro-4.1.6'
make: *** [all] Error 2
[/cut]


I got that after a "fix mingw32", "make all"

The line looks innocent enough, but when passing through "runner.exe", it
gives me the "Xgcc is not recognized...", where X is a thick underscore
character. If I copy and paste the line from gcc and on, it works fine. I
type "make all" and it continues till it gets to the next similar line. It
did it four or five times I think.

Perhaps something is messed up with runner.exe?

C:\code\allegro-4.1.6>obj\mingw32\runner.exe
'?' is not recognized as an internal or external command, operable program
or batch file.

C:\code\allegro-4.1.6>obj\mingw32\runner.exe echo
'?echo' is not recognized as an internal or external command,operable
program or batch file.

(I don't know how it will come across, but there is a think underscore in
both of those error lines. I tried to send, but it warned me about it having
to use Unicode to display properly. Dunno if that will effect anyone, so i
just sent it "as-is" without unicode.)

Did runner.exe change at all , or is my setup just fubar'd?

Specs:
~~
Windows XP
gcc 2.95.3-6 (mingw32)
~~

It's late, so I'm just going to bed. I haven't tried on MSVC or anything
else. Let me know if I'm missing something obvious here...

--
Matthew Leverton - matthew@...
http://www.allegro.cc

> obj/mingw32/runner.exe gcc -s  -Wl,--subsystem,console -o tools/dat.exe
> obj/mingw32/alleg/dat.o lib/mingw32/libaldat.a
> lib/mingw32/liballeg.a -lkernel32 -luser32 -lgdi32 -lcomdlg32 -lole32
> -ldinp ut -lddraw -ldxguid -lwinmm -ldsound
> '?gcc' is not recognized as an internal or external command,
> operable program or batch file.
> make[1]: *** [tools/dat.exe] Error 1
> make[1]: Leaving directory `C:/code/allegro-4.1.6'
> make: *** [all] Error 2

Why on Earth did the problem not show up during my many builds ? :-(
The obvious fix is attached.

[Try not to answer to an unrelated message when starting a new thread, th=
is=20
confuses my mail reader].

--=20
Eric Botcazou

>>The obvious fix is attached.
>>
Ok, that made it work fine.

>>[Try not to answer to an unrelated message when starting a new thread,
this
>>confuses my mail reader].
>>

Sorry. :) I've got a FreeBSD install problem now, and I'll try to do better
with that email. ;)

--
Matthew Leverton - matthew@...
http://www.allegro.cc

> Ok, that made it work fine.

Thanks. Any other problems (with MSVC for example) ?

-- 
Eric Botcazou

"Eric Botcazou" wrote on 03 Nov 2002...
> > Hmm, the pinkness seems to be caused by the DirectX Overlay driver
> > - if I manually switch it to DirectX Window, it works.
> The overlay driver is theoretically as fast as the fullscreen one, perhaps
> without acceleration though. Much faster than the windowed one.

Bit of a blast from the past this, but my conclusion has been that the DX
Overlay driver just gives a pink window if the game colour depth is the same
as the desktop colour depth. However, if this is the case, then the DX
Windowed driver's performance is good and can be used instead.

My startup code now uses this:

if (want_color_depth >= desktop_color_depth())
  driver = GFX_DIRECTX_WIN;
else
  driver = GFX_DIRECTX_OVL;

set_gfx_mode(driver, ...);

Is this a problem particular to my system, or does it happen to other people
as well? Should the DX Overlay driver be modified to return a failure if the
desktop colour depth is the same as the one requested, so that set_gfx_mode
will fail and the user can choose another depth based on that?

Cheers,
Chris

> Bit of a blast from the past this, but my conclusion has been that the DX
> Overlay driver just gives a pink window if the game colour depth is the
> same as the desktop colour depth.

This condition is required for the ovl driver to run, see the docs.

> However, if this is the case, then the DX Windowed driver's performance is 
> good and can be used instead.

Yes, but it is still double-buffered while the ovl driver is not.

-- 
Eric Botcazou

> > Bit of a blast from the past this, but my conclusion has been that the
> > DX Overlay driver just gives a pink window if the game colour
> > depth is the same as the desktop colour depth.
>
> This condition is required for the ovl driver to run, see the docs.

Ah, my apologies - in that case the overlay driver must always be failing
and it's falling back to the windowed driver anyway. I guess there's no way
we can detect when the colour depths are the same and the overlay driver
appears to succeed but just goes pink, then. Shame.