DirectDraw -> Direct3D

You can talk about almost anything that you want to on this board.

Moderator: Moderators

User avatar
rainwarrior
Posts: 7804
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: DirectDraw -> Direct3D

Post by rainwarrior » Wed Dec 12, 2012 12:41 pm

You don't actually have any drawing commands in there, except Clear. You fill in the texture and set it up for rendering but you never apply it with any draw commands. What you need to do is call DrawPrimitive with a full-screen quad of vertices.

For starters, maybe try DrawPrimitiveUP. It's not as efficient (but perfectly fine for drawing a single quad per frame), but avoids a bunch of necessary setup that you have to do for DrawPrimitive (build a vertex buffer, etc.).

WedNESday
Posts: 1236
Joined: Thu Sep 15, 2005 9:23 am
Location: Berlin, Germany
Contact:

Re: DirectDraw -> Direct3D

Post by WedNESday » Thu Dec 13, 2012 2:04 pm

I've managed to find an old DXSDK on the microsoft website that still has the DDraw files in so I'm back to that.

Now that I've locked on offscreen plain surface I want to copy the pixel data straight to the lpSurface pointer after I lock a surface.

Code: Select all

lpDDSBack->Lock(NULL, &ddsd, DDLOCK_WAIT | DDLOCK_SURFACEMEMORYPTR, NULL);
(COLORREF *)Pixel = (COLORREF *)ddsd.lpSurface;

memcpy(&Pixel, &buffer, 1);

lpDDSBack->Unlock(NULL);
...either crashes or does absolutely nothing. Ideas?

User avatar
rainwarrior
Posts: 7804
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: DirectDraw -> Direct3D

Post by rainwarrior » Thu Dec 13, 2012 2:08 pm

I would guess Pixel is NULL or something? Have you verified that the lock was successful?

Also:
http://msdn.microsoft.com/en-us/library/windows/desktop/bb172231%28v=vs.85%29.aspx wrote:Back buffer surfaces, which may be accessed using the IDirect3DDevice9::GetBackBuffer and IDirect3DSwapChain9::GetBackBuffer methods, may be locked only if the swap chain was created with the Flags member of D3DPRESENT_PARAMETERS to include D3DPRESENTFLAG_LOCKABLE_BACKBUFFER.

User avatar
James
Posts: 429
Joined: Sat Jan 22, 2005 8:51 am
Location: Chicago, IL
Contact:

Re: DirectDraw -> Direct3D

Post by James » Thu Dec 13, 2012 2:16 pm

WedNESday wrote:I've managed to find an old DXSDK on the microsoft website that still has the DDraw files in so I'm back to that.
You'll only get nearest neighbor scaling on Vista+ (unsure if this is Nvidia specific, though). This was my motivation for switching from DirectDraw to Direct3D several years ago.
get nemulator
http://nemulator.com

WedNESday
Posts: 1236
Joined: Thu Sep 15, 2005 9:23 am
Location: Berlin, Germany
Contact:

Re: DirectDraw -> Direct3D

Post by WedNESday » Thu Dec 13, 2012 2:28 pm

rainwarrior the lock was succesful as I can use Pixel[10] = ... to plot pixels no problem.

James I've already got a workaround for that. Just write more pixels to the buffer and Flip a larger picture to take into account stretching etc.

User avatar
James
Posts: 429
Joined: Sat Jan 22, 2005 8:51 am
Location: Chicago, IL
Contact:

Re: DirectDraw -> Direct3D

Post by James » Thu Dec 13, 2012 2:38 pm

you probably want

Code: Select all

memcpy(Pixel, &buffer, 1);
instead of

Code: Select all

memcpy(&Pixel, &buffer, 1);
get nemulator
http://nemulator.com

WedNESday
Posts: 1236
Joined: Thu Sep 15, 2005 9:23 am
Location: Berlin, Germany
Contact:

Re: DirectDraw -> Direct3D

Post by WedNESday » Thu Dec 13, 2012 2:41 pm

Work now James, even though I tried just that earlier.

User avatar
koitsu
Posts: 4217
Joined: Sun Sep 19, 2004 9:28 pm
Location: A world gone mad

Re: DirectDraw -> Direct3D

Post by koitsu » Thu Dec 13, 2012 3:53 pm

WedNESday wrote:Work now James, even though I tried just that earlier.
Provide the variable declarations themselves and we can tell you if you should be using & for dereferencing or not (for both Pixel and buffer). Don't forget related lines like how you're allocating memory for these (i.e. malloc, statically on the heap, etc.).

User avatar
thefox
Posts: 3141
Joined: Mon Jan 03, 2005 10:36 am
Location: Tampere, Finland
Contact:

Re: DirectDraw -> Direct3D

Post by thefox » Fri Dec 14, 2012 1:44 am

WedNESday wrote:

Code: Select all

(COLORREF *)Pixel = (COLORREF *)ddsd.lpSurface;
I have to comment on this one. It's a very strange thing to do, to cast an l-value to COLORREF* and then assign to it. It doesn't change the type of Pixel so it's pointless. It's also non-standard.
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi

WedNESday
Posts: 1236
Joined: Thu Sep 15, 2005 9:23 am
Location: Berlin, Germany
Contact:

Re: DirectDraw -> Direct3D

Post by WedNESday » Fri Dec 14, 2012 4:21 am

thefox wrote:
WedNESday wrote:

Code: Select all

(COLORREF *)Pixel = (COLORREF *)ddsd.lpSurface;
I have to comment on this one. It's a very strange thing to do, to cast an l-value to COLORREF* and then assign to it. It doesn't change the type of Pixel so it's pointless. It's also non-standard.
Had to do that in order for it to compile.

User avatar
thefox
Posts: 3141
Joined: Mon Jan 03, 2005 10:36 am
Location: Tampere, Finland
Contact:

Re: DirectDraw -> Direct3D

Post by thefox » Fri Dec 14, 2012 5:52 am

WedNESday wrote:
thefox wrote:
WedNESday wrote:

Code: Select all

(COLORREF *)Pixel = (COLORREF *)ddsd.lpSurface;
I have to comment on this one. It's a very strange thing to do, to cast an l-value to COLORREF* and then assign to it. It doesn't change the type of Pixel so it's pointless. It's also non-standard.
Had to do that in order for it to compile.
You could've cast ddsd.lpSurface to whatever type Pixel was.
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi

User avatar
rainwarrior
Posts: 7804
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: DirectDraw -> Direct3D

Post by rainwarrior » Fri Dec 14, 2012 2:16 pm

WedNESday wrote:Had to do that in order for it to compile.
That's not really an explanation. O_o You could just as easily have commented it out in order to compile. What is the type of Pixel, and why on earth would you be casting Pixel into a different type as you're assigning to it?

WedNESday
Posts: 1236
Joined: Thu Sep 15, 2005 9:23 am
Location: Berlin, Germany
Contact:

Re: DirectDraw -> Direct3D

Post by WedNESday » Fri Dec 14, 2012 2:18 pm

COLORREF *Pixel;

...

(COLORREF *)Pixel = (COLORREF *)ddsd.lpSurface;

User avatar
rainwarrior
Posts: 7804
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: DirectDraw -> Direct3D

Post by rainwarrior » Fri Dec 14, 2012 2:27 pm

If Pixel is already a COLORREF* you should not cast it.

The cast doesn't add anything, and it takes away type safety for Pixel. (E.g. if you changed Pixel and forgot to change that line, you could be assigning to it incorrectly without the compiler error that would normally catch that.)

It'd be normal to write:

Pixel = (COLORREF*)ddsd.lpSurface;

If that doesn't compile, there is another problem going on, but casting the l-value shouldn't be the solution to it.

User avatar
koitsu
Posts: 4217
Joined: Sun Sep 19, 2004 9:28 pm
Location: A world gone mad

Re: DirectDraw -> Direct3D

Post by koitsu » Fri Dec 14, 2012 3:19 pm

WedNESday wrote:COLORREF *Pixel;
So this explains a portion of the memcpy() issue you had. memcpy(&Pixel, &buffer, 1) would have handed memcpy() the address/memory location of the Pixel variable itself, not what Pixel pointed to.

Had you declared Pixel as COLORREF Pixel, then memcpy(&Pixel ...) would have been correct (because the declaration in that case would have meant you allocated on the heap whatever the size/type of COLORREF was itself, rather than just allocating on the heap a pointer to some piece of memory considered to be type COLORREF (which you then would have to allocate memory for using LocalAlloc() or whatever Windows uses).

As for the casting issue -- what rainwarrior and thefox have said is absolutely correct. Rule of thumb with C: do not force casting on things unless you know absolutely 100% that what you're doing is correct. I fully understand the need to squelch warnings from the compiler (even more important if you use -Werror or the compilers' equivalent of -Werror (treat warnings as errors)), but forcing a cast should not be the immediate solution to that. Possibly provide the warning/error you get and we can tell you what's going on. :-)

Post Reply