This needs to take the composite texture into account because panning in Build is based on tile size, not map dimension.
It was also redone to use floating point to get rid of the horrible precision of the scrolling effect.
* Before d545eb7aa9, `moveclouds()` simply set `ceilingxpanning`/`ceilingypanning`. Afterwards, it was accumulating with every passing loop.
* Despite fixing this, still seems a bit fast.
The way this is handled is the main reason why Build maps are size limited, but since it is extremely invasive it needs to be taken out of the game code piece by piece, this is the framework for doing this for Duke.
The main problem here is that there's two data arrays representing an actor - sprite and hittype and the engine only uses indices for reference.
By setting up hittype to contain a sprite reference, the function and iterator interface can be rewritten to use a single pointer instead to represent an actor.
The main objective is to reduce the number of accesses to the global arrays which constitute the biggest refactoring blocker.
The code base currently contains roughly 600 iterator loops directly referencing Build's global variables.
That state of things is not refactorable - these iterator wrappers are supposed to get rid of these explicit references.
The sprite lists may still need optimization. Due to different handling between Blood and the core engine they need to be written out completely which is quite wasteful.
* Blood had this right. It makes sense that the horizon be based around as it's easier to work with.
* Removed all associated game math to deduct default horizon of 100 when doing weapon zvel etc, meaning actual horizon can just be used.
* Re-did return to center function to work on the already converted pitch. Return speed should be 1:1 with previous code.
Whoever designed that map format with its idiotic encryption should burn in Hell >)
It's a needless complication and open invitation for errors.
To avoid follow up problems it now uses its own local struct for loading in the sprites and the global spritetype no longer depends on any map format and can be changed as the need arises.
Fixes#101
Apparently this is needed by some hires packs to fudge the sprite offsets.
Fortunately, setting sprite offsets is the only thing this was ever used for so it's relatively uninvasive.
