🔒 Locked

Advice for 2D in DX9 on low end systems?

Started by Avalon Apr 13, 2005 at 12:57 AM 4 replies 1.2k views

Original Post

Apr 13, 2005 at 12:57 AM

I'm currently trying to redo a simple diablo clone I lost a year ago and am having considerably more trouble this time around with my 'new' PC. I unfortunately have several questions to which I can't seem to find the answers. First of all, my system specs: P4 2.4Ghz 640MB RAM *8MB RAGE XL integrated graphics* I want my game to run around ~20 FPS on my dev system in release/retail mode which I don't think is too much to ask, but currently I'm getting around 1FPS with no game logic, little input, no sound nor music. According to DX, my HAL only supports software vertex processing which obviously slows things down. Any general advice on making my game run better on low end systems would be appreciated. Anyway, here are my questions: 1. In both HAL and REF modes I get a "D3D9 Helper: Error: Default value for D3DSAMP_DMAPOFFSET[0] is incorrect. Expected 0x100, Returned 0x0" message for all 16 elements of this array after the call to CreateDevice. Why am I getting this error? It doesn't stop my app from running, but does it cause other problems? 2. In HAL (SVP) mode, when I turn on all the DX error checking (including break on memory leaks and D3D errors), the program breaks with output: "Direct3D9: (ERROR) :Error during initialization of texture. CreateTexture failed." and "Windows has triggered a breakpoint in dx9_d3dxsprite.exe This may be due to a corruption of the heap, and indicates a bug in dx9_d3dxsprite.exe." The error returned is D3DERR_OUTOFVIDEOMEMORY which is obvious, but the texture is only 3MB (no mipchain). Using REF (SVP) yields neither of these. Is there likely something I can fix, should I use REF, should I reduce my texture size? 3. With that last choice in mind, I converted some of my bitmaps from 24 bits to 16 bits (using a program called Aha, because I couldn't find a way to do it in MSPaint or Photoshop(!) and the handy converter included with the SDK not only deleted some pixel data off the left edge, but the resulting image wouldn't preview in XP (it does open in Paint etc.)). However, even though every program (including XP) loads the bitmap Aha converted, CreateTexture says it's an unsupported format when I try to load it. Any suggestions? None of my textures use over 20k colors so 16bit is more than enough to keep quality close to the 24 bit version. Thanks in advance; this has been baffling me for a while now.

V-man

Apr 13, 2005 at 1:23 AM

1. I get those too. Ignore them.

2. D3D9 minimum requirements are too high I guess. Or you are loading too many textures. I don't know.

3. Try the DXTex tool and the dds format.

superpig

Apr 13, 2005 at 2:52 AM

The REF device isn't a viable solution if you ever intend to release your game to anyone who doesn't have the DXSDK installed, and it's very slow, so we'd better fix the problems you're seeing with the HAL device.

As V-man says, you ought to try using DXTEX to convert your textures into DDS format; you can ensure that they're 16 bits there, as well as turning on DXT compression to make them smaller.

A 3MB texture may not seem like much, but your card is only 8MB; that's almost half the available video memory. Which pool are you trying to create it in?

MasterWorks

Apr 13, 2005 at 3:54 AM

Also, the fact that your textures don't "use over 20k colors" isn't relevent, because your 16-bit image isn't palettized; you don't get to choose a set of 65k colors and then use them. 24->16 bit introduces banding because you're losing several bits of precision per color channel. (Of course, your images may look fine if they don't have smooth gradients, etc.)

superpig

Apr 14, 2005 at 3:06 AM

Quote:
Original post by Anonymous Poster
Quote:
Original post by superpig
A 3MB texture may not seem like much, but your card is only 8MB; that's almost half the available video memory. Which pool are you trying to create it in?
Yes, I agree that it's a lot for what I have, I just don't understand why it runs out of video memory. Here's how I want to spend my 8MB:
Fullscreen @1024x768x16 Windowed@1024x768x24
1.5MB for the display 2.25MB
1.5MB for the back buffer 2.25MB
2MB for my tileset 2MB
2.5MB for sprite animations(regularly exchanged) 1.25MB

Unfortunately, neither work this way. Windowed only works when my display settings are set to 32 bit (CreateDevice fails, saying that R8G8B8 returned by GetAdapterDisplayMode( D3DADAPTER_DEFAULT, &d3ddm ) isn't a valid format for the backbuffer (!) (but X8R8G8B8 works fine). I can't even load a 1MB texture in windowed.

Be aware that you don't get exclusive use of video card resources, even in fullscreen mode. Windows has certain things knocking about that you can't get rid of. Your fullscreen mode only leaves half a meg for those resources... it might not be enough. Plus, you may have more than just textures: vertex buffers, for example. I'm not sure how much you actually have to work with; you could probably find out through a little experimentation (progressively creating larger textures until it fails, sorta thing).

Quote:

Here are my results for maximum texture usage in fullscreen:

2MB tileset+12*28k textures=2.3MB
516KB tileset*3+16*28k textures=1.95MB

assuming the 96x96x24 textures are rounded to 128x128x24 (nearest power of 2):

2MB+12*50k=2.6MB
516KB*3+16*50k=2.3MB

So where is my 2.4MB+ going?

Are those sizes based on image width*height*bpp, or on filesize? Texture resources are usually compressed, if you're not doing anything special with them (like writing to them); IIRC the .dds format has that compression applied, so you can get a feel for how much it helps you.

Quote:
And why doesn't D3DPOOL_DEFAULT spill into my system ram if the VRAM is full?

To quote from the DXSDK docs: "Resources are placed in the memory pool most appropriate for the set of usages requested for the given resource. This is usually video memory, including both local video memory and accelerated graphics port (AGP) memory. The D3DPOOL_DEFAULT pool is separate from D3DPOOL_MANAGED and D3DPOOL_SYTEMMEM, and it specifies that the resource is placed in the preferred memory for device access." The device usually can't access system memory.

You're probably better off putting your tileset in the MANAGED pool. This will cause Direct3D to keep one copy in system memory, and when you need to use it, will shunt it across to video memory. If you create your sprite animations in the MANAGED pool as well, Direct3D will handle swapping them in and out alongside the tileset to fit in memory (assuming that you're not trying to render both sprites and tiles in the same render calls). Sure, you're going to be using the tileset most of the time so it'd be nice if it stayed in memory - and on hardware with more than 8mb of memory it probably will do - but as it stands you're going to have to do some swapping. It's probably best to get it working first and see what the performance hit is like later - there are some things you can do to help, like splitting the tileset up into smaller chunks so that only parts of it need to be paged in and out of video memory.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.