It is currently Sun Oct 22, 2017 12:20 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 39 posts ]  Go to page Previous  1, 2, 3  Next
Author Message
PostPosted: Wed Dec 12, 2012 12:41 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5732
Location: Canada
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.).


Top
 Profile  
 
PostPosted: Thu Dec 13, 2012 2:04 pm 
Offline

Joined: Thu Sep 15, 2005 9:23 am
Posts: 1194
Location: Behind you with a knife!
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:
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?

_________________
http://www.jamesturner.de/


Top
 Profile  
 
PostPosted: Thu Dec 13, 2012 2:08 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5732
Location: Canada
I would guess Pixel is NULL or something? Have you verified that the lock was successful?

Also:
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.


Top
 Profile  
 
PostPosted: Thu Dec 13, 2012 2:16 pm 
Offline
User avatar

Joined: Sat Jan 22, 2005 8:51 am
Posts: 427
Location: Chicago, IL
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


Top
 Profile  
 
PostPosted: Thu Dec 13, 2012 2:28 pm 
Offline

Joined: Thu Sep 15, 2005 9:23 am
Posts: 1194
Location: Behind you with a knife!
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.

_________________
http://www.jamesturner.de/


Top
 Profile  
 
PostPosted: Thu Dec 13, 2012 2:38 pm 
Offline
User avatar

Joined: Sat Jan 22, 2005 8:51 am
Posts: 427
Location: Chicago, IL
you probably want
Code:
memcpy(Pixel, &buffer, 1);

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

_________________
get nemulator
http://nemulator.com


Top
 Profile  
 
PostPosted: Thu Dec 13, 2012 2:41 pm 
Offline

Joined: Thu Sep 15, 2005 9:23 am
Posts: 1194
Location: Behind you with a knife!
Work now James, even though I tried just that earlier.

_________________
http://www.jamesturner.de/


Top
 Profile  
 
PostPosted: Thu Dec 13, 2012 3:53 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3192
Location: Mountain View, CA, USA
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.).


Top
 Profile  
 
PostPosted: Fri Dec 14, 2012 1:44 am 
Offline
User avatar

Joined: Mon Jan 03, 2005 10:36 am
Posts: 2963
Location: Tampere, Finland
WedNESday wrote:
Code:
(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: kkfos.aspekt.fi


Top
 Profile  
 
PostPosted: Fri Dec 14, 2012 4:21 am 
Offline

Joined: Thu Sep 15, 2005 9:23 am
Posts: 1194
Location: Behind you with a knife!
thefox wrote:
WedNESday wrote:
Code:
(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.

_________________
http://www.jamesturner.de/


Top
 Profile  
 
PostPosted: Fri Dec 14, 2012 5:52 am 
Offline
User avatar

Joined: Mon Jan 03, 2005 10:36 am
Posts: 2963
Location: Tampere, Finland
WedNESday wrote:
thefox wrote:
WedNESday wrote:
Code:
(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: kkfos.aspekt.fi


Top
 Profile  
 
PostPosted: Fri Dec 14, 2012 2:16 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5732
Location: Canada
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?


Top
 Profile  
 
PostPosted: Fri Dec 14, 2012 2:18 pm 
Offline

Joined: Thu Sep 15, 2005 9:23 am
Posts: 1194
Location: Behind you with a knife!
COLORREF *Pixel;

...

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

_________________
http://www.jamesturner.de/


Top
 Profile  
 
PostPosted: Fri Dec 14, 2012 2:27 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5732
Location: Canada
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.


Top
 Profile  
 
PostPosted: Fri Dec 14, 2012 3:19 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3192
Location: Mountain View, CA, USA
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. :-)


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 39 posts ]  Go to page Previous  1, 2, 3  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: Bregalad and 6 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group