Difference between revisions of "Talk:Managing the Item Limit"
m |
m |
||
| Line 9: | Line 9: | ||
Memory is always an issue in 16-bit DOS binaries. It is not possible for a single DOS pointer, in 16-bit mode, to address more than 64K of memory. | Memory is always an issue in 16-bit DOS binaries. It is not possible for a single DOS pointer, in 16-bit mode, to address more than 64K of memory. | ||
| − | The simplest way to implement the savefile format is that each file corresponds to one | + | The simplest way to implement the savefile format is that each file corresponds to one array of C structs. [[PROJECT.DAT]] is the exception, but even that may be a single C struct internally. Then each file in the savefile is simply dumping/loading the array using the relevant functions from stdio.h...very fast, somewhat clean. |
Good programming practice would be to either dynamically allocate the relevant arrays on tactical/battlescape start, or statically allocate them. Since none of the save files vary in length or have explicit record counts, I'd conjecture that the intended sizes of the arrays are compile-time constants, either #define'd or (for statically allocated arrays) computed using the sizeof(array)/sizeof(array_element) paradigm. | Good programming practice would be to either dynamically allocate the relevant arrays on tactical/battlescape start, or statically allocate them. Since none of the save files vary in length or have explicit record counts, I'd conjecture that the intended sizes of the arrays are compile-time constants, either #define'd or (for statically allocated arrays) computed using the sizeof(array)/sizeof(array_element) paradigm. | ||
Revision as of 19:33, 20 January 2007
Does anyone know if modding the .exe to raise the 80-item limit is feasible? The 80-item limit is the most "dated" thing about the game... that, and the limit on alien containment capacity.
It's not possible as of now. (We do not know the location of this limit). Even if we could "up" the limit for X-COM agents, it would cut into the aliens item limit and some alien units would probably get "shorted" on weapons since there are only so many items which can be placed on the battlescape map. A real pickle this is, but a necessary evil. --Zombie 19:53, 19 January 2007 (PST)
Well, I should have said, raise the overall limit as well... since memory isn't an issue now. Eric 10:30, 20 January 2007 (PST)
Memory is always an issue in 16-bit DOS binaries. It is not possible for a single DOS pointer, in 16-bit mode, to address more than 64K of memory.
The simplest way to implement the savefile format is that each file corresponds to one array of C structs. PROJECT.DAT is the exception, but even that may be a single C struct internally. Then each file in the savefile is simply dumping/loading the array using the relevant functions from stdio.h...very fast, somewhat clean.
Good programming practice would be to either dynamically allocate the relevant arrays on tactical/battlescape start, or statically allocate them. Since none of the save files vary in length or have explicit record counts, I'd conjecture that the intended sizes of the arrays are compile-time constants, either #define'd or (for statically allocated arrays) computed using the sizeof(array)/sizeof(array_element) paradigm.
Note that there is a total limit of 64K on static data in all 16-bit DOS memory models. So the larger save files (e.g, map.dat and soldier.dat) have to be dynamically allocated.
In any case, there is plausibly no single "location" for these limits -- such a mod would have to not only locate and adjust the storage (and all later storage, in the case of statically allocated array), but also locate and adjust the compile-time constants everywhere they were used.
Zaimoni 13:27, 20 January 2007 (CST)