Log In  


Cart #tadizihoma-0 | 2024-07-27 | Code ▽ | Embed ▽ | No License

I'm having trouble with my player movement after my map updates. My map seems psuedo-randomize after the 1st screen like I want (I can tinker and fix this later). The trouble I'm having is that my player won't continue moving upwards after the map redraws and resets your position. Essentially every screen seems to treat the lower half as if it's the first screen ie running the collision detection on sprites that don't seem to be there. I'm stumped. Any help would be much appreciated.



I just skimmed through your code for how you're currently accomplishing everything. The issue is that your code is checking the wrong map for collisions.

This code in your move_player() function:

		local x1=(o.x)/8
		local y1=(o.y)/8
		local x2=(o.x+7)/8
		local y2=(o.y+7)/8

should be this:

		local x1=(o.x)/8+cur_mx
		local y1=(o.y)/8+cur_my
		local x2=(o.x+7)/8+cur_mx
		local y2=(o.y+7)/8+cur_my

Thank you. That worked like a charm. It's 2am, and I'm having trouble wrapping my head around the math on why it works that way, and would I run into similar issues for enemy sprite's collision detection?


1

It's because the functions you're using to check the map for collisions checks what's in map memory, not what's on screen. I'm having trouble describing what that means in words, so here's a diagram instead:

If you don't have the + cur_mx and + cur_my then it's equivalent to checking the map memory at (0, 0) which is always where the starting map is.

Sorry if the diagram is too big. It's really hard to tell how big an image upload will be.

Edit: just realized immediately after clicking publish that I mixed up the units in the diagram. cur_mx and cur_my in your code appear to both be in tiles, while o.x and o.y are in pixels. Oops. Well, I guess just pretend one of those pairs was converted.



[Please log in to post a comment]