Using direct page as a cache is a bad idea a lot of games do

This is an archive of a topic from NESdev BBS, taken in mid-October 2019 before a server upgrade.
View original topic
Using direct page as a cache is a bad idea a lot of games do
by on (#169834)
Copying something to the zero/direct page, use it a couple times, and then storing it back.

I keep seeing this being done in SNES games and it makes me wonder, did developers actually think they were optimizing code by doing this? It makes sense if something was kept in the direct page, or used in the direct page for a long enough time, but I typically see it in places where the cycles taken to move something back and forth outnumber the cycles saved from direct page addressing.

I wonder if there's some sort of feedback loop, where the programmer does this type of "optimization" first, then it lags, then he "optimizes" it even more, and it lags even more, and so on, without realizing it was his "optimizations" all along that caused it.
Re: Using direct page as a cache is a bad idea a lot of game
by on (#169835)
It sometimes simplifies the code to not have to do a bunch of indexed lookups if you can read a couple of fixed ZP locations instead. In this case, it wouldn't be about a speed boost.
Re: Using direct page as a cache is a bad idea a lot of game
by on (#169848)
That and a lot of instructions don't support indirect addressing modes.

Are you available to do a code review on some 6502 projects to check for anti-patterns like the ones you say you're always finding in Super NES games?
Re: Using direct page as a cache is a bad idea a lot of game
by on (#169885)
I feel kind've stressed out from programming right now. Not only have I been working on my game, but I was also helping smwcentral.net optimize some code in SMW (I actually got passed the mods this time), which happens to be full of moving stuff to and from the direct page.