Log In  


morningtoast

I've been looking at a lot of the collision scripts for map tiles and they all make sense and work well...except when I start scrolling the map. I'm trying to make a scrolling side shooter (a la Gradius) but for the life of me can't get the scrolling speeds to match up so that the player doesn't get stuck on the walls.

Collision is working because the player stops but then he can't move up/down or back once he's blocked. I know that moving opposite direction should be doubled (which in this script it's not) but other than that, I just don't have my head around it. Hoping some extra eyeballs can help out.

What I'm trying to achieve is if the player hits a wall, they can at least move any non-blocking direction to avoid getting pushed off the screen.

The scripts I've studied have been great and at least got me this far...I'm just trying to make things move with the camera.

Cart #21850 | 2016-05-31 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

P#21851 2016-05-30 22:42 ( Edited 2016-06-01 01:06)


Synth_dfr
Synth_dfr

I thought of a quite different approach for movement and collisions.
It may not be the best method, but I chose to process both at the same time, in the _update() function:

    1. Scroll the map and auto-advance the player by 1px.
    1. Check if the auto-advance has put the player into a wall. If so, push him back by 1px.
    1. Check for user input (btn(x)). For each button, we're going to move the character by 1px in a direction and compute collisions accordingly.
      The tests are done pixel by pixel, which means if you set your player's speed to 10 then the tests will be done 10 times per direction per frame. It might not be the most optimized method, but it prevents from going through walls because you're moving too fast, or being pushed back too far away from the wall when you're colliding with it.

I have a quite "naive" way of processing collisions: I move the character 1px in a direction, and if it has moved into a wall, I push it back 1px — instead of doing collision tests 1px away from the character and only then moving it or not accordingly (but that would require 3x as many collision tests).

Also, I have a function for collision computation which returns a new table with the collision tests (true/false) of all 4 corners of the character's bounding box. Which means, each time the function is called, a new table is created. Not excellent in terms of memory management, but well...


Let me know if there's anything that wasn't clear enough, either in the code or in my explanation. :)

Side note: newb question, is it possible to remove an unused cartridge from the BBS at all?

P#21989 2016-05-31 20:33 ( Edited 2016-06-01 00:33)

morningtoast
morningtoast

Thanks, man...your rework behaves exactly like I want, and from a quick glance, I think I understand most of what you're doing. I'll spend more time with it and pull it apart to see what I can abstract out.

I think a lot of this for me is just not being familiar with mget() and fget() stuff with tiles. It didn't occur to me to divide by 8 and such. Some of the numbers seem arbitrary but they're not. The manual doesn't go into that much detail often.

I'll be sure post what I rework from your demo. Thanks again.

P#21993 2016-05-31 21:06 ( Edited 2016-06-01 01:06)

[Please log in to post a comment]