Slope Physics Tutorial
Well basically I hate slope physics. So in order to help myself figure out what the hell is going on here, I’m going to write a tutorial! Makes perfect sense. Let’s get started. First, a little background. If you are relatively well-versed with physics in an Axe environment, you can skip this part.

Part 1: Gravity.
First off let’s introduce the concept of gravity. Universal force that acts downwards. All objects fall at the same rate; or rather they all accelerate at the same rate. According to Newton, Force=mass*acceleration. More force=more acceleration. In real life, the acceleration of gravity is about 9.8 meters/second/second. Which makes sense: meters/second is a measure of speed, so meters/second/second is a measure of acceleration.
In our game world, we’ll set gravity to whatever quantity we want.

Part 2: Integer Math
Well, we’ve got no decimals. That is certainly a problem. Well, to simulate decimals, we can inflate all our values by a certain number. The standard is 256, although theoretically you could use any value. How does this work?...Let’s go with an example. Let’s do a simulation of an object being affected by gravity!
We want the y position to accelerate every time, so let’s set up the following code with gravity being 1 pixel:
0->Y
Repeat getKey(15)
ClrDraw
Y+1->Y
Pxl-On(5,Y)
DispGraph
End


Wait, but that’s way too fast! Let’s try the same example, but with inflation of values by 256
0->Y
Repeat getKey(15)
ClrDraw
Y+1->Y
Pxl-On(5,Y/256)
DispGraph
End
See? Each time you add 1, it’s like you’re adding 1/256th of a pixel….Anyway, let’s move on to…

Part 3: The Slope

So now, let’s draw a diagram of all the forces acting on an object on a slope. Forces are vectors; in other words, they are numbers with direction. And they can be split into different components.

 Remember, sin is opposite/hypotenuse, and cos is adjacent/hypotenuse.

Now, we can see that the force dragging an object down a hill is equal to the force of gravity times the sine of the angle. Remember that F=ma, so the force of gravity is mg. In games, unless you’re planning to change the mass, I would set it to 1 for simplicity’s sake. So we get F=g. Easy enough. The force that pulls you down the hill is equivalent to gsinθ, with the direction of θ. The Fn up there is called the normal force. Basically, it just cancels out the y-component of gravity, which is why we don't talk about them much.

Notating Vectors
We can either express vectors in component, or in magnitude+direction formats. In games, it is more common to store vectors as components, so let’s start with that.

The problem is, how do you increment your objects’ velocity diagonally? Well, let’s move on to some more trig….

And there you have it. Every frame, increment x velocity by gsinθcosθ and y velocity by gsinθsinθ
But wait…Is it really that simple?

Part 5: Applying this concept in an Axe environment
Here is the tricky part. Axe sets us up with a great coding environment designed on speed and efficiency. Unfortunately, this means no decimals. Which is a HUGE problem.

Axe’s sine and cosine functions are a little bit different from your traditional sine and cosine functions. First of all, they use a system of binary degrees Basically, one period or revolution is 256. You can use the conversion factor of 32/45 to convert from traditional degrees to binary degrees, or a factor of 128/π to convert from radians.
Degrees | Radians | Circle | Binary Degrees
0       | 0       | 0      | 0
45      | π/4     | 1/8    | 32
90      | π/2     | 1/4    | 64
180     | π       | 1/2    | 128
270     | 3π/2    | 3/4    | 292
360     | 2π      | 1      | 256But that’s not the end of our problems. Since there are no decimals, Axe’s sine and cosine functions have an amplitude of -127 to +128 (or something like that, I don’t remember the exact limits). Take a look:
Degrees | sin | cos | Axe sin | Axe cos
0       |  0  |  1  |     0   |   128
30      | .5  | .87 |    64   |    93
45      | .71 | .71 |    53   |    53
90      |  1  |  0  |   128   |     0
180     |  0  |  -1 |     0   | 65409
270     | -1  |  0  | 65409   |     0Basically, the decimals that the traditional sine and cosine values output are multiplied by 256, rounded off, and then have the value 128 subtracted from them.
So how do we apply this in Axe?
G*sin(θ)//128*sin(θ)//128 || G*cos(θ)//128*sin(θ)//128
It’s messy, but at least it works.

Part 6: Wait! How do I figure out the angle?
Ah, I thought you’d never ask.
Well, there are a few ways to do this. In traditional math and physics, we have this handy tool called the inverse tangent function. Unfortunately, we don’t get that in axe so....

Method 1: Tilemap.
Yay! Everybody loves tilemapping. Fast, easy, etc. Basically, all you have to do here is give each tile an angle associated with it. Then, if you detect that your player is *on* the tile, apply the slope physics. I would use pixel testing for collision here.
How do you figure out what tile you’re standing on? Well first, make sure you’re standing on something….If not, apply gravity. Otherwise….
{Y/8+8*(map width)+(X/8)+(pointer to map location)}should give you the tile you are standing on

Method 2: Pixel based method
This method is a bit more complex.  Basically, we shall look at the two pixels directly below us to determine the angle of the slope.

(The numbers in parentheses are binary degrees) Then, we’ll store this information in a lookup table (LUT)  since we don’t get a tan^-1 function….
Data(51+64,45+64,32+64)
Data(0,32,45,51)->GDB1I believe that this method works because the lines on the screen are all pixelated anyway. The total slope physics generated will all average each other out.
Note: This method can be easily adapted to memory reads instead of pixel tests if for some reason you have pixel heights stored in memory. Also, it may be easier for some to store the precomputed sin and cos values instead of the angle, for possible increased accuracy or speed.
.Note- make sure this runs before your sprite is drawn on screen
0->{L1}^^r
For(B,0,1)
For(A,0,7)
If pxl-Test(X+B,Y+A-3)
A-3->{B+L1}
End
End
End
{{L1}-{L1+1}+GDB1}
.^^this returns the angle value

Part 7: Multiple or Dynamic Slopes
All right, now we know how to deal with one slope. But what about slopes that change direction and stuff? Here is the time to use the other notation for vectors: magnitude-angle.

Basically, it’s relatively straightforward. Remember how the acceleration on the ball on the slope was Gsin θ? Well, changing the velocity with magnitude-angle notation is *almost* as simple as just adding gsinθ to the speed (S). Then, you have to store theta somewhere as the angle. To retrieve the x and y velocities, we can break the speed back into components: X speed=Scos θ and the Y speed= Ssin θ

However, one tricky part is that the acceleration angle and the velocity angles are not the same. Do not rely on using the same angle for both of them, as that will turn out…not so pretty. Here’s an example of what it might look like…

Correcting this problem, we get this


(Credit to Runer112 on the concept on how to make this hilly terrain)

…And that’s all I have for now
As I learn more, I’ll add more; Future additions include collision with an angled surface, and flying and other random stuff. Happy programming!

I like your graphics, though unfortunately it seems to be suffering the same problem as every grayscale scrolling game

Also, have you considered making the player sprite masked? (Sorry if this was mentioned, I didn't read the whole thread)

No comment on the plot lol. Although I was kinda suspicious since the phrase "jill off" is...pretty nsfw if you know what it means (although no one uses that term anymore haha)

I can't do pics, but I'll give a narrated tour of my room

Upon entering, the thing you'd notice first is the electric violin and its amplifier . Behind that lies my viola (traditional acoustic) and a music stand. On the music stand is an arrangement of JerryC's Canon Rock transcribed for violin. On the floor are bits of random sheet music, among them the Goldenrod City theme and Bach's 6th Brandenburg concerto. Next to the amplifier is a mess of cables including my phone and gameboy chargers. Looking back behind you towards the door, you'll see a couple of wooden 2x4 boards. I don't know how they got there. To the right, you see Pokemon Yellow on the floor. Further right is my closet. It's a veritable mess, some notable items include my boy scout uniform and OA sash along with several pairs of swim suits. Turning back around (standing in front of the closet) we can get a good look at my bed. In front of it lies a few textbooks and a large mess of papers. Further inspection reveals them to be a mix of Ash:Phoenix documentation and guitar music. On my beside shelf you can find coins, a wallet, a playbill, Pokemon Sea Blue Edition, a knife my ipod and calc, an alarm clock, light, and lots of manga. To the right is a little nook area semi hidden from the rest of the room. Here is a couch with lots of pillows (chill area), and my desk. My desk chair is stacked full of college spam mail. The drawers next to my desk are overflowing with papers. In the corner you can find swim caps, goggles, and my guitar (acoustic). On my desk we find a myriad of art supplies and a rubix cube.

And that's my cave

SirC's flood-filler would probably be easily modifiable to make grayscale.

IIRC the Circle() routines are coded in such a way that it is very difficult to make it draw on the back buffer.

For For() loops, just use a While loop instead and increment manually, it probably is just as optimized anyway.

As for the flickering on the grayscale, I think Deep Thought already mentioned going across the screen by rows instead of columns as per thepenguin77s grayscale tutorial, so I'll just remention that again

And now I have something I want to say...
People, this has kind of been bugging me. Feature-request-wise, remember that Quigibo is really busy. Complex routines are hard to put in, and most of the time they can easily be written in Axe anyway with a few commands (like the for() and the paint bucket thing). Figure out how to do it yourself; don't just ask for a feature request because you don't want to take the time to code your own routines. Another example: grayscale. Are you really complaining that the shades of gray are too dark/light? It's freaking grayscale on a monochrome screen. Seriously, any asm programmer will tell you that grayscale is a huge pain to program correctly and IMHO we should be grateful that we have it as good as it is. I'm talking to everybody here. I feel like some people are taking Quigibo for granted, and imo something like a paint bucket is in no way really important enough to merit its own command. Something like bit-manipulation, label-addresses or switch-statements or big-endian nibble reads hint hint hint are more appropriate candidates for feature requests. And did someone really ask for multitasking?

I guess what I'm really trying to say, is just try and think about what you are asking for before you post, and whether or not it's practical. Then think about how you could code it; a lot of things are not difficult to code by hand anyway. Some languages don't even have for() loops, for example. And when you do post, try to explain what you are talking about. Not everyone knows what the phrase "stateful goto" or "try/catch" means.

Sorry to rage like this but I felt the need to say it. No offense to anyone intended. Also I do not want to start any kind of war or fight so if you have a problem with this, rate it down and pm me. Leave it off the forums, thanks 

That's what I'm doing now lol

basically, find square root of v^2+w^2 without using that formula.

All right.

We've got an X-velocity (v) , and a Y-velocity (w) that can both get pretty large (ie, past 256). What's the best way to calculate the total speed (a scalar number) while maintaining at least some accuracy? Pythagorean theorem is out because squaring a number greater than 255 will go over our 65535 limit. (If anyone wants to give me assembly hex that's cool too )

On the Lighter Side



http://www.omnimaga.org/index.php?action=downloads;sa=view;down=641