I actually did this before the prototyping of a keybindings menu
in the imgui example code, so the prototype is actually based on this.
I'll merge the code from the prototype back once it's done.
idStr::(V)Format() is a static (v)printf-like function that returns
and idStr. Can be used like a better va(), or for
idStr mystr = idStr::Format( "number of items: %d", myarr.Num() );
turns out that __builtin_alloca_with_align() might releases the
allocated memory at the end of the block it was allocated in, instead
of the end of the function (which is the behavior of regular alloca()
and __builtin_alloca()): "The lifetime of the allocated object ends at
the end of the block in which the function was called. The allocated
storage is released no later than just before the calling function
returns to its caller, but may be released at the end of the block in
which the function was called."
https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html#index-_005f_005fbuiltin_005falloca_005fwith_005falign
Clang also supports __builtin_alloca_with_align(), but always releases
the memory at the end of the function.
And it seems that newer GCC versions also tend to release it at the
end of the function, but GCC 4.7.2 (that I use for the official Linux
release binaries) didn't, and that caused weird graphical glitches.
But as I don't want to rely on newer GCC versions behaving like this
(and the documentation explicitly says that it *may* be released at
the end of the block, but will definitely be released at the end of
the function), I removed all usage of __builtin_alloca_with_align().
(Side-Note: GCC only started documenting the behavior of
__builtin_alloca and __builtin_alloca_with_align at all with GCC 6.1.0)
added a simple helper print method to know what key/button is being pressed,
controlled via a bool cvar "in_namePressed" 1 or 0.
I tested it and it works with keyboard, mouse and gamepad.
it could happen that UIs are added to the internal list twice,
and also that the last UI wasn't removed from the list when a new one
was focused fast enough.
That should work better now, I hope I didn't break anything..
commit f56ad0aafa868303ce324ae8d45675570c66b050 from 2024-01-23
"Note termination of returned strings in contrib/minizip/unzip.h."
this is the code as it is upstream, the next commit will add some
doom3-specific changes
apparently this happens sometimes, but not often enough to reproduce
properly?
also some small changes (mostly formatting) to Configuration.md
refs #540
- 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
turns out SDL 2.0.12 added SDL_GameControllerGetType() which tells you
what kind of controller it is (xbox, playstation, nintendo, ..).
Using this to implement an auto-mode for joy_gamepadLayout, when it's
set to -1 (the new default).
This should still build with older versions of SDL2 (but won't have
that autodetection then).
The button names shown in the controls menu now depend on this CVar.
So if you set it to 1 (Nintendo), the "A" button (which, based on its
position, would be "B" on XBox/XInput gamepads) is actually shown as
"Pad A", and if it's set to 2 (Playstation), it's shown as "Pad Cross".
The "real" names, used in the config, remain the same and are based on
position: JOY_BTN_SOUTH, JOY_BTN_EAST, JOY_BTN_WEST, JOY_BTN_NORTH
- 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()
