Hey isn''t it just as bad to save all your surfaces to sysram? Cause if they''ve minimsed your app to do something else.. that something else may need the ram? You should theoretically free up the resources then take them again when you maximize, yes?

I''m building an Isometric RTS and it will load about 32 mb of graphics into sysram and use a syram back-buffer aproach (If you don''t know what this is search the board a bit) now my target system requirements are 64mb of ram but I''ll also have sound and map and unit data... so I won''t be leaving much room for other apps... it should free everything up and then load up again right?

Just my thoughts, haven''t actually implemented this yet...
- Ben

I have to say thanks guys for the excellent help on this.

Possibility

Here''s a method I use which is configurable base on hardware available.

Tile/Object Surface caching:

Sometimes you have lots of vram at your disposal, othertimes you don''t. My idea is to take your most used graphics and place them in vram. All other less frequently used graphics go in system ram.

The basic idea is to improve performance by keeping surfaces that are more active in vram.

I''ve created a class that takes these surfaces and loads them into the appropriate ram type. You can play with cache sizes, locations etc. to tweak your performance.

The great thing is that as your walking through your map, regions of your map typically have graphics that are common, and as you leave those area''s the caching systems dynamically adapts to these changes.

You can take a look at my demo which implements these ideas.

http://www.geocities.com/SiliconValley/Modem/2514/index.html

Darrell

Hmmm, i am getting stumped here, when I call

        //-------- windows message handler --------------//LRESULT CALLBACKWindowProc (HWND hWnd, unsigned uMsg, WPARAM wParam, LPARAM lParam){	switch (uMsg)	{	case WM_ACTIVATEAPP:		// recover any lost surfaces		if (lpDDSPrimary->IsLost()==DDERR_SURFACELOST)			lpDDSPrimary->Restore();		break;[/source]it crashes!But in my 3D program I can call the [source]if (lpDDSPrimary->IsLost()==DDERR_SURFACELOST)    lpDDSPrimary->Restore();        

and it works just fine,
so why does it not like the IsLost() function in my 2D program?

also, it seems that the WM_ACTIVATEAPP is given All the time, not just when the program is made active again, is there a 1 time call thing when the program is made active again, and not a constant one for the when the program is currently active, if you know what I mean.

Possibility





Edited by - Possibility on July 21, 2000 7:42:04 PM

I have never had a case where only a stray surface was lost, and I really don''t
know how such a case could happen when your program has exclusive full-screen
control. However, this could be different for windowed-mode. But, in my
experience, all the surfaces which are being used become lost when your DX app
loses focus. So, it seems logical to restore them all in one place at the
same time.

I also think you would have better control over re-creating surfaces that
dynamically change throughout the course of the game. Although, I think it
would be nearly impossible to re-create surfaces that are based on random number
generators. That''s if you don''t save -everything-.


Wayfarer

I know that wayfarer, I just put up the IsLost and Restore for a single surface because I didnt think anyone wanted to read my entire list of 300 surfaces, and I also tried the RestoreAllSurfaces and that just crashes aswell, I cant figure out why.

Possibility

Sorry Possibility, I was responding to someone else''s post, not the one
above.

WM_ACTIVATEAPP is called whenever your app gets focus, which means it probably
gets called when your app starts up. Most likely before you even have DX
created. So, you have to make sure your app is initialized first before trying
to restore anything. You can use a BOOL flag for checking for this like TAN did.
To be absolutely safe, destroy and release everything, including your primary
and back buffers. This is what the SDK docs do.

For the other posts:
I can think of some good cases where saving the entire screen surface
(for full-screen apps) to your hard disk might prove useful. For example,
when the player pauses the game or pops up an in-game option menu. If the
game action is frozen and stil visible in the background, you could save
the entire screen surface. Since the screen has an image on it that is
obviously something you can''t simply load from your bitmap resources, you
would probably just get a black screen if you didn''t save it.


Wayfarer

poss..

as wayfarer pointed out, WM_ACTIVATEAPP is called whenever an application gets the focus. when you create a window, a number of messages are immediately sent to the message handler, including WM_CREATE, WM_ACTIVATEAPP, WM_PAINT, and a few others.

in most program''s i''ve written using DirectX, i create my window before i do my directx initialization, so, when you''re code hits this code:

case WM_ACTIVATEAPP:
{
if(lpdds->IsLost()==DDERR_SURFACELOST)...
}

lpdds is going to be NULL, and so, the call will be invalid, since no valid IDirectDrawSurface7 object exists at memory location zero.

two ways you can counter this problem.

one: you can call all of your directx initialization in response to the WM_CREATE message. WM_CREATE is called before WM_ACTIVATEAPP is.

two: you can check to see if directx has been initialized before trying to restore your surfaces. in the case of directdraw, you should just be able to check that your IDirectDraw7 pointer is non-null.

Now that I think about it, it might be better to simply allocate some
temporary system memory instead of saving a surface image to disk. This
way you wouldn''t have to bother with stray files from possible program
crashes.


Wayfarer

possibility:
why don''t you just use a boolean like I suggested? :-)
this way you would only use the message handler to alter the state of the bool.. which should be accessible at any time during execution.. then check your DX return codes.. if the code is DDERR_SURFACELOST restore.. and remember only to execute your gameloop when the "Activate"-bool is true :-)