Archived

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

Ichabod

need some help..

Recommended Posts

Hi! We have a problem that we guess has something to do with lock and pitch. Let me first try to explain what we are trying to do. We are writing a small simple spaceship shooter (2D, dx7, 640x480, 16bit colors). The ship rotation contains of 36 sprites that are placed next to eachother in a large bitmap. A ship also has a placement for a gun that is plotted with a single pixel right under the 36 ship rotation sprites in the large bitmap. Upon creation of a ship we are reading those single pixels to get the gun placement for every sprite (we did this raw in the source code in the beginning, but with this method we can draw new ships and with single pixels mark where the gun for each of the 36 sprites is positioned). When we extract those single pixels we are aware of stuff like zeromemory, lock, pitch, 2 bytes per pixel in 16bit color mode, unlock and stuff like that). And now to the problem.. This works great on my machine and on my friends machine. We have also tried it on atleast 4 other computers, no problems. But I recently tried this on my friends laptop and everything was kinda messed up. Not only the gun is positioned wrong, but the actuall ship sprites seems to be cut out of the large bitmap with some sort of offset (the leftmost ~5 pixels are blitted to the right of the ship). To blit the right sprite according to the current angle (that is controlled with the arrow keys), we do something like display->Blt( x, y, surface, &rect) where rect contains the "right" sprite to blit due to the arrow key controlled angle. This laptop computer is using up to date dx drivers and the screen is in the right color mode. We can''t figure this one out. Please help! (if you don''t get me, please reply and I will explain further)

Share this post


Link to post
Share on other sites
How are you originally putting the graphics into the surface? are you accounting for the pitch possibly being different than the width?



Don''t listen to me. I''ve had too much coffee.

Share this post


Link to post
Share on other sites
Yes, that´s accounted for, we had that problem a while ago, but it´s now fixed.

It´s just as if the pointer "lpSurface", which we get from the Lock method, returns a pointer that points 5 pixels ahead of the surface.

It´s also worth mentioning that the problem only occures in 16-bit colour-depth.

And this happens only on that laptop computer...

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
If it only occurs in 16bit then it''s most likely a problem with the 5-5-5 or 5-6-5 format. I suspect you don''t notice this on your desktop test machines because they are probably all using one of the 16bit formats. However when you move to the laptop it uses a different format. So the suspect is the 5-5-5/5-6-5 pixel conversion code.

Share this post


Link to post
Share on other sites
First of all, thanks for the replies.

Yes, we have spent the entire evening (gmt ) trying to get this one solved. And just as you mention we have also concluded that it has something to do with the 16-bit bmp files.

I guess you are all aware of the file ddutil.cpp that comes with almost all samples in the SDK. That is what we use, aka LoadBitMapFromFile and so..

If we change the depth back to 8-bit it is working on the laptop (and ofcourse on all stationary machines as well).

And now some questions. How can we see what format we are using (5-5-5 or 5-6-5) and how can we change it? This is probably something you can''t manage with ddutil. Or are there some other ways to work around this?

Share this post


Link to post
Share on other sites
hello
quote:

How can we see what format we are using (5-5-5 or 5-6-5)


dont u set the format in the initialization sequence? ie: back buffer format, bak buffer width/height?

cause then u could just store the format u use in a var and call on it whenever you want
quote:

How can we see what format we are using (5-5-5 or 5-6-5)


X1R5G5B5 is 555. R5G6B5 is 565.







Al
** MY HQ**

[edited by - alfmga on August 14, 2002 9:03:19 PM]

Share this post


Link to post
Share on other sites