I''ve been using the code from "Real Time Strategy Game Programming using MS Direct X 6.0" and its worked fine untill now. I just bought a new video card, a Guillmot 3D prohet (thats GeForce 256 based), and basically my whole picture is garbled (check out a screen shot here http://www.123.net/~sourmosh/Image2.gif ). Now, I''ve looked thru the direct x 7.0 helpfile, and found this: "When rendering directly into surface memory, always use the pitch returned by the Lock method (or the IDirectDrawSurface4::GetDC method). Do not assume a pitch based solely on the display mode. If your application works on some display adapters but looks garbled on others, this may be the cause of your problem." I think this is it. I''ve looked through the help a little more, and the source from the book, but just cant find what I need to change. Does anyone have any ideas? BTW- all the examples on the CD DONT work, so its not my code. I can send the source code to anyone who wants it. Thanks for any help Dave

It''s been a while since I looked at the source code for that book so my idea might be a little off. I would agree that it apears as though you have a problem with pitch. Since the book does not use DiretDraw surfaces to store images, you know that is not the problem. There for the problem is that you are not properly copying the image to you back buffer.

As I recall, when you lock th back buffer, you have a SCREEN_STRUCT that is filled out. In this struct there is a member called RealWidth or something like that. All you need to do is in your functions that copy the image to the back buffer add the RealWidth to the pointer. Here is some psuedo code:

//some codefor( i = 0; i < graphic.Height, i++ ){        ptr = (U16*)Screen.screen+x+y*Screen.RealWidth;         //i forget how the book handles the image pointer        memcpy16(  ptr, graphicptr, graphic.Width );} 

If this doen''t help at all (It probably won''t) you can send me the source code and I''ll take a look at it. I may not be able to help, but I can give it a go.

I''m not sure how your code blits to the screen, but it could also be that your new video card is a different bit format.. such as 5-5-5 or 5-6-5 ..etc. But that shouldn''t be a problem if you are just using the DirectX blitter.

Gromit - nor should the pitch, if he uses the directdraw blitter.

I think when you call IdirectDraw4::Lock() with the flag DDLOCK_SURFACEMEMORYPTR it sets up your direct draw surface description struct with valid fields, one is called lPitch, this is the memory pitch per line of video display, so you need to multiply the y part by that to get the correct line.
I think thats right,

Take it easy

-Mezz

If u are using Mackey''s code straight from the book, note that although he says in a paragraph somewhere "Do not assume the pitch", his code does the total opposite.

I have confirmed this with the author a few months ago. Ask him to mail you u his latest version of the engine(If u *REALLY* want to use it; there are lots of other bugs)

Okay...I think that, your problem is the lpitch...
I guess you assume that your point (x,y) is in the memory at
x+y*SCREEN_WIDTH...
The problem is, that there might be other memory in between, due to non-linear memory...
So instead of using SCREEN_WIDTH, use the lpitch
(quite frequently lpitch IS the screen width, but it might not be, like in case of your video card)

So use lpitch and you should be fine...

- Sleepwalker

Check out the Directx FAQ at microsoft''s site.
This question apears under the DDraw section