Due to backwards compatibility needs and for flexibility this needs to be controlled by a gameinfo setting (fullscreenautoaspect):
0: Treat all images as having an aspect ratio of 4:3, this is the default for compatibility reasons
1: Scale all images to fit the screen, i.e. either pillarbox or letterbox them.
2: Scale all images to fill the screen.
3: Scale all images so that the center 4:3 area is always fully visible. This is the recommended mode for 16:9 images designed to be shown with the sides being cropped on narrower displays.
A new DTA_ tag - DTA_FullscreenEx also exists which allows specifying the scale mode directly
# Conflicts:
# src/rendering/v_video.cpp
# src/v_draw.cpp
# Conflicts:
# src/v_video.h
Now, all menus will use the same scale, i.e. it only depends on the screen width and a base size of 640. This nearly universally yields better results than trying to make a 320x200 screen fit.
The only exceptions to this are the intermission screens and the level summary. These, unlike the menu need to try to make a 320x200 screen fit, but without all the hackery that was present to adjust the menu display.
Note that since this affects globally visible script variables, both the intermission and summary drawers will not use their own set but instead temporarily override the global setting as long as they run their own code.
Changing the use of variables here might cause much worse problems with menu code so it wasn't attempted
# Conflicts:
# src/v_video.cpp
This was already far too generous and caused space problems, but with localization these became a lot worse, so now it will try to allocate at least 640 virtual pixels for the menu width and only go below that for small resolution ranges where the smaller value would result in too small text.
This partially reverts "- don't let the video scale let the screen end up with a client size less than 320x200, which may cause undefined behavior and trigger asserts in debug builds."
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.
Now it is no longer necessary to provide specially set up textures for rendering shaded decals, they can use any PNG texture now that contains a proper red channel.
Handling of the alPh chunk has been removed as a result as it in no longer needed.
d_net.cpp:2874:25: warning: format specifies type 'int' but the argument has type 'unsigned long long' [-Wformat]
gl/utility/gl_clock.cpp:240:38: warning: format specifies type 'int' but the argument has type 'uint64_t' (aka 'unsigned long long') [-Wformat]
v_video.cpp:883:71: warning: format specifies type 'unsigned int' but the argument has type 'uint64_t' (aka 'unsigned long long') [-Wformat]
v_video.cpp:883:80: warning: format specifies type 'unsigned int' but the argument has type 'uint64_t' (aka 'unsigned long long') [-Wformat]
* 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.
- Fix a crash if the window was resized before creating a game
- Fix main menu scaling being wrong if the video mode didn't match the unscaled screen size
src\v_video.cpp(1771): warning C4244: '=': conversion from 'double' to 'int', possible loss of data
src\v_video.cpp(1773): warning C4244: '=': conversion from 'double' to 'int', possible loss of data
For some files that had the Doom Source license attached but saw heavy external contributions over the years I added a special note to license all original ZDoom code under BSD.
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.
- 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.
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.
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 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.
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.
