6c0ae092c6
The g? structs had a mix of variables that were written to
the savefile, and those that were not.
For better clarity and to distinguish those that end up in
the savefile, relocate some g? variables that get written
directly to the savefile into different structs.
This updates EDITLEVEL, although technically it probably
didn't need to, since savefile contents are not changing.
Details:
gb.bases -> svb.bases
gb.bbubbles -> svb.bbubbles
gb.branches -> svb.branches
gc.context -> svc.context
gd.disco -> svd.disco
gd.dndest -> svd.dndest
gd.doors -> svd.doors
gd.doors_alloc -> svd.doors_alloc
gd.dungeon_topology -> svd.dungeon_topology
gd.dungeons -> svd.dungeons
ge.exclusion_zones -> sve.exclusion_zones
gh.hackpid -> svh.hackpid
gi.inv_pos -> svi.inv_pos
gk.killer -> svk.killer
gl.lastseentyp -> svl.lastseentyp
gl.level -> svl.level
gl.level_info -> svl.level_info
gm.mapseenchn -> svm.mapseenchn
gm.moves -> svm.moves
gm.mvitals -> svm.mvitals
gn.n_dgns -> svn.n_dgns
gn.n_regions -> svn.n_regions
gn.nroom -> svn.nroom
go.oracle_cnt -> svo.oracle_cnt
gp.pl_character -> svp.pl_character
gp.pl_fruit -> svp.pl_fruit
gp.plname -> svp.plname
gp.program_state -> svp.program_state
gq.quest_status -> svq.quest_status
gr.rooms -> svr.rooms
gs.sp_levchn -> svs.sp_levchn
gs.spl_book -> svs.spl_book
gt.timer_id -> svt.timer_id
gt.tune -> svt.tune
gu.updest -> svu.updest
gx.xmax -> svx.xmax
gx.xmin -> svx.xmin
gy.ymax -> svy.ymax
gy.ymin -> svy.ymin
Related note:
There are some pointer variables that are heads of chains that were not
moved from 'g?' to 'sv?', because they are not actually written to the
savefile directly, but the objects/monst/trap/lightsource/timer in the
chains they point to are. That can be changed, if desired.
Examples: gi.invent, gm.migrating_objs, gb.billobjs, gm.migrating_mons,
gf.ftrap, gl.light_base, gt.timer_base
Jan 2002 The MPW compilers are now supported again. Support for 68k has been discontinued due to a lack of a debugging system for 68k binaries. Note that the tiled MacOS X port uses the Qt windowport and the UNIX build system, not this windowport code. 26 Nov, 1999 NetHack 3.3.0 was built with Metrowerk's Pro 4 compiler on a PPC system. We are still compiling with 68K alignment because we know it works. No one has checked lately if the PPC alignment bug still exists. 23 May, 1996 NetHack 3.2.1 was built with Metrowerk's DR8 compiler on a PPC system. The official 68K and PPC versions were compiled with 68K Alignment to share files. The 3.2.0 versions were compiled with PPC alignment, but it was discovered that the Metrowerks 68K compiler has a bug with PPC alignment and structures that can be aligned to a single byte. This bug _may_ be fixed in DR10, it is not fixed in DR9. Why bother with PPC alignment at all? Because the space saving from 68K alignment is small and the PowerPC version will run better. The 68K version was compiled with 4 byte ints using the far model. Only the Metrowerks compiler has been used to compile the code in a long time. It is _very_ likely that the other compilers, Think C and MPW C, will no longer be able to compile NetHack out of the box. They and their files have been moved to the "old" directory until such time that someone can compile with them.