Looking for issues with scrolling

jorotroid

Member
So I've been spending my time since 4.1 released just reading through the code and taking notes with a particular focus on trying to understand how the scrolling does and doesn't work. I want to try to see if I can improve upon it, so I thought I would ask all of you for what sort of weird scrolling behavior you have seen so I can try to see if I can fix it. Here are the issues that I have observed:

-When you have both Right and Left Scrolling on, sometimes a gap will appear in the tiles when you go back in the opposite direction.
-Paths don't load properly when scrolling.
-Moving left to a new screen that has Left Scrolling enabled can lead to a variety of weird behaviors including no function left scrolling at all, as well as if you go yet another screen left you might warp to a random screen or maybe get stuck in a loop of warping to several different screens.
-There is no way to set up a group of screens as two way scrolling rooms. If the end screens only have scrolling in one direction, they you have to scroll completely to the next screen in the room before you can scroll back to the room's exit.

I think I have seen other issues, but it's difficult to determine what is causing what. So let me know what other crazy behaviors you have seen, and I will try to see if I can pin that down.


I'm thinking that what I want to do is eventually rewrite the scrolling so that there is only one flag for marking if a room is horizontally scrollable. Then scrolling will only occur if that room a room next to it are marked as scrollable. If a room is marked as scrollable, but does not neighbor a scrollable room, then no scrolling will occur.
 

LordFred

New member
... I will pray that at least you can solve the issues that you have listed ^^P

I found all these issues using scroll... ^^ path tiles vs scroll... scrolling to the left... looping to several screens... I have experienced all those failures
 

Mugi

Member
There is also the issue of collision tables going crazy when 2way scrolling is used. Usually after scrolling to the right for a couple of rooms, going back to the left causes the collision data of the first room you came from to load in your face.... Its a shit explanation, i know. Ill make a video of this if need be.
 

jorotroid

Member
dale_coop said:
Wow, jorotroid, would be awesome of you'd fix those issues! <3

I'm making no promises at this point, of course, but I am feeling confident enough to give it a try.


Mugi said:
There is also the issue of collision tables going crazy when 2way scrolling is used. Usually after scrolling to the right for a couple of rooms, going back to the left causes the collision data of the first room you came from to load in your face.... Its a shit explanation, i know. Ill make a video of this if need be.

Thanks, I haven't noticed that, but most of my tests have been with simple screen designs. I try paying more attention to the collisions.
 

dale_coop

Moderator
Staff member
Soemthing "funny" (I am not sure if the right term but)... even when you make a non scrolling game, you have this weird effect during the transition between 2 screens (because of the scrolling code).
Let's say I have screen A <-> B <-> C (in a screen--by-screen game, platformer or adventure... )
When the player moves from A to B... during the transition time, we can see the C appearing (loading), during a fraction of second!
Of course, same when the player moves from C to B... during the transition time, we can see the A displaying briefly :S

It's quite ugly. And surely a source of (collision) issues, visual glitchs, ...
 

Mugi

Member
I recorded a clip about what i was trying to explain, though i noticed that the behavior here is a little different than it was on my previous test (could be related to the fact that the left room here is screen 0,0 which means that scrolling to the left is impossible in that room)

regardless, in here you can see that specifically, the left edge of the leftmost room spawns to the left edge of the rightmost room when you attempt to return to the middle room from the right room. It seems like it's simply reloading the collision tables incorrectly. The seam between the rooms also indicates that room 1 is loaded instead of room 2 (pay attention to the random log graphic on the top left corner of the left room, which spawns to the top left corner of the right room when attempting to scroll back to left.)

anyway, the whole deal with showing the collision data and the log that is on the ground which i removed on the second pass, is that in my previous attempt, what happened was that instead of the first room's edge spawning into your face like happens in this video, only the actual collision data of the room was there. so the log would be there, where i get stuck on invisible something while walking, it would be the log, and since it's just one block high, jumping over it or walking on top of it would work just fine.

overall it really seems like it's some kind of oversight in the way the collision tables are loaded/reloaded and stored.
Or it could simply be related to the fact that since Joe said that the engine stores data for 2 screens at a time, and is only meant for one way scrolling, that it just doesnt really know what to do, and having to try and re-read the whole room data instead of having stored tables to deal with just ends up doing all sort of weird shit (propably due to the fact that the vblank is too short for the engine to fully reload the room before you move far enough in it.)

if the video looks like blurry shit, set it to 1080p
https://youtu.be/L_gukMV0lz4

it is also worth a note that the object's placement data is slightly off. (pay attention to the animated cross on screen 3 during scroll.)

EDIT: also, this sometimes happen when going back and forth left and right.

game_052.png

For the sake of clarification, the palettes in the screens are as follows:

palette 1: red/orange/yellow (not used on any screen/object.)
palette 2: light green/dark green/ dark cyan (grass/leaves/forest backdrop)
palette 3: light brown/orange/brown (stones/tree trunk)
palette 4: 3 shades of cyan (warp crystal/ health platform)

the glitched stripe of red palette there is not actually used for anything in these screens, so something messes up when loading the data for the screens.
 

Mugi

Member
there's also this, which i dont really know if it's a result of my own f-uppery with the code or not, but atleast for me, this has been there since the start (you generally dont notice this because mostly people have a HUD at the top of the screen.)
but when scrolling, the second screen omits the first row of tiles when drawing, leaving in a blank black gap to the screen. (this exists everywhere but for example, you cant see it on my stage selection because the screen is black by design. It actually draws the top left metatile of the currently loaded tileset into that blank space.)

for reference, the only thing i've done to the scrolling code so far was disabling the sprite zero draw from pre-draw.asm (use sprite zero is unticked in screen info for all screens.)

https://youtu.be/Kl27rxdvNrc
 

jorotroid

Member
Mugi said:
there's also this, which i dont really know if it's a result of my own f-uppery with the code or not, but atleast for me, this has been there since the start (you generally dont notice this because mostly people have a HUD at the top of the screen.)
but when scrolling, the second screen omits the first row of tiles when drawing, leaving in a blank black gap to the screen. (this exists everywhere but for example, you cant see it on my stage selection because the screen is black by design. It actually draws the top left metatile of the currently loaded tileset into that blank space.)

for reference, the only thing i've done to the scrolling code so far was disabling the sprite zero draw from pre-draw.asm (use sprite zero is unticked in screen info for all screens.)

Thanks, I'll watch out for that, too. I think I may have already fixed that. I guess I might as well give an update on my progress. I've definitely made progress, but as I fix one thing, I tend to break another. What this will probably all lead to is a custom core devoted to horizontally scrolling games. I have changed how the flags work with the assumption that you want scrolling by default. So now you can turn on a left or right flag to mark whether or not a screen is and end of scrolling screen. If you want a screen to not scroll, you just turn on both flags. I have also somewhat fixed the screen wrapping problem that had you go to the wrong screen when you hit a screen edge, but I have also since created new warping problems trying to fix other things.

With all that said, if I don't make some significant progress in say the next 5 days or so, I'll probably have to shelve this to focus on the competition. At this point I remain optimistic.
 

Mugi

Member
im just gonna let you know that regardless of the outcome of this, i'd kill to get my hands on your code regardless.
 

dale_coop

Moderator
Staff member
Sounds you made great progress already jorotroid!
I think a core dedicated to scrolling is not a bad idea. For the 4.1.5, Joe released a core just for non scrolling games ;)
So it’s perfect ;)
 

jorotroid

Member
Another update on my progress before I go to bed.
I feel like I am so close to having all the collision and screen warping stuff ironed out. As far as I know right now, I only I have two issues related to that left:
The scrolling check happens after your horizontal speed has been calculated, but before your new position has been determined. What this means is if the player is beyond the scroll pads and is running into a wall, the screen will continue to scroll. This is particularly an issue when combined with the first issue. If you are sliding along a wall and move a screen up or down and that new screen allows for scrolling, the screen will start to scroll as you hold to the side even though the player isn't moving horizontally. That feels weird, but then if you fall back down while this is happening, I think some conflicting information gets sent to the PPU and really weird graphical glitches will start to happen.

So first thing that I'm going to do is move the camera update code and make sure it only runs if the object that the camera is tracking has actually changed position.

Once I get that ironed out, I will focus on making sure the correct tiles get loaded. Much have it has already been solved as I have fixed other aspects of the scrolling code, but a few problem remain persistent. One issues is that tile column update code is a little aggressive and sometimes updates tiles that were fine they way they were.

Fixing paths will probably/hopefully be the last thing that I will need to fix.

Still feeling optimistic that I can get this done in the next few days.
 

Mugi

Member
sounds golden.

question though, how extensively have you modified the engine routines to fix all this ?
i mean, my game for example, does quite a lot of shit under the hood now that forced me to poke a lot of things not really accessible from the UI to begin with and quite frankly, im pretty terrified of attempting to implement your scroll.
(im currently working on writing the backswitch stuff for tile animations for example.)
 

jorotroid

Member
I think the biggest change is that I gutted out various screen flag implementations. So the formerly single screen flag doesn't do anything, nor do the auto scroll or monster scroll lock flags. My guess based on what you have shown is that you are using the auto scroll flag for you stage select. In my core in place of the auto scroll flag, I have a variable that keeps track of which object the camera should be following. So to achieve an auto scroll, you would have to create an invisible object for the camera to track and have it move in the direction you want it to scroll.

Also at this point, I'm not sure if the background HUD will still work. If it doesn't, I will probably wait until after the competition to reimplement it.

Beyond that, I'm not anticipating any more major changes on the user side of things. Yes, I did some major changes under the hood, but unless you were already messing around with the scrolling code, I don't expect it to affect you.

Finally, even if everything does work out an I manage to get this done within the next few days, I would consider whatever I put out as a beta release, and using it for the competition would be at your own risk.
 

Mugi

Member
the removal of autoscroll sounds bad atleast in my case.... it was difficult enough to make that screen wokr as it is lol......

sans that i dont have anything really done to the scroll code so that should be fine... the recent stuff i did regarding to chrram bankswitching was that i added some new tile sets to the game (4 sets of hud tiles, to animate those, though i use them for backgrounds, not for actual HUD.) the code for that sits mostly in handlescreenloads and predraw so it should be reimplementable anyway. for the new graphics im currently using bank 1D which seems to be okay for the moment, but if not, i will propably allocate bank 19 or another of the empty banks for that purpose.

i dont suppose there would be a way to take the autoscroll back in use by using a variable to identify it or something instead of the bit that was originally used for it ? or did you just completely nuke the code regarding to that (i have no clue how that even worked to begin with lol.)

that said i might be able to work around it by making the playerobject run while he's hidden, but not really sure how that will work unless i define him as a not player or something, hmm
oh well, i guess i will fight with that once i take that engine in use and test out how it goes.
 

jorotroid

Member
Part of the issue with the auto scroll code is that it no long made sense in the context of how my code functions. There is no longer a way to tell the game if it should be scrolling left or scrolling right, so the auto scroll bit wouldn't know which way the screen is suppose to scroll. So it's nuked for now. If the invisible object method I am pushing forward doesn't work out, I can look into a way to bring the auto scroll bit back, but it probably wouldn't happen until after the competition.

I did makes some changes to the HandleScreenLoads file, so you will probably have to go through it and figure out how to merge the code. I mainly did 3 sorts of changes:
-A few comments here and there.
-I consolidated some similar variables that served identical functions. I mainly did this because I kept forgetting which variable did what.
-The biggest change is that before odd numbered screens were loaded into the left nametable, and even screens into the right nametable. I changed it so screens can be arbitrarily loaded into either nametable, so some of the code has been changed so new screens will always load in the left nametable, and then as you scrolling on it alternates drawning in the right, then left, the right, etc.

I didn't make any changes to how screen information is read, so you probably won't run into any issues there.
 

Mugi

Member
Most of the things i did to handlescreenloads was actually clean up.
I was running so low on space in 1F that some actions needed to be taken so the chrRAM stuff along with some of the default code was moved from handlescreenloads into a new assembly that now sits in bank16.
Sans that i have a code there that alters the way player spawns based on my screenvariables, to allow hiding on stageselect etc. I will have to go through it to see but the code of the vanilla file is from most parts unchanged so adpting shouldnt be an issue.

As for the object based scroll on the stage selection, i cant really say before i test that out, the way im currently using to stop the screen and all the objects in their places is what worries me more than making it scroll using a monster.

Currently it is done by placing the char render and the invisible player in specific spots so that they end up on the exact spots where they stand when the last screen fully loads. The last screen then has its gravity turned off which stops all movement of all objects on the screen and enables the controller to gain control of the selection cursor. The controller inputs then start despawning the player and respawning it as the cursor icon.

Its a long daysychain of things that will propably end up getting destroyed from multiple parts when the scrolling is changed.

That said, i will trade functional scroll to redoing the stageselec any day :p
 

jorotroid

Member
Nightly update:
I think that the camera and screen edge stuff is just going to have to be good enough for now. There are a few things that I want to nitpick about them, or I can just give some "best practices" tips when I release this core. I'm itching to get back to working on Witch City proper, so I've moved on to dealing with the incorrect seam loads to keep things moving forward.

I understand at a high level what is going on with the seam update. 4 meta tiles can be updated per frame. There is memory allocated to say where those 4 tiles go and what they should be. There is a 16 bit variable that keeps track of where in the seam column those 4 tiles should be. If the tiles don't get updated, then the attributes may be updated instead. That functions in a similar manner, except 8 metatiles can be updated per frame. I'm still picking away at figuring out how all the specifics work. I also don't really know what is going wrong with the seam loads. I suspect that it is when tiles have already been queued to update, but then the player does something that changes what should be loaded and that throws everything off. I'm not quite sure how to go about proving that yet.

Oh, there is one more thing I need to fix with the screen edges. I have found that if you change directions right before hitting the edge of the screen such that you still trigger the screen transition, you'll end up in the next screen, but either on the opposite side of the screen or halfway between the left and right sides of the screen. I think I have an idea on how to deal with that, but I'll deal with it late.
 

dale_coop

Moderator
Staff member
Great update indeed. Congrats! And thanks again for keeping us informed of your progress. It's awesome.
 

jorotroid

Member
Ok. So it was looking pretty bleak for a while. I ended up vastly rewriting the scrolling tile loading code. But here is the run down as of this moment of the issues we had:
  • Gap appears when you backtrack: Fixed, though I did once see a single tile load incorrectly, but haven't been able to reproduce yet.
  • Going left into a new screen issues: Fixed
  • Difficult to define where scrolling should begin and end: The core assumes you want scrolling. Now you just have to say if a room is the end for right or left scrolling. If you want a single room that doesn't scroll, just turn on both flags.
  • Collision table issues: Fixed.
  • Object placement out of sync with the screen scroll: Still need to check this.

Anything I am forgetting?
I also need to check how object in general react to the scrolling. After that, I think I might actually be done with this.
 
Top Bottom