We're all familiar with thee size limit on Keen:Vorticons levels. I was just playing around with a level resizing function, and started pondering the reason for this limit.
The limit is 0x4000, or decimal 16x384. That's one quarter of 0x10000. Now that I think about it, that makes mathematical sense, since there are two words, four bytes, to every tile (two bytes to describe the tile number, two more for the info/sprite plane).
This would indicate the level array is set to hold 65,535 bytes, which means it only requires a one-word integer to describe its size while keeping memory usage at a reasonable level.
Originally, I was writing this to ask if anyone knew the reasoning, but it seems in the process of writing it I've found a viable theory. Nonetheless, it would be interesting if this can be patched to push the limits of modding just that little bit further.
Obviously, there is a practical limit to how far it could be pushed while still using less than 600k conventional memory, but that would be for the realm of experimentation to discover.
Level size limit
- CommanderSpleen
- Posts: 1017
- Joined: Sun Aug 31, 2003 12:11 pm
- Location: The Land of Sparkly Things
- Contact:
Hmmmmn, interesting, we now have an official limit to level size that can be written into editors and such. (I have on occasion made a level too large for its own good.)
It does seem that no matter how big a level gets it doesn't affect the memory used by other areas of the game (Keen and the sprites.) I've never looked into this before, it certainly wuld be interesting if e knew where to patch.
It does seem that no matter how big a level gets it doesn't affect the memory used by other areas of the game (Keen and the sprites.) I've never looked into this before, it certainly wuld be interesting if e knew where to patch.
- Malvineous
- Posts: 113
- Joined: Sat Mar 13, 2004 12:54 am
- Location: Brisbane, Australia
- Contact:
I think this would be very difficult to patch, as a limit of 65536 means it's using a 16-bit register/variable to hold the value. You'd need to change all the commands referencing this location to use a 32-bit command instead, all the code that accesses the level would need to be adjusted for 32-bit and I imagine DOS real-mode memory management gets pretty scary when you allocate blocks larger than 64k.
Even if you had access to the game's source code I think there'd be a lot of work in it...
Even if you had access to the game's source code I think there'd be a lot of work in it...