"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).
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
}
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
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.
- the gamepad button (or trigger) bound to attack (fire) now always
acts like the left mouse button in menus
- Display correct button name for "Back" button on Playstation-like
gamepads, even depending on whether it's PS3-like ("Select") or
PS4/5-like ("Share")
- Log some more information about detected gamepads
- make moving the cursor more precise by using an exponential curve
for axis value => cursor speed
- emulate cursor keys with DPad and Enter with left trigger
- also use right trigger for leftclick, as it's usually used for firing
a weapon and thus used for "clicking" ingame UIs
- fix hovering/highlighting menu elements when moving cursor
with gamepad
- treat DPad as 4 regular buttons (was already the case mostly, but now
the code is simpler)
- rename in_invertLook to joy_invertLook and in_useJoystick to
in_useGamepad and remove unused CVars
- make controller Start button generate K_ESCAPE events, so it can
always be used to open/close the menu (similar to D3BFG)
- move mousecursor with sticks, A button (south) for left-click,
B button (east) for right-click (doesn't work in PDA yet)
- removed special handling of K_JOY_BTN_* in idWindow::HandleEvent()
by generating fake mouse button events for gamepad A/B
in idUserInterfaceLocal::HandleEvent()
There were lots of places in the code that called Sys_GrabInput(),
some of them each frame.
Most of this is unified in events.cpp now, in handleMouseGrab() which
is called once per frame by Sys_GenerateEvents() - this makes reasoning
about when the mouse is grabbed and when not a lot easier.
Sys_GrabInput(false) still is called in a few places, before operations
that tend to take long (like loading a map or vid_restart), but
(hopefully) not regularly anymore.
The other big change is that the game now uses SDLs absolute mouse mode
for fullscreen menus (except the PDA which is an ugly hack), so the
ingame cursor is at the same position as the system cursor, which
especially helps when debugging with `in_nograb 1` and should also help
if someone wants to integrate an additional GUI toolkit like Dear ImGui.
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
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.
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.
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).
