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)
*.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? 
Can we see some more source code?
This is the smalest prog I was able to write which is reproducing the error.
| 1 | #include <allegro.h> |
| 2 | |
| 3 | int 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 | } |
| 63 | END_OF_MAIN(); |
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.
You are guessing really good.
That worked! Thank you a lot!!
[EDIT]
But why is this only happening in wondowed mode??
You can bypass show_mouse by just draw_spriting the mouse every loop:
draw_sprite(temp, mouse_sprite, mouse_x, mouse_y);
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.
You can bypass show_mouse by just draw_spriting the mouse every loop:
Ok, thanks.
I will try that.
Your program crashes in fullscreen mode too, you just don't get that friendly "program crashed" box.
Ah. Ok. Thanks for solving this! 
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.
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.
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.
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.
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.
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 
)
Ah yes. I had this problem before but no one could answer it.
Excellent job guys.
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.
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.
OK. Got it now.
Thanks for your patience with my slow mind!
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.
That would only work if you set bmp to NULL whenever you destroy it.
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.
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).
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().