OK, I have done a fair amount of my game and have just got to collision detection. It was working but I changed something and I'll have to fix it again. But anyway, I ran it on Windows and it sometimes works, and sometimes it doesn't draw anything in the window until I move it. It only updates the picture when I move the window. Does anybody know what could cause this? I'd like to have a Windows port so this is fairly important. Hopefully somebody has had this problem and fixed it...?

No idea, but I would help if you provide versions of everything (Allegro, static? dynamic?, compiler, compiler command, etc.)

Allegro 4.2.0 Static linked
Windows XP
Mingw32 (Dev-C++)
Compiler: -DALLEGRO_STATICLINK
C++ Compiler: -DALLEGRO_STATICLINK
Linker: -lalleg_s -lkernel32 -luser32 -lgdi32 -lcomdlg32 -lole32 -ldinput -lddraw -ldxguid -lwinmm -ldsound

EDIT:
Also it's written in C and has no other libraries. I don't have super user privileges, but it works sometimes so this might not be the problem.

If it sometimes draws to the screen and sometimes doesn't and almost seems to be random then my best guess is you're not drawing to the screen properly. I know, since it probably works on the other OS you're designing for that may not seem right, but Windows does some strange things when it comes to the screen and as a result, your code which works in one OS may not work in Windows.

Could you post a segment of your code showing just a little before the actual draw to the screen and just a little after?

I'm going to guess that you're doing something like this:

do {
  clear_bitmap(screen);
  vsync();

  // Game Code Goes Here

  blit(back_buffer,screen,0,0,0,0,screen->w,screen->h);
} while (gameloop_active);

--- Kris Asick (Gemini)
--- http://www.pixelships.com

while(!quit) {
  if(counter >= 5) {  //Simple timing ;)
    //Game
    counter = 0;
    draw_sprite(canvas, cursor[pointer], mouse_x, mouse_y);
    draw_sprite(screen, canvas, 0, 0);
    clear_bitmap(canvas);
  }
}

I have a timer callback, before you ask

Why do people insist on using draw_sprite to draw to the screen? I never get that myself.

I read something about making sure you use acquire_screen() and release_screen() functions before and after drawing to the screen?

Well I use it for window programs in Allegro

You don't need these functions, but they can help speed up drawing.

I had a problem like this on a really crappy laptop once. Try it on another computer, I'm quite sure that it will work.

First check if the allegro examples or other allegro programs have the same problem.

BAF, sorry if it offended you
Asam, I'll try that, thanks.
Michael, No. I am coding away and keep testing it, then one time I test it and it never works for the rest of the day. It happens on all of them. Although, they are all the same, I don't have access to any other Windows computers since my Dad installed Debian.
Richard, I will.

EDIT:
On a related note, if acquire_bitmap() and release_bitmap() speed up drawing, shouldn't blit() and draw_sprite() call them automatically?

They do. acquire/release are almost never needed, even to speed things up.

So what's the point in me calling them?

When you draw to the same bitmap multiple times in a row.

Oh. OK.

Is canvas a memory bitmap, made with create_bitmap(), or a video bitmap made with create_video_bitmap()?

If the later, then what's happening is canvas and screen are ending up using the SAME memory! Thus when you clear canvas, you clear the screen, and the pause between due to your timing routine is making the screen show up clear. Simply use create_bitmap() on your canvas object instead of create_video_bitmap().

And if you only ever make one draw to the screen, there's no point calling the acquire and release commands because Allegro will do it for you. You only need to call them if you plan to do multiple video-bitmap operations in one go.

--- Kris Asick (Gemini)
--- http://www.pixelships.com

Just a normal memory bitmap, I've never really got the hang of video bitmaps

Waitaminute...

You say it only updates the picture when you move the window. Does that mean the previous frame is still shown when you stop moving the window?

--- Kris Asick (Gemini)
--- http://www.pixelships.com

Yeah. I guess I should have been more specific.

Three more questions to narrow this issue down:

• Between window moves, does the game actually update and simply not draw to the screen, or does the game pause until the next time you move the window?

  
  

• If you click and hold down the mouse button to move the window, then move the window, then stop moving the window without releasing the mouse button, does the game keep updating properly or not?

  
  

• Does the game run fine full-screen?

I recommend you try running some other Allegro-driven games from the depot to see if the problem is limited to your own code or not. If other Allegro games are causing problems, it's likely nothing to do with your code and everything to do with your system configuration. (IE: Outdated drivers, background applications sucking resources dry, etc.)

--- Kris Asick (Gemini)
--- http://www.pixelships.com

1.) It updates but doesn't draw
2.) I don't remember, I'll find out tomorrow
3.) No, I have a thing that checks whether full screen is available. It uses full screen if it is and windowed if it isn't. It never runs full screen and it sometimes has the window problem. For some reason, after I've had the window problem once it doesn't work on that computer for the rest of the day (I say day because I don't know if it's while I'm logged on, before it is rebooted, or anything else)

I'll try some other allegro stuff. I can't do anything about drivers though, they're schools computers.

If it's not running full-screen when you're telling it to then you're probably requesting a video mode that isn't standard, either because of a bad resolution or a colour depth the video card can't handle. Good resolutions that work on just about any computer are 320x200, 640x480 and 800x600. 8-bit colour depth will work on anything, 16 and 32 bit will work on most things, but not really old systems, and 15 and 24 bit are fairly uncommon and sporadically work on some systems and not on others.

Start with trying to use a more normal resolution and see if that helps run full-screen. If you are... well...

Depending on the school, especially if we're talking pre-college level, the computers there could be EXTREMELY outdated and would not make a good development or testing platform. You really ought to find a more personal locale to do your programming, either at home, a friend's house, somewhere where the computer can be kept up to date.

--- Kris Asick (Gemini)
--- http://www.pixelships.com

640x480x24. The 24 might be the problem. I'll change it to 32 and see what happens. It is pre-college but the computers are fairly new (they upgrade about once every two to three years), but I'll see how it runs on friends computers.

Add checks to try 24 bit if 32 bit fails (and to use 15 bit if 16 bit fails).

OK. I'll do that now.

I had this exact problem with some college computers. It was interesting trying to play the game, whilst keeping one hand on the mouse moving the window around. The program worked fine on everything else but those computers. They updated the drivers and everythig worked fine after that.

I've had the same problem with Windows. Never thought to move the window around, though.

Onewing, That's probably my problem then. I'll ask Michael to update the video drivers - Michael is the 'IT Technician'. He spends his time playing Roller Coaster Tycoon and writing the website for his fair (a merry-go-round) http://www.mikeyjsfunfair.co.uk

EDIT:
CGames, I only did by accident