Refactorings

[volca02]

General

• [x] get rid of OPDELIB_EXPORT macro altogether
• [ ] base directory is needlessly branched, which complicates include declarations in cmake. flatten that directory.
• [x] While we're at it, also remove obsolete files (ex. dyntype/dtypedef) - do we need Dark headers, still?
• [ ] iterator concepts are bulky and use dynamic allocations - since users of the iterator should hold refs to services they get the iterators from, the iterators could use move semantics and/or references. No need to allocate memory so much. Also they are virtual for no good reason in most places, which forces them to use heap, too
• [ ] huge amount of std::map uses that could be moved to unordered_map
• [x] typedef struct {} name is C construct - use struct name {} instead
• [x] Formatting of the project needs to be changed. Remove the usage of tabs, don't indent namespaces... Probably best use clang-format
• [x] use std::shared_ptr instead of the custom class
• [ ] lighten the use of dynamic allocations in general
• [ ] transition to std::vector/std::unique_ptr as appropriate for array alocations and simple allocations
• [ ] split data loaders into data handlers and graphics adaptation code - in case this project changes to different rendering lib, the code only needs to change the latter, not the former (MBin loader, Worldrep loader - WRCell should only enable comfortable access to cell data)
• [ ] Common listeners/callback classes: separate headers for them (don't include service headers in other service headers).
• [ ] Maybe replace the current Callback class with std::function
• [ ] Service registration could as well be done with lambdas or templatization, no need to implement whole factory class
• [ ] Get rid of GameStateManager and others. Drive the whole game via services.

Property service

• [x] dtype/dtypedef should be removed. Implement instead with packed structs and static descriptions - do not handle unknown types at all (there's aready StructDataStorage for that)
• [ ] PropertyChangeMsg should contain data of the property if applicable (templatize the message?)
• [ ] ActiveProperty methods should be prefixed on... as those are basically callbacks - but we don't need that class in general - there should be virtual methods for common events in the base class, instead.
• [ ] Template the property interface, add direct data type accessors. Do not force users to access fields by name if the type is available.
• [ ] Don't use BitArray for object masking in save/load - use lambda to filter the objects.
• [ ] Inject the type of data storage as a template parameter to Property. Don't force dynamic allocation there - the lifetimes of Property and datastore are bound, so should the objects (member by value).

Link service

• [x] Don't store links as shared pointers. Use references in the message.
• [ ] Make template out of relation. Don't use string maps to fill it.
• [ ] Inherit service a listener on metaprop relation. Rather than that, it could directly implement that relation - that would save some effort when inheritance changes.
• [x] Remove allocations from inherit service (InheritLnkPtr)

DataStorage

• [ ] StructDataStorage - store whole stored value at once. Where inappropriate, specialize the serialization templates. Don't handle fields via string indexation. Slow ugly bad

Rendering

• [ ] Transition to shader based rendering, remove the material overrides for transparency and other things
• [x] Lightmaps have atrocious packing. A lot could be improved - use exponent of 2 rounding for placement, place the largest lightmaps first (sort by size before building atlas)
• [ ] Terrain textures could be stored in atlases based on their sizes (I think they are 2^n, so easily tiled), again reducing batching
• [x] Light update code is only needed for dynamic lights, static lights can be attached to cells based on light list in cell (light_indices).

Scripting

• [ ] Re-evaluate the choice of python as the language choice
• [ ] Could also rewrite the bindings so that they are language-agnostic, and rather describe the project in a way adding a new language in will be simple
• [ ] Squirrel looks like an obvious choice for scripting language here, but have to look further

Invalid

• [x] Light propagation is wrong. The reason is it portal traversal. Should instead generalize the portal traversal code (common code to enumerate cell list given position and view direction) - use this for spotlight and omni light (omni light has to do it 6x to get all affected cells).

Note: This only would apply to dynamic lights (static lights have baked areas of influence in the WR chunk). Dynamic lights should be bounding sphere based anyway (not propagation based) to keep the original look intact.

For dynamic shadows (which would be interesting alternative to static low res lightmaps) the approach should be to generalize camera cell finding code in a base class. This will probably be done anyway since there might be no fat camera class after changing rendering engine.