Jump to content

Problems with dxDrawImageSection


MaddDogg

Recommended Posts

Hi!

I just tried to work with dxDrawImageSection for the first time, but just can't figure out, how it is working.

The wiki article says that the arguments u, v, usize, vsize determine the section of the image to be shown.

I understood it like this:

u and v are the absolute coordinates of the starting point (left top) of the section, whereas the zero point is at the corner of the image (and not the whole screen).

usize and vsize are the absolute values for the width and height, starting at the point defined by u and v.

But somehow, it just does, what it wants, when I set the values to something.

I can't figure out, what MTA is doing there, because for example when I make vsize smaller than the actual image height, the image is moved downwards from it's original position. This makes no sense to me, since vsize just defines the vertical size.

With other images I tried, the usize and vsize just have no effect at all.

Do I just have a mental block or is someone having the same problems?

Also I looked into the MTA source code, and it seems very weird to me.

I'm not a programmer expert, but if you search for the function definition in the source code, you find that a function named DrawTextureQueued is called, which for some reason does not expect the image section arguments.

The function is called like this:

DrawTextureQueued ( fX, fY, fWidth, fHeight, fU, fV, fSizeU, fSizeV, false, strPath, fRotation, fRotCenOffX, fRotCenOffY, ulColor, bPostGUI )

But the function prototype looks like this:

bool DrawTextureQueued ( float fX, float fY, float fWidth, float fHeight, const std::string& strFilename, float fRotation, float fRotCenOffX, float fRotCenOffY, unsigned long ulColor, bool bPostGUI );

You see? The image section arguments (fU, fV, fSizeU, fSizeV) are not used by the actual function.

So, am I understanding something wrong or is there really a mistake?

Thanks for any help and explanation!

Madd

Link to comment
  • 2 weeks later...

It's perhaps useful to post steps to reproduce, like a script or something.

In my recent attempts for dxDrawImageSection, I can actually confirm it works fine. Either that or I made some mathematical error in which it somehow corrected itself correctly.

Also, you noted that the function prototype indeed is:

bool DrawTextureQueued ( float fX, float fY, float fWidth, float fHeight, const std::string& strFilename, float fRotation, float fRotCenOffX, float fRotCenOffY, unsigned long ulColor, bool bPostGUI );

However, this isn't the only function with that name. You can "overload" functions, meaning you can make another function with the same name, but with another return type or arguments. Like for instance:

bool DrawTextureQueued ( float fX, float fY, float fWidth, float fHeight, float fU, float fV, float fSizeU, float fSizeV, bool bRelativeUV,  const std::string& strFilename, float fRotation, float fRotCenOffX, float fRotCenOffY, unsigned long ulColor, bool bPostGUI );

If this wouldn't be correct, the function wouldn't even be in MTA, because it would fail to even actually compile.

Link to comment

Thanks for the reply.

Thanks for the explanation regarding the source code.

This is my actual source code:

addEventHandler("onClientRender", getRootElement(),
function ()
if f_showHealthBar then
dxDrawImage(430,980,256,64,"images/health_bar_body.png")
 
-- full at 239, empty at 18, length is 221
local health = getElementHealth(getLocalPlayer())
		dxDrawImageSection(430,980,256,64,0,0,18 + math.round(221 / 100 * health),64, "images/health_bar_status.png", 0, 0, 0)
outputChatBox(18 + math.round(221 / 100 * health))
end
end
)

This is supposed to draw a health bar.

The actual image has the size 256x64px. The image used by dxDrawImageSection is the red status indicator within the bar, which is drawn longer, the higher the player's health is.

As you can see in the following pics, the section of the image is not correct.

The numbers in the chatbox are the output of the one outputChatBox line. These numbers define the actual width of the section.

http://img35.imageshack.us/img35/4703/fullhealth.jpg

http://img824.imageshack.us/img824/9862/injured.jpg

Link to comment

Please note that you should also modify the actual width. You can modify the UV as much as you like, but this means the rest of the picture will be stretched out over the width and height. Your picture will always be 256 pixels wide with your script, because you specify 256 to be its actual width. The only thing the UV is for, is so you can decide to draw a partial image. For instance, if you'd be making a custom minimap, you wouldn't want to have to draw the entire minimap onto the screen.

To fix this, you can try setting the width to the same value as you set the U width. Then it should work.

Link to comment

Thank you!

That actually was my problem.

I didn't consider this and tried a lot of things, but not changing the original width and height, because I thought, they represent the actual image size of the source image.

Thank you again.

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...