IGNORED

# Frustration with bB decimal numbers

## Recommended Posts

I'm having trouble figuring out why the black car is not turning in a circle with the following code. The operations around variable p2dir are not working as expected. Can anyone see what I'm doing wrong?

##### Share on other sites

Not sure if this would work for you or not, but why not skip decimal and do everything in integers that are 100 times your decimal values, then divide down by 100 when you need to...

For example, instead of saying y=y+.78

Make it y=y+78

Then when you actually want to set the sprite value, do something like player0y=y/100

Does this make sense? The code will execute faster and should be smaller, too... (careful of rounding, though, you will have to adjust for that). If you can adjust your code so that you divide by a base 2 number, that's even better 'cos you won't need a module...

Just a quick thought after very briefly reviewing your code...

Thanks,

Mike

Edited by lord_mike
##### Share on other sites

I'm having trouble figuring out why the black car is not turning in a circle with the following code. The operations around variable p2dir are not working as expected. Can anyone see what I'm doing wrong?

Anytime you assign a value to a fixed point variable, it needs to contain a decimal.

For instance, p2x=143 will not work - it needs to be p2x=143.0. But now that I've mentioned it, I now see that this is kind of a stupid requirement. I'll see about making it work without the .0 at the end.

Also, you don't need the fixed_point_math.asm module for what you are doing. It's only needed in certain special circumstances - see the bB manual for more information.

##### Share on other sites

I see something else - p2dir is a 4.4 fixed point type (which is probably the core of the original problem.) It's not clear why you need a 4.4 type for p2dir, as its value seems to only be 1-16, right? That, and 4.4 types are only valid from -8 to +7.9-something.

(Also, when used in a conditional statement, 4.4 types are multiplied by 16 so they can be used as normal integers, so the conditional statements wouldn't work anyway as shown.)

##### Share on other sites

I see something else - p2dir is a 4.4 fixed point type (which is probably the core of the original problem.) It's not clear why you need a 4.4 type for p2dir, as its value seems to only be 1-16, right? That, and 4.4 types are only valid from -8 to +7.9-something.

(Also, when used in a conditional statement, 4.4 types are multiplied by 16 so they can be used as normal integers, so the conditional statements wouldn't work anyway as shown.)

Great info. Thanks! This would be really helpful to have here:

http://www.randomterrain.com/atari-2600-me...ds.html#decimal

##### Share on other sites

Not sure if this would work for you or not, but why not skip decimal and do everything in integers that are 100 times your decimal values, then divide down by 100 when you need to...

For example, instead of saying y=y+.78

Make it y=y+78

Then when you actually want to set the sprite value, do something like player0y=y/100

Does this make sense? The code will execute faster and should be smaller, too... (careful of rounding, though, you will have to adjust for that). If you can adjust your code so that you divide by a base 2 number, that's even better 'cos you won't need a module...

Just a quick thought after very briefly reviewing your code...

Thanks,

Mike

That's a good idea for the direction (p2dir) var. I'll change from a 4.4 to just using a regular non-decimal 8 bit number and divide/add 1 to get 1-16.

For player coordinates though, since there are 4 players the max range of any 8 bit unsigned number is 255, and p2x, p2y, p3x, p3y, p4x, p4y, p5x, and p5y vars represent the coordinates of those then that wouldn't work right? (BTW- the reason the varnames contain 2-5 instead of 0-3 or 1-4 is because originally it mapped to their multisprite player numbers).

I did think about just adding 3, 7, or 10 to the player coordinates (p2x, p2y, etc.) and I may end up doing that to save variables. However gameplay will be way too fast I think and won't be very smooth. I could also do 1, 3, 5 for a "slower" speed but that might be really rough looking. I'm guessing that's what I'll have to do in order to save variables for other things.

##### Share on other sites

That's a good idea for the direction (p2dir) var. I'll change from a 4.4 to just using a regular non-decimal 8 bit number and divide/add 1 to get 1-16.

For player coordinates though, since there are 4 players the max range of any 8 bit unsigned number is 255, and p2x, p2y, p3x, p3y, p4x, p4y, p5x, and p5y vars represent the coordinates of those then that wouldn't work right? (BTW- the reason the varnames contain 2-5 instead of 0-3 or 1-4 is because originally it mapped to their multisprite player numbers).

I did think about just adding 3, 7, or 10 to the player coordinates (p2x, p2y, etc.) and I may end up doing that to save variables. However gameplay will be way too fast I think and won't be very smooth. I could also do 1, 3, 5 for a "slower" speed but that might be really rough looking. I'm guessing that's what I'll have to do in order to save variables for other things.

If you want to save variables, you can use the sprite position variables as the integer portion and save at least 8 variables in your code (possibly more.)

dim p2x=f.g
dim p2y=h.i

...

player0x=p2x
player0y=p2y

Just do this:

dim p2x=player0x.g
dim p2y=player0y.i

And you not only save variables, there isn't any need to copy them over.

##### Share on other sites

Just do this:
dim p2x=player0x.g
dim p2y=player0y.i

And you not only save variables, there isn't any need to copy them over.

Great idea!

Michael

##### Share on other sites

Just do this:
dim p2x=player0x.g
dim p2y=player0y.i

And you not only save variables, there isn't any need to copy them over.

Great idea!

Michael

Does this work even if player0 and player1 sprites are being reused, since I'm not using multisprite kernel?

I'm guessing it does now that I look at it. Man, that is a great idea.

I had been considering switching around on each frame like this to be able to handle collision detection between the 4 players sharing the 2 player sprites like:

frame 1: show p2 and p3 as player0 and player1 sprites (and check for collision)

frame 2: show p4 and p5 as player0 and player1 sprites (and check for collision)

frame 3: show p2 and p4 as player0 and player1 sprites (and check for collision)

frame 4: show p3 and p5 as player0 and player1 sprites (and check for collision)

frame 5: show p2 and p5 as player0 and player1 sprites (and check for collision)

frame 6: show p3 and p4 as player0 and player1 sprites (and check for collision)

but I think the flicker would have been too bad for some player sprites if I did that, and I think the benefit of getting more variables freed up with the method described is worth the lack of good collision detection between the 4 cars.

Edited by Fort Apocalypse
##### Share on other sites

Does this work even if player0 and player1 sprites are being reused, since I'm not using multisprite kernel?

Actually it looks like this couldn't work if you are reusing player0 and player1 sprites. Rats.

## 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.

×   Pasted as rich text.   Paste as plain text instead

Only 75 emoji are allowed.