Make Common (shared lib) code not rely on global objects

[ivan-mogilko]

Problem

This task is complementary with #1833. Currently there are several global objects declared or defined in the Common code. A number of shared functions, such as ones that load data, or draw game elements (GUI classes), reference these global objects. Some of these objects are defined right in the Common, others may be defined in the engine part but declared in Common. This is a bad program structure, as it makes it difficult (if not impossible) to link some of the shared classes or functions separately; for instance if they are required for standalone tools.

These global objects are:

• [x] AssetMgr (a global instance of the AssetManager);
• [x] DbgMgr (a global instannce of the DebugManager, i.e. "logger"); this probably will have to be made a static member of DebugManager itself, resulting in a singleton class.
• [x] spriteset (a global instance of the SpriteCache);
• [x] font renderers array; (leave? as font renderers are mostly a incapsulated module)
• [x] guis array, as well as other complementary arrays: guibuts, guilabels, and so on.
• [x] guis global Options and Context: should leave until #2058 is resolved
• [x] ancient "graphical variables", see InteractionVariable globalvars[MAX_GLOBAL_VARIABLES]
• [ ] any other global variables? our_eip
• [ ] script's global variables: compilation options, ccError, currentline - need to decide what to do with these.

Solution

Instead of referencing global objects, the functions in Common code might receive necessary objects as arguments. In certain cases the logic may have to be changed a little: for example, instead of using strictly AssetMgr to open a data stream, a common function or a class may instead require that stream to be passed as a parameter (in such case the stream has to be opened prior to calling this common function, whether using AssetManager or other means - would depend on the context in which the common function is called).

See also

1833

2058

[ivan-mogilko]

Hmm, while the above is still a proper way to go, I remembered that the actual problem with GUI classes is bigger, and may require a more serious changes (it also is related not only to GUI classes, but primarily to them for some reason). I need to think this over and open a separate ticket perhaps.

EDIT: also to CharacterInfo.

[ericoporto]

our_eip

The set_our_eip calls could be hidden by a macro and then just define to empty - like #define SET_EIP(X). Other way could be a class EIP with a get and set to it's static member - and maybe having the methods inline defined in the header too.

[ivan-mogilko]

I think I'd rather remove uses of "our_eip" from Common code completely. That ended up to be a collection of utility and shared data loading (GUI drawing and input handling is probably the only notable exception, but there's #2058 for that).