Re: DirectX Blues; 3D Engine

["Neil" <dreaded.neil@phreaker.net>]

> When your app is deactivated you may lose the memory allocated for your
> directx program. Therefore if your program detects a WM_ACTIVATE, you
> should call functions which restore your draw surfaces and sound
> buffers, and reloads the data you want into those surfaces and buffers.

Okay, I see that. Instead of checking for an error with the memory and
fixing it like I've been doing, I'll check WM_ACTIVATE to fix it when I
know the error is coming. I read something about making sure not to use
your surfaces while they're not visible (i.e. when your app is minimized).
Is this a problem, or can I just go on merrily writing to a surface that
isn't on-screen (I haven't encountered any problems yet with this code, but
my last game did have some which may have been realted to this)? Even if
not, I'd still like to know when my program is not active so I can pause
it. Is there a WM_DEACTIVATE message that will tell me this?

> I think all of this will be solved by including the DDSFLIP_WAIT flag in
> your call to IDirectDrawSurface::Flip, and DDBLT_WAIT in your call to
> IDirectDrawSurface7::Blt.

There lies my problem: I am doing this, and it still doesn't work. The odd
thing is that I made a simple game with the same process before, and [I
think] it worked. Now it doesn't. I was hoping that there was an obvious
solution that I was missing, but apparently I've got some debugging to do.

> However, the DDBLT_WAIT flag can be rather
> inefficient... I believe there is a better alternative given somewhere
> in the DirectX.chm help file in the sdk. IDirectDrawSurface7::Flip by
> default waits for the vertical retrace. It will only flip other than
> during a vertical retrace if you specify DDFLIP_NOVSYNC.

That doesn't bother me (The inefficiency, that is) because I'm not using
blitting at all, but rather drawing pixels directly to memory. I'm glad I
don't have to worry about sync. myself. I assume that the program continues
running while the flip function is waiting to be in sync (hence the need
for DDFLIP_WAIT?).

I may have mentioned this before, but I'm exploring different 3D engine
algorythms. I've figured that if you calculate the normals for the axes
from the point of view (which I use for correct relative camera movement
anyway) then you can skip all of the
matrix-and-different-spaces-and-trig-functions stuff and project a point at
absolute{x y z} to pixel{x, y} like this:
shifted = absolute - pov.position;
relative.x = shifted * pov.xAxisNormal;
relative.y = shifted * pov.yAxisNormal;
relative.z = shifted * pov.zAxisNormal;
pixel.x = relative.x / relative.z * ProjectionDistance + HalfScreenSize.x;
pixel.y = relative.y / relative.z * ProjectionDistance + HalfScreenSize.y;
. . . where - and * have been programmed as vector subtraction and dot
product operations, respectively, and pov.position is the point of piew.
relative could be thought of as being in camera space. I don't know if this
has been done before (I hope not . . . I like coming up with new ideas, but
I suspect that it probably has; either that or it doesn't work). I like it
because x, y, and z are calculated independently so it's easy to, say,
calculate z first and skip the rest if it's not between the near and far
clipping distances (Which is nice for a simple engine). Does this appear to
be an elegant solution, or is it just stupid? Can anyone tell if it will
even work? Any comments? :]

Now to conjure up some more crazy ideas for drawing polygons . . . And some
of mine have indeed been quite crazy. 8-)

-- Neil Edelman
-- ICQ UIN: 705130
-- email: mailto:dreaded.neil@phreaker.net?subject=sig
-- home: http://members.xoom.com/dreadedneil
-- moop: http://moop.bizland.com
-- "My air-to-air missile overrides your air traffic control clearance"
=================================================================
The GameProgrammer.Com mailing list is for the open discussion
of any topic related to the art, science, and business of
programming games. This list is especially tolerant of beginners.
We were all beginners once

To SUBSCRIBE or UNSUBSCRIBE please visit:
http://gameprogrammer.com/mailinglist.html