It sometimes happened when changing image_* cvars for compression and
then vid_restarting and then running listImages.
In one case the whole process hung and len was a ridiculously big number
=> most probably the (unsigned!) size_t overflowed by subtracting a
number > len (most likely from input_field.GetCursor()).
So I just made it a plain signed int.
I couldn't reproduce the issue anymore after doing this change.
.. when setting IMGUI=OFF in CMake, of course.
I don't think it's a very good idea to remove that directory, or to
disable ImGui support for any reason besides "I'm on an ancient
platform that doesn't support C++11", but this is an simple enough
change so whatever.
there are lots of values between
GL_COMPRESSED_RGBA_S3TC_DXT5_EXT (0x83F3) and
GL_COMPRESSED_RGBA_BPTC_UNORM (0x8E8C). We don't support them as valid
compressed formats.
(strictly speaking BPTC is not DXT so the function name doesn't fit 100%
anymore, but DXT1-5 is now BC1-3 and BPTC is BC7 so.. close enough.)
Apparently OpenGL (or at least nvidias driver?) is unhappy if the
smallest mipmaplevel isn't 1x1 pixels. It doesn't show any error in
debug messages, but it's just set to black.
This can be worked around by setting GL_TEXTURE_MAX_LEVEL
Can have better image quality than S3TC (DXT1-5).
based on a patch by Github user "Manoa1911":
https://github.com/dhewm/dhewm3/issues/447#issuecomment-2254369525
Only supports DXGI_FORMAT_BC7_UNORM - I hope that's enough?
BC7/BPTC is supported by all GPUs that support DX11 (or newer)
or OpenGL 4.2 (or newer). That should be the case for Radeon HD 5000
and newer, Geforce 400 and newer and Intel iGPUs from Ivy Bridge on.
Those GPUs are from 2009/2010, 2012 for Intel.
fix#447
it has a member with a vtable that gets overwritten then, that's bad
(even though I've never seen a crash caused by this?!)
Instead set the members to NULL/zero manually
After loading a texture, Doom3 calculates an MD4-sum of it.. this is
mostly pointless and only used for the "reportImageDuplication" console
command, but whatever.
The problem here was that the image was 32000x2000 pixels (due to some
error when creating it) which dhewm3 wanted to convert to the next
bigger power-of-two values with R_ResampleTexture(), but that function
clamps to 4096x4096, so the actually used pixeldata was for 2048x4096.
However, R_ResampleTexture() didn't communicate this to its caller,
and thus a too big size was used for calculating the MD4-sum and it
crashed.
That's fixed now and also a warning is printed about this.
BUILD_CPU has been replaced by D3_ARCH, which is also set by CMake on
most platforms, except for Windows, there it's set in neo/sys/platform.h
because CMake is not able to tell us what CPU platforms it's targeting
(for other platforms we parse the output of gcc/clang's -dumpmachine
option, but for MSVC that's not an option, of course)
in SkinDeep regs not being initialized caused random crashes
(in dhewm3 I haven't seen that so far, but fixing this won't hurt).
From SkinDeep commit message:
In idRegister::SetToRegs() at `registers[ regs[ i ] ] = v[i];`
regs[i] contained values like 21845 or 22010 or 32272, even though
the static registers array that's written to there only holds 4096
elements (it's `static float regs[MAX_EXPRESSION_REGISTERS];`
from `idWindow::EvalRegs()`).
So it overwrites other data, likely other global variables, like
`gameLocal.entities[4967]`, that now contain garbage and next time
someone tries to use them, bad things happen.
In this case, if someone tries to dereference gameLocal.entities[i]
and the pointer at i contains garbage, there's a segfault (crash).
462404af67
"gui::horPad" is now called "gui::cstHorPad", "gui::vertPad" is now
called "gui::cstVertPad", so it's clearer that they belong to the
CST anchor system.
I also added "gui::cstAspectRatio", the aspect ratio of screen or Doom3's
window resolution (when using windowed mode).
Furthermore "gui::cstWidth" and "gui::cstHeigh" with the screen
(or Doom3 window) resolution in *virtual* pixels, based on that GUI
640x480 coordinate system.
For widescreen resolutions, "gui::cstHeight" is always 480 and
"gui::cstWidth" is scaled according to the aspect ratio (>640).
For tall resolutions, "gui::cstWidth" is always 640 and "gui::cstHeight"
is scaled according to the aspect ratio (> 480).
So far one could only use either naturalmatscale or matscalex/matscaley.
Just "naturalmatscale 1" lets a texture repeat in its native size, i.e.
if you have a 64x32 texture and a 320x160 (in the 640x480 GUI coordinate
system) windowDef, it will be repeated 5 times in each direction.
If you resize the windowDef to 384x160, it will repeat the texture
6 times horizontally (and still 5 times vertically).
matscalex/y allow scaling that texture. If both values are set to 2,
(and naturalmatscale to 1) the 64x32 texture in a 384x160 windowDef
will be repeated 12 times horizontally and 10 times vertically, at half
the size per direction.
Without naturalmatscale it would be repeated 2 times in each direction,
no matter how big the windowDef is.
they are set before onActivate and also whenever the (Doom3 SDL) window
size changes, in that case additionally the "UpdateWindowSize" Named
Event is called in the script, in case you wanna do anything special
in that case:
onNamedEvent UpdateWindowSize {
set "print" "UpdateWindowSize - horPad:" "gui::horPad"
"vertPad:" "gui::vertPad";
}
horPad is the width of the padding border (empty space) between the
left/right border of Doom3's SDL window and a centered
(cstAnchor CST_ANCHOR_CENTER_CENTER) full-sized windowDef in virtual
pixels (in the Doom3 GUI coordinate system, which usually is 640x480).
vertPad is the same for the padding border between the top/bottom border
and a centered full-sized windowDef
One of those values will always be 0.
So for example if you play Doom3 at 1600x1200 (a 4:3 resolution like
640x480) both horPad and vertPad are 0.
If you play at 1680x1050 (16:10 resolution) and your windowDef Desktop
is 640x480 (the default), horPad is 64 (and vertPad is 0), because
there are 64 virtual pixels between the left window border and a
centered 640x480 windowDef (and also between the centered windowDef
and the right window border.
gui::horPad and gui::vertPad are useful for filling those otherwise
empty padding areas with windowDefs that you anchor to the corresponding
points of the window (like CST_ANCHOR_LEFT and CST_ANCHOR_RIGHT when
there's horizontal padding) that have just the right size.
Example of a green rectangle filling parts of the left padding area,
but not touching the center area (10 virtual pixels distance):
windowDef leftPadFiller {
cstAnchor CST_ANCHOR_LEFT
rect 0, 200, "gui::horPad" - 10, 40
backColor 0, 1, 0, 1
}
Example:
onActivate {
set "print" "this windowDefs rect:" "$rect";
}
(added to the Desktop of a GUI) prints
"GUI debug: this windowDefs rect: 0 0 640 480"
to the ingame console
especially useful when using cstAnchor
also providing an easy generic way to figure out if the window of an
idUserInterface is scaled to 4:3 aspect ratio or not, depending on
r_scaleMenusTo43 and the WIN_SCALETO43/WIN_NO_SCALETO43 window flags,
that come from "scaleto43 1" (or 0) set in the GUIs Desktop windowDef
for my scale to 4:3 hack idRenderWindow::Draw() already calls
if(dc->IsMenuScaleFixActive()) {
dc->AdjustCoords(&x, &y, &w, &h);
}
and AdjustCoords() already takes the cst offsets into account, so all
that was left to do was making idDeviceContext::IsMenuScaleFixActive()
aware of the cst stuff
even if r_scaleMenusTo43 1 and they'd usually be scaled to 4:3.
Useful when using anchors in fullscreen menus (like the PDA)
This is analogous to "scaleto43 1" in windowDefs which allows scaling
to 4:3 (with black/empty bars) even if by default it would *not* be
scaled.
somehow the collision code managed to spread NaNs on Win32, which caused
a horrible framerate, "GetPointOutsideObstacles: no valid point found"
warnings in the console and assertions in debug builds.
Didn't happen in Vanilla Doom3 though.
At the location I changed the code in, I saw the following values in the
debugger:
normal: {x=0.00610326231 y=5.58793545e-09 z=1.19209290e-07 }
trmEdge->start: {x=-1358.00000 y=913.948975 z=25.2637405 }
start: {x=-1358.00000 y=916.000000 z=34.0000000 }
end: {x=-1358.00000 y=810.000000 z=34.0000000 }
dist (normal*trmEdge->start): -8.28822231
d1: 9.53674316e-07
d2: 9.53674316e-07
f1 (d1/(d1-d2)): inf
"normal" isn't normalized and also very small (in all directions),
"start" and "end" have quite different y values, but still doing scalar
multiplications of each with "normal" gave the same result..
No idea what this all means exactly, but checking if d1 - d2 is (almost)
0 to prevent INF solved the problems. In the end it will be some tiny
differences in floating point calculations between different platforms
and compilers..
In my test d1-d2 was exactly 0, but I compare with FLT_EPSILON to be
on the safer side.
incl. backwards compat for older savegames.
only partly useful: old savegames only work if you didn't change the
gamedata, with the CstDoom3 .gui files, loading them crashes. I don't
think that can be avoided, apparently Doom3 has no way to detect that
the GUIs have changed?
In idWindow::Redraw(), I had to make sure the menu scale fix (which,
if enabled for a window, renders that in 4:3 with empty or black bars
on the side if needed for widescreen etc, instead of stretching it)
is disabled if a window uses CST anchors, because the CST anchor code
also adjusts for the display aspect ratio and if we do both, things get
distorted in the other way.
The biggest change is that idDeviceContext::DrawStretchPic(Rotated) now
has code to adjust the coordinates for both CST and the menu scale fix,
so idDeviceContext::AdjustCoords() is mostly obsolete - it's only still
used by idRenderWindow.
Unlike DstDoom3 now that extra adjustCoords argument to those Draw
functions indicates that any coordinate adjustment should be done, so
if it's set by a caller, it's set to true.
I removed idDeviceContext::AdjustCursorCoords() because it was only used
in one place anyway
By writing that info into the demo when recording it (when demos are
played back, mylevel.map isn't read, only mylevel.proc, so the
worldspawn can't be accessed to get allow_nospecular from there)
D3::ImGuiHooks::NewFrame() was still called every frame, but EndFrame()
wasn't because idSessionLocal::UpdateScreen() exited early.
This caused an assertion in Dear ImGui, because it doesn't like calling
NewFrame() if it has been called before without EndFrame() afterwards
based on https://github.com/dhewm/dhewm3/pull/254
The "nospecular" parm will only be used if either
r_supportNoSpecular is set to 1
or r_supportNoSpecular is set to -1 (the default) and the maps spawnargs
contain "allow_nospecular" "1"
This probably doesn't work with (time)demos yet, because I think when
they're being played I can't access the worldspawn entity
If it (or Documents/My Games/dhewm3/) can't be created, show a windows
MessageBox with an error message and exit.
Would've made #544 easier to figure out
At least VS2017 doesn't like the big string literal of
proggyvector_font_base85.h (its limit is 64KB, Error C1091), so go back to
using proggyvector_font.h (which contains an int32 array) for MSVC..
Keep the base85 version around for proper compilers, because (unlike
the non-base85 version of the font) it works on Big Endian machines.
It seems like VS2022, maybe even some point release of VS2019 removed this
limitation (our CI build succeeds), but I couldn't find any details about
that change.
Based on whether handleMouseGrab() in events.cpp sets
GRAB_ENABLETEXTINPUT or not.
Should prevent the issue that on macOS pressing a button for longer
while playing (as one does, e.g. to run forward) opens a popup menu
with alternative characters (like "è", "é", "ê", etc for "e")
like in Doom3 BFG: If it's set to 1, no autosaves are created when
entering a level. Defaults to 0 (autosaves enabled)
While at it, I also documented com_numQuicksaves in Configuration.md
based on a fix from @dezo2 from the >60Hz support branch
(TBH I don't know why the crosshair must be scaled to 4:3 but the
grabber cursor not, but this works..)
Modern mice support ridiculously high DPI values, >20'000.
Not sure what that's actually good for, but if people use that, they
ran into the "idUsercmdGenLocal::MouseMove: Ignoring ridiculous
mouse delta" case which just threw away the mouse input values so the
game didn't respond to mouse input anymore or at least felt choppy.
I'm not sure what that code was originally good for, under which
(undesired) circumstances that happened, but for now it's disabled,
only the warning is still logged, but only once.
For these high DPI values to still be usable (camera not moving way
too fast), it probably makes sense if the mouse sensitivity can be set
to values < 1.0. The CVar always supported that, but I adjusted the
Dhewm3SettingsMenu so it sensitivity can also be set to values between
0.01 and 1 there (still going up to 30, like before).
fixes#616
