Allegro.cc - Online Community

Allegro.cc Forums » Programming Questions » Fullscreen mode ok; Windowed crashes

Credits go to BAF and Jonny Cook for helping out!
This thread is locked; no one can reply to it. rss feed Print
Fullscreen mode ok; Windowed crashes
Christopher Bludau
Member #5,401
January 2005

I use the var
BITMAP *temp;

creating it using
temp = create_bitmap(800,600);

After that I'm using it to draw stuff to it and blitt it to the screen.
No problem so far.

At the end of my prog I call
destroy_bitmap(temp);

When running the prog in fullscreen mode it exits properly.

When running in windowed mode it crashes wit the folowing error (translated)

Quote:

*.exe did encounter a problem and had to be closed (what i wanted to do anyway!!) [send] [not send]

When I remove the line destroy_bitmap(temp); then the program closes fine in windowed mode too.

Any ideas? What is wrong in destroying a used bitmap? And why is this only happening when windowed? ???

BAF
Member #2,981
December 2002
avatar

Can we see some more source code?

Christopher Bludau
Member #5,401
January 2005

This is the smalest prog I was able to write which is reproducing the error.

1#include <allegro.h>
2 
3int main(int argc, char *argv[])
4{
5/*** MAIN begin ***/
6 
7 /* some vars */
8 int col_white;
9 BITMAP *temp;
10 
11 /* install allegro, set up the screen */
12 allegro_init();
13 set_window_title("windowed test O_o");
14 
15 install_keyboard();
16 install_timer();
17 install_mouse();
18
19 /* set a 15 or 16 bpp video mode */
20 set_color_depth(16);
21 if (set_gfx_mode(GFX_AUTODETECT_WINDOWED, 800, 600, 0, 0) != 0) {
22 set_color_depth(15);
23 if (set_gfx_mode(GFX_AUTODETECT_WINDOWED, 800, 600, 0, 0) != 0) {
24 set_gfx_mode(GFX_TEXT, 0, 0, 0, 0);
25 allegro_message("Error setting a 15 or 16 bpp 800x600 video mode\n%s\n", allegro_error);
26 }
27 }
28
29 /* color white */
30 col_white = makecol(255,255,255);
31
32 /* creating the bitmap temp*/
33 temp = create_bitmap(800,600);
34 
35 /* clear temp to col_white */
36 clear_to_color(temp,col_white);
37 
38 
39
40 /* main loop */
41 while(!key[KEY_ESC]) {
42
43
44 /* show mouse */
45 show_mouse(temp);
46 
47 /* blit temp to screen */
48 blit(temp, screen, 0,0,0,0,800,600);
49
50 
51
52 }
53 
54
55 /* THIS LINE is causing the problem. removing it will make the prog quit properly */
56 /* Otherwise it just crashes */
57 destroy_bitmap(temp);
58
59 return 0;
60
61/*** MAIN end ***/
62}
63END_OF_MAIN();

Jonny Cook
Member #4,055
November 2003

Try show_mouse(NULL) before you destroy temp. That might work, but I'm totally just guessing. Otherwise the hardware mouse will be drawn to a bitmap that no longer exists, making your game crash.

The face of a child can say it all, especially the mouth part of the face.

Christopher Bludau
Member #5,401
January 2005

You are guessing really good.

That worked! Thank you a lot!!

[EDIT]
But why is this only happening in wondowed mode??

BAF
Member #2,981
December 2002
avatar

You can bypass show_mouse by just draw_spriting the mouse every loop:

miran
Member #2,407
June 2002

Quote:

But why is this only happening in wondowed mode??

Your program crashes in fullscreen mode too, you just don't get that friendly "program crashed" box.

--
sig used to be here

Christopher Bludau
Member #5,401
January 2005

Quote:

You can bypass show_mouse by just draw_spriting the mouse every loop:

Ok, thanks.
I will try that.

Quote:

Your program crashes in fullscreen mode too, you just don't get that friendly "program crashed" box.

Ah. Ok. Thanks for solving this! ;D

Evert
Member #794
November 2000
avatar

Quote:

You can bypass show_mouse by just draw_spriting the mouse every loop:

Which isn't always a great idea (in fact, I personally consider it a bad idea in all circumstances).
I won't repeat why, I posted that once already today.

Christopher Bludau
Member #5,401
January 2005

Because mouse update speed will be limited to the framerate of the game.

But..hmm... should be enough.
Still in development. maybe i will change it again.

And hardware acceleration is not so important. yet ;)

Thanks for mentioning that.

Evert
Member #794
November 2000
avatar

Quote:

Because mouse update speed will be limited to the framerate of the game.

But..hmm... should be enough.

It won't be if your framerate drops for some reason or if your game is running on a slower computer.

Quote:

And hardware acceleration is not so important.

I didn't mean hardware acceleration, I meant letting the OS do the cursor drawing for you. This eliminates all headaches associated with scaring or unscaring the mouse yourself, it plays a bit nicer with windowed mode (your mouse cursor doesn't get clipped at the edge of the window) and you don't run into problems when your framerate drops.

Christopher Bludau
Member #5,401
January 2005

Quote:

I didn't mean hardware acceleration, I meant letting the OS do the cursor drawing for you. This eliminates all headaches associated with scaring or unscaring the mouse yourself, it plays a bit nicer with windowed mode (your mouse cursor doesn't get clipped at the edge of the window) and you don't run into problems when your framerate drops.

Ok. That sounds interesting! Thank you for clarifying this.

Quote:

It won't be if your framerate drops for some reason or if your game is running on a slower computer.

But when the framerate drops, the whole gameplay will be screwed up.
What use is a smooth mouse in such a situation? I mean if the mouse cursor is the only thing that runs smooth, it is of no use? Or am I missing something here (again :-/)

Ceagon Xylas
Member #5,495
February 2005
avatar

Ah yes. I had this problem before but no one could answer it.
Excellent job guys.

Evert
Member #794
November 2000
avatar

Quote:

But when the framerate drops, the whole gameplay will be screwed up.

That should not happen (normally, but depends on your game type) because the game logic and input should continue to run at the same rate on all computers.

Quote:

What use is a smooth mouse in such a situation? I mean if the mouse cursor is the only thing that runs smooth, it is of no use?

See above. If you've done things right, the input and logic continue to run at the same speed and it's just the graphics that are lagging behind. It's pretty annoying when the game becomes hard to control because the visual cursor is lagging far behind the real position of the cursor.
In a way, the mouse cursor is not a part of the graphics system, it's a part of the input system and should therefor update at (approximately) the same rate.

For reference, I once (years ago, computers are literally one or two orders of magnitude faster nowadays) looked at this. I had the mouse cursor drawn to a double buffer background and updated it along with the buffer. This was ok-ish on my 300MHz k6 box, but it was utterly unusable on my 486-DX2. Warcraft II ran on the same machine with a perfectly responsive and smooth mouse cursor, so I knew that it was possible to do it `properly'. I think I even had a clever dirty-rectangle-type trick to get around the problem of having to call scare_mouse()/show_mouse(). I even implemented my own scare_mouse_area() (it didn't exist in Allegro back then).
Nowadays, I think hardware cursors are the way to go, if they're available.

Christopher Bludau
Member #5,401
January 2005

OK. Got it now.
Thanks for your patience with my slow mind!

wiseguy
Member #44
April 2000
avatar

I know you seem to have already gotten past this problem, but you may also want to check to make sure that create_bitmap didn't return NULL. I don't see where you did any error checking on that. Whenever I destroy a bitmap I do something like this:

if (bmp)
destroy_bitmap(bmp);

that way, if there isn't a bitmap to destroy it doesn't do anything. I had the same problem with something I was working on, and that fixed the problem.

BAF
Member #2,981
December 2002
avatar

That would only work if you set bmp to NULL whenever you destroy it.

Christopher Bludau
Member #5,401
January 2005

Error checking is always a good idea.
But I don't understand what BAF means.

I just changed my code to display the mouse cursor on the screen and not on my temp bitmap.
(with calling "show_mouse(screen);" only once)

After blitting all the stuff to my temp bitmap I do this:

  scare_mouse();
  blit(temp, screen, 0,0,0,0,800,600);
  unscare_mouse();

I guess this does what i want.

Evert
Member #794
November 2000
avatar

Quote:

Whenever I destroy a bitmap I do something like this:

if (bmp)
destroy_bitmap(bmp);

You don't have to. Passing NULL to destroy_bitmap() is perfectly legal (it does nothing).

Quote:

I just changed my code to display the mouse cursor on the screen and not on my temp bitmap.

That's a good idea. Having allegro draw the mouse anywhere else than on the screen is sortof pointless anyway and defeats the purpose of having Allegro draw the mouse in the first place.

One suggestion: look into scare_mouse_area(). That won't do anything different if you're using a double buffer, but if you ever want to update only part of the screen, then using scare_mouse_area() is better than using scare_mouse().

Go to: