Archived

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

Megatron

Crazy, Crazy Sprites

Recommended Posts

So I''m writing this program that let''s the user "drive" a little car across the screen. Anyway, I''m doing my first version in 8-bit (just cuz) and I''ve run into a problem. While I can blit the background and sprite onto the screen, and move the car across the screen, the car itself looks messed up. I have no idea why, because it is an 8-bit image and the dimentions are correct and all that. Here is the code...could someone lend a hand? [url]http://missoula.bigsky.net/law/DDRAW.txt[/url]

Share this post


Link to post
Share on other sites
It looks like a bunch of lines, in a 100 x 100 pixel square (which is the proper size). Again, the background looks fine, but the car sort of looks like a badly tracked video cassette tape.

Share this post


Link to post
Share on other sites
I posted some suggestions to the other thread you started. Double check the rectangle you are reading in for the sprite. If the height and width are not correct, the image will show up strange. If just the pallettes where off, the image would still show up correctly, just that all the colors would be off. Hope this helps.

-----------------------------
kevin@mayday-anime.com
http://dainteractive.mayday-anime.com

Share this post


Link to post
Share on other sites
Hello,

I think the problem is where you Lock() your surface to copy the car bitmap to the surface. DirectDraw tends to size your surface widths and heights to the nearest power of 2. For example when you create your car sprite surface (100x100) it instead creates a 128x128 surface. So, when you lock and copy your data to the surface, you copy 100 bytes and advance the pointer by 100 bytes,
which causes your next line starts 28 bytes too early..

You should advance the pointer by the "real" surface width. You can get this width from the lock(), like this:

DDSURFACEDESC2 ddsdesc;

pSurface->Lock(NULL, &ddsdesc, DDLOCK_SURFACEMEMORYPTR | DDLOCK_WAIT | DDLOCK_NOSYSLOCK, NULL);

advance = ddsdesc.lPitch // The real surface width

Hope this helps.

Share this post


Link to post
Share on other sites
I haven''t checked if this is always the case, but in my implementation of a DirectDraw wrapper this indeed was the case.
By taking the surface width returned from Lock() it fixed my problem totally.

Search the SDK for topic "Width vs. Pitch" if you don''t believe me.

Share this post


Link to post
Share on other sites
Direct quote from the SDK:

"When rendering directly into surface memory, always use the pitch returned by the Lock method"

As far as I understood from the code, he loads a bitmap, then locks the sprite surface and renders the bitmap in the surface, and then uses blt to blit the sprite to the back buffer..

Edited by - skallio on July 24, 2001 9:58:52 AM

Share this post


Link to post
Share on other sites
If you look where I'm locking the lpddsbackground surface, you'll see I do use ddsd.lpitch instead of the screen width. I converted the code to 16 bit, but the problem remains. The background looks fine, but the sprite is screwy. Do you think it has to do with the order I'm loading? I tried loading my sprite before doing the lpddsbackground lock, but that crashes the program. I'm not sure why this is, and I suspect the problem with the image might have to do with this. I load the background, do the color and video memory loading stuff, and then load the sprite. Why it has to be like this I don't know.

I've uploaded the .exe file so you can see for yourself what it's doing. I do appreciate the help, btw. This is very frustrating because I seem to be overlooking something every time.

p.s. Does anyone have a program that blits two images properly? I was sort of hoping they would and we could compare notes.


.EXE file at
http://missoula.bigsky.net/law/Game.zip (600 kb)

Source Code at
http://missoula.bigsky.net/law/DDRAW.txt

Edited by - Megatron on July 24, 2001 12:37:14 PM

Share this post


Link to post
Share on other sites
When in the code are you copying the bitmap to the surface? I saw you load the background bitmap and copy it to the surface, and unload the bitmap. Then, you load the car bitmap but you don''t copy it to anywhere and immediately unload it??

Share this post


Link to post
Share on other sites