This is part of the code I wrote to make a "foolproof" physics engine (meaning there's no way for an object to pass through a block by going too fast). It uses mget to check if a tile is there or not which should be pretty fast although maybe not the fastest. This is based on the blog post by Towerfall creator Matt. Although there's missing features like moving solids and stuff it's inspired by it.
If you haven't read the blog post about this you should, it's quite insightful!
http://mattmakesgames.tumblr.com/post/127890619821/towerfall-physics
Controls:
arrows, o to jump normally, x to fly really fast upwards to show that you won't pass through things
at extreme speeds.
Feel free to use this code.
Awesome. Thanks for the share...this should let folks make all sorts of things. I have an idea already :)
YAY! I honestly was convinced that nobody would even pay attention to this post (it's my first) I'm glad you found it useful.
looking at map_collide() it seems you have a bias on the y direction (travelled first) that could cause problems around corners. like hitting a roof when you should near-miss:
|
[0x0] |
it might not be noticeable when running and jumping around but could be a problem if you have to aim and shoot projectiles. although towerfall seems to do the same thing (separate moveX() & moveY()), while being quite playable.
actually I had started a bombjack a few months ago, with a collision routine roughly like this:
nb = max(pixels_vx,pixels_vy) dx = pixels_vx/nb dy = pixels_vy/nb for i=1,nb do if (hit(x,y+dy)) dy=0 if (hit(x+dx,y)) dx=0 x+=dx y+=dy end |
I think I had this refined further, i'll try to post actual code when I get a chance.
side note: you can replace x=limit(x, m) by x=mid(-m,x,m)
@ultrabrite, It's true, this is a weakness of it. To midigate it all you have to do is move 1px x-dir and 1px in the y direction and alternate. It becomes less and less of an issue if you have a higher framerate (I'm pretty sure towerfall runs at 60fps) The things I like about this system is that it's simple and seems to perform flawlessly. If I wanted ultra efficiency you could even do a binary search for the final collision position (could be good for instantaneous bullet). This is just simpler.
Just looked at your code, it's a little inefficient in the fact that the loop goes the duration of both directions even after a collision has happened in both directions. Also it checks for collisions multiple times per pixel if you aren't moving very fast in an x/y direction but very fast in the other. However I doubt this will cause your game to be slow and I am very against premature optimization.
you're right on every point, that was merely pseudo-code from the top of my head :)
I had real case working versions in a bombjack and arkanoid prototypes, but it's on the now-black-screen-borked-linux-laptop I used this summer (hopefully). I know dropbox is my friend, I guess I'm of the kind that never learns ;)
no doubt that works very well for towerfall. though I remember those arrows could be pesky at times. that was part of the fun, but now I'm wondering if that could be linked to these edge cases. well, it's on my ouya in some drawer... also 50% on gog.com right now :)
[Please log in to post a comment]
