Hey all so I posted a cart so you can see what I am facing here:
I have the town with buildings that have collision coded into them with the doors coded to take the player to another room which is admittedly hacked together.
What happens is the player is then transported(sorta) to a new location - yet when I move him around in the 'new' zone there seems to be residual collision code which prevents total freedom of movement for the player.
Any better ways to go about this? I want the player to enter the brown zone and be able to freely move around at will.
Thanks!
Hey @gigs You'll want to have your collision calls take into account the difference between the player's position relative to the screen (what you use when you call spr()) and their overall position on the map.
Could you possibly elaborate? Or maybe show me an example in another cart?
Sure! On mobile but I'll try.
So iirc the problem is that p.x and p.y are relative to the screen. Not relative to the ENTIRE map. When you go to another screen, you need to adjust p.x and p.y accordingly so that the map tiles you're checking are on that area of the map. Right now, if you move to a new screen, you're still checking the tiles for collision using coordinates from the beginning screen.
If you plan on keeping everything in 128x128 pixel areas (moving a screen at a time, you can change your spr calls for the character to use spr(tile, p.x/8, p.y/8..)
Let me know if that doesn't make sense though and I can make an example.
Another way of putting what @enargy is telling you, is that, since entering the building currently just changes your camera position, JUST while you draw the map tiles. The actual position you're at on the map, and the player's actual position, are still exactly where he was when he entered the church door. You're just playing a video trick to make it "look" on screen like he's somewhere else, but the program logic won't be fooled by that - it knows the player hasn't moved.
There are a couple ways you could go about fixing this: one is to actually change the player position too - add 30 to that when you add 30 to the camera, add that amount to the player position as well, and then draw the player while the camera's still shifted, before the camera() reset call.
Another solution would just be to make sure to add the appropriate amount to the player's position before checking for tile positions. So in cmap(), where you set the locals x1,y1,x2,y2, you'd also add cam_x and cam_y:
local x1=(player.x+cam_x)/8 local y1=(player.y+cam_y)/8 |
and similarly for x2 and y2.
Personally, I'd suggest the first option, as otherwise you may find you have to do that same "camera adjustment" bit in a number of other places as well. If you change the player position to where it really "is" on the map, it may simplify future checks you'll be making.
Good luck!
Ok I think I see the issue, going to try some things based on this new knowledge.
Thanks! I'll let ya know if I have any other questions
Hopefully this helps explain it:
This method is designed around you moving a screen at a time (like in the original Legend of Zelda.)
The basic idea is that you have the player's coordinates stored as absolute values. As you move around the map, those will increase past the width of the screen (so, past 128 pixels). But that when you /draw/ the sprite, you're drawing it relative to the screen. So you use modulo.. Which gets the remainder from dividing that absolute coordinate by the possible screen coordinates (which only go 0 --> 127).
fwiw, this was my first time using the 'map' feature. So there could be an easier way to accomplish this.
[Please log in to post a comment]
