Image resize script using PTM ratio and level building

[UKDeveloper99]

I think this is kinda a bug maybe not a bug but more just a problem that I ran in to.

Because I use pixel accuracy in the rube editor for images I want my images to match exactly the dimensions on the device. So of course I used the script that resizes images to their pixel height. However the function that gets image pixel height:

Code: Select all

image.getPixelHeight() 
// or width

returns an int (as you would expect, can't have half pixels). However this doesn't work so well in calculations because you end up with floating point innaccuracy's, for example when the image width or height is an odd number. It then doesn't scale correctly. So maybe using an int and not a float return type for this function doesn't make so much sense. This is my quick fix, I cast it to a float before using it in the script.

Code: Select all

    float PTM = 30.0f;
    image[] imgs = si(); //selected images
    for (uint i =0; i < imgs.length; i++)
    {
	float height = imgs[i].getPixelHeight();
        imgs[i].setScale(height / PTM );
    }

I also have several other image scripts such as align to origin and align images side by side or snap to left edge. These help greatly with level building in the editor. Especially if you're using tileable sprites for example. I use the same float cast method in those scripts too.

Just sharing

[iforce2d]

I don't quite follow... it sounds like you are talking about rounding that happens when dividing an int with another int, for example:

int a = 10;
int b = 3;
float c = a / b; // result will be 3

This is not floating point inaccuracy, it's just integer division. But as long as the divisor is a float it should not happen, for example:

int a = 10;
float b = 3;
float c = a / b; // result will be 3.33333

In the script you showed, the divisor is the value PTM which is a float, so I would not expect any integer division rounding to occur.

I also don't get why it matters that the divisor is an even or odd number, if the value for b in the first example above was 6, then integer division would give 10 / 6 = 1 even though both numbers are even. If you could give an example of what you mean by "doesn't scale correctly", maybe I could tell if it's something that needs to be fixed in my scripts too.

[UKDeveloper99]

Yes you're right my apologies. I think the problem was actually coming from some of my other scripts, I posted it here for your convenience.

A simple script to align an image's bottom corner to the origin in the editor.


ImageAlignOrigin.rs (with error)

Code: Select all

    float PTM = 30.0f;
    image[] imgs = si(); //selected images
    for (uint i =0; i < imgs.length; i++)
    {
	int imageWidth = imgs[i].getPixelWidth();
	int imageHeight = imgs[i].getPixelHeight();
        imgs[i].setCenter(0.0f + ((imageWidth/2) / PTM), 0.0f + ((imageHeight/2) / PTM) );
    }

ImageAlignOrigin.rs (without error)

Code: Select all

    float PTM = 30.0f;
    image[] imgs = si(); //selected images
    for (uint i =0; i < imgs.length; i++)
    {
	float imageWidth = imgs[i].getPixelWidth();
	float imageHeight = imgs[i].getPixelHeight();
        imgs[i].setCenter(0.0f + ((imageWidth/2) / PTM), 0.0f + ((imageHeight/2) / PTM) );
    }

So as you can see images that have odd resolutions are divided by 2 which I assume is performing an int/int=int calculation here. Then it is performing an (float + (int / float)) calculation. I had this issue with several of my other scripts too. They all use float for the pixel height and width now. It's just safer for me to not worry about if the error might occur or not.

p.s. when I said floating point innacuracies I simply meant the decimal part that is omitted by dividing whole numbers. I know they're separate things.

[UKDeveloper99]

I have another question, is there a way I can recreate the functionality of the snap to grid stepping while holding ctrl in a script?

I want to take the bottom left corner position similar to how I do it in the other script I pasted in my last post and then increment in a set amount of units, something like

Code: Select all

one_pixel = 1 / ptm_ratio;
increment = one_pixel * num_increments;

This would work for translating but I'd have to call it from the action menu each time, can I bind this to a key or something?

p.s. just found script hooks

[iforce2d]

p.s. just found script hooks

Did script hooks solve the problem? You can also check if the ctrl, shift or alt keys are being held down inside a script. If you have not seen it already, the final section of this video might help explain a few things: https://www.youtube.com/watch?v=XM_yYvk3AKk#t=24m

[iforce2d]

btw the problem in your script above would have been due to the (imageWidth/2) part which will do an integer division first, causing the rounding to occur for odd numbers before the PTM division is done. You could do (imageWidth/2.0) instead to make sure the divisor is a float.

[UKDeveloper99]

Yea like I said, it's doing an int/int operation first. The script hooks worked fine, thanks Chris.

[UKDeveloper99]

Is there no way to have script hooks for keybinds other than 1-9?

[iforce2d]

That's correct. You can augment those keys with combinations of Ctrl and Alt, by checking in your script to see which are currently pressed. This allows for four distinct hooks per key:
- the key alone
- Ctrl + the key
- Alt + the key
- Ctrl + Alt + the key
.... for a total of 40 possible keyboard hooks using the number keys 0-9

[koiko]

Why is there no R.U.B.E method to check whether Shift is pressed? There is one for Ctrl and Alt but not Shift. I would expect that Shift + key would allow me to reverse the hook action of pressing the key alone. For example if the hook was about rotating a body would be useful to use Shift to revert the action and use Ctrl and Alt to set two different magnitudes of rotation for example: pressing the key alone would result in rotating by 1 degree (fine rotation), Ctrl would rotate by 10 and Alt by 45 and Ctrl+Alt by 180.