# Platformer Physics

1

Wild William 2021-08-20 23:38

Hello! I’m attempting to create and modify existing platformer engines to suit my needs, however! I need it to support proper x/y velocities, changeable gravity and most importantly, a camera that can follow the player. And if it affects anything large tile mode

Wild William 2021-08-20 23:39

I know it’s ambitious, that’s why I’m having trouble with it

was8bit 2021-08-21 04:06

https://lowresnx.inutilis.com/topic.php?id=318

Wild William 2021-08-21 06:43

It literally couldn’t be better, however I’m not sure how to do gravity without the player becoming a frog or stopping a pixel or two above the ground before falling again.

was8bit 2021-08-21 08:47 (Edited)

You might find this interesting...

https://lowresnx.inutilis.com/topic.php?id=2018

It shows gravity, jumping,,etc... but in a changeable 4 directions ;) simply use the one direction and ignore the other directions...

You may want to ignore my detection method, I was experimenting with an approach that was making detection to the level of a pixel, but it is complicated and can be buggy... Timo's method in the above posted link is easier and reliable... just if you are concerned about pixel level contact simply make all your objects nearly full 8x8 pixels cell sized and it will all look good

(example, if you make a floor only half fill the cell, the empty spaced other half of the cell will still count as if the whole cell was full, so go ahead and draw the whole cell for the floor)

Wild William 2021-08-22 23:45

I’d like to send the project, but I want to keep it a surprise, I know that trying to collide with oddly sized tiles will just collide like normal tiles, if it wouldn’t be a trouble it’d be nice if you could explain the engine more in depth or even just turn it into a textbook of comments and what each variable is

was8bit 2021-08-23 05:21

Basically the only real collision detection that LowRes automatically does is between. Sprites, with the SPRITE HIT command... SPRITE collision is automatically done with quick PIXEL PRECISION...

We can do our own collision based on the format we choose...

BLOCK MOVEMENT only, no sprites....
Some of my games behave much like checkers or chess... that is, each cell holds one thing at a time... my code scans the cells and determines what a piece may do... grow, shrink, live, die, move, attack, etc.... the point is that any movement is a jump from cell to cell as this approach uses only cells... you CAN use arrays to keep track of stuff, but i guess I am wierd and like to think of things in each cell as real things that can interact with other things... cells can be rocks that don't move, or animals that do move, etc... my FARM LIFE game is one example....

CELLS AND SPRITES...
This is the method Timo uses in the link I provided... it is a more popular approach.... the background cells function purely as background, and all moving things are SPRITES.... it then takes math to calculate what cell in the background a Sprite may have "touched"

SPRITE ONLY for contact detection...
Although you still have a background, it functions strictly as decoration only... all contact is detected as SPRITE to SPRITE only... i use a variation of this with my Llaftip (pitfall) game... the twist is that embedded in the background files are key cells that my game code converts into SPRITES, so this let me put into the background design WHERE I wanted any sprites to start.... some sprites were things like PLAYER, VINE SWING, SNAKES, FIRE, ETC... and other sprites were HOLES, ROPE, LADDER, MONEY, ETC.... anything that needed something to happen if touched was made possible with a Sprite....

..... in my 4way gravity, I created a clever trick.. I use math to calulate possible cells my player may be touching, temporarily add SPRITES directly on top of these cells, using the same graphics in each Sprite each cell is using, and do a SPRITE HIT check between my player and each Sprite... then i remove the sprites.... and then I write that decides what to do based on the results of each Sprite check...

It took a TON of tweaking to get it to work reasonably well.... and the logic behind it may not work in all possible things you may want to do with it... but that's the general idea of how it works.....

Wild William 2021-08-23 23:38

Cell-sprite collision would fit my needs, I have a good idea on the theory for fixing collision & gravity but I’m not sure how to write it in Basic

was8bit 2021-08-24 01:24 (Edited)

For cell-sprite collision, i reckomend using Timo's existing platform... you can always add gravity....

The thing about gravity is to not allow a fall faster than 1 pixel per DO LOOP... to keep things simple.... and also only allow a jump if already standing on something....

DY=DY+jump# where jump# is a number you create via trial and error until you get it right...

GRAV=# would control how strong gravity is...

IF DY>1 THEN DY=1

TY=Y+DY to test if the new position is clear, or hits something

Y=TY if it is clear to change the y position

was8bit 2021-08-24 01:27

I use DY as in math the delta symbol means "change of" so delta-y is change in y...