Feature Request - Sprite scale origin variables

[Sporadic]

Hi guys,

 

I mentioned this the other day briefly in another thread.

 

I'm thinking it might be useful to be able to set the origin for scaling operations in the object file. Sometimes it definitely helps if the origin is the middle of the sprite rather than in the corner.

 

Perhaps 2 new variables we can set for scale_origin_x and scale_origin_y in a similar way to the collision box origin. Or, use the collision origin for scaling operations and perhaps rename it and use for both things. Obviously your call etc etc.

 

This way we wouldn't have to work out the new x/y position after the object is scaled at runtime to keep it central (otherwise it scales out to the right/down).

 

Is this possible?

Edited August 28, 2015 by Sporadic

[sh3-rg]

possible? has to be

 

probable? hmmm, I think we've run out of credits when it comes to asking stuff of CJ recently

[Sporadic]

haha yeah I do worry

[ggn]

Yeah I think cj physically shuddered at the thought of doing maths .

 

However, I'm sure that one of you gentlemen has tackled this problem in the past so you probably have some code that does the translation. Why don't we wrap it in a function so it can be accessed from anywhere? Something like centreoriginx(width,scalex) / centreoriginy(height,scaley)? (I dunno, just typing things here!)

Edited August 28, 2015 by ggn

[sh3-rg]

Well he said gentlemen, so he must mean you, so good luck with that

[ggn]

No I didn't

[Sporadic]

Just trying to understand the basic code i used for this in astrostorm lol.

 

It's something like;

newspritex = spritex - INT( 0.5 * scalex  )
newspritey = spritey - INT( 0.5 * scaley  )

Basically because the scale is an int from 0 to 255, these map to pixels on the screen. So you have to take half the current scale amount off the sprites position.

 

I think...... lol

 

I can create a test project if that helps, rather than waste anyones time.

Edited August 28, 2015 by Sporadic

[+CyranoJ]

I think we've run out of credits when it comes to asking stuff of CJ recently

 

I do have my own projects to get back to

[Sporadic]

 

I do have my own projects to get back to

No problem. You said ask, so I asked

 

Just a roadmap feature would be cool, whenever Its done, its done.

[+CyranoJ]

A roadmap?

 

We're making this up as we go along. Are we there yet?

[Sporadic]

A roadmap?

 

We're making this up as we go along. Are we there yet?

ok, "roadmap"

[+CyranoJ]

[ggn]

[Sporadic]

[GroovyBee]

 

newspritex = spritex - INT( 0.5 * scalex  )
newspritey = spritey - INT( 0.5 * scaley  )

 

Does INT round up or down? If it rounds down then you can avoid the floating point multiply and an integer->float "promotion" and a final float->integer conversion by using :-

 

newspritex = spritex - (scalex/2)
newspritey = spritey - (scaley/2)

[Sporadic]

Does INT round up or down? If it rounds down then you can avoid the floating point multiply and an integer->float "promotion" and a final float->integer conversion by using :-

 

newspritex = spritex - (scalex/2)
newspritey = spritey - (scaley/2)

 

Help file says it rounds down I believe.

 

Cheers for the input, that will should at least be faster that the INT function

 

 

Syntax: RetVal% = INT(Number)

 

Parameters:

• RetVal% INT returns the greatest integer less than or equal to floating point Number.
• Number Floating point number to be converted to an integer.

[sh3-rg]

[Sporadic]

Does INT round up or down? If it rounds down then you can avoid the floating point multiply and an integer->float "promotion" and a final float->integer conversion by using :-

 

newspritex = spritex - (scalex/2)
newspritey = spritey - (scaley/2)

Yep, that works

 

Just tested it.

[Sporadic]

I might have had my explanation wrong. I think the scale/2 works because my test sprite is 16 px. Which is half of 32 (1:1).

 

I will do a proper test project and work this out for sure.

 

Not now though cause lunchtime is over..... booooooo

Edited August 28, 2015 by Sporadic

[+CyranoJ]

I might have had my explanation wrong. I think the scale/2 works because my test sprite is 16 px. Which is half of 32 (1:1).

 

I will do a proper test project and work this out for sure.

 

Not now though cause lunchtime is over..... booooooo

 

 

There must be some contention aboard the Jaguar bus. HoHoHo. I'll get my coat.

[sh3-rg]

When I was playing around with this at first, I found some magic shifting value, but I don't recall it being something as straight forward as a half. But I can't remember what the project was I was using (it was January time and all this was super brand new and scary! lolol)

[ggn]

Well, if sporadic/groovybee's snippet works universally I can just add two #defines in rbasic.h and then it'll work everywhere.

[Sporadic]

Well, if sporadic/groovybee's snippet works universally I can just add two #defines in rbasic.h and then it'll work everywhere.

Thanks ggn,

 

I don't think that code will work though. I believe I lucked out because my sprite was 16px (half of 32 1:1 scale).

 

 

I'll work out the proper formula and report back when I get the chance.

 

The Pseudo code is something like;

spritex - ((diff between currentscale and 32) * (half sprite width))

 

But that ^ is probably bollocks so i'll test to be sure first.

[Sporadic]

My pseudo code couldnt have been more wrong. That would end up with massive values.

 

Thinking on the drive home I think its;

 

Offsetx = (spritescalex / 32) * (half sprite width)

If spritescalex < 32 then

Spritex += offsetx

Else

Spritex -= offsetx

endif

 

Then the similar on the y axis etc.

 

That would have the origin in the centre though. Would need to think more about it for an origin variable. Although I imagine most people would want centre anyway. At least on x or y or both.

Edited August 28, 2015 by Sporadic

[Sporadic]

Ok,

 

I have finally managed to get a test project together. It actually ended up being quite a tasty algorithm to get it to work with any sprite size. (i've only tested multiples of 32)

 

I've attached the project code. There are 2 subs at the bottom that do the scaling and repositioning. Some sizes didn't work unless I delved into subpixel tastyness - so you will see the horrible code I came up with for that. If anyone can make that cleaner/faster then please go ahead as it's not my area.

 

- Use the DPad to change the x/y scale of the square.

- Change the "block1" and "block2" vars at the top of the code to 1&2 or 3&4 to pick which square "group" to resize.

 

It's quite a lot of code compared to other functions, if this could be added as a fast RB+ function at some point that would be great and i'm sure people would find it useful. But if not then no worries. It's fast in this project as nothing else is going on

 

Also, this only scales the sprite based on the origin being in the centre. That would probably cover most needs, if someone did require it.

Perhaps being able to specify which axis to scale would be useful though, SCALEX, SCALEY, SCALEXY etc etc.

 

Either way, this might be a useful example for someone

 

 

scaler.zip