How would you implement collision for a 2D side scrolling game so it could handle pic related slope types?

How would you implement collision for a 2D side scrolling game so it could handle pic related slope types?

Other urls found in this thread:

youtube.com/watch?v=ixwQEQRiFhM
youtube.com/watch?v=IysShLIaosk
info.sonicretro.org/Sonic_Physics_Guide
twitter.com/SFWRedditImages

Pay a Pajeet to do it for me.

How much would mr. Pajeet want for that though? And how good is the code quality?

use a physics engine

Check if your next frame puts you in a collision. If it's does, move you back.

lots of tiny cubes

How are you handling types? Wouldn't it be easy to just test for slanted tile types and add movement based on the angle of the tile? And, assuming you're managing tile maps like that, you can just predefine angles and data, especially if its stored in JSON or some shit. As for collision, go look up some basic trig

quadtree

There are a few articles that explain how the old 2D Sonic games handled their physics. They're quite interesting and might help you, OP.

You can calculate everything using high school analytic geometrics. Most of the stuff will be made up of (rotated) rectanges and circles, anyway

Just use a physics engine.

Bitmap collision detection.

youtube.com/watch?v=ixwQEQRiFhM

Thanks captain obvious

How do you implement that though

man, you're a stupid piggot, it's basic trig shit you can even do it with modular arithmetic because any operation done in a computer is done (mod 2^64) if the PC is 64bit

I recommend you this method which doesn't correct collisions, rather it prevents them.

youtube.com/watch?v=IysShLIaosk

He explains in detail how it works but basically when your abs(pos) + 1 meets a wall then your speed is set to 0.

I am not sure about slope handling but you can probably figure that out; this way of handling collision is the best in my opinion.

google slope collision faggot

what language are you writing this in?

Slopes? You need to calculate derivatives and integrals, my friend. If you aren't a brainlet you can do it.

t. Genius who can fully comprehend Calc I, II and III AND IV

>what is a triangle

is that a new dragon dildo?

Reserve a specific pixel color for collision surface or maintain a separate collision mask.

>you can even do it with modular arithmetic
Eh?

Tunneling

how I did it my game is
>try to move player forward, if you end up in the air, move player down one or two pixels (however steep your slopes can be) to be on the ground to go down a slope
>instead of moving the player back when colliding, try to move them up a couple pixels to go up a slope
it isn't that hard to implement unless you're retarded

info.sonicretro.org/Sonic_Physics_Guide
This right here is a gold mine of 2d physics info. The article on solid floors alone is more than enough to build your character on.

Well you write it in your programming language of choice
and then you run it

I've thought about this, my favorite solution is to mark the tile as "special" and give it a slope factor (essentially: Y/X) (this could be generalized as having all tiles have a slope factor, the horizontal ones would be just 0).
Upon entering the collision "box" of the slope, the precise Y value of the ground at any point would be easily computed from the slope factor.
Of course, it depends on what kind of collision detection are you using, in my scenario, it'd be an array that maps a particular (x,y) position of the player to a ground data object (such "objects" would have to be very cheap, memory-wise, perhaps merely just a number in the array), like so:
tile = tiles[player_x/tile_width, player_y/tile_height];

if the end of a sprite is on the position of another end of another sprite. you obviously need a coordinate system

test

...

i used a function which found by google for mouse click in rotated rectangle

bool Math_IsPointInRectangle(float check_pointX, float check_pointY, float rect_pointX, float rect_pointY, float rect_width, float rect_length, float rect_rotationAngle)

float sWidth = rect_width;
float sLength = rect_length ;
float sRot = rect_rotationAngle;


float xr = check_pointX - sWidth/2 - rect_pointX; //find the mouse coordinate
float yr = check_pointY - sLength/2 - rect_pointY; //relative to the center of image

float rot = sRot ;
bool check;

rot = rot + .0001; //Prevent devision by zero

float yc = xr*tan(rot+PI/2); //find y offset from lines across rectangle
float yd = -xr/tan(rot+PI/2);

//check that the mouse point is within the rectangle
check = (fabs(cos(rot+PI/2)*fabs(yc-yr))

You test the collision before the graphics are drawn again
>right?

Your game loop should be like this
gameLoop (meh)
{
if test_collision(obj1,obj2) == True
{
change_position(obj1);
}
drawscreen();
}


I don't code games, I'm a bioinformatician but this is what I would think you would do.

>if (check)
>{
>return true;

>}
>else
>{
>return false;
>}
Are you retarded lol

Just return check

>Bioinformatician
Bio inform dis dick

pennies and it would be shit. But you seem to don't know how to do it or even start to write it, so you could steal his shit, understand how it works and rewrite it.
You were looking for a push either way to see how the fuck you can do this right?

Google it. The problem has been solved a billion times. In fact, there are entire books devoted to the topic of collision detection.

Fuck off and never come back, this board isn't meant to finish your shitty indie garbage for you. Learn to actually code if you want to make a game.

the same way as normal, just have some indication that it's a slope for animation purposes