#### Archived

This topic is now archived and is closed to further replies.

# Weird video_buffer formula

This topic is 6921 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

I came across the following formula... USHORT *video_buffer; // pretend that it points to the primary surface.. video_buffer[x + 640*y] = color; To me, this doesn't make much sense. What I do know though, is that 640 is the number of pixels per row on the screen (right?), and color is a pointer to PALETTEENTRY (right?). What is wracking my brain right now is why you multiply y by how many pixels per row and then add x. Can anyone shoot this into the clear for me? Thanks to all! Edit: When I point video_buffer to the primary display, I have always been using this.. video_buffer = (USHORT *)ddsd.lpSurface; Could I, for arguments sake, point the video buffer to the primary surface by doing this: video_buffer = lpddprimary; // lppddprimary is the primary surface Thanks! GO LEAFS GO! Edited by - Fredric on 5/6/00 8:32:14 PM

##### Share on other sites
The video memory is address linearly, so for each row down you have to add the width of a row. For example, coordinates (47, 4) would mean x=47 and y=4. So the pixel would be at (47 + 640 + 640 + 640 + 640), or (x + width*y).

Also note that you should NOT be using "640" in the equation, but rather ddsd.lPitch because DirectDraw may be using more than 640 bytes per row, even on 8-bit surfaces.

aig

##### Share on other sites
Ohhhhhh....... I get it now! So, if say I had the coordinates (23, 3), it would be:
// x=23, y=3
video_buffer(23 + ddsd.lPitch + ddsd.lPitch + ddsd.lPitch);

but in code, it would actually be:
video_buffer(x + ddsl.lPitch*y);

That''s cool, thanks! It''s kind of confusing, but your explanation was really easy to understand! Thanks An Irritable Gent!

GO LEAFS GO!

• 10
• 13
• 52
• 11
• 15