This was originally invented to fix the sprite offsets for the hardware renderer.
Changed it so that it doesn't override the original offsets but acts as a second set.
A new CVAR has been added to allow controlling the behavior per renderer.
No more locking insanity! :)
There are no locking counters or other saveguards here that would complicate the implementation because there's precisely two places where this buffer must be locked - the RenderView functions of the regular and poly SW renderer which cannot be called recursively.
In its current form this is quite useless. What's really needed is to require a lock on the RenderBuffer for the 3D scene, but since this is not needed for the 2D stuff anymore it can be done far simpler.
This was done mainly to reduce the amount of occurences of the word FTexture but it immediately helped detect two small and mostly harmless bugs that were found due to the stricter type checks.
When running in a confined environment (such as a snap) it may not be
possible to write to directories such as ~/.config. By using the $HOME
variable instead of the '~' shortcut, the confined environment can pass
an alternative 'home' directory with write privelges.
I have only changed this for posix/unix and haven't touched code for
MacOS, as I don't know if that behaves differently
Since this is a non-standard function it's better kept to as few places as possible, so now DirEntryExists returns an additional flag to say what type an entry is and is being used nearly everywhere where stat was used, excluding a few low level parts in the POSIX code.
- now that the frame buffer stores its render time, the 'ms' return from I_GetTimeFrac is not needed anymore, we may just as well use the globally stored value instead.
The only feature this value was ever used for was texture warping.
Since this calls I_WaitVBL, which resets the frame time, it was essentially just like calling a real-time timer anyway and nothing in it required a specific 0-timepoint.
The same applies to the ZScript interface. All it needs is a millisecond-precise timer with no semantics attached.
* store the frame time in the current screen buffer from where all render code can access it.
* replace some uses of I_MSTime with I_FPSTime, because they should not use a per-frame timer. The only one left is the wipe code but even this doesn't look like it needs either a per-frame timer or a timer counting from the start of the playsim.
- moved timer definitions into their own header/source files. d_main is not the right place for this.
- removed some leftover cruft from the old timer code.
- Added: d_main.cpp now searches for "gzdoom_optional_assets.pk3" - this can be changed in version.h for fork authors.
- Updated forum links to point to ZDoom.org.
The old code went through a list of predefined file names and looked each of them up in a list of predefined directories until it found a match. This made it nearly impossible to add custom IWAD support because the list of valid file names could not be extended.
This has now been switched around to run a scan for matching files on each given directory. With this approach it can look for *.iwad and *.ipk3 as IWAD extensions as well and read an IWADINFO out of these files that can be added to the internal list of IWADs, making it finally possible to define custom IWADs without having to add them to the internal list.
(This isn't fully tested yet so some errors may still occur.)
This fixes two issues:
* timer related texture animations are not being recreated multiple times if a scene renders multiple viewpoints (e.g. camera textures or portals.)
* interpolation is smoother when maps have a high think time of multiple milliseconds. A good map to see the difference would be ZDCMP2 which has a think time of 4-5 milliseconds. With the timer taken in real time after the thinkers have run and VSync on this resulted in alternating time slices of 11 and 21 ms between frame interpolations instead of an even 16 as should be done for smooth 60 fps because roughly every second frame was offset by those 5 ms.
