A little help with DirectDraw

Started by
11 comments, last by Evil Steve 17 years, 2 months ago
It's been a long time since I've posted to GD.net, and I feel that I've developed a lot as a programmer... HOWEVER, I've been trying to extend my 2D engine to work with directdraw as well as openGL, and I'm running into some issues. Now, the problem is really just loading graphics onto a DDS... Before I had known about the lPitch variable, it seemed like I was able to load the full graphic onto the surface, except it would be tinted with the first color of the RGBA int, so everything would be tinted red for example. After reading up a bit more, I would get the right colors... but something horrible!! It only seemed to fill about 1/4 of the surface!! Free Image Hosting at www.ImageShack.us as demonstrated here... It really baffles me, I don't understand why. So I was hoping someone with more DirectDraw experience could shed some light on this for me, I would be most grateful. PS Yes i have read the articles on loading images in DDraw and what not, I found them very informative, but rereading them again and again havn't been much help to me on this. Here is my "loading image into DDS" code, currently :

int img_to_dds ( struct s_imgload *load, struct s_image *img )
{
    DDSURFACEDESC ddsd;
	int i = 0;
	int x, y, p;
	int pixels, px;
	//DATA8 *pixelptr;
				//DATA32 *pixel;
	DATA8 *pixel;
	unsigned int *lpscreen;

	memset( &ddsd, 0, sizeof(ddsd) );
    ddsd.dwSize = sizeof(ddsd);
    ddsd.dwFlags = DDSD_CAPS | DDSD_HEIGHT |DDSD_WIDTH;
    ddsd.ddsCaps.dwCaps = DDSCAPS_OFFSCREENPLAIN|DDSCAPS_VIDEOMEMORY;
    ddsd.dwWidth = load->w;
    ddsd.dwHeight = load->h;

    if (IDirectDraw_CreateSurface( DDRAW, &ddsd, &img->surface, NULL) != DD_OK)
        return FALSE;

	IDirectDrawSurface_Lock( img->surface, NULL,  &ddsd,  NULL, NULL );
	pixel = (DATA8 *)ddsd.lpSurface;
	p = ddsd.lPitch ;
	pixels = load->w * load->h;
for ( y=0;y<load->h;y++ )
	for ( x=0;x<load->w;x++, i++ )
	{
		int c;
		int r,g,b,a,cr,cb,cg,ca, rgb;
		rgb = 255;
			c = (DATA32)load->data;
			READ_RGBA( &c, cr, cg, cb, ca );
			//pixel = x+y * p;
			r = ( cr * ( 1 << r_bits )) / 256;
			g = ( cg * ( 1 << g_bits )) / 256;
			b = ( cb * ( 1 << b_bits )) / 256;
			a = ( ca * ( 1 << a_bits )) / 256;
   // Convert the Values to the appropriate Location in the returned colour value
			 r <<= r_low;
			 g <<= g_low;
			 b <<= b_low;
			 a <<= a_low;
			 rgb = r | g | b | a;
			 //pixel[x + y] = rgb;
			 pixel[x+y*p] = rgb;
			 //pixel[x+y*p] = 255;
			//memset ( pixel, rgb, 4 );

	}

	IDirectDrawSurface_Unlock ( img->surface, NULL );

	return TRUE;
}

In the above, the imgload struct is just a struct with the height and width of the image, the BPP and a pointer to the data, it gets filled by functions which are modified from imlib2, and work reliably in OpenGL, so I'm not convinced that the problem is in that area. Thanks in advance for helping.
|aaap.penopticon.com| My website, including game projects. Collaboration/comments are welcome, please visit :)
Advertisement
You can try to set a pixelformat when you create your surface.
set the pixel format? i was under the impression that the pixel format for a surface is the same format of the current video mode o_o

can someone please elaborate on this?
|aaap.penopticon.com| My website, including game projects. Collaboration/comments are welcome, please visit :)
You need to adapt that code according to the pixel format of the created surface. Your code right now seems to assume an 8bit format (you're sqashing rgba into a single byte).

Since it seems to work without you setting a format you need to request the used format with GetPixelFormat.

Fruny: Ftagn! Ia! Ia! std::time_put_byname! Mglui naflftagn std::codecvt eY'ha-nthlei!,char,mbstate_t>

Thanks.. Now I can grasp this.. I just want to know this one thing, because this is what I had come to understand from reading I did.

1) The surface should have the same number of elements as the display mode ( EG, RGB for 24 bit display, RGBA for 32 bit display? )

2) (and I'm not 100% on this one) all surfaces created under a IDirectDraw interface should be in the same pixel format.

As demonstrated in that one tutorial paper on GD.net on putting pixels into a DDS, I call getpixelformat after creating the primary surface, and save the bits and low bit as global variables. So this is not enough, I'm guessing?

Also, about the "squashing data into 8 bits" thing, I was getting segfaults when using shorts or longs instead of chars, which just baffled me. The pixel format for my primary surface is 32 bits, 8888 (where only 1 bit of the alpha is being used), and if the above are true then all surfaces should be like that.

I guess I just got a bit flustered and started trying different things instead of rationally thinking about it, but it still confuses me why I would get a segfault doing that.

*Tears hair out*
|aaap.penopticon.com| My website, including game projects. Collaboration/comments are welcome, please visit :)
If you try to access the pixel as 32 bit data you have to be careful with the pitch. The pitch is given in bytes, so if your pointer is a DATA32* type you have to divide the pitch by 4.

You'd have to change the loops inner line to

pixel[x + y * ( p / 4 )] = rgb;

Also, if in your case you know both the source data and surface format is 32bit you can simply copy the image data line per line with a memcpy call.


@Nitpickers: Any half decent compiler will change the division to a right shift, don't nag about that bit.

Fruny: Ftagn! Ia! Ia! std::time_put_byname! Mglui naflftagn std::codecvt eY'ha-nthlei!,char,mbstate_t>

hmmm... i tried your advice and, while it does not segfault, it again seems to use the incorrect colours. I know I'm doing something wrong thats really obvious, I just don't see it.
|aaap.penopticon.com| My website, including game projects. Collaboration/comments are welcome, please visit :)
Hmm, what order are the RGB bits in the loaddata? Is it ARGB? Cause the DirectDraw surface will be.

If it is that format try the following snippet, it should work cleanly with 32bit to 32bit copying:

for ( y = 0; y < load->h; y++ ){  memcpy( pixel + y * p, ( (DATA8*)load->data ) + y * load->w * 4, load->w * 4 );}


Just noticed something, what type is load->data?

Fruny: Ftagn! Ia! Ia! std::time_put_byname! Mglui naflftagn std::codecvt eY'ha-nthlei!,char,mbstate_t>

in the load struct the data is in RGBA, however in following one of the articles on GD.net, I save the num bits and the low bit for each element of the pixel one time during initialization of primary surface.

Now this rides on the assumption that all surfaces have the same pixel format, which would make sense of course but I don't know this to be true for sure. At any rate, it is really making me feel dumb lol.

By incorrect colours, what I mean is the whole screen is tinted blue with black vertical scanlines (I guess those are due to the alpha channel or something not cooperating with the pixel format )

Also, when I try doing a memset, what I get is a correctly colored image that takes up about 12/th of the surface ( which is actually only about a third of the full sized image ), and repeats it several times.

I tell you, things were much simpler with openGL to do this kind of work for ya lol but hey it's a good learning experience I guess. I can't wait to be doing sprite rotations and scaling if this is giving me so much trouble :p
|aaap.penopticon.com| My website, including game projects. Collaboration/comments are welcome, please visit :)
Haha, sorry, hardware rotation with DirectDraw is very rare. You're going to have to write your own software routine to rotate an image.

Or, you could move to Direct3D and use ID3DXSprite instead. The D3DX library has functions to load in textures, and since ID3DXSprite uses 3D hardware, it supports things like scaling, rotation and blending.
NextWar: The Quest for Earth available now for Windows Phone 7.

This topic is closed to new replies.

Advertisement