DirectDraw -> Direct3D
Moderator: Moderators
- rainwarrior
- Posts: 8732
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: DirectDraw -> Direct3D
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.).
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.).
Re: DirectDraw -> Direct3D
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.
...either crashes or does absolutely nothing. Ideas?
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);
- rainwarrior
- Posts: 8732
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: DirectDraw -> Direct3D
I would guess Pixel is NULL or something? Have you verified that the lock was successful?
Also:
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.
Re: DirectDraw -> Direct3D
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.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.
get nemulator
http://nemulator.com
http://nemulator.com
Re: DirectDraw -> Direct3D
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.
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.
Re: DirectDraw -> Direct3D
you probably want
instead of
Code: Select all
memcpy(Pixel, &buffer, 1);
Code: Select all
memcpy(&Pixel, &buffer, 1);
get nemulator
http://nemulator.com
http://nemulator.com
Re: DirectDraw -> Direct3D
Work now James, even though I tried just that earlier.
Re: DirectDraw -> Direct3D
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.).WedNESday wrote:Work now James, even though I tried just that earlier.
Re: DirectDraw -> Direct3D
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.WedNESday wrote:Code: Select all
(COLORREF *)Pixel = (COLORREF *)ddsd.lpSurface;
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi
Re: DirectDraw -> Direct3D
Had to do that in order for it to compile.thefox wrote: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.WedNESday wrote:Code: Select all
(COLORREF *)Pixel = (COLORREF *)ddsd.lpSurface;
Re: DirectDraw -> Direct3D
You could've cast ddsd.lpSurface to whatever type Pixel was.WedNESday wrote:Had to do that in order for it to compile.thefox wrote: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.WedNESday wrote:Code: Select all
(COLORREF *)Pixel = (COLORREF *)ddsd.lpSurface;
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi
- rainwarrior
- Posts: 8732
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: DirectDraw -> Direct3D
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 wrote:Had to do that in order for it to compile.
Re: DirectDraw -> Direct3D
COLORREF *Pixel;
...
(COLORREF *)Pixel = (COLORREF *)ddsd.lpSurface;
...
(COLORREF *)Pixel = (COLORREF *)ddsd.lpSurface;
- rainwarrior
- Posts: 8732
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: DirectDraw -> Direct3D
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.
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.
Re: DirectDraw -> Direct3D
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.WedNESday wrote:COLORREF *Pixel;
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. :-)