Quick fix for Paths while Scrolling

jorotroid

Member
Hey all, I'm still working on a new scrolling core (sunken cost fallacy is a hell of a drug), and I just got around to figuring out what is wrong with paths. Turns out it's a pretty easy fix, so for those of you already making one way scrolling games, this is something you can easily do yourself.

Open up the file HandleUpdateObjects.asm located in the Routines\Basic\System folder.
Search for the label "DoGetFireTilesLoop" It's probably on line 985. Right after it you should see the following two lines:
Code:
	LDA (updateNT_ntPointer),y
	JSR GetSingleMetaTileValues

Before those two lines, insert the following code:
Code:
	LDA temp16
	PHA
	LDA temp16+1
	PHA
	LDA updateNT_ntPointer
	STA temp16
	LDA updateNT_ntPointer+1
	STA temp16+1

Then after those two lines, add in this code:
Code:
	PLA
	STA temp16+1
	PLA
	STA temp16

And that's it! Paths are now working*. You might not need those lines that save and retrieve the values of temp16 and temp16+1. I needed them for sure with the changes I'm making for my scroll core; but unless you are feeling brave, just keep them in for safety. :)

Enjoy!

*Ok, they are still slightly broken on screen edges. Certain configurations look fine, but others don't. Basically as long as you have path tiles neighboring each other on adjacent screen edges, it will look fine. But if you have a tile on one screen and no partner on the next screen, it will look broken. Fixing this probably wouldn't be that quick of a fix. But still it's way better than before, right?
 

Mugi

Member
Thats pretty neat.

not sure if it could be abused for (further) fixing this, but handlescreenloads has the defines for what tiles it checks for when it starts doing automated path drawing (it looks for #$80 and #$90 from the chr to initialize procedural path drawing.)
granted i dont really know whats wrong with it to begin with aside that joe just said it doesnt start doing that stuff because it doesnt see stuff next to it. maybe poking at the defines to slightly change the way it checks to do the pathing could assist on getting it to behave better with edges.
 

dale_coop

Moderator
Staff member
Awesome jorotroid! Thank you for sharing that.
Will test that... when I will be back home (I take my flight back to France, tomorrow morning... I'll be offline for 24hours).
But sounds great!
 

jorotroid

Member
Mugi said:
Thats pretty neat.

not sure if it could be abused for (further) fixing this, but handlescreenloads has the defines for what tiles it checks for when it starts doing automated path drawing (it looks for #$80 and #$90 from the chr to initialize procedural path drawing.)
granted i dont really know whats wrong with it to begin with aside that joe just said it doesnt start doing that stuff because it doesnt see stuff next to it. maybe poking at the defines to slightly change the way it checks to do the pathing could assist on getting it to behave better with edges.

So that JSR GetSingleMetaTileValues actually jumps to the code you are referring to. The scrolling code had been running the path code this whole time! The problem was that it was expecting the pointer to the table of tile date of the screen you are updating to be in temp16 and temp16+1, but the scrolling code puts that pointer in the updateNT_ntPointer and updateNT_ntPointer+1 variables instead. The temp16s are used for storing the pointer for the table for the attributes. All my code does is copy the information the scrolling code already got elsewhere and stores it into the temp16s for the path code to use. Once that routine is finished, the temp16s values get restored to whatever they were before.

I can sort of picture some ideas on how to further modify things to get the screen edge paths working better, but at this point I feel like it wouldn't be worth the effort.




dale_coop said:
Awesome jorotroid! Thank you for sharing that.
Will test that... when I will be back home (I take my flight back to France, tomorrow morning... I'll be offline for 24hours).
But sounds great!

Awesome! Can't wait to see what you put together for the competition.
 

Mugi

Member
Im not particularly interested of it either since i disabled the pathing code and use the path chr as normla metatile area instead, but i ran into that code while messing with it and figured that if you or someone else is still messing with fixing it,
it could be a worthwhile place to look into. Although, im not really sure what exactly would happen if you were to say, add more trigger tiles into the code that initializes the procedural drawing.
It could allow the paths to function better and initialize reagardless of if they see the next tiles or not, but then again, i suppose it could just royally mess things up further too.
I do know that those defines there are the only ones that do actually trigger it, since using the path tiles from any other coordinate allows them to draw as-is and only the tiles that are listed in those indexes start the pathing process.
(just change the 80 and 90 to 81 and 91 completely kills the autopathing since the metatile system never uses those as topleft corners of a metatile.)
 

dale_coop

Moderator
Staff member
jorotroid said:
So that JSR GetSingleMetaTileValues actually jumps to the code you are referring to. The scrolling code had been running the path code this whole time! The problem was that it was expecting the pointer to the table of tile date of the screen you are updating to be in temp16 and temp16+1, but the scrolling code puts that pointer in the updateNT_ntPointer and updateNT_ntPointer+1 variables instead. The temp16s are used for storing the pointer for the table for the attributes. All my code does is copy the information the scrolling code already got elsewhere and stores it into the temp16s for the path code to use. Once that routine is finished, the temp16s values get restored to whatever they were before.

I can sort of picture some ideas on how to further modify things to get the screen edge paths working better, but at this point I feel like it wouldn't be worth the effort.

This is blowing my mind... jorotroid. Even I can understand the code... I can't understand how the while thing works. I am still learning, digging everyday more deeply in that (when I can). The scrolling and even the paths, a half part of the screen loads... can't understand how it 's currently working >_<
But hey, very happy you are here to show us the way :) and be fixing the broken parts.


jorotroid said:
Awesome! Can't wait to see what you put together for the competition.

Ah ah... thanks ;) it will be simple game... but, I hope, will be fun to play.
 

jorotroid

Member
Mugi said:
(just change the 80 and 90 to 81 and 91 completely kills the autopathing since the metatile system never uses those as topleft corners of a metatile.)

That's pretty neat. I assume that you have to manually add those tiles into the screen data files? I'll have to look into that. May just kill some paths to make room for metatiles, but still keep some rows of paths.
 

Mugi

Member
yeah, you will have to either manually poke the screen data, or have a way to generate assets that use values outside of the bckchr/SSbckchr
if you want to keep some paths, you could take one row of them off (4 paths are loaded at once, iirc the code has it for #$80, #$90, #$A0 and #$B0, since a single path is 1 row of 8x8 tiles.) to drop off 2 paths and still keep 2. that way you'd still have 2 paths per tileset, and gain 8 new metatiles to use. I took a slightly more aggressive approach for this, since im terrible at using paths and i dont use the tile hud, so i literally nuked everything and use the entire CHR for metatiles now.
 

AllDarnDavey

Active member
I was using a similar cheat as Mugi to regain the pathing (and HUD) tiles as regular meta tiles. I found paths seemed hard coded to look for #$80, #$90, #$A0 and #$B0. I just avoided those specific tiles. At first I exported the screen, changed those tile values in a hex editor and re-imported the screen.

Currently, however, I just export an asset with everything set the way I want it except for tile address, with very descriptive name. Then open the export file in a hex editor change the tile value to the path/menu tile I want (but avoiding #$80, #$90, #$A0 or #$B0), then re-import the asset. The tile appears garbled in the screen painter (why I make sure to use a very descriptive name and save those areas for lesser used tiles), but it builds just fine. I lose one 16x16 area worth of path tiles avoiding those specific addresses the pathing system seems to look for, but it's a small price to pay for almost double screen tiles (more then double if I don't need to use text for the HUD).

Although with this path scroll fix (Thanks BTW), I'll have to decide if I want the WYSIWYG of using the path tiles like normal, or the extra control but less user friendly approach of hacking in outside normal range metatiles.
 

Mugi

Member
i do the same, except that like i said, i patched the code out so that you dont have to avoid the 80 90 A0 and B0 tiles so you gain full access to the whole chr.
then i just made a quick cli program for myself to generate assets outside of nesmaker.
i make whatever i want, import it to nesmaker, and paint my screen (shows garbage, really annoying) and off i go.
 

pit.baldriz

New member
Hi Guys!

I´m looking for the HandleUpdateObjects.asm file to edit, but can´t find it on my basic scroller game. Can anyone point me out the direction? Where should I find the Routines\Basic\System folders?

Thanks!
 

dale_coop

Moderator
Staff member
The "HandleUpdateObjects.asm" script is located in your GameEngineData\Routines\Basic\System\ folder. Open an Windows File Explorer and go in your NESMaker folder... then in the GameEngineData\Routines\Basic\System\ folder ;)
 

pit.baldriz

New member
dale_coop said:
The "HandleUpdateObjects.asm" script is located in your GameEngineData\Routines\Basic\System\ folder. Open an Windows File Explorer and go in your NESMaker folder... then in the GameEngineData\Routines\Basic\System\ folder ;)

Thanks a lot! I found the file, made the changes and now the paths are working!
 
Top Bottom