Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Newcomers DBPro Corner / Unexpected copy bitmap or bitmap to sprite result.

Author
Message
Naphier
14
Years of Service
User Offline
Joined: 2nd Oct 2010
Location: St Petersburg, Florida
Posted: 3rd Dec 2011 05:36 Edited at: 3rd Dec 2011 06:53
Happy Friday everyone.

I've been working on this little function as a matter of exercise more than functionality. In a nutshell it draws something to a non-zero bitmap and gets the image there, then puts that image into a sprite. However when the sprite was being drawn onto bitmap 0 it was getting stretched out (see attached). I was able to remedy this by deleting the sprite I was initially setting up in the procedure that found the first available sprite number.

I'm not sure why this would cause the sprite to be stretched.
Any one got some ideas?

At any rate I essentially have it fixed, but I noticed another peculiarity; the text seems to get thinner when it is in the sprite versus when it is drawn with a text command to bitmap 0. I have a feeling that this is due to how windows or direct x is handling the drawing of a font vs. what is actually in video memory, but I'm way to new to this to be sure of such a judgement call. Also when I take a screenshot of this effect and paste it into GIMP there is no difference between the two which is even stranger.

Any insight on this is welcome.



Hopefully the code is straight forward. I aim for clean code!
Thanks for the help.

EDIT:
After some messing around I see that the pixel loss of the text seems less when running the displayed sprite in a synced loop. But there is still some loss to the clarity / sharpness of the text. Would be nice to get over that hump.

EDIT 2:
I'm over the hump, but not completely sure why.
I set the texture flag on the get image command and it prevented any noticeable pixel loss. This worked with texture flag 1 and 3 only. Both of which have no stretching set, not sure why that would make a difference. I was thinking it might be something to do with the alpha, but it doesn't appear to be so since texture flag 1 uses colorkey and texture flag 3 retains alpha.
Insight is still highly sought.

~Napland Games~

Attachments

Login to view attachments
IanM
Retired Moderator
22
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 3rd Dec 2011 21:25
Use the 6-parameter version of GET IMAGE - add a ',1' to the end.

Naphier
14
Years of Service
User Offline
Joined: 2nd Oct 2010
Location: St Petersburg, Florida
Posted: 3rd Dec 2011 23:46
Thanks IanM, I figured that out (see edit 2 above - texture flags 3 also works).

Anyone able to tell me why it is happening or what is going on to make both of these issues occur?

~Napland Games~
EricB
13
Years of Service
User Offline
Joined: 3rd Nov 2011
Location:
Posted: 5th Dec 2011 23:33
From what I can see both flag 0 and 2 allow stretching while 1 and 3 do not. Perhaps it has something to do with how pixels are copied when the use stretching bit is set.
Naphier
14
Years of Service
User Offline
Joined: 2nd Oct 2010
Location: St Petersburg, Florida
Posted: 5th Dec 2011 23:48
That's my conjecture as well, EricB.
I'd love to know what is really doing though!

IanM
Retired Moderator
22
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 9th Dec 2011 15:23
Depending on your graphics card capabilities, when DBPro requests a texture, DirectX will return a texture with the x/y sizes scaled up to the next power-of-2 (eg, 100x50, could become 128x64).

DBPro deals with this by scaling the image from the file to the correct size to fit that scaled-up texture.

When you specify the ',1' flag, you disable the scaling. This puts extra work onto DBPro.

Generally, you should specify this flag when using the image for sprites, but not when using it for objects (however, for object you should have your textures correctly sized in the first place).

Regarding card capabilities, original 3D acceleration required textures with power-of-2 sizes - they literally could not accepts textures of other sizes. As things moved on, the capability to accept non power-of-2 textures became mainstream, but generally they are still not rendered as fast (the reasons are mathematical - if you understand how floating point numbers are represented, the short-cuts to power-of-2 sizes becomes glaringly obvious).

Naphier
14
Years of Service
User Offline
Joined: 2nd Oct 2010
Location: St Petersburg, Florida
Posted: 9th Dec 2011 23:44
Thanks Ian. That's the explanation I needed!
Now I understand a bit more about how sprites are handled as well as textures. I didn't even think about the fact that sprites initiate 3d mode and the image of the sprite is actually a texture (I sort of knew this because you can alter the UV mapping).

I remember UDK needing images sized in the power of 2.
So what's happening here is that the since the image size has the same size as the screen and the screen size is not a power of 2 then the image is stored in memory with a size in power of 2 increments, but then when mapped onto the sprite it is actually scaled.
Very interesting.

Thanks a ton

Login to post a reply

Server time is: 2024-11-23 23:49:01
Your offset time is: 2024-11-23 23:49:01