Jump to content

OTHGMars

Members
 View Profile  See their activity

  • Posts

    34

  • Joined

  • Last visited

 Content Type 

Posts posted by OTHGMars

    SDL_Joystick and SDL_GameController

    in C++

    Posted

    @chriscalef This is probably the function that you're remembering: https://github.com/GarageGames/Torque3D/blob/development/Engine/source/platformWin32/winDirectInput.cpp#L852. SDL does have equivalent commands for polling individual device states but they are not exposed as console functions in this branch. I'll be sure to get those added before a PR is made.


    I would expect the hat to generate dpad events though, https://github.com/GarageGames/Torque3D/blob/development/Engine/source/platform/input/event.cpp#L374-L377. Were you able to run the input monitor to see if the hat was generating any events?

    SDL_Joystick and SDL_GameController

    in C++

    Posted

    @irei1as Thanks for testing and giving feedback!

    If the driver is actually generating 2 events and the ActionMap has 2 bindings, both would get called.


    I forgot that F1 has a GlobalActionMap bind in the Full template. I should have picked a different key for that. Anything with a bind in the GlobalActionMap gets pulled out of the event loop before it gets to the gui. Glad you found the work-around.


    I've never looked at sdl keyboard layout handling, but I made a note to check it out the next time I'm in the docs.

    SDL_Joystick and SDL_GameController

    in C++

    Posted · Edited by OTHGMars

    This is a wip branch that adds support for the SDL_Joystick and SDL_GameController sub-systems to T3D: https://github.com/OTHGMars/Torque3D/tree/SDL_Joy_wip

    Hopefully with some code-reviews/community input/testing this can be improved and a clean PR made so T3D will have device independent joystick and gamepad support.


    Testing

    To encourage testing, there's a testing module that creates an event viewer gui so you can view events that your devices generate in real-time (it's more fun than stepping through the event loop in the debugger). It also has a settings window so you can see the effect the prefs have on how devices are opened if they are connected or disconnected. After building the engine and installing BaseGame, copy the inputTest directory from Templates/Modules to your game/data directory. It will add a button for the event viewer to the main menu. Please throw any gaming-type input device you have at it and post your results. I do not have any devices with a trackball, so those events are completely untested.


    The Details

    The input model under SDL is different than the existing DInputDevice platform code. Under SDL all input devices other than keyboard/mouse are considered Joysticks. Game Controllers are a subset of Joysticks. The advantage to using Game Controllers is the SDL database of controller mappings. Recognized gamepad devices can be mapped to the xbox input scheme so a single set of ActionMap defaults can be identical buttons on different devices. Additional mappings can be loaded from script or file. More info at https://wiki.libsdl.org/SDL_GameControllerAddMappingsFromFile


    There's a new global, $pref::Input::sdlControllerEnabled. If true, any device that SDL recognizes as a Game Controller will be automatically opened as a controller and these events will be used: https://github.com/OTHGMars/Torque3D/blob/SDL_Joy_wip/Engine/source/platform/input/event.cpp#L392-L430.

    The existing global $pref::Input::JoystickEnabled is still used. If true, any device that cannot be recognized as a Game Controller (or all devices if pref::Input::sdlControllerEnabled is false) will be automatically opened as a Joystick and these events will be used: https://github.com/OTHGMars/Torque3D/blob/SDL_Joy_wip/Engine/source/platform/input/event.cpp#L309-L390.

    If both globals are false, no joystick devices will be opened. There is a script interface for opening/closing and getting device details that closely mirrors the SDL_Joystick and SDL_GameController function sets if you do decide to take manual control of opening/closing devices from script.

    New events were added for trackballs and the guide button on gamepads.

    There are 2 new script callbacks that fire anytime a device is connected or disconnected, onSDLDeviceConnected() and onSDLDeviceDisconneceted(). The connected callback is called before the device is opened by the InputManager so you can modify default behavior if you need to.


    Unresolved Questions

    Is it possible to use the DECLARE_CALLBACK IMPLEMENT_CALLBACK macros with a class that's not a CONOBJECT? If so, that would be cleaner and easier to document than the current Con::executef() method, but I couldn't figure out how to do it.

    Edit: I used the IMPLEMENT_GLOBAL_CALLBACK macro and was able to implement the connect/disconnect callbacks.


    I left this enumeration commented out https://github.com/OTHGMars/Torque3D/blob/SDL_Joy_wip/Engine/source/platformSDL/sdlInputManager.cpp#L30-L42. It worked as the return value here https://github.com/OTHGMars/Torque3D/blob/SDL_Joy_wip/Engine/source/platformSDL/sdlInputManager.cpp#L990, but I could not find the correct way to get the string from the value here https://github.com/OTHGMars/Torque3D/blob/SDL_Joy_wip/Engine/source/platformSDL/sdlInputManager.cpp#L1044. Lookup is complicated by the fact that the enumeration contains a negative value. So, I went with a simple static lookup function https://github.com/OTHGMars/Torque3D/blob/SDL_Joy_wip/Engine/source/platformSDL/sdlInputManager.cpp#L81. I'm looking for suggestions for a better way.

    Edit: castConsoleTypeToString() is the function I was looking for.


    This if block, https://github.com/OTHGMars/Torque3D/blob/SDL_Joy_wip/Engine/source/windowManager/sdl/sdlWindowMgr.cpp#L262-L268 could be where it is now, or it could be in the default branch of the switch statement just below it. Is there a preference? Is one better?

    Edit: Left as is.


    As is sometimes the case with T3D, you go to start something and realize something else needs fixed first. I liked the LOG_INPUT define in the old platform layer, so I defined it when starting on this, but the engine wouldn't build under windows. I 'fixed' that as the first commit. I wouldn't use it anymore since the event monitor gives as much information. But...Since it's in the code, I really should verify it works under Linux or take it back out. I don't have a Linux test environment atm, so if anyone could help out with that, it would be greatly appreciated.

    Edit: Removed from the code.


    Because of the way they're generalized, these functions https://github.com/GarageGames/Torque3D/blob/development/Engine/source/app/game.cpp#L70-L88 will activate and deactivate the sdl input manager...I'm not sure if duplicates should be made with general names or if it should left as is? If the legacy platform code is going to be depreciated at 4.0 in favor of all sdl, the activation/deactivation could be cleaned up and some functions that only exist to match the old structure could be removed.

    Finding simObjects by name, from script.

    in C++

    Posted

    In that case:

    %name = "SomeName";
%objID = findSimObjectByName (%name);

     

    would be functionally equivalent to:

    %name = "SomeName";
%objID = isObject(%name) ? %name.getId() : 0;

     

    or, if you want to restrict it to being a member of a particular SimSet. 

    %name = "SomeName";
%objID = SomeSet.isMember(%name) ? %name.getId() : 0;

    Is there a particular case where a dedicated function would be preferable?

    Releasing OpenAL Sound Buffers

    in General

    Posted

    I'm posting this here hoping to save someone debugging time. We use looping music during our game menus and the music changes as you switch menus. I noticed memory usage would increase every time the music changed. You can see the issue with devhead or release and full template by doing the following:

    Launch game, make sure OpenAL is the sound provider and open the guiMusicPlayer.

    exec("core/scripts/gui/guiMusicPlayer.cs"); toggleMusicPlayer();

    Select "art/sound/environment/amb.ogg" (because it's big).

    Click play, then stop and repeat several times while watching the apps memory usage and you'll see the memory usage continue to climb and never return to it's original baseline state. If you then switch to DirectSound and repeat the experiment, you'll see the baseline memory usage remains pretty constant.

    The problem turned out to be related to the sound streaming. The descriptions are set to isStreaming = true; If those are changed to isStreaming = false; both OpenAL and DirectSound release all memory reserved for the sound buffers when the sound is stopped and do not hold a large chunk until the app exits. Another work-around would be to manage all of the sound sources from script and not recreate them as the sounds are played/stopped, but in our case in addition to menus, we have multiple music tracks that will play depending on where the user is in a level, so that is not an appealing option.

×
×
  • Create New...