Null Math loops, slops, curves, that sort of stuff (GM 4,5& 6)

[null1024]

By null math, i mean little to no trigonomics, little to no sine calculations, something that a Neandherthal or a Cro-Magnon may understand.

My 2 cents:

------------------
For 45° slopes
In Slope Create event:
execute a piece of code: raiseamount=(Whatever speed you want)

In Slope right key event:
set SonicObj.x+=raiseamount
set SonicObj.y+=raiseamount
set SonicObj.sprite_index=spr_RunR
-----------------

There you go.

[Kain]

If you want a truly 360 degree engine than making it "without math" is going to be 100 times more complicated than with math. Trust me.

But simple slopes are extremely easy without math:

//Move Left and Right
if( xspeed > 0)
{
   repeat( xspeed )
   {
      if(collision_right() ) { xspeed=0; break;}
      x += 1;
   }
}
else
{
   repeat( -xspeed )
   {
      if(collision_left() ) { xspeed=0; break;}
      x -= 1;
   }
}

//Slope Movement
repeat(20)
{
   if( !collision_bottom() ) break;
   y += 1;
}
repeat(20)
{
   if( collision_bottom() ) break;
   y -= 1;
}

Collision left right and bottom should correspond to the red, yellow, and blue dots respectively:

[Damizean]

Well, it's the same thing, just you have to change both coordinates Though, I don't like using an x_speed loop, it's not as precisse when going at low speeds than just adding the x_speed.

[Kain]

That's why I use this little thing as suggested by Smidge some while ago:

//Calculate leftover fraction, so that you only have to deal with an
//intiger movement speed, but don't lose decimal precision smoothness
fractionx += spd;
xmov = fractionx div 1;
fractionx -= xmov;

fractiony += grav;
ymov = fractiony div 1;
fractiony -= ymov;

And act with x/ymov

[Smidge204]

By null math, i mean little to no trigonomics, little to no sine calculations, something that a Neandherthal or a Cro-Magnon may understand.

My 2 cents:

------------------
For 45° slopes
In Slope Create event:
execute a piece of code: raiseamount=(Whatever speed you want)

In Slope right key event:
set SonicObj.x+=raiseamount
set SonicObj.y+=raiseamount
set SonicObj.sprite_index=spr_RunR
-----------------

There you go.

This only works because the slope of a 45 degree incline is 1. Although it is an intelligent way to handle that specific case, it is useless for all other cases. If all you have are 45 degree slopes, then by all means do it this way.

Even if you have a very limited number of slopes, you can pre-calculate the movement ratios. Providing you can tell what the slope is, you can apply the proper ratio.

Ratio table for 15 degree increments is attached.

=Smidge=

[null1024]

wow, alot of this is very brilliant.

[VectorSatyr]

And obviously, you don't get it.

*points at topic title*

[Smidge204]

*Points out to AeroGP that null1024 is the guy who CREATED the topic.*

=Smidge=

[VectorSatyr]

Whoopsie! 0_0;

Anyways, I was just pointing out the hypocracy in that last message; isn't this thread supposed to archive simple code? I wouldn't call any of this "brilliant," by that sense.

[null1024]

Ok, mabye only Smidge's post was easy to understand/impliment.

[Kain]

AeroGP: I will grant that it's a topic that's not difficult enough to spawn many truly "brilliant" solutions, but in coding, "simple" is in no way an antonym for "intelligent" or "brilliant."

null1024: Buh? You understand Smidge's suggestion more than anything else here? That's kinda hard to believe considering you claimed no knowledge/use of trig, but if you say so...

[null1024]

That's kinda hard to believe considering you claimed no knowledge/use of trig, but if you say so...

Umm... I never said that, I simply find it hard to understand. I use it, personally. (but on very rare occasions...)

[VectorSatyr]

While we're on the subject, I ENJOY trig. I especially enjoy when my fellow classmates complain about having to take it. It's so funny, and yet I find myself unable to laugh about it during school hours...

HA HA HA HA... [/only once]

[null1024]

Aero... you scare me.

Back on topic:

Collision Event with object slope:
if expression keyboard_check(vk_right) is not true
      set the gravity to 0 in direction 0
      set variable s_jump to 0
      move in direction direction at most speed till a contact with solid objects
      set the vertical speed to 0
else
      set the sprite to slopeRun with scale factor 1
      set the vertical speed to -Y slope movement
      set the horizontal speed to -X slope movement

And you correctly plug in the values.

[VectorSatyr]

Question: how much precision does a Sonic game NEED? Would geometry be too much? Would I miss out on something by using these functions?

[null1024]

Question: how much precision does a Sonic game NEED? Would geometry be too much? Would I miss out on something by using these functions?

In *some* cases, yes. Mainly because theese functions would give precison equal to Sonic Pocket Adventure with it's line based slopes.

[VectorSatyr]

ic... back to trig, then.

[null1024]

Of course, I don't need that much precision.

[Kain]

Trig isn't about precision at all. It's about adding a new depth to the movement engine. You could argue that using trig functions gives precision over methods such as "y+=1; x+=1;", but that small bit of code is, itself, trig--albeit in a very rudementary form.

Without trig, you have pretty much just have a 4-directional engine. It won't be less precise (actually much more precise since you don't need to deal with decimals), but it won't be able to loop or quarter-pipe. It'll have a more Old Mario feel (but even they had slope acceleration).