|
Fullscreen mode ok; Windowed crashes |
count
Member #5,401
January 2005
|
I use the var creating it using After that I'm using it to draw stuff to it and blitt it to the screen. At the end of my prog I call 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
|
Can we see some more source code? |
count
Member #5,401
January 2005
|
This is the smalest prog I was able to write which is reproducing the error.
|
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. |
count
Member #5,401
January 2005
|
You are guessing really good. That worked! Thank you a lot!! [EDIT]
|
BAF
Member #2,981
December 2002
|
You can bypass show_mouse by just draw_spriting the mouse every loop: draw_sprite(temp, mouse_sprite, mouse_x, mouse_y);
|
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. -- |
count
Member #5,401
January 2005
|
Quote: You can bypass show_mouse by just draw_spriting the mouse every loop:
Ok, thanks. Quote: Your program crashes in fullscreen mode too, you just don't get that friendly "program crashed" box. Ah. Ok. Thanks for solving this!
|
Evert
Member #794
November 2000
|
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). |
count
Member #5,401
January 2005
|
Because mouse update speed will be limited to the framerate of the game. But..hmm... should be enough. And hardware acceleration is not so important. yet Thanks for mentioning that.
|
Evert
Member #794
November 2000
|
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. |
count
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.
|
Ceagon Xylas
Member #5,495
February 2005
|
Ah yes. I had this problem before but no one could answer it. |
Evert
Member #794
November 2000
|
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. 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). |
count
Member #5,401
January 2005
|
OK. Got it now.
|
wiseguy
Member #44
April 2000
|
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) 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
|
That would only work if you set bmp to NULL whenever you destroy it. |
count
Member #5,401
January 2005
|
Error checking is always a good idea. I just changed my code to display the mouse cursor on the screen and not on my temp bitmap. 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
|
Quote: Whenever I destroy a bitmap I do something like this: if (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(). |
|