with Subdivisions > 1, m_exprTransformFunction uses too much memory, and
very few scrollers use this. Usually, per-item effects can be done better by
using DynamicActorScroller and doing the effects on item load (but this can
do some things that can't).
it's assumed to be free to use when translating the information on http://www.x-saru-x.com/index.php?mode=fontr
These graphics require modified metrics (so that the arrows just don't appear out of nowhere). I'd commit the modified metrics myself, but I'm unsure if I can do that with my status.
Also, ScreenGameplay oni life frame should be redir'ed to ScreenGameplay life frame with this setup.
backup directory immediately after a successful load. This ensures that
the data we're copying is valid, so after a successful copy, the backup
is valid, too. This has a couple problems:
- Copying takes a while. It's much faster to move data.
- Data shouldn't be written during a profile read. Players should be able
to assume that it's safe to remove the memory card at any time except
when the game is explicitly saving.
- Copying good data from one place to another is just as prone to error as
initially writing it. It's at least as easy for the backup copy to fail
and result in a bad backup as it is for a save to fail in the first place.
Instead, when we successfully load profile data (and not from a backup),
set a flag. Later, when we save over that data, we'll clear the flag and
move the data we're about to overwrite to the backup.
PAGE_TYPE_ALL_STEPS, PAGE_TYPE_*_COURSES) and ScreenRankingLines
(PAGE_TYPE_CATEGORY, PAGE_TYPE_TRAIL).
Use DynamicActorScroller for ScreenRankingScroller; reduces overhead
significantly.
ScreenCredits and ScreenRanking without constructing dozens or hundreds
of actors, which saves a lot of memory and is easier to manipulate. This could
also be used to support CourseContentsLists for long courses cheaply, etc.
Chris Danford