This is an incredibly costly way to do a debug check as it infests the entire VM design from top to bottom. These tags are basically useless for anything else but validating object pointers being passed to native functions (i.e. mismatches between definition and declaration) and that simply does not justify a feature that costs execution time in non-debug builds and added memory overhead everywhere.
Note that this commit does not remove the tags, it only discontinues their use.
See https://forum.drdteam.org/viewtopic.php?t=7588
Processing order is now the same as in Chocolate Doom
prBoom+ loads separate files after all WAD lumps though
This makes sense but would change loading sequence existed in ZDoom for years
This is somewhat brute-force thanks to the surprising lack of good documentation for the Ogg headers. The only other option would have been some rather bloated library for a function that should be 25-30 lines at most.
The idea is to have more control on the game side instead of dealing with these formats in the backend, which was done for FMod because it already had the decoders implemented.
However, with OpenAL this setup makes no sense and only complicates future extensions that can be better handled at a higher level.
No more error when running with +map command line parameter with classic HUD:
> VM execution aborted: Attempt to draw to screen outside a draw function
> Called from BaseStatusBar.DrawImage [Native]
> Called from DoomStatusBar.DrawFullScreenStuff at gzdoom.pk3:zscript/statusbar/doom_sbar.txt, line 140
> Called from DoomStatusBar.Draw at gzdoom.pk3:zscript/statusbar/doom_sbar.txt, line 41
- all 5 settings affected by uiscale have been changed to have the exact same semantics: -1, if supported means special scaling, this is available for HUD and status bar, 0 means to use uiscale, any larger value is a direct scaling factor.
- scaling is cut off when the factor is larger than screenwidth/320 or screenheight/200 because anything larger will definitely not fit.
- a lot of code has been cleaned up and consolidated. Especially the message code had an incredible amount of redundancy.
- all scaling options have been moved into a submenu. This menu is not complete, though - it still requires a special menu widget to convey the intended information without confusing the user.
- activated the RenderOverlay event, now that it can be called from the correct spot, i.e. right after the top level HUD messages are drawn. The system's status output will still be drawn on top of them.
- changed the effect spawn prevention of the Hexen flame strike weapon and reverted the attempt to fix this in FastProjectile.
This cannot be fixed in the base class, which was doing everything right. It's the flame missile that was doing undefined things by stopping its movement without clearing its missile flag. This cannot work because missiles are given some minimal forced velocity to ensure collision detection and any attempt to address this without clearing the missile flag is doomed to fail.
This allows using the UI scale or its own value, like all other scaling values.
In addition there is a choice between preserving equal pixel size or aspect ratio because the squashed non-corrected versions tend to look odd, but since proper scaling requires ununiform pixel sizes it is an option.
- changed how status bar sizes are being handled.
This has to recalculate all scaling and positioning factors, which can cause problems if the drawer leaves with some temporary values that do not reflect the status bar as a whole.
Changed it so that the status bar stores the base values and restores them after drawing is complete.
This would cut off overlong names and the handling for status bars with protruding elements was far too simplistic and worse, making assumptions based on game mode.
It now uses a virtual function to query the status bar itself for returning this information so it can be overridden and uses V_BreakLines to split the text if it is wider than the display.
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.
All our continuous integration targets have no problems with C99 isnan() macro but on Ubuntu 16.04 compilation fails
It appeared that some implementation of C++ Standard Library may undefine bunch of C macros to avoid conflicts with own declarations
- finished work on the Doom status bar. I also took the opportunity to fix the layout of the inventory bar which is a bit broken in SBARINFO.
- tuned the selection rules for deciding what creates the status bar, so that the most recent definition that can be found is chosen.
- got rid of the image list in the Doom status bar. The cost of the texture lookup is mostly irrelevant here so clearer and shorter code is preferrable.
- moved the box fitting code from DrawTexture into the native function to have all coordinate calculations in one place which is necessary to implement proper alignment default handling. Without higher level functions altering positioning the default can be set to automatic alignment determination, i.e. the value's sign decides where something is placed. Of course for special cases this can be overridden.
- use ANIMDEFS to animate the inventory arrow,
Fullscreen HUD done with the exception of key and inventory bar. I also used the opportunity to make it a bit more resistant against badly designed inventory icons.
- better handling of ForceScale for the fullscreen HUD that doesn't mess around with CVARs.
- moved the mug shot into the status bar, because this is global state that needs to be shared between different pieces of code which want to display a mug shot.
- SBARINFO should work off the current status bar settings instead of the ones stored in its script object
Note that there is no direct access, all this exposes is a single function to get the current face's texture which then can be drawn using the existing functions.
Note that the pop screens are special because they are not subject to scaling - they will always be drawn with the current resolutions clean scale. As a result they cannot use the HUD drawers but instead continue to use the low level draw functions directly.
- replaced Inventory.DrawPowerup with a GetPowerupIcon method so that the calling code can handle the drawing and apply its own rules. This was a major design flaw of allowing the inventory items to handle the drawing themselves, because they were unable to adjust to different HUD frontends. Note that any mod that overrides DrawPowerup will not draw any icon that expects to be handled that way!
- the alternative HUD now has its own, separate drawer that obeys the AltHUD's rules, and not the ones of the normal fullscreen HUD.
- the standard drawer has been scriptified as a virtual function.
- Both drawers now handle positioning of the icon inside its assigned box themselves instead of trusting the powerup item to do it correctly.
- DTA_HUDRules and Screen.DrawHUDTexture are to be considered deprecated because both do not integrate into the redesigned HUD code.
- merged BaseStatusBar and CustomStatusBar back together.
Since the low level draw functions are better done in native code for both performance and debuggability the split has become pointless.
- decided to ditch the widget system I had started to lay out. As it turns out that would make things far more complicated and slower than they need to be.
This makes VMValue a real POD type with no hacky overloads and eliminates a lot of destructor code in all places that call a VM function. Due to the way this had to be handled, none of these destructors could be skipped because any value could have been a string.
This required some minor changes in functions that passed a temporary FString into the VM to ensure that the temporary object lives long enough to be handled. The code generator had already been changed to deal with this in a previous commit.
This is easily offset by the code savings and reduced maintenance needs elsewhere.
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.
Using I_MSTime is not precise enough, because some camera textures can be done quicker. It was pointless anyway trying to make this multithreading-safe, the entire caching idea here makes no sense if two clippers can simultaneously work on the same level data without changing the memory organization and rendering it ineffective.
It used the expression's value type, but needs to use the variable's, which can be different when the assignment is synthesized from a builtin function.
- keep string registers which are being used as function parameters allocated until after the function call returns. This is for allowing to pass strings by reference which would avoid some costly constructor/destructor loops in the call instruction.
Back to Saturn X E1: Get Out Of My Stations (https://www.doomworld.com/idgames/levels/doom2/megawads/btsx_e1) uses tabs instead of spaces and bunch of 'Need data after par' warnings were printed during loading
PrBoom supports arbitrary space characters too
src/gl/scene/gl_clipper.h:150:23: warning: comparison of integers of different signs: 'int' and 'unsigned int' [-Wsign-compare]
src/gl/dynlights/gl_aabbtree.cpp:137:24: warning: using integer absolute value function 'abs' when argument is of floating point type [-Wabsolute-value]
src/gl/dynlights/gl_aabbtree.cpp:137:34: warning: using integer absolute value function 'abs' when argument is of floating point type [-Wabsolute-value]
src/gl/dynlights/gl_aabbtree.cpp:137:44: warning: using integer absolute value function 'abs' when argument is of floating point type [-Wabsolute-value]
src/gl/dynlights/gl_aabbtree.cpp:139:6: warning: using integer absolute value function 'abs' when argument is of floating point type [-Wabsolute-value]
src/gl/dynlights/gl_aabbtree.cpp:139:30: warning: using integer absolute value function 'abs' when argument is of floating point type [-Wabsolute-value]
src/gl/dynlights/gl_aabbtree.cpp:139:54: warning: using integer absolute value function 'abs' when argument is of floating point type [-Wabsolute-value]
src/gl/dynlights/gl_aabbtree.cpp:142:6: warning: using integer absolute value function 'abs' when argument is of floating point type [-Wabsolute-value]
src/gl/dynlights/gl_aabbtree.cpp:143:3: warning: using integer absolute value function 'abs' when argument is of floating point type [-Wabsolute-value]
src/gl/dynlights/gl_aabbtree.cpp:144:3: warning: using integer absolute value function 'abs' when argument is of floating point type [-Wabsolute-value]
src/gl/dynlights/gl_aabbtree.cpp:167:6: warning: using integer absolute value function 'abs' when argument is of floating point type [-Wabsolute-value]
src/gl/dynlights/gl_shadowmap.cpp:163:31: warning: '&&' within '||' [-Wlogical-op-parentheses]
src/p_saveg.cpp:367:16: warning: comparison of integers of different signs: 'unsigned int' and 'int' [-Wsign-compare]
src/p_saveg.cpp:402:60: warning: comparison of integers of different signs: 'int' and 'unsigned int' [-Wsign-compare]
src/p_setup.cpp:1553:39: warning: format specifies type 'ptrdiff_t' (aka 'long') but the argument has type 'int' [-Wformat]
src/scripting/zscript/zcc_compile.cpp:293:74: warning: field 'AST' will be initialized after field 'mVersion' [-Wreorder]
src/swrenderer/drawers/r_thread.cpp:113:21: warning: comparison of integers of different signs: 'int' and 'size_t' (aka 'unsigned long') [-Wsign-compare]
- allow treatment as one-character string constants as character constants. This became necessary because name constants already use single quotes and are much harder to repurpose due to a higher degree of ambiguity.
- fixed: protected methods in structs were not usable.
It looks like the memory management at use here is not capable of maintaining multiple instances simultaneously and the camera textures create another scene drawer so the initialization of the main scene drawer has to be delayed until after the camera textures are done.
- replaced TStaticArray with regular TArrays.
They had incomplete implementations preventing proper cleanup of the level loading code. It makes more sense to add the missing methods to the regular TArray and use that.
This also makes some changes to how the game nodes are used to avoid creating a copy: If the head node's pointer is stored in a separate variable, no code needs to check which of the two arrays gets used.
src/p_glnodes.cpp:670:3: error: cannot jump from this goto statement to its label
src/p_glnodes.cpp:682:4: error: cannot jump from this goto statement to its label
- consolidated the code to calculate a sprite's display angle for all 3 renderers.
As it turned out, they all differed in their feature support because they had always been updated independently by different people.
The values were still 8 and 32 respectively which applied to hardware from last decade, but for modern mods these are simply too low. New values are 64 as minimum and 128 as default.
- added script access to a sector's colormap and specialcolors fields. (Writing only through dedicated functions because these fields are render state which may need to trigger some form of refresh if the renderer changes.)
With no 3D floors this appears to be ok, but there are so many places where colormaps are being set in the software renderer that I cannot guarantee that I got all of them correct. This will need some testing.
- moved testcolor and test fades into SWRenderer files.
These CCMDs work by hacking the default colormap and were never implemented for hardware rendering because they require many checks throughout the code.
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.
This is only the parsing part, the arrays are not yet getting evaluated.
This required quite a hacky workaround because the gramma couldn't be made to accept the rule. The scanner will check if a 'static' token is immediately followed by a 'const' token and will combine both to a new 'staticconst' token that does not create conflicts with other rules.
- added a StartSlideshow ACS and ZScript command and extended the functionality to specify the slideshow's name when starting it.
This is for triggering any kind of intermission definition in the middle of a level - keep in mind that this may not be set up to loop!
This method was chosen because it avoids adding variable declarations to the global namespace which would have required a lot more work while polluting the grammar.
This way the global variables can be handled by a small bit of special coding in the struct generator.
If we have to write compiler specific code for micro-optimizations I am out.
The Posix compatible version nullified most the advantage on MSVC by writing out the XMM register to memory and then reading back the float.
That's not worth the hassle for an optimization that brings a few microseconds at best.
* dynamic lights also work in the true color software renderer and have been moved out of the OpenGL menu.
* created a separate software renderer menu and moved all relevant options there.
* delete non-applicable options when running in legacy mode.
* moved the OpenGL preferences menu one level up to eliminate a two-entry GL top level menu.
Removing this made me realize that calling the renderers' FakeFlat functions from the automap is inherently unsafe with the recent refactorings because there is absolutely no guarantee that the data may actually still be defined when the automap is being drawn.
So the best approach here is to give the automap its own FakeFlat function that runs independently of render data and assumptions of data preservation. This one can also be a lot simpler because it only needs the floor, not the ceiling info.
- optimized the math to get a plane equation from a linedef. The original code used a generic algorithm that knew nothing about the fact that Doom walls are always perfectly vertical. With this knowledge the plane calculation can be reduced to a lot less code because retrieving the normal is trivial in this special case.
- use the SSE2 rsqrtss instruction to calculate a wall's length, because this is by far the most frequent use of square roots in the GL renderer. So far this is only active on x64, it may be activated on 32 bit later as well, but only after it has been decided if 32 bit builds should be x87 or SSE2.
# Conflicts:
# src/gl/dynlights/gl_dynlight.cpp
# Conflicts:
# src/g_shared/a_dynlightdata.cpp
Since the true color software renderer also handles them there is no point keeping them on the GL side.
This also optimized how they are stored, because we no longer need to be aware of a base engine which doesn't have them.
- removed the LastCamera logic in RenderView. This code predates the first GZDoom release and apparently was only added because back then R_SetupFrame was not fully compatible with the hardware renderer. Today it is not needed anymore.
(Is there anyway to tone down GCC's warning level? It outputs too many false positives for potentially uninitialized variables in which the genuine errors get drowned.)
- enable precompiled headers for all non-system-specific MIDI devices.
- moved the native Windows and Mac MIDI devices into their respective sections in the project file so that they won't get compiled on the other ones.
This one was particularly nasty because Windows also defines a DWORD, but in Windows it is an unsigned long, not an unsigned int so changing types caused type conflicts and not all could be removed.
Those referring to the Windows type have to be kept, fortunately they are mostly in the Win32 directory, with a handful of exceptions elsewhere.
A major part of this device's implementation details about how to handle the callback were not encapsulated by the device class at all, they were #ifdef'd into the streamer class.
This puts everything into the device class which now exposes a clean interface to the rest of the game with no special handling aside from calling two additional virtual functions that are empty for the other devices
* make the critical section local to the respective platform instead of polluting everything with system specific symbols.
* moved system specific class declarations into the source file instead of having them in the global header.
This commit temporarily disables the Windows system device because it cannot be done without polluting the global header and still needs a bit of refactoring.
The approach being used here caused the entire sound system to be infested by windows.h, just to avoid copying around a handful of variables in one place, effectively preventing any compiling optimization.
Windows will now use the same internally defined structure for all MIDI processing which only for actual submission to the system player will be converted to the internal format.
Both files can now be included independently without causing problems.
This also required moving some inline functions into separate files and splitting off the GC definitions from dobject.h to ensure that r_defs does not need to pull in any part of the object hierarchy.
Most of those which still rely on ZDoom's own definition should be gone, unfortunately the code in files that include Windows headers is a gigantic mess with DWORDs being longs there intead of ints, so this needs to be done with care. DWORD should only remain where the Windows type is actually wanted.
