Request for Smooth Sprite scaling example code

[+Sporadic]

I put this request in the thread for my new game in progress but the formatting got mashed so it might have been missed.

Easier for other people to find anyway if posting separately.

 

I am after some help with smooth sprite scaling if possible.

 

I played around but could only get it to scale with whole numbers. I couldnt work out the correct sequence or bit shifts to pass to setobj for the scale size. It has been mentioned in the tutorials for sprite positioning but I just had no luck with it.

 

Eg. If I have a float variable for the distance to the screen then I'd like to translate that to a scale size at runtime. Then perhaps I could have missiles coming at the player , into the screen.

 

So a missile might be a 32x32 sprite and start scaled at size 1. Then I would have a float variable that would gradually increase each frame by 0.25 for example. This needs "translating" to the sprite scale setobj command and set each frame.

 

Thanks in advance for an help

Edited July 19, 2015 by Sporadic

[+CyranoJ]

the scale value is constructed as the following 8 bit value.

 

%xxxyyyyy

 

where XXX = 0-7

and yyyyy=0-31

 

XXX is the integer part so for a 1:1 you would use %00100000 = 32 decimal

YYY is the fractional part so for 1.5:1 you would use %00101000 = 40 decimal

[+GroovyBee]

YYY is the fractional part so for 1.5:1 you would use %00101000 = 40 decimal

In that fixed point notation 1.5 would be %00110000 or 48 decimal.

[+CyranoJ]

Good point, this has been another 6:00am screw up from CJ

[+GroovyBee]

Good point, this has been another 6:00am screw up from CJ

Easy typo to make. If you'd said 1.25 it would have been correct .

[+GroovyBee]

Eg. If I have a float variable for the distance to the screen then I'd like to translate that to a scale size at runtime. Then perhaps I could have missiles coming at the player , into the screen.

Personally I'd avoid floating point operations. They are handled in software so are going to be quite slow. If you keep it 8 bit then every time you add 1 to the scale factor it goes up 1/32. If you aren't familiar with fixed point notation this diagram might help:

 

+------+-----+-----+-----+-----+-----+------+------+
|   4  |  2  |  1  | 1/2 | 1/4 | 1/8 | 1/16 | 1/32 |
+------+-----+-----+-----+-----+-----+------+------+

So to make the fraction 3.09375 you'd do :-

 

=2 + 1 + (1/16) + (1/32)

=3 + (3/32)

=3.09375

 

To make 1.5 :-

 

=1 + (1/2)

=1.5

 

To make 3.33 :-

 

=2 + 1 + (1/4) + (1/16)

=3 + (5/16)

=3.3125 (this is as close as you'll get)

 

The scaling factors might not be exactly the ratio you want e.g. 3.3125 and not 3.33, but they will certainly be be good enough for action games.

[+GroovyBee]

OK, here is a list of the available fractions that are possible and their corresponding hex value :-

 

 

 

0.000000 = 0x0000
0.031250 = 0x0001
0.062500 = 0x0002
0.093750 = 0x0003
0.125000 = 0x0004
0.156250 = 0x0005
0.187500 = 0x0006
0.218750 = 0x0007
0.250000 = 0x0008
0.281250 = 0x0009
0.312500 = 0x000A
0.343750 = 0x000B
0.375000 = 0x000C
0.406250 = 0x000D
0.437500 = 0x000E
0.468750 = 0x000F
0.500000 = 0x0010
0.531250 = 0x0011
0.562500 = 0x0012
0.593750 = 0x0013
0.625000 = 0x0014
0.656250 = 0x0015
0.687500 = 0x0016
0.718750 = 0x0017
0.750000 = 0x0018
0.781250 = 0x0019
0.812500 = 0x001A
0.843750 = 0x001B
0.875000 = 0x001C
0.906250 = 0x001D
0.937500 = 0x001E
0.968750 = 0x001F

 

 

If RB+ doesn't support hex, let me know, and I'll output the numbers in decimal.

[+Sporadic]

Thanks guys for the explainations.

 

Yeah, I've not had to deal with fixed point before. What both of you have said makes sense.

 

I'll have a go and see if I can make some progress.

 

 

cheers.

[+Sporadic]

the scale value is constructed as the following 8 bit value.

 

%xxxyyyyy

 

where XXX = 0-7

and yyyyy=0-31

 

XXX is the integer part so for a 1:1 you would use %00100000 = 32 decimal

YYY is the fractional part so for 1.5:1 you would use %00101000 = 40 decimal

 

 

Personally I'd avoid floating point operations. They are handled in software so are going to be quite slow. If you keep it 8 bit then every time you add 1 to the scale factor it goes up 1/32. If you aren't familiar with fixed point notation this diagram might help:

 

+------+-----+-----+-----+-----+-----+------+------+
|   4  |  2  |  1  | 1/2 | 1/4 | 1/8 | 1/16 | 1/32 |
+------+-----+-----+-----+-----+-----+------+------+

So to make the fraction 3.09375 you'd do :-

 

=2 + 1 + (1/16) + (1/32)

=3 + (3/32)

=3.09375

 

To make 1.5 :-

 

=1 + (1/2)

=1.5

 

To make 3.33 :-

 

=2 + 1 + (1/4) + (1/16)

=3 + (5/16)

=3.3125 (this is as close as you'll get)

 

The scaling factors might not be exactly the ratio you want e.g. 3.3125 and not 3.33, but they will certainly be be good enough for action games.

 

 

These explanations really helped my understanding, so thank you both again.

 

I now have my smooth scaling sprite thanks to RSETOBJ(SPRITENUM,R_sprite_scale_x,scale) where scale is an integer which defaults to 32. Simply increasing/decreasing the scale variable has the effect i'm after. I think before, I was thinking about it too much (or not as it happens) trying to shift the digits or something when passing into the RSETOBJ.

 

Let the scaling commence.....

[sh3-rg]

Well that's all nice and fun and informative and everything, but I honestly CBA handling scale factors in that way. Once I considered the scale variables as a single, whole number, where 32 was the magic number giving a 1:1 representation of my sprite, everything became simple and I said "yeah,eff that binary and bit-bopping bullshit" and that was that. And that's how that dancy girl in the "plasma" screen in CWACOM scaled up... by just adding 1 every x-frames. As simple and crap as the rest of it. Of course, the stuff CJ and GB said is good if you want to scale stuff by definite amounts based on conditions, but I never found a need to do that yet.

 

While I'm here, there's a few "fun" Jaguar "features" when using scaling along with some general stuff to just keep in mind:

 

It's best to create your sprite 1 pixel taller than you would normally and leave the top row of pixels empty. The Jaguar does terrible things to the top row!

 

Scaling just horizontally can be less demanding on the system than vertically as it's still 1 object covering the same amount of scanlines, therefore simple stuff for the OP to handle.

 

Scaling the particle buffer can make for some silly fun stuff, especially if you use multiple objects based on the same source.

 

IIRC Raptor helps out when you flip objects by adding in an offset leaving you with the object you wanted in the place you expect it to appear when displayed regularly/unflipped. When you add scaling in to the mix with flipped objects, curious magic happens... have a play, it's simple to counteract, but can leave you scratching your head if your large objects are actually wrapping around the screen when scaled up and flipped, some real fun WTF moments possible there :0)

 

There's probably more, I haven't touched any of this in 4 months or so and at my age that's getting into having to learn it all over again territory, but looking forward to doing that soon. Well I deffo should chop up CWACOM into a series of little fun tutorials at the very least, that might help keep things a little fresher.

[+Sporadic]

Well that's all nice and fun and informative and everything, but I honestly CBA handling scale factors in that way. Once I considered the scale variables as a single, whole number, where 32 was the magic number giving a 1:1 representation of my sprite, everything became simple and I said "yeah,eff that binary and bit-bopping bullshit" and that was that. And that's how that dancy girl in the "plasma" screen in CWACOM scaled up... by just adding 1 every x-frames. As simple and crap as the rest of it. Of course, the stuff CJ and GB said is good if you want to scale stuff by definite amounts based on conditions, but I never found a need to do that yet.

 

While I'm here, there's a few "fun" Jaguar "features" when using scaling along with some general stuff to just keep in mind:

 

It's best to create your sprite 1 pixel taller than you would normally and leave the top row of pixels empty. The Jaguar does terrible things to the top row!

 

Scaling just horizontally can be less demanding on the system than vertically as it's still 1 object covering the same amount of scanlines, therefore simple stuff for the OP to handle.

 

Scaling the particle buffer can make for some silly fun stuff, especially if you use multiple objects based on the same source.

 

IIRC Raptor helps out when you flip objects by adding in an offset leaving you with the object you wanted in the place you expect it to appear when displayed regularly/unflipped. When you add scaling in to the mix with flipped objects, curious magic happens... have a play, it's simple to counteract, but can leave you scratching your head if your large objects are actually wrapping around the screen when scaled up and flipped, some real fun WTF moments possible there :0)

 

There's probably more, I haven't touched any of this in 4 months or so and at my age that's getting into having to learn it all over again territory, but looking forward to doing that soon. Well I deffo should chop up CWACOM into a series of little fun tutorials at the very least, that might help keep things a little fresher.

 

Haha, a big yes to this. It does seem that I didn't need to know the theory in the end. But I always appreciate that side of things so it's good to know.

 

I have the scaling working now I think. The origin is in the top left so I did have to work out the ratio/percentage of the current scale to 1:1 then adjust the x position by half-width multiplied by that ratio. It looks accurate and fast so hopefully it will be ok.

 

Some of the stuff I have in mind will only need the x-scaling, so it's good to know the performance gains. Thanks!

 

I would be interested to see the source/tutorials from the "Cloudy" demo. I did think that was pretty cool.