Leftmost column of collision table repeats for one extra screen

TakuikaNinja

Active member
I've noticed this issue in the metroidvania module (may be the case in all scrolling modules).
If I have solid collision on the leftmost column of the screen, the column gets repeated on the next screen to the right for some reason.
This happens on every screen as far as I'm aware of.
Here are some screenshots to illustrate the problem.
The collision:
1604798058970.png

The collision gets repeated on the screen to the right like this (you can land on it, but not walk into or jump through it on the ground):
game_010.png

My best guess is that there is a one-off error when a new column is loaded, but I'm not really sure.
Any help with figuring this out is appreciated.
 

AllDarnDavey

Active member
I tried to recreate on my project and I'm seeing similar weirdness. It's not blocking me like a true wall, but I do sometimes will jump and land on a solid block that isn't there? Noticing that I only see this in scrolling module games I think I may have a guess at what's happening.

I little while back I had this strange issue. Sometimes my character would fire, and no projectile would spawn. Not every time, but just in seemingly random dead zones -- no bullet, move 1 square forward or back, everything works again. I finally traced it down, it wasn't random, it only happened on a seam between screens. If you looked at NESmaker I was always standing right on the boundary of a screen. I found out, it was because I was getting the screen ID from the player LDA Object_screen,x, but then I added an x offset before creating the projectile. So in effect, the player was on the end of screen A, but the projectile spawn location was on the start of screen B. The projectile was being created, just a full screen behind me just offscreen. I had to add a extra check when facing right, did my x offset spill over 256, if so, add one to Object_screen, and on facing left did my x offset go below 0, if so subtract one from Object_screen.

I suspect maybe the scrolling physics script may have a similar issue. It's getting the Object_screen variable from the object, which would match what screen the object's bounding box left side is in, but when checking collisions hits for the right corners of the bounding box it's not doing an extra check if those points have spilled over to the next screen. Most of the time it's fine, but if you stand right on a screen edge... instead of checking what tile collision flag is at a point Object_screen=1, xPos=0, it's actually looking at the tile at Object_screen=0, xPos=0. But this only happens when the bounding box straddles across a screen edge.

And of course, this would only ever be an issue when using a scrolling core. Non scrolling games would be unaffected.
 
  • Like
Reactions: Yan

TakuikaNinja

Active member
That must be it. What does your projectile script look like in that case?
I don't know enough about assembly to figure out how you'd do the "did my x offset spill over 256" check.
 

AllDarnDavey

Active member
This is a short example of checking if we ran over 255
Code:
LDA Object_screen,x ;;objects screen number
STA tempD ;;save into tempD
LDA Object_x_hi,x ;;objects xPos
STA tempA ;; save into tempA
CLC ;; clear the carry flag... the carry flag gets set if we add over 255
ADC #RIGHT_PROJ_X ;;add projectile right offset
STA tempA ;;store the result
BCC +    ;;if we did not trip the carry  skip, if we did trip the carry flag then...
    LDA tempD ;;load the screen number
    CLC ;;clear the carry flag
    ADC #$01 ;;add one
    STA tempD  ;; save the new screen number
+
 

AllDarnDavey

Active member
I think I have a fix, try replacing your doHandlePhysics_PlatformBase.asm file with this:
 

Attachments

  • doHandlePhysics_PlatformBase_SeamFix.txt
    14.5 KB · Views: 2

TakuikaNinja

Active member
That didn't work.
Also it seems tempA is written to in the "getPointColTable" subroutine in "game/subroutines/locationfinders.asm".
 

AllDarnDavey

Active member
Ahh, looks like there way a check if we've spilled over the screen seam, and that's it.

But it only checks if the left side offset crossed over, and doesn't check the right side to see if the bounding box is slit across a seam, plus even if the right side did do a getPointColTable check, it would overwrite tempA and it would still be checking one side in the wrong nametable. Also, looks like for collision attributes it switches between 0 and 1 based on even or odd number screens. Looks like we can use that for the left side check, but will need to do something a bit different for the right side check.

Give this version a try.
 

Attachments

  • doHandlePhysics_PlatformBase_SeamFix.txt
    14.4 KB · Views: 3

dale_coop

Moderator
Staff member
I'd suggest to share that issue with Joe Granato on the facebook group, it would be great to have that issue official fixed in the next update!
 

Jonny

Well-known member
I'd suggest to share that issue with Joe Granato on the facebook group, it would be great to have that issue official fixed in the next update!
Does anyone know if this was mentioned to Joe on Facebook. I'm not a facebook member.

As of v4.5.9 this is still happening. I though for a while it was fixed but I guess I was just getting lucky with level design.
I was thinking of just redesigning all the parts were it happens (i.e move certain solid tiles from the screen edge).

Before I do that I just wanted to ask if anyone knows of either a fix or if anyone has shared it with Joe yet?
 

TakuikaNinja

Active member
Bumping this thread because it suddenly clicked for me.
It's not the nametable collisions that are the problem - it's the player's bounding box. When the player sprite straddles along the screen boundary, one side of the bounding box probably over/underflows its position in such a way that the box spans an entire row of the screen.
Basically, we need to fix the object bounding box collisions at screen boundaries.
 

Jonny

Well-known member
@TakuikaNinja hi. I was just wondering if you got eny further with this? Do you think doHandleTileCollisions.asm would be where to start? It looks like thats where this is handled.
 

TakuikaNinja

Active member
BIG update: derexgar recently told me that Joe had actually fixed this issue in the 4.5 bootcamp series. After looking at the code derexgar had backed up, I figured out how the 4.5 version solved the issue and managed to adapt it for 4.5.9. I'll make a new topic to share the fixed script.
 

dale_coop

Moderator
Staff member
Didn't know Joe fixed that in the bootcamp files. Why he didn't used those files in the new version ?! o_O
 
Top Bottom