Show differencesHistory of post edits
Posted 05 February 2013 - 04:37 AM
Anyway, I implemented the system roughly like in my post before, seems to work fine, it now has three levels of storage:
- Objects currently on screen. This is a small amount, currently 6 enemies + 5 items, can be tuned as necessary. The limiting factor here is not actually memory, but CPU time consumption (C64 has 1MHz clock speed.)
- Pool of fully stored (position/type/other data) offscreen objects. Currently max.96, which is also fairly arbitrary and can be changed. Both the pre-placed and runtime-created objects are stored here, but runtime-created ones may be overwritten if necessary.
- The bit storage for the pre-placed objects in the whole gameworld. On map change time, relevant objects are created into the offscreen pool from here, using static data from disk for their positions & types. This static data needs to exist only during the map loading and can be overwritten with other runtime data immediately afterward.
The last two are now part of the save state. This means the memory use of the save state grew, which is somewhat uncomfortable, but the benefit in the gameworld making more sense to the player, as objects don't arbitrarily disappear, should outweight it.
Posted 05 February 2013 - 04:20 AM
Yeah, the NES is much more brutal than Commodore 64, as it has 2 KB RAM (if the cartridge has no extra) into which you have to store everything dynamic, therefore necessitating fetching almost everything directly from the ROM. It's a whole play mechanic of its own trying to get some flying enemy spawned at a convenient time by scrolling the screen just right