Hi all, I realise this topic has come up numerous times before (I''ve searched..) but nothing quite fits my problem. At the moment, I''m listening out for a WM_ACTIATE msg in my callback procedure, and setting a boolean variable to indicate whether my app has focus or not. Then, I have a main() loop which I call if, and only if, my variable indicates we''re currently active. Ok... my problem is that this only works 1 in 10 times, if that. I''m guessing my problem is that my app is losing focus whilst within main() thus crashing out before realising it''s not active (when it gets to its callback func). Basically what I need is an elegant solution to fix this... asuming my guess is right. I''ve narrowed my flipping() function to be the one that crashes ddraw fully, with all prior blitting/locking functions simply returning DDERR_SURFACELOST. I tried calling my own RestoreAllSurfaces() function before calling flip() so I could see if we had focus (ie. checks if focus is lost, then checks to see if it can restore... if it can''t we must of lost focus). This works 9/10 times, but occasionly still hangs my system. Again, I''m guessing we lose focus inbetween this check, and the actual flip() call. Anyway, I''ve rambled enough and its probably all crap so I''ll stop Any general pointers etc. greatly appreciated, Thanks, -- Rah

For full screen projects, I do something very similar to what you describe, however, I check WM_ACTIVATEAPP. I set the flag when I receive this message, and then I check the flag in two places... My message loop (prior to doing the next game update) and before I do any actual updating of the screen (before I try to flip) or attempt to create surfaces in vram.




Mark Fassett
Laughing Dragon Entertainment
http:\\www.laughing-dragon.com

as i understand from what you are telling, you imply that you would receive a message while inside your main loop.
i don''t think that is possible because you have to call getmessage() to actually receive the message first...
so i think your problem lays in some other part of your app...
btw i am using the same technique and it works fine for me...
what parameter of the WM_ACTIVE message do you use for your active check? there are two and one wouldn''t do for my check

Hi,

Basically what I thought was happening was that my app was losing focus, before I recieved the message (whilst in the main() loop) but I realise this was wrong now...

I fixed it by using WM_ACTIVEAPP as Mark suggested. This seems to work fine now (which is good )

Thanks for your input all,

--
Rah

Hi again

Following on from before, I now have a working routine.
One thing though... On my p200mmx, 4mb matrox mystique, I just can't get the damn thing to lose its surface data (the surfaces become 'lost' when alt-tabbing, but don't seem to lose their data). I've tried loading other games whilst my app is out of focus etc. to try and lose the images, but it just won't let em' go

Is this normal...? On trying on my other machine, p400, 8mb ati, it loses its data ok.

I'm creating two 800x600 surfaces (primary, backbuffer) in video ram, and also an 800x600 offscreen surface (also in vid ram), all in 16bit.

Could it be that DX is placing my offscreen surface into sysram without telling me? All load functions return no errors to suggest this however.

Any ideas?

--
Rah

Edited by - Rah on 2/21/00 6:41:20 PM

If you really want to know where the surfaces are, you can check the surface description (it''s in the DDSCAPS or DDSCAPS2 structure (depending on which DX version you''re using) to figure it out.

You may want to check and see if your offscreen surface is in system ram (I''m assuming this is the one where the data still is). If it is getting put there, it means you didn''t lose that surface (you can''t lose system ram surfaces), you lost one of your other surfaces.

I''m interested in knowing how you''re finding out that the data is still valid? Is it causing a problem?

Mark Fassett
Laughing Dragon Entertainment
http:\\www.laughing-dragon.com

Hi Mark,

The reason I know the data I loaded onto the surface is still valid (after a RestoreAllSurfaces()) is basically because I can see it... ie. I blit it. On my other computer this just appears as a black square (data has been lost).

It's not causing a problem as such, I'm just interested in knowing why and making sure my routines work correctly.

Thanks for the tip with DDSCAPS, I'll have a play around with that in a sec. However, I'm pretty sure it (my offscreen surface) is being created in video ram as I get around 85fps (on p200, 4mb old gfx card). I could surely not achieve blitting an 800x600x16 surface from system->vid ram at this speed. When explicitly setting my program to create the offscreen surface in system ram, I get around 24fps... a more realistic figure.

Anyway, I'll see what I can figure out. Like I said, it's not a problem, I'm just interested to know why this is happening.

Thanks

--
Rah

Edited by - Rah on 2/22/00 9:08:55 AM

Hi,

As an update, my program is definitely creating my offscreen surface in video ram (check with GetCaps()), yet doesn''t seem to lose its surface contents. Weird.

--
Rah

If no other application needs the video memory that the surface uses you wont loose it.

And I wouldn''t rely on it being there either... The ATI driver might be cleaning it up... the Matrox driver might not. In any case, if you''ve been told it''s been lost, you should restore it anyway, regardless of whether the data is still there. Using data you no longer own is a good way to get yourself in trouble (although I''m sure you know that

Mark Fassett
Laughing Dragon Entertainment
http:\\www.laughing-dragon.com