A pointer to an object has quite different semantics so let's do this with proper virtual inheritance. This should allow to simplify a lot of pointer related checks in the compiler.
- fixed: IsVisibleToPlayer and optimized it a bit more.
- moved SourceLumpName to PClass, so that it can also be used for non-actors (there's a lot of non-Actor classes already.)
- separated the serializer for PClassPointer from PPointer. Even though not doable, a pointer to a class type is something entirely different than a class pointer with a restriction so each should handle its own case.
- added a few access functions for FActorInfo variables.
With PClassActor now empty the class descriptors can finally be converted back to static data outside the class hierarchy, like they were before the scripting merge, and untangle the game data from VM internals.
For these fields maps have no advantage. Linearly searching a small array with up to 10 entries is nearly always faster than generating a hash for finding the entry in the map.
- some optimization of access to OwnedStates in old DECORATE.
- consolidate all places that print a state name into a subfunction.
- allocate states from the ClassDataAllocator memory arena. States do not need to be freed separately from the rest of the static class data.
This reinstates the old FActorInfo as part of the meta data a class can have so that the class descriptor itself can be freed from any data not directly relevant for managing the class's type information.
This is not needed anymore because classes do not need to be replaced. The only reason this was implemented was the original design with the class descriptors taking on all the metadata themselves.
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.
