catarm_savegame_compat.txt

Nasty...

* Note: These are near pointers.

skycolor can be any of
- &debug_sky
- &scolor
- &sky_colors[0] (commented out in Arm/Apoc)
- &sky_colors[gamestate.mapon] for some map (commented out in Arm/Apoc)
- (See note about **** PlayLoop can increment the skycolor POINTER (until read value is 0xFFFF).
- Could also decrement but that's commented out...
- scolors, an input to InitBgChange. This is either sky_daytonight (commented out in Arm/Apoc) or sky_lightning.
- C5_WIZ.C:ReadScroll, &blackcolor (set just temporarily so not saved; commented out)
- C5_WIZ.C:ReadScroll, skytemp (just old value of skycolor; and again commented out)

Similarly groundcolor can be any of
- &debug_gnd
- &gcolor
- &gnd_colors[0] (commented out in Arm/Apoc)
- &gnd_colors[gamestate.mapon] for some map (commented out in Arm/Apoc)
- **** PlayLoop can increment it like skycolor
- Also decrement, but again that's commented out
- gcolors, an input to InitBgChange. This is however NULL so InitBgChange never actually sets this.
- C5_WIZ.C:ReadScroll, &blackcolor (set just temporarily so not saved; commented out)
- C5_WIZ.C:ReadScroll, gndtemp (original groundcolor pointer; commented out)

A FEW MORE NOTES THAT CAN BE USEFUL:
- Looks like InitBgChange is always called with gtimer==-1, so effectively
the groundcolor pointer is never incremented in PlayLoop.
- skycolor *can*, however, be incremented (for the lightning). This is done
by a call to InitBgChange with skytimer==1 and scolors==sky_daytonight.
- So in *theory*, skycolor should only increment as long as it goes over
sky_daytonight (or similarly sky_lightning in CatAbyss), until the value
of 0xFFFF is reached at the end of the sky colors array.

PROBLEM:
- It looks like if sky color is changed in Apoc using a cheat while in the
middle of a lightning, it CAN lead to a buffer overflow. This must depend on
the EXE layout.