I am new to directdraw. I wrote a simple test program.. my goal is to
get the pointer to my video card's primary surface so I can modify the
surface directly and see my changes immediately on the screen. I did the
following steps
1) Create DDraw Object and set display mode and coorperative level with
arguments NULL and DDSCL_NORMAL.
2) Create a primary surface and lock it.
3) Modify some contents pointed to by ddsd.lpSurface, and I see the result
straight away. Bingo!
Based on this test, I have two questions.
1) ddsd.lpSurface ALWAYS points to address 0xb50000 everytime I run this
test program. Why is that? Is the mapping of this particular address to VRAM
the default address for primary surface?
2) Since primary surface should be always there (bcos I can see my desktop),
what's the effect of calling lpdd->CreateSurface(&ddsd, &lpddsprimary,
NULL);?
thanks!
=?Utf-8?B?ZnVuZ2k4MjEw?= <fung...@discussions.microsoft.com> spake the secret code
<0218626A-BE9C-4021...@microsoft.com> thusly:
> I am new to directdraw. [...]
DirectDraw is deprecated. You should be using Direct3D. Why are you
starting with DirectDraw? It hasn't been updated in about 10 years and
its the slow path on modern video cards.
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://www.xmission.com/~legalize/book/download/index.html>
Legalize Adulthood! <http://blogs.xmission.com/legalize/>
Since you have suggested Direct3D, that means it supports 2D programming, am
I correct?
I am doing my implementation on windows mobile 6.1 (CE 5). I don't know
whether Direct3D needs to be implementing in the display driver layer or not,
but since I know DDraw HAL is already implemented in our display driver, I'm
going to use it for the time being.
ps. Do you know the answer to the two questions I previously asked?
thanks!
No. That's just the first available virtual address in your process after
your program loads. Your program loads at 0x400000, and your program must
be using 0x750000 bytes of memory, probably including the initial stack.
The display driver has to map the frame buffer into your process every time
it runs. The address is strictly local to your process.
>2) Since primary surface should be always there (bcos I can see my desktop),
>what's the effect of calling lpdd->CreateSurface(&ddsd, &lpddsprimary,
>NULL);?
Well, the frame buffer memory is always there. What you are doing is
registering your interest in it, and getting a data structure back.
It's called CreateSurface because the same API is used to connect to any
kind of surface -- primary, overlay, or offscreen.
--
Tim Roberts, ti...@probo.com
Providenza & Boekelheide, Inc.
Well, sort of. The things you can do with a DirectDraw overlay can also be
done with a Direct3D texture.
> I am doing my implementation on windows mobile 6.1 (CE 5). I don't know
>whether Direct3D needs to be implementing in the display driver layer or not,
>but since I know DDraw HAL is already implemented in our display driver, I'm
>going to use it for the time being.
That's perfectly fine. Deprecation is just a state of mind. ;)
DirectDraw is well-known, well-documented, and well-understood.
>ps. Do you know the answer to the two questions I previously asked?
Yes. See other post...
=?Utf-8?B?ZnVuZ2k4MjEw?= <fung...@discussions.microsoft.com> spake the secret code
<2B5216B9-CFA9-436A...@microsoft.com> thusly:
>Since you have suggested Direct3D, that means it supports 2D programming, am
>I correct?
Yes, Direct3D supports 2D programming. You can do everything by
diddling pixels directly if you want to, although that will not be
taking the fastest path on modern hardware.
> I am doing my implementation on windows mobile 6.1 (CE 5).
Ah, that's different. I don't know what support Windows Mobile has for
DirectX, but I know it has something. In that environment, DirectDraw
may be the best you have available.