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.).
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);
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.
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.
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.
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.
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.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.
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.
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.
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.
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. :-)