The source (CPP and H) is over 6Mb for all the sub projects.
The problems with using a larger variable in legacy code are legion. This code was written in the 90s to fit 386 PCs with 1MB memory, and where disk access was slow, and in any case MSDOS did not provide disk paging virtual memory swap file like windows does. So bytes and so on are common. Object oriented code not used, as back then the space for OO bloated things too much.
Simply changing variabl X from an unsigned byte in the main header file solves no problems, your problems have just started!
- If this variable forms part of any saved memory structure (save game files, OOB files etc), then you have just rendered all these data toast. You will have to build and test some sort of data-massage utility to convert all these files. Bad enough for all the stuff you have control of, but you have no control over any third-party stuff (scenarios, OOBS etc) out in the field.
- You then have to find out everywhere this variable is used, e.g. stuffed into a temporary holding variable, or passed as a parameter from some routine to a subroutine, and ensure these are appropriate. If not, you have to change these, and then recompile and find all the other things that call these subroutines and are now broken. Follow the chain into the subroutines, and check these for temporary holding variables and so on and repeat recursively. Be careful to check that any places it gets stuffed into are correct for signed or unsigned.
- Now check everywhere this variable (and any changed local copies) are used for maths routines, and bitwise logic operations and so on, check any bitmasks used etc. Check any "safety" code used on this inside routines for upper or lower bound tests. Now it is bigger, any result variable may need to be increased to fit. This can have yet more knock-on effects, especially if that result variable was say a global that is referred to in 9,999 other places and if you change the size, these routines all need fixing.
- Any variables that had to be changed to accomodate the knock-on effects of the changed variable need to be checked as if they were this new variable, and subroutines etc, and anything depending on these. If the variable(s) have file storage effect you need to add this to your data massage exercise.
- Assuming you have all these fixed (changing something is like snapping one link in a spider web. Sometimes one link is affected, sometimes it affects everything), you now need to check all your file i/o routines. Also - if this variable is something that can be input by the user (say in the scenario designer perhaps) - check all the UI I/O routines for that as well to ensure the correct conversions, upper and lower bounds checks and so on.
- Now check all your memory allocation (mallocs callocs, news etc) for things like file block data allocation etc.
- Oh joy!, your variable is now bigger. So if it is displayed anywhere in the User Interface you may now need to allocate more column space for it to allow for this. Maybe the extra space will fit the UI no bother, but be prepared to have to completely or at least partially rewrite some parts of the UI that require a new screen layout to accomodate the extra few columns due to lack of space. Fix and test UI, and if needed update any end-user documentation. (Changes involving any rearrangement of the game UI will probably take a lot of time. It is not forms-based, like say Delphi or C++ Builder is for Windows apps like the GameOptions launcher
- Now, repeat the exercise for all the utility programmes like Mobhack, map editor and so on. Remember that Mobhack uses Delphi (started as Turbo Pascal back in 95 ods, then Borland Pascal for Windows, then Delphi) as opposed to C++.
- Do some unit testing yourself. Fix any problems. Then release to playtesters, and see what unexpected side-effects arise. Fix any new problems. rinse, repeat as required. Build release package and issue to end users. End users will probably find cases the pre-release playtesting failed to spot..
That is about it for upsizing one variable. nothing for actually changing any algorithms using it (that is a "how long is a piece of string" sort of thing
Cheers
Andy