Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Test Builds => Topic started by: The E on December 01, 2013, 08:36:21 am
-
And once more, it is Antipodes time.
For those who are not used to this, Antipodes is a special development branch we are maintaining to test features and additions that are either too big or too fundamental to just be stuffed into trunk.
This time around, the topic is "SDL Everywhere". What does this mean?
Well, here's the issue: On Linux and MacOS (and FreeBSD), we are using the SDL (http://www.libsdl.org) middleware library to manage the hairy bits of setting up windows, getting an OpenGL context, and handling control input. This has worked pretty well for us, but had one big drawback: SDL 1.2 did not have any support for force feedback effects.
Now, after several years of development, SDL2 has been released. This allows us to do force feedback on all platforms, and this means that it is about time we started using SDL on Windows too, cutting down on the amount of platform-specific code we have to write and maintain.
Given that this changes the behaviour of one of the biggest things in any game engine, namely player input handling, we need this tested thoroughly. Keyboard/Mouse/KB+Mouse/Joystick/Joypad input all has to be checked, because we want the engine to behave very much the same for obvious reasons.
Here then are the builds for Windows (Built in Visual Studio 2013)
fs2_open_Ant9_20150716_2777459.7z (http://scp.fsmods.net/builds/WIN/Antipodes/fs2_open_Ant9_20150716_2777459.7z)
fs2_open_Ant9_20150716_2777459_SSE.7z (http://scp.fsmods.net/builds/WIN/Antipodes/fs2_open_Ant9_20150716_2777459_SSE.7z)
fs2_open_Ant9_20150716_2777459_SSE2.7z (http://scp.fsmods.net/builds/WIN/Antipodes/fs2_open_Ant9_20150716_2777459_SSE2.7z)
fs2_open_Ant9_20150716_2777459_AVX.7z (http://scp.fsmods.net/builds/WIN/Antipodes/fs2_open_Ant9_20150716_2777459_AVX.7z)
All builds are based on git hash 2777459.
You must have SDL2.dll present for the builds to run. You can get it from libsdl.org (https://www.libsdl.org/release/SDL2-2.0.3-win32-x86.zip). Make sure the SDL2.dll is in your FS2 folder alongside the downloaded executables.
And here are the builds for other supported platforms (late to the party)
OS X: FS2_Open_Ant9_20150716_2777459.zip (http://scp.fsmods.net/builds/OSX/FS2_Open_Ant9_20150716_2777459.zip) Built on OS X 10.10.4, Xcode 6.4
FreeBSD x64: fs2_open_ant9_20150716_2777459.tar.bz2 (http://scp.fsmods.net/builds/FREEBSD/fs2_open_ant9_20150716_2777459.tar.bz2) Built on PC-BSD 10.1, clang 3.4.1
Ubuntu x86: fs2_open_ant9_20150716_2777459.tar.bz2 (http://scp.fsmods.net/builds/LINUX/fs2_open_ant9_20150716_2777459.tar.bz2) Built on Ubuntu Server 14.04.2 LTS, GCC 4.8.4
Big thanks go to taylor, for providing the force feedback code, and m|m and Echelon9 for various fixes and enhancements.
EDIT:
Update posted on 15/12/2013
Changelog:
-Updated to trunk revision 10223
-Made a few housekeeping changes (A few defines removed)
-Fixed bug involving crash when Force Feedback is activated.
Updates posted 18 July 2015
-All new builds for every platform based on latest Git hash
-Many new SDL-only optimizations have been merged including dialog cleanup, dead code removal, etc.
-
The AVX build does not have an "sdl2.dll" file. Is it not required?
-
Yes, you do need it. I have reuploaded the AVX archive.
-
It would be nice to base the antipodes build off a more recent nightly so you don't get the error message when using the Media VP beta release.
One thing I noticed was the build reversed my throttle and bank on the joystick (Logitech Extreme 3D Pro). The other thing I noticed was if you disconnected the joystick during the game and then re-plugged it in it would not redetect the joystick. I sometimes reset the joystick by doing this if it isn't exactly centered.
-
Yes I meant to mention the axis swap too, it seems they map differently in game than from DirectInput. It seems to say Rx and Z are different between the two. Also, enabling Force Feedback on Windows leads to an immediate crash on load because of how we're using SDL_LoadObject (we pass in NULL). Supposedly this works for Linux, as taylor said it was working for him, but on Windows it blows up. Hard-coding it to "SDL2.dll" actually seems to let it work on Windows. Not sure if we just need an ifdef _WIN32 there or what, I haven't been able to verify what happens on Linux/OS X yet with the Force Feedback code as it is now.
Other than those issues, my previous testing of the Antipodes branch has been very successful. Played a couple entire missions with no hiccups.
Edit: Also added an Antipodes 9 version to Mantis.
-
sse2 build seems to work ok in the input department with keyboard and mouse, however there seems to be a major graphical glitch in that the black behind the stars background does not appear (only nebula, planets ect...) Causes some pretty freaky problems
[attachment deleted by an evil time traveler]
-
I tested the SSE2 build using a joypad (Xbox 360 Gamepad - wired), the triggers are treated as two separate axes (Ry for Left Trigger, Rz for Right Trigger) which are on 0% when released. When you hold them down, they go to 100%.
The main control stick (left) is mapped correctly as Joystick X and Joystick Y.
The secondary control stick (right) is mapped as Joystick Z Axis (for its horizontal axis) and Joystick RX Axis (for its vertical axis)
The buttons go as:
D-Pad up: Button 1
D-Pad down: Button 2
D-Pad left: Button 3
D-Pad right: Button 4
Start: Button 5
Back: Button 6
Left Stick Click: Button 7
Right Stick Click: Button 8
LB: Button 9
RB: Button 10
A: Button 11
B: Button 12
X: Button 13
Y: Button 14
It seems to recognize everything well, the only thing that is an annoyance in my opinion is the way it handles the triggers.
I assume the other 2 builds are going to handle the same way as far as XBox Pad input goes, but I can test it if you guys want.
EDIT: I forgot to mention, in non-SDL builds, the triggers are recognized as a single axis, and it seems to go from -100% (Left trigger fully pressed) to 0 (both fully pressed or both released) to +100% (Right trigger fully pressed). The horizontal axis of the right stick was simply not recognized at all and might as well not exist.
-
Yes I meant to mention the axis swap too, it seems they map differently in game than from DirectInput. It seems to say Rx and Z are different between the two.
Might be related to the axes confusion I reported on Mantis, here. (http://scp.indiegames.us/mantis/view.php?id=2660)
-
I've had a bit more time to test the sse2 build (for some reason the graphical glitch fixed itself) and the mouse only moves as if the axis is tied to desktop position. if your cursor is all the way to the left then you can't turn anymore in that direction.
-
It would be nice to base the antipodes build off a more recent nightly so you don't get the error message when using the Media VP beta release.
One thing I noticed was the build reversed my throttle and bank on the joystick (Logitech Extreme 3D Pro). The other thing I noticed was if you disconnected the joystick during the game and then re-plugged it in it would not redetect the joystick. I sometimes reset the joystick by doing this if it isn't exactly centered.
the first issue comes from the fact that fs2 dates back to the days of yore when gameports were still the standard interface. and back then completely different axis designations were used (x,y,throttle/z,rudder/r). there were really named after whatever the driver decided to name them. usb sticks are usually based of an hid class from the usb specifications, and they used different axis names. d3d had its own names and so does sdl. none of them are anywhere near compatible. when it comes right down to it, its a binding issue, i dont see it being too much trouble to tweak your control profiles.
for the second issue, you just need to have the game re-scan the system for joysticks. this is probibly only being done once at start up, you just need to have this done either at a regular interval (every few seconds), or perhaps when you enter the control config screen. if you needed to unplug or replug a joystick while in game, you would just have to go into options and back out and the stick would be found and remapped. bind by guid instead of stick number to make sure you dont get your sticks mixed up.
It seems to recognize everything well, the only thing that is an annoyance in my opinion is the way it handles the triggers.
thats just M$ being a dick. sdl is probibly bypassing the thing in the ms driver that combines those triggers into a single axis (this was done because ms thought that all axes should be center rested). i actually combine my ch toe breaks into a single rudder axis, because my actual rudder axis is so clogged with dirt it makes this annoying grating sound when used. this might be solved with a 3rd party utility (ppjoy, anything based on vJoy, etc) in a similar way. the other way to fix this is by letting you combine axes in the game, its not really hard to do but would be somewhat hard to mesh that into the existing interface. perhaps use half axis binds as an alternative to full axis binds (like bank left axis, bank right axis). assuming the axis are mapped out to a -1.0f to 1.0f range, axis merging should looks something like this:
float bankAxis = (bankLeftAxisValue*0.5f) - (bankRightAxisValue*0.5f);
there arent really a whole lot of cases where you would need this though.
-
Before SDL, I used that for roll, left trigger was left roll, right trigger was right roll. I admit I don't see many more uses beyond that, though. At the same time, I like it that SDL allows me to use the secondary stick correctly instead of being forced to ignore its horizontal axis.
-
the reason that the 360 controller meshes so poorly with direct input is because it was natively an xinput device. it was never designed to be a direct input controller, and so its direct input mode was utter crap. sounds like sdl is just bypassing a lot of that crap, exposing raw, unfiltered data. its probibly talking xinput on the controller side. sdl is ultimately just a wrapper for whatever native apis are running on the platform. on windows sdl goes through direct input (possibly xinput as well, as this behavior would seem to suggest) for controller support. i like it because its easy to use and i dont have to download gigabytes of microsoft sdks to compile stuff that uses it.
-
Now re-replaying the default FS2 campaign on SSE2 SDL Build. Any specific kind of stuff I should look out for, while testing?
-
Managed to get my freelook patch update, and operable in the cockpit, have yet to tried the other view modes.
Now re-replaying the default FS2 campaign on SSE2 SDL Build. Any specific kind of stuff I should look out for, while testing?
Letsee, the SDL changes should affect the control input and graphics, the goal should be that there shouldn't be any apparent changes in either department vs. trunk (other than the desired performance boost, of course).
-
Not sure if there's any real performance boost here, the idea is that SDL will allow us to do more cool things going forward, and simplify the code base by removing DirectInput specific code.
-
Yeah, there probably isn't, but it isn't a negative if there is indeed some sort of performance gained. :D
-
New builds have been posted. Please see the first post for details.
-
Tried out my Force Feedback Pro joystick with the new adapter I got. FF works in IL-2, and FSO 3.7.0, but not with these SDL builds. I did some extra debugging and it doesn't want to initialize FF on the sdljoy joystick resource. I tried switching it to use Cur_joystick directly with SDL_HapticOpen instead of SDL_HapticOpenFromJoystick and just got an error when loading the first effect to the joystick. So not sure why this is being so cantankerous on Windows when Taylor had this working on Linux just fine.
Also, I was working with a more recent build with latest trunk merged in locally, and some of the command line code tweaks seem to be breaking flag parsing by the launcher. When trying to load the flags, it is instead running the game. Also, this sometimes leads to a freeze where it gets stuck before the video even plays. Not sure if that's related to the flag parsing or if that's just a separate bug altogether.
-
Same here, FF is not working with this build. Plus I'm constantly rolling to the left, as if the rudder (rX axis) is always on the minimum.
-
My rudder axis was different between my pecision 2 and ff pro, probably because the usb adapter returns so many axis.
-
I've been working Internally with m|m and z64555 on testing and iterating feedback for issues. Not FF related (yet) but for mouse control and input.
-
I'm running into a problem compiling off antipodes current svn that I can't replicate on current trunk or 10550 (last trunk sync to antipodes). The briefing and pre-briefing voices are getting cut off after about half a second. But it doesn't do that all the time. Every once in a while, one will play correctly. I have had no problem with the in game sounds and voice clips so far. I can't peg down any trigger for it working or not right now, though.
My environment:
Fedora 20 x86_64 (updated today)
Asus Sabertooth 990FX R2.0 (integrated Realtek ALC892)
Nvidia GTX 760
fs2_open antipodes branch updated today
I was preparing to test the force feedback code when I get a Sidewinder FFB2 next week, but ran into this first.
Steel01
-
I've also noticed this issue, I believe it's a problem with .wav playback on Linux & not on windows. Not sure why since SDL shouldn't touch that at all :confused: Anyway, if you test with retail assets (i.e. no mod) I believe the briefing music will also cut out.
-
Yeah, confirmed on retail assets. Plus an odd, really short loop in the background music during the briefing that hasn't happened to me yet on the 2014 media vps. Which, if it is a wav problem, that makes sense since the remastered music is ogg, iirc.
Steel01
-
As far as I know there is something the SDL port could have changed and that is the threading stuff for .wav playback.
-
Got my FFB2 in today and ran it through my build of the antipodes branch. Haptic feedback isn't working for me either. Input seems great otherwise. All the axis' were perfectly centered, even after I mapped bank to z axis.
Steel01
-
So I guess it's not just my FFB1 having problems then. Good to know.
-
Nope. And not just Windows either. Which kinda surprised me since the haptic code was based against Linux.
Steel01
-
So, that's very odd since taylor definitely had that code running on Linux, and specifically mentioned the extreme effect he was getting.
-
Steel01, were you saying that you're using Linux? We have a compiled version of the SDL testrumble application for 64-bit Linux available here (https://www.dropbox.com/s/p7oekozuzyqcmnj/testrumble) if you want to see that the SDL haptic code definitely works with your joystick. I'll be trying to get a OS X and/or Windows version available of that test app soon too.
-
INFO: 1 Haptic devices detected.
INFO: Device: Microsoft SideWinder Force Feedback 2 Joystick
ERROR: Failed to initialize rumble: Haptic: Device has no free space left.
I got this thing used. Might there be a problem with it?
Steel01
-
It's trying to load the haptic effects onto the stick, but I think that's where mine fails too. I doubt it's your stick.
-
Okay. But now I'm interested. Is that a generic SDL2 program, or something put together by the SCP? If it's generic, I'm surprised that part of the library passed testing like that. If it's not generic, I'm going to have to find something Linux based that supports force feedback and see if it really does work.
Steel01
-
Well, the problem with FF on my FFB2 don't appear to be SCP related. I can't even get the ff-util programs to do anything. It appears to be a kernel module problem.
kernel: usb 7-4: New USB device found, idVendor=045e, idProduct=001b
kernel: usb 7-4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
kernel: usb 7-4: Product: SideWinder Force Feedback 2 Joystick
kernel: usb 7-4: Manufacturer: Microsoft
kernel: input: Microsoft SideWinder Force Feedback 2 Joystick as /devices/pci0000:00/0000:00:16.0/usb7/7-4/7-4:1.0/input/input6
kernel: hid-generic 0003:045E:001B.0001: device reports 0 simultaneous effects
kernel: hid-generic 0003:045E:001B.0001: pid_block_load failed 60 times
kernel: hid-generic 0003:045E:001B.0001: upload request failed
kernel: hid-generic 0003:045E:001B.0001: input,hidraw0: USB HID v1.00 Joystick [Microsoft SideWinder Force Feedback 2 Joystick] on usb-0000:00:16
Says it can load 0 effects. So, I'm off to attempt some module debugging. Probably won't get very far, though.
Steel01
-
Getting back into FSO and figured I'd start out here.
Playing through a couple of campaigns using this, with a terrible no-name usb joystick (12 button, 4-axis, 8 position hat). So far, more or less exactly like playing with standard builds. This stick is supposed to support FF, but only with the provided drivers on the CD that I'm fairly certain are XP x86 (and I'm on 7 x64) only. I'll do some research to see if I can find them, and if I can I'll report on whether FF is working for me or not.
-
oh my jebus
as someone who uses a ps4 controller emulating a 360 controller via xinput i'm already pretty used to being an edge case for things not working but hooooooly crap this works splendidly and i have all my sticks and such good to go. had to reconfig basically every button but its TASTY
my heroes!
-
So, a while back when I was messing with the Haptic stuff, I tweaked some of the error reporting. As there are still issues with the haptic code, I thought maybe putting my tweaks up for review would be helpful and spur some further enhancements to that aspect of the code by some other more intrepid coder(s) than myself.
Index: code/io/joy_ff-sdl.cpp
===================================================================
--- code/io/joy_ff-sdl.cpp (revision 10795)
+++ code/io/joy_ff-sdl.cpp (working copy)
@@ -24,6 +24,7 @@
#endif
extern SDL_Joystick *sdljoy;
+extern int Cur_joystick;
static int Joy_ff_enabled = 0;
static SDL_Haptic *haptic = NULL;
@@ -67,20 +68,20 @@
mprintf((" Initializing Haptic...\n"));
if (SDL_InitSubSystem(SDL_INIT_HAPTIC) < 0) {
- mprintf((" ERROR: Could not initialize Haptic subsystem\n"));
+ mprintf((" ERROR: Could not initialize Haptic subsystem: %s\n", SDL_GetError()));
return -1;
}
if ( !SDL_JoystickIsHaptic(sdljoy) ) {
- mprintf((" ERROR: Joystick does not have haptic capabilities\n"));
+ mprintf((" ERROR: Joystick does not have haptic capabilities: %s\n", SDL_GetError()));
SDL_QuitSubSystem(SDL_INIT_HAPTIC);
return -1;
}
- haptic = SDL_HapticOpenFromJoystick(sdljoy);
+ haptic = SDL_HapticOpen(Cur_joystick);
if (haptic == NULL) {
- mprintf((" ERROR: Unable to open haptic joystick\n"));
+ mprintf((" ERROR: Unable to open haptic joystick %d: %s\n", Cur_joystick, SDL_GetError()));
SDL_QuitSubSystem(SDL_INIT_HAPTIC);
return -1;
}
Index: projects/MSVC_2008/code.vcproj
===================================================================
--- projects/MSVC_2008/code.vcproj (revision 10795)
+++ projects/MSVC_2008/code.vcproj (working copy)
@@ -1886,10 +1886,6 @@
>
</File>
<File
- RelativePath="..\..\code\osapi\osapi_unix.cpp"
- >
- </File>
- <File
RelativePath="..\..\code\osapi\osregistry.cpp"
>
</File>
I don't believe the osapi_unix.cpp file was actually needed to be in the VC project file anymore, I don't remember why I removed it but I'm fairly certain it was running fine with that change so I left it in the patch (http://swc.fs2downloads.com/files/haptic_error_reporting.diff) (Tortoise-generated, sorry if it doesn't apply cleanly for you but it's a very short patch) as food for thought. By bringing in the Cur_joystick external identifier, I'm not sure if sdljoy is still used in the file or not, so also leaving that alone for discussion. Like I said, I wrote this stuff months ago and can't remember the exact reasons behind some things already, but I do remember the build was successfully giving me a little more useful information in the fs2_open.log. So if anyone would like to run with this patch and add any further enhancement to the joystick error reporting, that would be frickin' sweet.
-
I'm getting also Soundtrack stuttering, but I'm using 3.7.2 RC3, not the Antipodes. (To late here to bring it into Mantis, I will create an Account in the next few days when I find the time...)
-
Yeah, any RC3 bugs should definitely be in Mantis or the RC3 thread, or both.
-
Should Mantis 2651 (http://scp.indiegames.us/mantis/view.php?id=2651) be merged into Antipodes maybe? I doubt we'd want to put something like that into trunk now but Antipodes seems like a good home for it and would let us close the ticket still.
-
Sounds good. It'll conflict with at least this recent commit (http://svn.icculus.org/fs2open/trunk/fs2_open/code/controlconfig/controlsconfigcommon.cpp?r1=10899&r2=10900&pathrev=10900&sortby=file&limit_changes=1), so maybe roll that commit into antipodes as well?
-
Yeah can do a trunk sync first and then make it line up probably. Unless this would actually just work in trunk without any real problems, I don't know how much controlsconfigcommon was hacked apart in that area of the file in Antipodes.
-
Hmm... I don't know that much about the controls config section myself, I think z64555 would be most qualified to comment here.
-
It doesn't appear that I committed most of my hacks for the controls code. I have it on my github clone only.
-
While we are at this topic , I noticed that the current version of wxLauncher is not compatible with the current SDL builds. wxLauncher gets the joystick list like the current FSO builds but those indices are different from the indices SDL supplies. To fix this wxLauncher would need to be modified to also retrieve the list using SDL and use those indices. For that to also work with older builds a new build capabilities flag has to be added to the flags file.
However there is better solution. SDL is capable of supplying GUIDs for the joysticks (SDL_JoystickGetGUID and SDL_JoystickGetGUIDString) which can be used to uniquely identify the joysticks without having to rely on the indices (that also means that removing a device would not suddenly change the used joystick).
What do you think?
-
id just yoink the stick select out of the launchers and allow bindings to every stick on the system. selecting one stick makes things easy because bindings can simply be axis1 or button2, indexing into whatever stick is the chosen one. if you add multiple sticks you then need to bind something like stick3:axis4, or stick2:button1, bringing fourth the problem of non-numeric indexing (especially if you use guids instead of stick indices). then to deal with users plugging and unplugging different joysticks into the system, drastically changing the configuration and causing total chaos.
thing is you dont need to say goodby to numeric indices. if you can say axis1, button2, you can say axis42 or button350 just as well. you just need to scan every stick on the system, figure out its axis/button count, then allocate space on a master list of axes and buttons. these indices are then used for bindings, and wraps functions to get the state any button or axis on the master list by the appropriate sdl calls. for example, masterFakeJoystick:getAxis(12) or masterFakeJoystick:getbutton(69).
to keep track of everything, build another list where each entry is a joystick, using the guid as the unique identifier (thats what guids are for after all). this maps physical controls into the master list in a very permanent way without confusing the code. this keeps track of every joystick the user ever had connected to the machine when the game ran, and stores mapping information to resolve big number indices to their device-local equivalents. new joysticks are, scanned, and mapped into the master list, old joysticks are retained for later use. this list has to be saved to avoid a particular stick's master list indices from changing.
this is a good opportunity to shoot down, once and for all, the one stick limit.
-
That would obviously be the ideal solution (I think z64555 works on this) but would require a lot of work, ideally it would be implemented by a completely rewritten joystick management system.
My point is to use this as a preliminary solution until the new joystick handling can be implemented which will probably need another antipodes cycle.
-
m!m is correct, the joystick overhaul is so extensive that it'll need an antipodes cycle all by itself. There's just a whole lot of assumptions in the existing codebase that make a change from a single joystick to multiple controllers non-trivial.
-
I went ahead and implemented the necessary changes, here is a comparision which sould show what needs to be done: https://github.com/asarium/fs2open.github.com/compare/asarium:cmake...feature/joystickGUID
This also adds handling of added/removed devices.
This also requires changes to wxLauncher but I already implemented it.
-
oh damnit, you're gonna make me get back to work on the io/controls overhaul, aren't you? :P
-
I've tested this build, but for some reason my joystick/gamepad did not work or get recognized.
-
There is an issue with the current version of wxLauncher, try selecting other joysticks in the launcher until one is recognized.
-
First post finally updated with OS X builds.
-
And now FreeBSD builds. OS X builds updated again to match current latest. Will try to get Windows builds soon as these are pretty outdated. Then we really need to have a go at bug squashing in this branch.
-
And Linux builds because why not.
-
And now finally updated Windows Antipodes 9 builds in the first post. Been a while. Not sure if we still need the custom SDL2 so I have uploaded it alongside the new builds as a potentially optional download. If it is indeed still definitely required it can be re-clarified as such but I was thinking we were compatible with the official release now.
-
The binaries in the git repository are the release binaries so no custom built binaries are needed.
-
On OS X 10.10 (which with trunk no longer works due to SDL 1.x problems), the Antipodes 9 build work fine from the command line.
There is however a new error when double clicking the .app from Finder or the Dock, which is that FS2_Open reports "Unrecognized command line parameter -psn_<xxx>". This parameter is apparently one which Finder/Dock silently adds on Mac. The <xxx> number is the PSN - process serial number (a unique PID-ish thing).
VLC and Firefox ran into this based on found bug reports, so I'll spend some time trying to resolve it.
GitHub Issue reported here (https://github.com/scp-fs2open/fs2open.github.com/issues/248). Would someone with access mind tagging it as Antipodes?
-
I tagged the issue as Antipodes and created a pull request with a proposed patch which should match what SDLMain.c did: https://github.com/scp-fs2open/fs2open.github.com/pull/250
-
Trunk and zookeeper's FotG builds still seem to be working for me for the most part on 10.10. I'm not sure they are broken for everyone.
-
I don't know if this is the right place for bug reports but here is something I ran into while testing the Antipodes 9 July 18 2015 build.
On my Xbox360 controller, binding "Bank Axis" to either the left or right trigger causes my ship to continuously roll counter clockwise even though I'm not pressing anything. Pressing the trigger half way down stops the spinning. In 3.7.2 final this doesn't happen.
Another thing is that I cannot bind "Primary Fire" to a trigger, ie. it just will not register. This happens in both Antipodes and the regular build so maybe it's by design, I don't know.
Edit: This is on Win7 64-bit.
-
Unfortunately both issues are caused by the way FSO handles axis inputs. The triggers are registered as an axis and FSO assumes that the 'middle' means that there is no input which is not accurate for the XBox controllers. Until the input handling is rewritten this will not change.
Your second issue is again caused by the input handling of FSO. Primary fire is expected to be used with a button but the triggers are recognized as axes so you can't map that control using the triggers.
There could be some external software that allows you to remap how the controller inputs are passed to FSO but for the immediate future FSO won't be able to handle this use case correctly without external help.
-
Unfortunately both issues are caused by the way FSO handles axis inputs. The triggers are registered as an axis and FSO assumes that the 'middle' means that there is no input which is not accurate for the XBox controllers. Until the input handling is rewritten this will not change.
Your second issue is again caused by the input handling of FSO. Primary fire is expected to be used with a button but the triggers are recognized as axes so you can't map that control using the triggers.
There could be some external software that allows you to remap how the controller inputs are passed to FSO but for the immediate future FSO won't be able to handle this use case correctly without external help.
Ok. Maybe I'll try hacking around it with XPadder.
-
Let us know how it went, if it works it could be added to the FAQ so other people don't have to go through the same trouble.
-
Yeah, it's working now. Just had to map the triggers to ctrl and space bar.
-
Without having done that, wouldn't even simple control mapping in FSO have been broken with that joystick? If it is constantly detecting them being engaged. Unless FSO watches for changes on axis and not just non-zero axis values during binding.
-
AFAIK it only registers differences for control binding.
-
Now that I think about it, I guess that makes sense, otherwise I'd have to zero my throttle to bind anything.
Wonder if those buttons can be recalibrated in Windows natively, or how much work it would take to support non-zeroing axis better in FSO.
-
any work with the controls code is like pulling fragmented wisdom teeth. painful, slow, but doable.
-
And what about window handling?
-
What exactly do you want to know?
Window handling in FSO is pretty simple because there is only one. I would like to add lua support for creating new windows and rendering stuff onto them but that won't be implemented for quite a while.
-
I'm really liking the new SDL2 integration into FSO. The mouse is much smoother, I can use the CapsLock key to toggle glide mode, and I'm able to move the mouse around during loading screens and other time-consuming procedures. It seems that the mouse input is now asynchronous.
However, I am unable to load mods with folder names that have spaces in them. Additionally, the SDL2 error dialog says it has copied the error message to the clipboard, even though it hasn't (or if it did, maybe it isn't the X clipboard?).
Here's the error message I'm getting when I try to load Shadow Genesis:
(http://www.ciinet.org/kevin/myimages/SGModLoadFail.png)
-
However, I am unable to load mods with folder names that have spaces in them. Additionally, the SDL2 error dialog says it has copied the error message to the clipboard, even though it hasn't (or if it did, maybe it isn't the X clipboard?).
The mod option handling shouldn't have changed in antipodes. Could you post your fs2_open.log file, maybe the launcher didn't add the quotes around the mod with spaces.
The clipboard is implemented by calling a SDL function so we can't influence that. When I have the time I'll step through the code to check if the function is actually called but other than that there isn't much we can do about it.
I'm really liking the new SDL2 integration into FSO. The mouse is much smoother, I can use the CapsLock key to toggle glide mode, and I'm able to move the mouse around during loading screens and other time-consuming procedures. It seems that the mouse input is now asynchronous.
The whole input handling should be much better. The mouse capture behavior was changed and should now behave the same on Windows and Linux. Now you're not locked out of using your computer if you run FSO. Previously FSO didn't want to let go of the mouse which caused quite a few problems...
-
It seems I'm only able to get an fs2_open.log file if I hit "Continue". And if I do, here's what I get:
Initializing SDL...
FreeSpace 2 Open version: 3.7.3
Passed cmdline options:
-spec_exp 11
-ogl_spec 60
-spec_static 0.8
-spec_point 0.6
-spec_tube 0.4
-ambient_factor 75
-missile_lighting
-3dshockwave
-soft_particles
-post_process
-fxaa
-fb_explosions
-brief_lighting
-enable_shadows
-ballistic_gauge
-dualscanlines
-rearm_timer
-targetinfo
-3dwarp
-ship_choice_3d
-weapon_choice_3d
-warp_flash
-snd_preload
-mod Shadow,zoom
Building file index...
Found root pack '/home/kevinc/Games/FSO/Freespace 2/multi-mission-pack.vp' with a checksum of 0x377695e0
Found root pack '/home/kevinc/Games/FSO/Freespace 2/multi-voice-pack.vp' with a checksum of 0xd50e7442
Found root pack '/home/kevinc/Games/FSO/Freespace 2/Root_fs2.vp' with a checksum of 0xce10d76c
Found root pack '/home/kevinc/Games/FSO/Freespace 2/smarty_fs2.vp' with a checksum of 0xddeb3b1e
Found root pack '/home/kevinc/Games/FSO/Freespace 2/sparky_fs2.vp' with a checksum of 0x164fe65a
Found root pack '/home/kevinc/Games/FSO/Freespace 2/sparky_hi_fs2.vp' with a checksum of 0xa11d56f1
Found root pack '/home/kevinc/Games/FSO/Freespace 2/stu_fs2.vp' with a checksum of 0xd77da83a
Found root pack '/home/kevinc/Games/FSO/Freespace 2/tango1_fs2.vp' with a checksum of 0x4c25221e
Found root pack '/home/kevinc/Games/FSO/Freespace 2/tango2_fs2.vp' with a checksum of 0x86920b82
Found root pack '/home/kevinc/Games/FSO/Freespace 2/tango3_fs2.vp' with a checksum of 0x705e8d71
Found root pack '/home/kevinc/Games/FSO/Freespace 2/warble_fs2.vp' with a checksum of 0xd85c305d
Searching root '/home/kevinc/.fs2_open/' ... 2 files
Searching root '/home/kevinc/Games/FSO/Freespace 2/' ... 23 files
Searching root pack '/home/kevinc/Games/FSO/Freespace 2/multi-mission-pack.vp' ... 110 files
Searching root pack '/home/kevinc/Games/FSO/Freespace 2/multi-voice-pack.vp' ... 307 files
Searching root pack '/home/kevinc/Games/FSO/Freespace 2/Root_fs2.vp' ... 157 files
Searching root pack '/home/kevinc/Games/FSO/Freespace 2/smarty_fs2.vp' ... 10 files
Searching root pack '/home/kevinc/Games/FSO/Freespace 2/sparky_fs2.vp' ... 3027 files
Searching root pack '/home/kevinc/Games/FSO/Freespace 2/sparky_hi_fs2.vp' ... 1337 files
Searching root pack '/home/kevinc/Games/FSO/Freespace 2/stu_fs2.vp' ... 2355 files
Searching root pack '/home/kevinc/Games/FSO/Freespace 2/tango1_fs2.vp' ... 32 files
Searching root pack '/home/kevinc/Games/FSO/Freespace 2/tango2_fs2.vp' ... 15 files
Searching root pack '/home/kevinc/Games/FSO/Freespace 2/tango3_fs2.vp' ... 10 files
Searching root pack '/home/kevinc/Games/FSO/Freespace 2/warble_fs2.vp' ... 52 files
Found 13 roots and 7437 files.
os_config_read_string(): section = "Default", name = "Language", default value: "NULL"
AutoLang: Language auto-detection successful...
Setting language to English
Game Settings Table: Using Standard Loops For SEXP Arguments
Game Settings Table: Using standard event chaining behavior
Game Settings Table: External shaders are DISABLED
Initializing OpenAL...
os_config_read_string(): section = "Sound", name = "PlaybackDevice", default value: "NULL"
os_config_read_string(): section = "Sound", name = "CaptureDevice", default value: "NULL"
Available Playback Devices:
Built-in Audio Analog Stereo *preferred*
GM204 High Definition Audio Controller Digital Stereo (HDMI)
Available Capture Devices:
Built-in Audio Analog Stereo *default*
Monitor of GM204 High Definition Audio Controller Digital Stereo (HDMI)
Monitor of Built-in Audio Analog Stereo
OpenAL Vendor : OpenAL Community
OpenAL Renderer : OpenAL Soft
OpenAL Version : 1.1 ALSOFT 1.16.0
Found extension "AL_EXT_float32".
Found extension "ALC_EXT_EFX".
Enhanced sound is enabled.
Sample rate: 44100 (44100)
EFX version: 1.0
Max auxiliary sends: 4
Playback device: Built-in Audio Analog Stereo
Capture device: Built-in Audio Analog Stereo
... OpenAL successfully initialized!
Failed to init speech
os_config_read_string(): section = "Default", name = "VideocardFs2open", default value: "NULL"
Initializing OpenGL graphics device at 1280x1024 with 32-bit color...
Initializing SDL video...
Requested SDL Video values = R: 8, G: 8, B: 8, depth: 24, stencil: 8, double-buffer: 1, FSAA: 0
Actual SDL Video values = R: 8, G: 8, B: 8, depth: 24, stencil: 8, double-buffer: 1, FSAA: 0
OpenGL Vendor : NVIDIA Corporation
OpenGL Renderer : GeForce GTX 970/PCIe/SSE2
OpenGL Version : 4.5.0 NVIDIA 352.63
Using extension "GL_EXT_fog_coord".
Using extension "GL_ARB_multitexture".
Using extension "GL_ARB_texture_env_add".
Using extension "GL_ARB_texture_compression".
Using extension "GL_EXT_texture_compression_s3tc".
Using extension "GL_EXT_texture_filter_anisotropic".
Using extension "GL_ARB_texture_env_combine".
Using extension "GL_EXT_compiled_vertex_array".
Using extension "GL_EXT_draw_range_elements".
Using extension "GL_ARB_texture_mirrored_repeat".
Using extension "GL_ARB_texture_non_power_of_two".
Using extension "GL_ARB_vertex_buffer_object".
Using extension "GL_ARB_pixel_buffer_object".
Using extension "GL_SGIS_generate_mipmap".
Using extension "GL_EXT_framebuffer_object".
Using extension "GL_ARB_texture_rectangle".
Using extension "GL_EXT_bgra".
Using extension "GL_ARB_texture_cube_map".
Using extension "GL_EXT_texture_lod_bias".
Using extension "GL_ARB_point_sprite".
Using extension "GL_ARB_shading_language_100".
Using extension "GL_ARB_shader_objects".
Using extension "GL_ARB_vertex_shader".
Using extension "GL_ARB_fragment_shader".
Using extension "GL_ARB_shader_texture_lod".
Using extension "GL_ARB_texture_float".
Using extension "GL_ARB_draw_elements_base_vertex".
Using extension "GL_EXT_framebuffer_blit".
Using extension "GL_EXT_geometry_shader4".
Using extension "GL_EXT_texture_array".
Using extension "GL_ARB_uniform_buffer_object".
Found extension "GL_EXT_transform_feedback", but can't find the required function "glBeginTransformFeedbackEXT()". Extension will be disabled!
Using extension "GL_ARB_draw_instanced".
Using extension "GL_ARB_texture_buffer_object".
Found special extension function "glXSwapIntervalSGI".
os_config_read_string(): section = "Default", name = "OGL_AnisotropicFilter", default value: "1.0"
Compiling new shader:
Particle Effects
Loading built-in default shader for: effect-v.sdr
Loading built-in default shader for: effect-particle-f.sdr
Shader Variant Features:
Compiling new shader:
Particle Effects
Loading built-in default shader for: effect-v.sdr
Loading built-in default shader for: effect-particle-f.sdr
Loading built-in default shader for: effect-screen-g.sdr
Shader Variant Features:
Geometry shader point-based particles
Compiling new shader:
Distortion Effects
Loading built-in default shader for: effect-distort-v.sdr
Loading built-in default shader for: effect-distort-f.sdr
Shader Variant Features:
Compiling new shader:
Deferred Lighting
Loading built-in default shader for: deferred-v.sdr
Loading built-in default shader for: deferred-f.sdr
Shader Variant Features:
Compiling new shader:
Clear Deferred Lighting Buffer
Loading built-in default shader for: deferred-clear-v.sdr
Loading built-in default shader for: deferred-clear-f.sdr
Shader Variant Features:
Compiling new shader:
Post Processing
Loading built-in default shader for: post-v.sdr
Loading built-in default shader for: post-f.sdr
Shader Variant Features:
Compiling new shader:
Bloom Brightpass
Loading built-in default shader for: post-v.sdr
Loading built-in default shader for: brightpass-f.sdr
Shader Variant Features:
Compiling new shader:
Gaussian Blur
Loading built-in default shader for: post-v.sdr
Loading built-in default shader for: blur-f.sdr
Shader Variant Features:
Horizontal blur pass
Compiling new shader:
Gaussian Blur
Loading built-in default shader for: post-v.sdr
Loading built-in default shader for: blur-f.sdr
Shader Variant Features:
Vertical blur pass
Compiling new shader:
FXAA
Loading built-in default shader for: fxaa-v.sdr
Loading built-in default shader for: fxaa-f.sdr
Shader Variant Features:
Compiling new shader:
FXAA Prepass
Loading built-in default shader for: post-v.sdr
Loading built-in default shader for: fxaapre-f.sdr
Shader Variant Features:
Max texture units: 4 (32)
Max client texture states: 4 (8)
Max elements vertices: 1048576
Max elements indices: 1048576
Max texture size: 16384x16384
Max render buffer size: 16384x16384
Can use compressed textures: YES
Texture compression available: YES
Post-processing enabled: YES
Using trilinear texture filter.
OpenGL Shader Version: 4.50 NVIDIA
... OpenGL init is complete!
Size of bitmap info = 927 KB
Size of bitmap extra info = 56 bytes
ANI cursorweb with size 24x24 (25.0% wasted)
ANI cursorweb.ani with size 24x24 (25.0% wasted)
GRAPHICS: Initializing default colors...
os_config_read_string(): section = "Default", name = "GammaD3D", default value: "1.0"
SCRIPTING: Beginning initialization sequence...
SCRIPTING: Beginning Lua initialization...
LUA: Opening LUA state...
LUA: Initializing base Lua libraries...
LUA: Beginning ADE initialization
ADE: Initializing enumeration constants...
ADE: Assigning Lua session...
SCRIPTING: Beginning main hook parse sequence....
Wokka! Error opening file (scripting.tbl)!
TABLES: Unable to parse 'scripting.tbl'! Error message = Failed to open file.
SCRIPTING: Inititialization complete.
SCRIPTING: Splash screen overrides checked
SCRIPTING: Splash hook has been run
SCRIPTING: Splash screen conditional hook has been run
os_config_read_string(): section = "PXO", name = "Login", default value: "NULL"
Error reading in PXO login data
os_config_read_string(): section = "PXO", name = "Password", default value: "NULL"
Error reading PXO password
os_config_read_string(): section = "PXO", name = "SquadName", default value: "NULL"
Error reading in PXO squad name
Using high memory settings...
Wokka! Error opening file (interface.tbl)!
WMCGUI: Unable to parse 'interface.tbl'! Error message = Failed to open file.
Dutifully converting retail sound 36, 'l_hit.wav' to a 3D sound...
Dutifully converting retail sound 37, 'm_hit.wav' to a 3D sound...
os_config_read_string(): section = "Default", name = "ConnectionSpeed", default value: "Fast"
Initializing Joystick...
No joysticks found
Current soundtrack set to -1 in event_music_reset_choices
Wokka! Error opening file (armor.tbl)!
TABLES: Unable to parse 'armor.tbl'! Error message = Failed to open file.
ANI support1 with size 108x24 (25.0% wasted)
ANI damage1 with size 148x25 (21.9% wasted)
ANI wingman1 with size 71x53 (17.2% wasted)
ANI wingman2 with size 35x53 (17.2% wasted)
ANI wingman3 with size 14x53 (17.2% wasted)
ANI toggle1 with size 57x20 (37.5% wasted)
ANI head1 with size 164x132 (48.4% wasted)
ANI weapons1 with size 126x20 (37.5% wasted)
ANI objective1 with size 149x21 (34.4% wasted)
ANI netlag1 with size 29x30 (6.2% wasted)
ANI targhit1 with size 31x21 (34.4% wasted)
ANI time1 with size 47x23 (28.1% wasted)
ANI targetview1 with size 137x156 (39.1% wasted)
ANI targetview2 with size 4x96 (25.0% wasted)
ANI targetview3 with size 7x20 (37.5% wasted)
ANI 2_energy2 with size 86x96 (25.0% wasted)
ANI 2_reticle1 with size 40x24 (25.0% wasted)
ANI 2_leftarc with size 103x252 (1.6% wasted)
ANI 2_rightarc1 with size 103x252 (1.6% wasted)
ANI 2_toparc2 with size 35x24 (25.0% wasted)
ANI 2_toparc3 with size 41x29 (9.4% wasted)
ANI 2_lead1 with size 26x26 (18.8% wasted)
ANI 2_lock1 with size 56x53 (17.2% wasted)
ANI 2_lockspin with size 100x100 (21.9% wasted)
ANI energy1 with size 12x41 (35.9% wasted)
ANI 2_radar1 with size 209x170 (33.6% wasted)
TABLES => Starting parse of 'ssm.tbl'...
ANI cursor with size 24x24 (25.0% wasted)
ANI cursor.ani with size 24x24 (25.0% wasted)
Ships.tbl is : VALID
Weapons.tbl is : VALID
cfile_init() took 298
MVE: Buffer underun (First is normal)
Got event GS_EVENT_GAME_INIT (49) in state NOT A VALID STATE (0)
os_config_read_string(): section = "Default", name = "LastPlayer", default value: "NULL"
PLR => Loading 'Talon_BP.plr' with version 2...
PLR => Parsing: Flags...
PLR => Parsing: Info...
PLR => Parsing: Scoring...
PLR => Parsing: ScoringMulti...
PLR => Parsing: HUD...
PLR => Parsing: Variables...
PLR => Parsing: Multiplayer...
PLR => Parsing: Controls...
PLR => Parsing: Settings...
PLR => Loading complete!
PLR => Verifying 'Talon_WCAG.plr' with version 2...
PLR => Parsing: Flags...
PLR => Parsing: Info...
PLR => Verifying complete!
PLR => Verifying 'Talon_Derelict.plr' with version 2...
PLR => Parsing: Flags...
PLR => Parsing: Info...
PLR => Verifying complete!
PLR => Verifying 'Talon_GR.plr' with version 2...
PLR => Parsing: Flags...
PLR => Parsing: Info...
PLR => Verifying complete!
PLR => Verifying 'Talon_cs.plr' with version 2...
PLR => Parsing: Flags...
PLR => Parsing: Info...
PLR => Verifying complete!
PLR => Verifying 'Talon_BP.plr' with version 2...
PLR => Parsing: Flags...
PLR => Parsing: Info...
PLR => Verifying complete!
PLR => Verifying 'Talon_Diaspora.plr' with version 2...
PLR => Parsing: Flags...
PLR => Parsing: Info...
PLR => Verifying complete!
PLR => Verifying 'Talon.plr' with version 2...
PLR => Parsing: Flags...
PLR => Parsing: Info...
PLR => Verifying complete!
Got event GS_EVENT_QUIT_GAME (5) in state GS_STATE_INITIAL_PLAYER_SELECT (37)
Freeing all existing models...
... Log closed, Mon Jan 18 08:44:02 2016
"Shadow" should be "Shadow Genesis" in addition to the 1.1 patch and the MediaVPs. It should be noted that spaces in a command line must be escaped or surrounded with single or double quotes on Unix-like platforms.
Here's the command line, according to wxLauncher:
/home/kevinc/Games/FSO/Freespace
2/fs2_open_antipodes_d2c8943_20151213_DEBUG -mod Shadow Genesis
1.1,Shadow Genesis,MediaVPs_2014 -missile_lighting -3dshockwave
-post_process -soft_particles -fxaa -fb_explosions -enable_shadows
-dualscanlines -targetinfo -rearm_timer -ballistic_gauge -ship_choice_3d
-weapon_choice_3d -3dwarp -warp_flash -snd_preload -brief_lighting
-ambient_factor 75 -spec_exp 11 -spec_point 0.6 -spec_static 0.8 -spec_tube 0.4
-ogl_spec 60 -mod zoom
-
Which wxLauncher version are you using?
The current version of FSO handles spaces in the mod arguments differently than the antipodes version but I'm pretty sure that the current version of wxLauncher surrounds mod names with spaces with quotes.
-
I'm using wxLauncher v0.10.1. This is the commit (https://github.com/scp-fs2open/wxLauncher/commit/a7edf77de6a3580cb0ac1bbfec101b6b51d46623) that my wxLauncher build is compiled from.
-
I was wrong, wxLauncher doesn't surround mods with quotes. I opened a PR which adds that feature: https://github.com/scp-fs2open/wxLauncher/pull/132
-
The PR still open, and yet to be commited into the main git branch, I presume. Or isn't it?
-
No, the changes have not been merged yet.
-
In this thread (http://www.hard-light.net/forums/index.php?topic=91909.0), it was discovered that Visual Studio Community 2015 Update 2 removed the speech API (or at least removed support for the gc command), preventing FSO from compiling; this PR (https://github.com/scp-fs2open/fs2open.github.com/pull/600) was needed to fix it. For the sake of those wanting to compile the Antipodes branch with the latest version of Visual Studio, could the changes in that PR be applied to the Antipodes branch as well?
-
Excuse, please. Can FSO and SDL2 both work in Windows 10 without lagging (e.g. mouse input)?
-
Yes.
-
We can probably unsticky this now right? Since it's merged and released now, any further discussion would be about stable builds.
-
Yeah, definitely.