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.
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 a bad idea from the start and really only made sense with DirectDraw.
These days a FrameBuffer represents an abstract hardware canvas that shares nothing with a software canvas so having these classes linked together makes things needlessly complicated.
The software render buffer is now a canvas object owned by the FrameBuffer.
Note that this commit deactivates a few things in the software renderer, but from the looks of it none of those will be needed anymore if we set OpenGL 2 as minimum target.
This is a necessary first step for simplifying the texture handling in order to refactor it.
# Conflicts:
# src/gl/system/gl_swframebuffer.cpp
# src/textures/textures.h
# src/win32/fb_d3d9.cpp
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.
These cannot be done with the regular textures so there needs to be an option to create more than one native texture per FTexture. For completeness' sake there is also the option now to create a paletted version of a texture if the regular one is true color. This fixes a long standing problem that translations were not applied to non-paletted textures.
The native byte order converters were defined as macros which hid some issues due to lack of type checks.
Additionally the ???Long variants taking 'long' variables were removed, because longs are not always 32 bits so this could be destructive.
As a result of this, removed several DWORDs from struct definitions in i_crash.cpp.
* do not use the global temp directory. Instead create one in the AppData folder.
* removed lots of unneeded code from tmpfileplus.
* use C++ strings in there.
- 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.
This reverts commit b8c0e78c91 et al.
Instead, use the already provided access function I_FindName to get the file name from findstate_t.
Also made the contents of findstate_t private so that use of the access functions is required to retrieve the information and direct access triggers a compile error.
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.
Restored old exception handling for 32-bit Windows executable
Tested on 32-bit Windows XP (previously exited without notification), 64-bit Windows 7 and 10 (previously deadlocked in system DLLs)
This is to ensure that the Class pointer can be set right on creation. ZDoom had always depended on handling this lazily which poses some problems for the VM.
So now there is a variadic Create<classtype> function taking care of that, but to ensure that it gets used, direct access to the new operator has been blocked.
This also neccessitated making DArgs a regular object because they get created before the type system is up. Since the few uses of DArgs are easily controllable this wasn't a big issue.
- did a bit of optimization on the bots' decision making whether to pick up a health item or not.
I have no idea why they were even in there, as they intentionally circumvented all GC related features - they declared themselves fixed if prone to getting collected, they all used OF_YesReallyDelete when destroying themselves and they never used any of the object creation or RTTI features, aside from a single assert in V_Init2.
Essentially they were a drag on the system and OF_YesReallyDelete was effectively added just to deal with the canvases which were DObjects but not supposed to behave like them in the first place.
This is necessary because the hardware accelerated renderers will hide the problem, but with pure software rendering to a locked hardware surface, like DirectDraw can result in a crash.
Note that ANY mod that gets caught in this did something wrong!
Currently this is only being used for draw operations that are not automap related, i.e. DrawLine, DrawPixel and FillSimplePoly are not subjected to it.
Note that the Strife status bar does not draw the health bars yet. I tried to replace the hacky custom texture with a single fill operation but had to find out that all the coordinate mangling for the status bar is being done deep in the video code. This needs to be fixed before this can be made to work.
Currently this is not usable in mods because they cannot initialize custom status bars yet.
This has increasingly become an obstacle with the hardware renderer, so now the values are being stored as plain data in the sector, with the software renderer getting the actual color tables when needed. While this is a bit slower than storing the pregenerated colormap, in realistic situations the added time is mostly negligible in the microseconds range.
