Jump to content
IGNORED

Zooming and scaling with rB+


Recommended Posts

I am trying to make a burger zoom towards the screen

 

in the rapapint.s file the scaling is set to spr_scale. The X and Y factors are set to 32 by default.

 

 

Here is what I have tried:

 

RSETOBJ(burger, R_sprite_scale_x, 16)
RSETOBJ(burger, R_sprite_scale_y, 16)

 

This just sets the scale factor to 16 making it smaller and it stays that way. I want to start at a scale factor of 16 and go up by 1 each frame

 

RSETOBJ(burger, R_sprite_scale_x, (burger, R_sprite_scale_x+1))
RSETOBJ(burger, R_sprite_scale_y, (burger, R_sprite_scale_x+1))

 

RSETOBJ(burger, R_sprite_scale_x, (burger, R_sprite_scale_x+1<<16))
RSETOBJ(burger, R_sprite_scale_y, (burger, R_sprite_scale_x+1<<16))

 

These 2 just make the burger instantly become giant.

 

I have tried other variations of these too, with no luck^^^^

 

 

Next I tried setting up a subroutine and calling on it by pressing 9. It looked something like this:

 

sub scaleburger


IF zoomtimer=0 THEN
RSETOBJ(burger, R_sprite_scale_x, 16)
RSETOBJ(burger, R_sprite_scale_y, 16)
ENDIF
IF zoomtimer=2 THEN
RSETOBJ(burger, R_sprite_scale_x, 17)
RSETOBJ(burger, R_sprite_scale_y, 17)
ENDIF
IF zoomtimer=4 THEN
RSETOBJ(burger, R_sprite_scale_x, 18)
RSETOBJ(burger, R_sprite_scale_y, 18)
ENDIF
IF zoomtimer=6 THEN
RSETOBJ(burger, R_sprite_scale_x, 16) (<------------Note this crap is really long. I don't like this, plus it doesn't work anyway)
RSETOBJ(burger, R_sprite_scale_y, 16)
ENDIF
IF zoomtimer=8 THEN
RSETOBJ(burger, R_sprite_scale_x, 20)
RSETOBJ(burger, R_sprite_scale_y, 20)
ENDIF
IF zoomtimer=10 THEN
RSETOBJ(burger, R_sprite_scale_x, 21)
RSETOBJ(burger, R_sprite_scale_y, 21)
ENDIF
IF zoomtimer=12 THEN
RSETOBJ(burger, R_sprite_scale_x, 22)
RSETOBJ(burger, R_sprite_scale_y, 22)
ENDIF

YOU GET THE IDEA IT GOES ON AND ON (Wasteful)


end sub

 

 

zoomtimer++ is in the main game loop

 

zoomtimer% :zoomtimer=0 is in DIM

 

The only thing this does is make the burger scale to 16 and stay that way.

 

 

I am posting here because perhaps there is a different approach to this effect I have not considered. Any tips would be much appreciated.

 

 

Thanks in advance!

Edited by Jeffrey_Bones
Link to comment
Share on other sites

There are several errors I can see straight off, and I'd suggest you might want to invest some time in learning how to do debugging.

 

1. RSETOBJ(burger, R_sprite_scale_x, (burger, R_sprite_scale_x+1)) - now as the third parameter you are trying to pass has to be in the range 0 - 255, what do you actually think the (burger, R_sprite_scale_x+1) will give you? [hint: it isn't the current value plus 1]

 

2. RSETOBJ(burger, R_sprite_scale_y, (burger, R_sprite_scale_x+1<<16)) - much like #1 but this time even worse. You have tried shifting the old value, which you are not going to be getting anyways, left by 16 bits. It fails at that too as you have not followed the rules of operator precedence so a shift/multiply/divide would be carried out before addition i.e. you've tried adding 1 shifted left 16 times to it. i.e. 0. If it has the same result as attempt #1 it means you are using the wrong value.

 

3. sub scaleburger

IF zoomtimer=0 THEN
RSETOBJ(burger, R_sprite_scale_x, 16)
RSETOBJ(burger, R_sprite_scale_y, 16)
ENDIF
IF zoomtimer=2 THEN etc.....

 

Apart from being bad coding practise (as all IF statements will be calculated even if you match at the first one), the fact it sets the first size correctly means that zoomtimer is set to 0 at some point but not being incremented between calls to the subroutine. I take it you've actually checked the value when the subroutine is called. i.e. you are almost certainly re-initialising the variable inside the main loop.

 

The code option shown by atari2600land is much better but needs checking for max scale AND should only rsetobj the scale values inside the if statement - i.e. when the scaling changes. (it also does it every 4th frame instead of 2 in your version)

  • Like 3
Link to comment
Share on other sites

I agree with Welshworrier's way of replying: without the slightest hint of irony or partonising from me you really need to step back a bit and read up/practice general programming a bit more if you're having these kinds of problems. I'll also say that the basic dialect (and virtually all languages out there) didn't add PRINT statements for fun (and indeed it took a major amount of effort to add a proper print routine in rb+) so you should be using it more.

 

One final thing: an excerpt from the bcx manual (bundled with rb+) because "<<" seems to be confusing you. It's not a magic operator that makes things work, it's just this:

 

<< bitwise left shift left-to-right

>> bitwise right shift

And if this still seems cryptic to you, it's multiplying or dividing the number with powers of 2. So <<2 will multiply your number by 2^2=4, <<16 multiplies by 2^16=65536, >>4 divides by 2^4=8 etc etc.

Link to comment
Share on other sites

I agree with Welshworrier's way of replying: without the slightest hint of irony or partonising from me you really need to step back a bit and read up/practice general programming a bit more if you're having these kinds of problems. I'll also say that the basic dialect (and virtually all languages out there) didn't add PRINT statements for fun (and indeed it took a major amount of effort to add a proper print routine in rb+) so you should be using it more.One final thing: an excerpt from the bcx manual (bundled with rb+) because "<<" seems to be confusing you. It's not a magic operator that makes things work, it's just this:And if this still seems cryptic to you, it's multiplying or dividing the number with powers of 2. So <<2 will multiply your number by 2^2=4, <<16 multiplies by 2^16=65536, >>4 divides by 2^4=8 etc etc.

Ok ggn.

 

 

btw, I got it to do what I wanted it to do. Using a variation of my long method above. Welshworrier was right in that the zoomtimer was staying at zero. The burger now scales towards the screen every 4 frames. Its sluggish and I dont really see how Im going to have more than one obiect doing it this way as its going to be additional lines of code which everyone here including myself agrees the long list of IFs and ENDIfs is just a bad way of setting up the code. I will just have to come up with something better

Link to comment
Share on other sites

  • 2 weeks later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

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