skidding effect for player0

[abaudrand]

Hi,

I'm trying to create a skid effect for the player0: like Halo or the original Super mario bros, when you go left or right, there is a variable to make you slide a bit further depending how long you were going to a direction.

I thought something like

 

Left

 

playerx=playerx-c:if c=0 then skip else c=c-1

 

Right

 

playerx=playerx+c:if c=0 then skip else c=c+1

 

 

Still

 

if c>1 then playerx=playerx+c

if c<0 then playerx=playerx-c

 

 

Do you think there is a better way to do it?

[+Random Terrain]

I haven't tried doing this stuff yet, so I don't have any experience with it, but this thread might help:

 

http://www.atariage.com/forums/topic/139926-horizontal-friction-and-acceleration/

[abaudrand]

thanks, I'll have a long study of it tonight.

Regards Random Terrain.

 

 

[abaudrand]

Thanks for the thread Random Terrain. I've tried to put the code from jrok into my game with little modification but each time I go to right, the player never stops. Damn mathematics...

[+Random Terrain]

Thanks for the thread Random Terrain. I've tried to put the code from jrok into my game with little modification but each time I go to right, the player never stops. Damn mathematics...

I'm not good at this stuff, but I could play around and see if I can get something to work later on today.

[abaudrand]

Thanks but I will try to rewrite my code tommorow and hope my mind will be more clear (which I doubt). The code of Jrok works perfect for his program so I guess I've missed something in mine. I'm still working on Dragons' Nights: Done a map for changing quest, add a gameover title and now designing the IcyMountain screen and I'm stuck with my archer sliding right off the screen. I guess my problem is the same as it's tough to understand that +255 equals -1 (or something close to it)

[+Random Terrain]

I guess my problem is the same as it's tough to understand that +255 equals -1 (or something close to it)

I still don't understand that. So if I want my variable to be 255, it's not 255? It's actually -1? Very strange. I use the info to make a program do what I want, but I still don't understand it.

 

In real life, if I could shoot an arrow 255 feet, it would be 255 feet in front of me. It wouldn't magically appear a foot behind me. And when you count down from 255, when does it stop being a negative number? Weird.

[+RevEng]

The interesting thing about your arrow analogy, is it can be modified to be analogous to the way 6502 byte arithmetic works.

 

If the universe was only 256 feet long, and you shot your arrow 255 feet, it would wind up 1 foot behind you. (assuming space curves back on itself.) You'd also be wise not to shoot the arrow 257 feet.

 

Similar to the arrow in our 256 foot universe, when you keep adding one to a byte and it reaches the 255 limit, it starts over again at 0 and continues up.

 

In this kind of system, you can treat bytes as if they were from 0<->255 *or* from -128<->127, depending on which suits your needs. Mainly this is handy in assembly code - one example is when you want to check if a number has become less than zero.

 

To answer your question about counting down from 255, the number stops being negative when the you reach 127. (but "stops having the same representation as negative numbers" is probably a more accurate way to describe it.)

[+Random Terrain]

The interesting thing about your arrow analogy, is it can be modified to be analogous to the way 6502 byte arithmetic works.

 

If the universe was only 256 feet long, and you shot your arrow 255 feet, it would wind up 1 foot behind you. (assuming space curves back on itself.) You'd also be wise not to shoot the arrow 257 feet.

 

Similar to the arrow in our 256 foot universe, when you keep adding one to a byte and it reaches the 255 limit, it starts over again at 0 and continues up.

 

In this kind of system, you can treat bytes as if they were from 0<->255 *or* from -128<->127, depending on which suits your needs. Mainly this is handy in assembly code - one example is when you want to check if a number has become less than zero.

 

To answer your question about counting down from 255, the number stops being negative when the you reach 127. (but "stops having the same representation as negative numbers" is probably a more accurate way to describe it.)

Thanks. Can you explain one more thing? If I had a for-next loop that went from 1 to 255, why doesn't it step forward half way, then step backwards the other half?

[+RevEng]

A quick definition to make the language easier. The two number representations we're talking about are usually referred to as "signed" (for a byte, -128 to 127) or "unsigned" (for a byte, 0 to 255).

 

The slightly shorter answer to your question...

 

The 6502 doesn't really know about numbers being signed or unsigned. The numbers are laid out in such a way that the math will work out the same from a binary perspective.

 

If you're not doing anything in the context of signed numbers, you should consider the numbers as being unsigned. So your loop from 1 to 255 is just a loop from 1 to 255.

 

If you do something like "if mynum<0 then goto someroutine", then you are treating mynum like a signed number, and you should probably consider stuff like 255 is the same as -1, and that a signed number rolls after 127 instead of 255.

 

The longer answer to your question...

 

The 2 number representations, signed and unsigned, are mapped out in such a way that the arithmetic works out the same whether you think of the number as signed or unsigned, with the exception of the limits where the numbers roll-over. (i.e. from 0<->255 or -128->127)

 

This mapping system is called two's complement.

 

Here's a quick summary of how unsigned and signed values are mapped out in two's complement...

 

Signed  Unsigned  Binary
 0         0       00000000
 1         1       00000001

         ...

127       127       01111111
-128      128       10000000
-127      129       10000001

         ...

-2        254       11111110
-1        255       11111111

 

The CPU actually doesn't actually know or care if your program is expecting to use a number as signed or unsigned. It just adds up everything in binary, and leaves the signed/unsigned context up to you.

 

Consider the signed expression "-2 + 1 = -1" and the unsigned version of the same expression "254 + 1 = 255". The binary math works out fine whether you treat the numbers as signed or unsigned.

 

So for your loop from 1 to 255...

 

The CPU just counts from 00000001 to 11111111.

From an unsigned context, the loop looks like it goes from 1 to 255.

From a signed context, the loop looks like it goes from 1 to 127, then rolls over, and goes from -128 to -1.

 

But remember that the actual context comes from the way your code treats the number. It's a bit weird to loop from 1 to 255 and do tests for negativity and other stuff that would imply signed values, so you really wouldn't be thinking in terms of signed values as you coded this loop.

 

Hopefully this has helped, and we haven't had more worms escaping from the can!

[+Random Terrain]

Hopefully this has helped, and we haven't had more worms escaping from the can!

Thanks. I wouldn't be able to explain it to somebody else in my own words, but I understand it enough to stop wondering about it.

[abaudrand]

thanks for the lesson RevEng. I guess it will help many readers but it still weird for me. I will study it next week till it ring a bell in my low-frequency budbrain ...