S3B4 2021-08-22 01:11
This is my attempt at making a platformer “engine” for some games I wanna make.
This isn’t an actual physics engine, all it does is apply gravity, move the objects and check for collision.
was8bit 2021-08-22 05:45
Very nice... i was even able to jump on top of the upper right wall.... i was abit sad that i couldn't jump on top of the little jumping block... i envisioned the block temporarily stopping if it was going up but ran into the player...
CubicleHead 2021-08-22 12:24
That Sprite is thicc!
Timo 2021-08-23 10:10
Works really well! And by the way, no classic 2D platformer had real physics, you are not alone ;)
Wild William 2021-08-23 23:44
Could you explain how you did collision? I’d be interested in integrating it into Timo’s scrolling engine along with gravity
S3B4 2021-08-24 16:05
The way collisions work is that it only checks collisions in an axis when it’s position in that axis is a factor of 8 since that’s the size of a cell and it only checks collisions in the direction it is moving. It divides the position by 8 and then checks the adjacent cell in the direction of movement. I am currently trying to implement scrolling, however, it is a bit difficult but I’ll post a version with scrolling when I manage to get it working.
Wild William 2021-08-24 23:04
Oh, sorry well I should’ve clarified, how did you push sprites out of cells, I get the theory of it (figure out how far you have to move them back and move them there) but I’m having trouble doing it in Basic
was8bit 2021-08-25 04:30 (Edited)
If you look at a Timo's code, it checks first for collision of the wanted move, and only applies the move IF there is no collision...
... you shouldn't automatically move, and then check for collision, and then try to back it up.. that is way to complicated...
All movement should be restricted to 1 pixel movement at a time to simply the process and avoid complications...
Timo's example also handles scrolling, which can get complicated really quickly....
Timo 2021-08-25 06:04
Well, for nice jumping you need to move more than one pixel per update.
And yes, it makes it more complicated ;)
Timo 2021-08-25 06:08
…in that case I think you need to calculate the target position first and THEN check for collisions and “back up”.
It’s important not to move more than 8 pixels in one update, then you could teleport through cells :O
Or do a collision check every 8 pixels… (i guess they did this in the Sonic games)
S3B4 2021-08-25 13:13
The way my code works is that it checks for collision, and if there is no collision it it moves the smallest number between 8 and the distance the object wants to move. The reason I don’t restrain it to 1 pixel movements is because I want to use the least cpu I can. Essentially, it only checks for a collisions every 8 pixels.
S3B4 2021-08-25 13:15
It avoids the “having to back up from a wall” thing by avoiding getting stuck in the wall in the first place
Timo 2021-08-25 15:35
was8bit 2021-08-25 16:38 (Edited)
My latest game, Drag and Drop, does all 63 sprites constantly, at one pixel at a time, and never exceeds 63% CPU .... as long as it doesn't max out, you're ok...
... on a side note, I've noticed that playing the games online works fine on my iPads but on the iPhone the edges of the gameplaying screen remains off and unseen on the iPhone screen, and I have tested many phones and they all cannnot get the online player to keep the whole playing screen in view... nearly 50% of the screen cannot be accessed on the iPhone when trying to play it online off these boards :/