Quote:
Originally Posted by Don_Adan
Ok, more infos. If file must be depacked then use fast memory to load and depack to chip or fast.
Think how works original Turrican 2. This game needs only 0.5MB chip from $0 to $80000 area.
Then if You allocate 0.5MB of chip ram under OS and relocate all absolute addresses to new values, You can run this game from different memory, but it still needs only 0.5MB of chip.
F.e for original T2, of course I dont remember exactly location.
all ingame music are loaded at $60000, no difference if TFMX song has 60kB or 50kB,
all graphics level data are loaded $20000 and memory area from $20000 to $60000 is
reserved for level graphics data, not important if some levels used f.e only $20000 KB or $30000 KB. $40000 KB of memory is reserved for graphics level data.
Original T2 has short loading screen, then all old level data can be overwritten.
From Your example You need 1000k of memory. Then alloc only 1000k once.
And show short loading screen, and load/depack all necessary to 1000k area.
|
OK, that's what I thought you were suggesting at the start, but I was trying to explain why I think it is a bad idea.
It might make sense when working with tight 500k/ASM/1 floppy games, where the musicians, artists and level designers can be given hard limits. But there is a reason gamedevs moved away from this approach as games increased in size.
On the surface it may looks like all that changed in my AGA version was double the number of bitplanes, but there is a lot more to it. There is 600k of sound data the original did not have for a start (due to this version using a sound effect mixer). The loading/decompression times can not be compared between a 512k/1 floppy game and a 3MB/3 floppys game.
World 2-2 uses 128k of unique sound effects (mostly the wind tunnel). If I reserved that 128k globally, it would be wasted space for every other level. Instead World 5-2 can use that space for the final boss battle sprites (just an example - but every level has a different distribution of assets). I also desired to keep it flexible for future additions or new projects.
At the end of the day, it would have resulted in greater RAM usage and slower loading times (e.g. I measured 16 seconds to 40 seconds for World 1-2). So I prefer the dynamic approach in this case.