If in_ignoreConsoleKey is set, the console can only be opened with
Shift+Esc, not `/^/whatever, so you can easily type whatever character
is on your "console key" into the game, or even bind that key.
Otherwise, with SDL2, that key (KEY_SCANCODE_GRAVE) always generates the
newly added K_CONSOLE.
in_kbd has a new (SDL2-only) "auto" mode which tries to detect the
keyboard layout based on SDL_GetKeyFromScancode( SDL_SCANCODE_GRAVE ).
Wherever Sys_GetConsoleKey() is called, I now take the current state of
Shift into account, so we don't discard more chars than necessary, esp.
when they keyboard-layout (in_kbd) is *not* correctly set.
(TBH the only reason besides SDL1.2 to keep in_kbd around is to ignore
the char generated by the "console key" in the console..)
it wants to store a pointer to itself in an idWinVar - on 32bit idWinInt
was suitable for that, on 64bit it's not, so instead convert the pointer
to a hex-string and stuff it in a idWinStr
also fix a crash when adding a choiceDef in the gui editor
WIN_DESKTOP means that this can currently only be set for the top-level
window in a .gui (all its subwindows/widgets will be scaled implicitly)
There are two ways to make a GUI use this:
1. in the .gui add a window variable "scaleto43 1", like
windowDef Desktop {
rect 0 ,0 ,640 ,480
nocursor 1
float talk 0
scaleto43 1
// .. etc rest of windowDef
2. When creating the GUI from C++ code, you can afterwards make the
UserInterface scale to 4:3 like this:
idUserInterface* ui = Whatever(); // create it
ui->SetStateBool("scaleto43", true);
ui->StateChanged(gameLocal.time);
Both lines are important!
As you can see in my changes to Player.cpp, my primary usecase for this
is the cursor/crosshair GUI.
So stuff doesn't look so distorted in widescreen resolutions.
Implies that there are black bars on the left/right then..
Can be disabled with "r_scaleMenusTo43 0"
Does *not* affect the HUD (incl. crosshair) - scaling it automagically
would be very hard (or impossible), because it doesn't only render
the crosshair, healthpoints etc, but also fullscreen effects like the
screen turning red when the player is hit - and fullscreen effects
would look very shitty if they didn't cover the whole screen but had
"empty" bars on left/right.
(Mostly) fixes#188 and #189
Mods that have their own video settings menu can tell dhewm3 to replace
the "choices" and "values" entries in their choiceDef with the
resolutions supported by dhewm3 (and corresponding modes).
So if we add new video modes to dhewm3, they'll automatically appear in
the menu without changing the .gui
To enable this, the mod authors only need to add a "injectResolutions 1"
entry to their resolution choiceDef. By default, the first entry will
be "r_custom*" for r_mode -1, which means "custom resolution, use
r_customWidth and r_customHeight".
If that entry shoud be disabled for the mod, just add another entry:
"injectCustomResolutionMode 0"
Sometimes memory was allocated with new[] but freed with delete instead
of delete[], which is wrong.
And there were some small memory leaks, too.
Furtunately clang's AddressSanitizer detected all that so I could easily
fix it.
(There seem to be some more small memory leaks which are harder to fix,
though)
The fullscreen guis pretend to be 640x480 internally, also for the mouse
cursor position. So adding the actually moved pixels (when playing the
game at a higher resolution) to the GUIs cursor position makes it move
too fast.
To fix that I detect (hopefully that check is reliable!) if the
idUserInterfaceLocal instance is a fullscreen GUI and if so scale the
reported mouse moved pixels with 640/actual_window_width and
480/actual_window_height.
the resolutions are really hardcoded in an ugly combination of the
values r_mode supports, a string in strings/*.lang ("#str_04222")
describing the resolutions r_mode supports
("640x480;800x600;1024x768;1152x864;1280x1024;1600x1200")
and a string in mainmenu.gui with the corresponding r_mode values
("3;4;5;6;7;8").. as neither the strings nor mainmenu.gui are GPL'ed
I can't really redistribute a changed version of them.
So I added lots of resolutions to r_vidModes and wrote two functions
that generate the resolutions list string and r_mode value
string for the GUI.
Then I added a hack in the code that detects when the "window" for the
system options ("choiceDef OS2Primary") is created and overwrites the
hardcoded strings with custom ones from my new functions.
This is tested with both the main game and the official d3xp
(Resurrection of Evil) Addon.
No idea if it works with other mods, depends on whether they just copied
that part of the menu or wrote their own.
Don't include the lazy precompiled.h everywhere, only what's
required for the compilation unit.
platform.h needs to be included instead to provide all essential
defines and types.
All includes use the relative path to the neo or the game
specific root.
Move all idlib related includes from idlib/Lib.h to precompiled.h.
precompiled.h still exists for the MFC stuff in tools/.
Add some missing header guards.
hides overloaded virtual function
Fix member signatures of deriving classes to its super classes.
Removes the unused idGameBustOutWindow::Activate() and the
useless idMarkerWindow::GetWinVarByName().
variable set but not used
Removes some CollisionModel code under _DEBUG which was probably a
leftover, since it was completely useless (its done later anyways).
