Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Problem with CreateOffscreenPlainSurface

664 views
Skip to first unread message

Joris Slob

unread,
May 16, 2004, 6:02:48 PM5/16/04
to
My CreateOffscreenPlainSurface call doesn't seem to be working, but I
have no idea what is wrong with it.

/////

D3DXIMAGE_INFO Info;
D3DXGetImageInfoFromFile(SPRITE_FILE, &Info);

HRESULT result = g_pd3dDevice->CreateOffscreenPlainSurface(Info.Width,
Info.Height, Info.Format, D3DPOOL_DEFAULT, &g_Surface, NULL);

if(result == D3DERR_INVALIDCALL) {
MessageBox(hWnd,"Invalid Call","",MB_OK);
}

/////

g_Surface never gets a pointer to a new Surface. Something has to be
wrong with my arguments to the CreateOffscreenPlainSurface function,
because I get the Invalid Call message.

I checked the Info structure and it contained all the information it
should. I tried using different files as input (jpg en bmp). I tried
changing the D3DPOOL setting, nothing helped.

Does anyone have any clues what might be the problem?

Rich [Microsoft Direct3D MVP]

unread,
May 16, 2004, 6:35:09 PM5/16/04
to
[Please do not mail me a copy of your followup]

jori...@hotmail.com (Joris Slob) spake the secret code
<166e0f7a.0405...@posting.google.com> thusly:

>Does anyone have any clues what might be the problem?

Standard questions apply:
- debug runtime installed?
- debug runtime selected?
- debug level turned up?
- no relevant messages in the debug output stream?
--
"The Direct3D Graphics Pipeline"-- code samples, sample chapter, FAQ:
<http://www.xmission.com/~legalize/book/>
Pilgrimage: Utah's annual demoparty
<http://pilgrimage.scene.org>

Joris Slob

unread,
May 17, 2004, 3:59:42 AM5/17/04
to
Eyal Teler <e...@nospam-et3d.com> wrote in message news:<#V5m6J5O...@TK2MSFTNGP09.phx.gbl>...

> Try running with the debug runtime and see if it prints anything.

I found the error. It is as follows:

Direct3D9: (ERROR) :This format is not supported for offscreen plain
surfaces. CreateOffscreenPlainSurface fails.

I tried making different files with different extensions and different
color depths, but I can't seem to make it work. Is there some
fail-safe (fool proof) methode to make a file which should work no
matter what?

Rich [Microsoft Direct3D MVP]

unread,
May 17, 2004, 9:06:45 AM5/17/04
to
[Please do not mail me a copy of your followup]

jori...@hotmail.com (Joris Slob) spake the secret code

<166e0f7a.04051...@posting.google.com> thusly:

>Direct3D9: (ERROR) :This format is not supported for offscreen plain
>surfaces. CreateOffscreenPlainSurface fails.

You need to call IDirect3D9::CheckDeviceFormat to enquire about
surface format support.

Eyal Teler

unread,
May 19, 2004, 1:08:08 PM5/19/04
to
> I found the error. It is as follows:
>
> Direct3D9: (ERROR) :This format is not supported for offscreen plain
> surfaces. CreateOffscreenPlainSurface fails.
>
> I tried making different files with different extensions and different
> color depths, but I can't seem to make it work. Is there some
> fail-safe (fool proof) methode to make a file which should work no
> matter what?

What are you using the off screen surface for? You'll have more
flexibility if you use it in the scratch pool, and if you want a
surface in device memory, you might could create it in another way.

Eyal

Rich [Microsoft Direct3D MVP]

unread,
May 19, 2004, 12:36:15 PM5/19/04
to
[Please do not mail me a copy of your followup]

Eyal Teler <e...@nospam-et3d.com> spake the secret code
<e4Gp4tb...@tk2msftngp13.phx.gbl> thusly:

>What are you using the off screen surface for? You'll have more

>flexibility if you use it in the scratch pool, [...]

I think you mean system memory pool? There really is not much you can
do with a surface in the scratch pool because its potentially
imcompatible with the device, so the runtime doesn't let you
StretchRect from it to a device surface. You could use
D3DXLoadSurfaceFromSurface with the source surface in the scratch
pool, but that's all CPU-side surface format conversion, which can be
slow.

Joris Slob

unread,
May 20, 2004, 7:24:19 AM5/20/04
to
Eyal Teler <e...@nospam-et3d.com> wrote in message news:<e4Gp4tb...@tk2msftngp13.phx.gbl>...

> What are you using the off screen surface for? You'll have more
> flexibility if you use it in the scratch pool, and if you want a
> surface in device memory, you might could create it in another way.

I am trying to make this surface to hold images so I can copy them to
the backbuffer.

It must be fairly obvious that I am just starting out with DirectX. I
am using "DirectX9, User Interfaces, Design and Implementation" by
Alan Thorn as a guide to begin using it. I cannot recommend it though,
because there seem to be quite a number of errors in the book, and I
keep running into problems and snags like this. Most of them I can
solve by reading the DirectX documentation, but this one had me
puzzled.

I plan to use DirectX to program a game with some of my friends. I
like programming as a hobby and try to understand more about windows
programming.

Joris Slob

unread,
May 20, 2004, 7:43:05 AM5/20/04
to
legaliz...@mail.xmission.com (Rich [Microsoft Direct3D MVP]) wrote in message news:<#vico9bP...@tk2msftngp13.phx.gbl>...

> I think you mean system memory pool? There really is not much you can
> do with a surface in the scratch pool because its potentially
> imcompatible with the device, so the runtime doesn't let you
> StretchRect from it to a device surface. You could use
> D3DXLoadSurfaceFromSurface with the source surface in the scratch
> pool, but that's all CPU-side surface format conversion, which can be
> slow.

After some more testing, I finally got it to work. It only seems to
work when I use D3DPOOL_SYSTEMMEM. I don't actually understand why the
default wouldn't work. The book "DirectX9, User Interfaces, Design and
Implementation" by Alan Thorn said 'Often you will want this argument
[the pool] automatically selected, in which case you should pass
D3DPOOL_DEFAULT'. All the examples in the book use the D3DPOOL_DEFAULT
pool too. Might it be graphics-card dependable if D3DPOOL_DEFAULT
actually works for your computer?

No matter what, it seems to be working fine with the D3DPOOL_SYSTEMMEM
setting. Thanks for all the suggestions and help!

Rich [Microsoft Direct3D MVP]

unread,
May 20, 2004, 9:14:28 AM5/20/04
to
[Please do not mail me a copy of your followup]

jori...@hotmail.com (Joris Slob) spake the secret code
<166e0f7a.04052...@posting.google.com> thusly:

>I am trying to make this surface to hold images so I can copy them to
>the backbuffer.

There are two methods for copying from one surface to another:
UpdateSurface and StretchRect. UpdateSurface copies surface data from
system memory to device memory. StretchRect copies surface data from
device memory to device memory. (For transport from device memory to
system memory you can use GetRenderTargetData, but you only need that
to read back rendered data, since any other data would have been
transported to device memory from system memory and you can always
lock and read system memory surfaces.)

If you need to reepatedly copy the same image to the back buffer, then
on initialization use UpdateSurface to get the image into a device
memory surface and then use StretchRect to repeatedly copy it onto the
back buffer. You can use D3DXLoadSurfaceFromFile to get file data
into a device memory surface during initialization. It will do the
UpdateSurface for you, if necessary.

0 new messages