Plan for cleanup and control of fades
Some fading happens automatically, such as when you use doors to other maps, or when you enter and exit battle. It would be very nice if the game author could be given control over whether or not these automatic fades happen.
This is also a good opportunity to clean up the rather messy code for triggering fades.
examining the mess
- Identify all the places where fades happen automatically, and make a list of them.
- Clean up the needf variable. needf means need-fade-in and it is uses to trigger fades back in after a fade out. (done)
- needf is not a global. Maybe it should be a member of GameState?
- needf is sometimes used as a countdown to zero, or sometimes as a simple 0/1 flag.
- The countdown may be very important in some cases, to allow the screen to be repainted before the fade... in other places it might be superstition.
- There should be a set of options (maybe bitsets in .gen?) to disable automatic fading
- some of the random battle related code only runs when needf=0. figure out exactly why
- Be sure to check all combinations of title/load screens enabled/disabled, since fading behavior is different
- the browse sub in browse.bas has a needf argument, which cannot be merged with gam.need_fade_in because browse is used mostly by custom. browse sub should be cleaned up separately.
- There are two classes of fades: those that are cancelled by a fadescreenout command, and those that aren't. See r6457
fixing the mess
- move/split needf to gam.need_fade_in and gam.fade_in_delay (done)
- We could add a "cancel pending fade" script command to cancel fades. This would remove the need for lots of bitsets, though not all fades can be cancelled in this way (eg. entering and leaving battle)
- ... (still planning)