BUG FIX & PATCH: Solves right-hand screen boundary transition problems

FrankenGraphics

New member
PROBLEM DESCRIPTION:
When attempting a transition from one screen to the other, if crossing the righ-hand camera boundary, the leftmost column of tiles on the screen would block and bounce you back if they were solid. This previously forced you to certain level design compromises and a bit of tedium manually alterning solidity properties on the left-hand column of each screen which should allow a right-hand transition.

What's more, different player speeds would affect the occurrence.

FIX:
I figured the bug where transitions to the right was an conditional edge bug (a generally common bug cause where a value is 1 off from what it should be to be properly functioning as a branch determinator). Finally identified exactly where condition miss happened! Inserted a fix at line 168 for the file in question. You're now free to design the left and right columns of each screen however you'd like.

There were suggestions in this thread ( http://nesmakers.com/viewtopic.php?p=10763#p10763 ) - maybe the later suggestion worked too, but i came up with a one-line fix instead on my own.

NEED OF VERIFICATION IN SCROLLING GAMES:
I have only confirmed that this works for non-scrolling screens. It should also fix transitions for scroller games, but if anyone with a scrolling game project could confirm that it doesn't mess with the camera or anything would be great.

STEPS:
1) Optionally, save a backup of CheckPlayerCameraPosition.asm
2) Replace it in place with the attached file. Remove the FG_ prefix. (you can't access script paths like normal from script settings; you'd need to add a user constant and edit another file.. not worth it).
3) Have fun!
 

Attachments

  • FG_CheckPlayerCameraPosition.zip
    1.5 KB · Views: 166

dale_coop

Moderator
Staff member
nice, thanks for sharing that fix, FrankenGraphics <3

PS: I thought this bug was fixed by the 4.1.1 patch? http://joshuafallon.com/nesmaker/?fbclid=IwAR1ZQaSV0CURv4vQv02i6BcKAM2u8zTpvwXfeye5uCeubdqc7lNThc2drnc
 

FrankenGraphics

New member
Hm.. maybe?! I haven't updated since 4.1.0 and the changelogs don't mention any bug fixing other than to some new GUI features, so i didn't see any reason to update. :S

btw, you can't keep the backup in the same folder (macros) or else it will try to double-list the macro with the same label.
 

Mugi

Member
there was a fix that joe posted on facebook that involved setting a BEQ statement into the handleplayercameraposition to fix the issue, but it doesnt actually fix it.
alternatively, this bug only happens (in my game) during scrolling screens. if the screen is not scrolling, this bug never happens, but if i do scroll into a screen, it does.

i will have to take a look at what you did to your file (mine's heavily modified) and shout back at you about how it fares.

edit: i gave it a go and the bug still persists (again, only if you scroll to the edge, as a static room it works.) (note: im on 4.1.4 engine base.)

just to confirm you only added the line "DEC temp1" and nothing else, right ?
 

FrankenGraphics

New member
That's right. It's at line 164, not 168... probably deleted some comment space i did which might've been confusing, sorry!

Works like a charm in non-scrolling rooms. But i was able to reproduce it setting the scroll in the same test room. I'll try some other things.
 

Mugi

Member
seems like the behavior is the same for you then.
i havent given this much attention lately due to the fact my scroll engine is undergoing a complete rewrite and things will change drastically with that,
but i did poke at it earlier a little and it might be a result of the fact that the screens dont always align per pixel when scrolling (you might scroll more than one pixel at the edge of the nametable) which causes your scroll to actually clip a pixel worth into
the next screen (this displays itself as a one pixel column of garbage from the adjacent screen at the right edge if the next screen contains visible pixels.) this could explain why you said that the player speed affects the behavior too, because the player speed effectively affects the scrolling speed, and thus the way the nametables align during scroll.
it could be responsible for messing up with the edge reaction but i pretty much left it at that until i get the free-scroll running since that will alter the way everything is handled.
 

FrankenGraphics

New member
Strange thing is i need the room to be non-scrolling in order for player speed to help to overtrace the barrier. When scrolling, it's constistently colliding.

In the case of scrolling rooms, I'm starting to think anything done within camera control might be futile because things have the 'wrong' causality:

transitions are handled from within scrolling control. but the collision detection prohibits any further scrolling to take place as if there was a block in the way. collision happens before checking for the need to update the scroll buffer. you can't switch collision table since it is contingent on checking for further scrolling. To solve it, a switch switch check needs to take place inside the attempt to move the player right, but before the pushback to the right and subsequent animation stop. At least that's my working theory for now. I just need to find the right place in the file jungle to test it.

Update:
-Nope - checkPlayerCameraPosition definitely happens right before the critical collision check. So the options are narrowed down to these:
-checkPlayerCameraPosition is still returning a false negative (seems likely) under the circumstance of scrolling rooms.
-the condition in checkPlayerCameraPosition operates correctly but the information is not properly acted on before collsion pushes the players' potential movement back. (seems very unlikely at this point - the macro should back out of the collision subroutine based on player vs camera bound).

update 2:
-it's a bit frustrating at this point - i can get it to switch screen at will, scroll by commenting out the subsequent tile check - but don't feel closer to an answer. i checked the condition over and over but nothing seems wrong. i'm back to having a gut feeling that there is a race condition which is always lost between collision and the scroll buffer. i don't know. maybe some sleep will help.
 

BingoRingo

New member
Just checking... since I haven't found any more reference to this bug. I'm on version 4.1.5 and I have the same issue, and none of the proposed solutions seem to work for me. I'm using the Adventure module and experience this bug going right if the left is solid, but going left when the right of the screen is solid seems to work...

Is there a fix somewhere that I have missed in my research?
 

Mugi

Member
as far as i know the bug still persists in all up to date versions and in all modules.
 

mouse spirit

Well-known member
Pretty sure i tried this. I am on the scrolling platformer 4.1.5. Didnt work for me but let me say more. On a scrolling game isnt there 2 nametables n stuff like its looking at a screen ahead of you as well as the screen you are on. So 2 collision tables too. So maybe theres an error within a part of code that had to do with scrolling module. I want to say that i dont use scrolling,im still using single screens but my module was the scrolling one. Dont ask dont tell.

I work around this all the time as it sucks you know what.
 

mouse spirit

Well-known member
Ok, so maybe this was not my actual issue then ,and this patch Did work as i did apply it.
My issue is that sometimes the tiles on the screen to the left or the right of my current screen affect my current screen but only at the edges. Like tiles i have on the adjacent screen affect this current screen so ive had to build levels around the glitch.
It only happens on every other screen, NOT every screen.
glith12.gif
Its the screen to the rights fault here,if i take away those tiles on the border on the next screen its fine. It happens with all tiles including monsterlocks and so on.
glitch1.png

I made it do it here, in my game i simply build around this glitch,which is tedious and kinda limiting.


Heres to show that it is the screen to the rights fault fersure.
glith123.gif
Sorry, had to kill that shroopie.
 

dale_coop

Moderator
Staff member
Oh, this one is another (well known) issue... it's the collision from the wrong screen (never been patched).
The issue is when the engine is checking the wrong screen collision: instead of checking the collision data from the destination screen before the screen transition (to see if it's solid on the other side), it's checking the collision of your current screen:

glith12.png


Only the tiles on the edges are causing the issues... you should try to make them "null / walkable" in the current screen (to allow your player to exit the other side)
 
Top Bottom