#### Archived

This topic is now archived and is closed to further replies.

# Andre La Mothe TOTWGPG Cource Code Problem

This topic is 6098 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Sorry to be another person with a problem on this subject, but I have a few problems with the source code. Firstly, the examples on loading a bitmap file and copying it to the primary surface. It load up in Game_Init() and works fine.. if I use the Sleep function in Game_Main(). Otherwise I see nothing.. so something is causing the primary surface information to change immediately after the bitmap is drawn. This happens for the 8 bit, 16 bit and 24 bit examples. Any clues on how I can make the bitmap stay on the screen, other than redrawing it every frame? That seems kind of redundant to me, and I suspect this is why LaMothe loaded the bitmap in Game_Init() rather than Game_Main(). Also, the demo using source keying that loads 3 aliens onto a background and moves/animates them across the screen.. well the background is fine, and the aliens move, but the pictures of them are corrupted. I just get lines moving across the screen. Any ideas on this one too? Sorry to bother you all, but I''m just a beginner who''s a little stumped.

##### Share on other sites
Hi. I asked this question on Usenet recently and a GameDev.net regular answered it (it was Zipless). I used their suggestion and it worked. Here is what they said:

quote:

"the black screen is cause cos windows generates a WM_PAINT message after
init and wipes the screen clean. copy the bitmap disply code into the main
function.

The garbled bitmaps are indeed cause by the lPitch. Inside the bitmap
loader LaMothe (or an editor) has decided to use dwWidth, just replace it
with the appropriate lPitch inside the for loop.

If you want a longer explanation check the GameDev.net forums, title is
something like "Tricks of the windows programming..."

Hope this helps.

##### Share on other sites
Thanks a heap. The second bit about lpitch worked, and now the monsters are there and animating, but the first bit.. well the pictures flicker, even if I try doing it by copying the picture to a back buffer and then flipping to a front buffer.

I even try just using a flag to draw one frame of the picture, and not touch the display, but it ends up working randomly.. ie I run it once, it works, i run it again *blank screen*. I'm not extremely savvy with windows program, but it'd be handy if someone could tell me how that works. The flag is just a global int.

Edited by - Darkm00n on February 4, 2002 4:18:06 AM

##### Share on other sites
Basically the code is fine, because your drawing to the primary buffer (to which you have exclusive access to (sorta)) whatever you put there should stay put. The only problem is that windows likes to help out when you least expect it and does nice things like posting WM_PAINT messages.

What we really want to do (maybe) is use this to our advantage and place a call to our display functions inside the WM_PAINT handler but you can worry about that later.

You should really be asking why the hell the WM_PAINT message is posted in the first place, to tell the truth i'm not too sure *where* it comes from but i know why. The simple way to solve it is to change the window class properties and change this line in WinMain

  winclass.hbrBackground = (HBRUSH)GetStockObject(BLACK_BRUSH);

to this
  winclass.hbrBackground = NULL;

When you draw onto the primary surface your drawing over the window's background colour and a WM_PAINT is thrown up, so if you remove the colour windows stops worrying about it.

SpaceRook: Hey cool, i'm a recognised regular :-)

zipless

Edited by - zipless on February 4, 2002 10:03:11 AM

##### Share on other sites
Thanks a lot, Zipless : ) The code worked and now all of La Mothe''s examples work too.

I''m curious, though, as to how I would use MW_PAINT to call the display functions and why?

Cheers, and thanks for all the help Zipless and Spacerook.

##### Share on other sites
Windows is rather handy when your working with (shock!) windowed apps. It sends us a WM_PAINT message whenever the window is being shown after being totally or partially hidden behind another window, basically when we need to redraw it.

Like you said earlier, constantly redrawing something isn''t always a good idea and thought it''s fine for games because you''ve got fast access to fast hardware it''s not always OK for windowed apps, especially if your using the windows GDI functions.

GDI can be dreadfully slow so it doesn''t make sense to redraw the whole screen all the time. Instead you can update only the bits that have changed knowing that the rest of your display is still visible. Whenever you process the WM_PAINT message you know that some part of the display needs redrawn so you can call a function to fully redraws the screen, like loading the bitmap to the primary surface.

It''s usually not a problem for games because you''ll be drawing to a back buffer and drawing that to the window every turn anyway but if your going to make any windows apps it''s a good idea to use WM_PAINT.

Bit of a long explanation but hopefully you get the idea,
zipless

##### Share on other sites
Thanks again Zip.

I kind of knew that already with pure windows, just wondering how/why to do it in directx. So thanks : )

1. 1
2. 2
3. 3
Rutin
22
4. 4
5. 5

• 11
• 18
• 14
• 9
• 9
• ### Forum Statistics

• Total Topics
632929
• Total Posts
3009281
• ### Who's Online (See full list)

There are no registered users currently online

×

## Important Information

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!