Scenery boundbox refactor

[spacek531]

This PR adds user-definable bounding boxes to small and large scenery. It streamlines small and large scenery paint code by moving branches and calculations into import code instead of evaluating during paint. With user-definable bounding boxes, scenery can be created with bounding boxes that match the visuals of the scenery. This has the potential to reduce z-fighting, giving builders more freedom and expanding options.

The PR is divided into two commits which should be squash-merged. The first PR implements new loading and painting behavior, but keeps the existing paint behavior to verify the results are identical. The second PR removes the old behavior entirely, leaving only new behavior.

I have created a few test objects to test import behavior. Note that the ipdeco objects will trip the asserts of the first commit because of their custom bound boxes.
bboxtest objects.zip

[duncanspumpkin]

What is the point of the sprite offset part of this. You can already specify the offset of a sprite when specifying your individual sprites. This just leads to multiple places you can set the same value.

[spacek531]

Small scenery has an offset value of (1, 1, height), (3, 3, height), (15, 15, height) or (7, 7, height) depending on what flags are set - flags that control multiple behaviors. Large scenery has an offset value of (0, 0, height) always. Being able to manually set the offset value allows small and large scenery to draw sprites the same way.

[duncanspumpkin]

Small scenery has an offset value of (1, 1, height), (3, 3, height), (15, 15, height) or (7, 7, height) depending on what flags are set - flags that control multiple behaviors. Large scenery has an offset value of (0, 0, height) always. Being able to manually set the offset value allows small and large scenery to draw sprites the same way.

Yes we need to support the old flags but we shouldn't provide a new way to do this as you can already specify arbitrary offsets in the sprite. Large scenery does things correctly image offsets should always be 0,0 in paint functions, unfortunately small scenery did this wrong but we will have to keep supporting that.

[spacek531]

The 2D sprite coordinates are not redundant with regards to the 3D sprite offset on small scenery, because the 3D sprite offsets are tied to behavior flags. If a behavior flag changes, so does the 3D sprite offset. That means all the 2D sprite coordinates have to change to compensate. If a user mis-configures the object and sets the sprite coordinates based on that, all that work is undone when they configure the object correctly. That is bad user experience, whether the object has 4 sprites or 8 or 1024. The dilemma of accepting a mis-configured object versus the time to update all the 2D sprite coordinates is an unnecessary one that this PR solves.

This truth table shows the normal combinations of flags, their sprite offsets, and features that the flags enable/disable:

FLAG_NO_WALLS	FLAG_VOFFSET_CENTRE	FLAG_FULL_TILE	FLAG_HALF_SPACE	Sprite Offset	Scenery placement	Additional behavior
0	0	0	0	(7,7)	quarter tile	no additional behavior
0	0	0	1	(3,3)	half tile	no additional behavior
0	0	1	0	(15, 15)	full tile	incorrect z-order with adjacent quarter tile scenery
0	1	0	0	(7, 7)	quarter tile	blocks rain on full tile
0	1	1	0	(3, 3)	full tile	blocks rain on full tile, fixes aforementioned z-order issue
1	0	0	1	(3, 3)	half tile	blocks wall placement on full tile
1	0	1	0	(15, 15)	full tile	blocks wall placement on full tile, suffers from z-order issue
1	1	1	0	(1, 1)	full tile	blocks wall placement on full tile, fixes z-order issue

Memorizing this should not be required to make small scenery, and changing the sprites' coordinates based on these flags should not be required either.

[spacek531]

I fixed the compiler linking issue. To others who have issues where the game will compile on all platforms except windows, be careful of what files are marked as ClInclude and ClCompile in .vcxproj.