What changed in EDuke32, build by build

This means that the internal change done to these sprite members in r3159 is hidden from CON for backward-compatibility purposes. Note that .cstat and .{ceiling,floor}stat aren't touched, and will return unsigned values to CON.

Described here: http://forums.duke4.net/topic/3857-the-crash-thread/page__view__findpost__p__141202

Also, add a missing "pragma pack(pop)" to build.lua.

I think this may fix some negative "non-profiled overhead" that I have been seeing.

http://forums.duke4.net/topic/6031-eduke32-crashes-if-hrp-model-skin-not-available/

- Eliminate use of the C++ standard library from arttool. I improved some of the program's workings but it continues to corrupt my art files in certain circumstances. (Note: Not a regression; it happens with previous revisions.) - Construct "make utils" for the game side following the pattern of the engine. - Move ivfrate to this new distinction. - Minor Makefile cleanup and tweaks, mainly to facilitate CLANG=1 and to formalize text output in special cases.

I think there's also a fix for the CON precache system breakage in here (lost it in my local tree when I started getting the C++ build working in MSVC, sorry!)

Specifically, if the first wall of the sector-to-split is to the left or right of the *start* of the splitting line AND the sector has no TROR extensions, make these two the new nextwalls of the respective split sectors.

Exporting only (de)compression functions. Also, different reader/writer functions can be set.

It would be something like "ProjectileData\[([^]]+)]\.([a-z_]+)".

This requires ripping out the .proj member of tiledata_t back into ProjectileData[] again because it was the only one in g_tile[] that changed during the course of a game. The g_tile[] array is now also correctly flagged as "constant throughout a game" (DS_NOCHK). Savegame version bumped.

It's still not pretty though since there's no interpolation from G_DrawRooms().

On the engine side (functions starting with L_), there are now the basic parts like state creation and running code from strings and files. The game and editor can add to that by e.g. loading whatever they please into the state. Their functions start with El_ and Em_, respectively. The Lua scripts still reside in source/lunatic, even for the common ones. This is because they will be embedded into the binaries as bytecode or compressed source eventually, so their location on disk will be irrelevant.

See the next commit for details.

Also, enable showing sprites in Mapster32's overhead view again, since that was one (the only?) use of that code path. The uninitialized read was introduced in r2927.

Also, reorganize some G_DrawRooms() code a little without changing anything.

Instead of later in P_ProcessInput(). This fixes one drawrooms() call in between where the sectnum is the camera's, but the position the player's, which can lead to a slow "outer view" render in Polymer.

arrays; any write access to them will run the corresponding hook and write to the [sector/wall/sprite/tsprite]clean array. Note: tsprite and sprite use the same hook and require running a few more instructions per access in order to disambiguiate; this could be made more optimal (like the other arrays) by clearly separating the types in the game code. Note #2: taking a member's address currently marks it dirty because of tons of helper functions across the editor code. I don't know how many read-only accesses we have after taking a member address, but it could also be fixed with some finessing of the code.

The command-line utility can query and set the frame rate of IVF files, since apparently encoders don't care too much about setting proper values in the IVF header. Also, add the utility to the synthesis build. On the playback side in EDuke32, get rid of the 1/(2*fps) "correction" if the FPS numerator is <1000 (presumably used in older encoders) and properly print the frame rate's fractional part.