- moved the ALTHUDCF parser PClass::StaticInit, so that it gets done right after creating the actor definitions.
All left to do is not to reallocate the AltHud object for each frame but store it in a better suited place.
For this to work the 2D mode has to be properly set and unset at the right places so that no double mapping occurs and no render operation can happen while in 2D mode.
# Conflicts:
# src/d_main.cpp
# src/v_video.h
This code was written when the window wasn't resizable and didn't actually manage to restore it before. With today's changes this design flaw caused totally incorrect results.
Like Linux and macOS this will only support borderless fullscreen in the active desktop resolution now, which is what modern systems need.
The list of discrete resolutions has been removed as it makes no sense anymore with a fixed video mode - all the other scaling options remain active, though.
Remaining object(s) led to a potential crash on the next garbage collection cycle
Assertion failure was triggered during restarting in Debug configuration
This is better be made part of the 2D interface.
That would have been done long ago if it hadn't been for the totally incompatible way this was handled by the purely paletted software renderer.
Now with that out of the way there is no point keeping this code this deeply embedded in the renderer.
Lots of this was still laid out for DirectDraw. This removes most of Begin2D so that it can be done more cleanlz.
Note that this commit renders weapon sprites and screen blends incorrectly. Those will be fixed in an upcoming commit.
- with renderers freely switchable, some shortcuts in the 3D floor code had to be removed, because now the hardware renderer can get FF_THISINSIDE-flagged 3D floors.
- changed handling of attenuated lights in the legacy renderer to be adjusted when being rendered instead of when being spawned. For the software renderer the light needs to retain its original values.
This does not work with a setup where the same backend is driving both renderers.
Most of this is now routed through 'screen', and the decision between renderers has to be made inside the actual render functions.
The software renderer is still driven by a thin opaque interface to keep it mostly an isolated module.
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.
It now works the following way:
(0) - Force off (ZDoom defaults)
(1) - Force on (Doom defaults)
(2) - Auto off (Prefer ZDoom defaults - if DEHACKED is detected with no ZSCRIPT it will turn on) (default)
(3) - Auto on (Prefer Doom defaults - if DECORATE is detected with no ZSCRIPT it will turn off)
