Open btstevens89 opened 11 years ago
Hah yep, there's an old todo comment hiding in the Physics class that I never touched, take a look at Physics::Move specifically lines 24 and 25, which clamp the entity between 0 and 320 on x & y.
The gamepad controlled entity (the square) is unaffected because he doesn't use the Physics::Move function to move, since he moves in vector based motion which isn't currently supported. As a side effect of this, his collision box won't move from where he started since the his Physics component never gets updated.
The todo was to change it to the map dimensions but it kind of ended up getting put aside for a while.
I'm not sure how to change the values in those clamping functions dynamically since the Player is bound by Lua.
It should be ok to just change the clamping done to testPos.x/y in Physics::Move, since the player and all entities soon, use the physics class to actually make the movement happen, see Player's Move and Update functions in the script. So it should be possible to tweak the values in the Physics class to update based on the map box and have those values be used for clamping.
I also started adding vector based motion stuff, but parts of it seem buggy, however it's backwards compatible with the old system for now until i get it fixed up. So you can use the old UP/DOWN/RIGHT/LEFT methods as usual.
Maybe some kind of static rect of the map clamp box could work, then it'll set it for all entities' physics. Although maybe some entities would want to be clamped to smaller/bigger areas? Perhaps two separate options: a static map clamp box, and then if desired an entity specific sub-clamp box. Let me know what you think.
Right now there must be something hard coded into the program that limits the players movement. In a 20x20 tile, 640x640 pixel map, the player can only move about 320pixels in each direction. Is there a hard limit coded somewhere in the program?