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.

Thanks for the info.

The issue with your player movement could be related to how the collision detection and map position are being managed after the map updates. If the lower half of the screen is incorrectly treated as the starting position, it may be due to improper handling of the player's position and collision detection logic when the map redraws or resets. Ensure that the player’s position and velocity are correctly updated relative to the new map state after each redraw. Double-check that your collision detection code is correctly referencing the current map layer or state, and that it is recalibrated or reinitialized appropriately after the map updates. It might also be helpful to debug or log the player's coordinates and collision interactions before and after the map redraw to pinpoint where the discrepancy occurs. I had too much homework and not enough time, so I decided to get some help from https://academized.com/do-my-homework The service was amazing! They handled my assignments quickly and efficiently, and the quality of the work was outstanding. It really took a load off my shoulders, and I was able to focus on other important tasks. I couldn’t have asked for a better experience, and I’ll definitely use this service again.



[Please log in to post a comment]