Author Topic: Joystick turning lag  (Read 15394 times)

0 Members and 1 Guest are viewing this topic.

Offline Avder

  • 25
Joystick turning lag
Hi there

I'm having a problem with getting a joystick to work properly that I can't seem to figure out, and searching through this forum hasn't led me to anyone who have had similar problems.

The problem I'm having is there is a discernible lag between when I start moving my joystick and when my ship in game begins to respond.  There's anywhere from a quarter to a half second of lag between my hand doing something and something happening in game.  Button presses on the joystick are instant.  Keyboard input is also instant. Moving the mouse also results in instant movement.

As an example, I'll leave my stick handle centered and then slam it all the way to full deflection.  The stick will reach the fullest extent of it's range and then an instant later the ship will start turning.

So far I've tried multiple versions of FSO including the current "final" release, two prior releases, and the current antipodes version which uses SDL for joystick input instead of DirectInput.

I've also used 4 different joysticks as well as both manufacturer drivers and default windows HID drivers for one of them:
Saitek Cyborg EVO (both mfg and default drivers), MS Sidewinder 3D Pro with Grendel adapter, MS Sidewinder Precision 2, MS Xbox 360 controller.

I've also tried my joysticks in Descent 1 & 2 (rebirth versions), Descent 3, and Oolite for comparison, but there is no joystick lag in any of them.  Increasing joystick sensitivity predictably does nothing except make me overshoot my targets even worse than I already am.

Any help would be appreciated.  For now I'm working around it by using an autohotkey script to emulate X and Y axis movement with a mouse as well as assigning buttons on my stick to keys, but this means I can't use my twist axis for roll and have to do it on the keyboard.

 

Offline z64555

  • 210
  • Self-proclaimed controls expert
    • Minecraft
    • Steam
Alright, and this is for the FS2 campaign correct?

Try Fredding a test mission and try out the various craft (Just open FRED and then save the empty mission it creates within your /data/missions subdirectory). Paying particular attention to differences between the light and fast interceptor craft and the slower bomber craft.


If you are able to, could you also take a video of it?
Secure the Source, Contain the Code, Protect the Project
chief1983

------------
funtapaz: Hunchon University biologists prove mankind is evolving to new, higher form of life, known as Homopithecus Juche.
z64555: s/J/Do
BotenAlfred: <funtapaz> Hunchon University biologists prove mankind is evolving to new, higher form of life, known as Homopithecus Douche.

 

Offline Avder

  • 25
Alright, and this is for the FS2 campaign correct?

Try Fredding a test mission and try out the various craft (Just open FRED and then save the empty mission it creates within your /data/missions subdirectory). Paying particular attention to differences between the light and fast interceptor craft and the slower bomber craft.


If you are able to, could you also take a video of it?

Have tried it in FS2 unmodded as well as with the media vp's, as well as the FS1 port with and without media VP's.

What made me notice is was I was going to play through the whole series starting from the beginning and I noticed the Apollo fighter was a lot harder to control than I remember from the last time I played years and years ago, so I loaded up the Vasudan gauntlet and flew a Ulysses and the problem persisted.  I then loaded up regular FS2 and found the Erinyes has the same problem.

I'll see if I can take a video.  My hardware is rather old so programs like fraps and the like don't work too well.

 

Offline Avder

  • 25
Here's a quick video

https://www.youtube.com/watch?v=lvF1KRAGhRg

The first time I'm firing by bringing my hand back hard directly against the trigger button.

The second time I fire I slapped the left mouse button.

The first time I'm firing it takes until the 2nd shot is firing before the ship responds.

The second time it responds just as I'm firing the first shot.

I know it doesn't look like much of a difference, but it makes a HUGE difference when trying to shoot at anything that's not flying straight.

Response is the same on the FS1 Apollo, Valkyre, Herculese, Ulysses, and FS2 Erinyes.

 

Offline AdmiralRalwood

  • 211
  • The Cthulhu programmer himself!
    • Skype
    • Steam
    • Twitter
And this happens with multiple different joysticks, but only in FSO? Please post your fs2_open.log file.  Instructions on how to do this can be found in this post.
Ph'nglui mglw'nafh Codethulhu GitHub wgah'nagl fhtagn.

schrödinbug (noun) - a bug that manifests itself in running software after a programmer notices that the code should never have worked in the first place.

When you gaze long into BMPMAN, BMPMAN also gazes into you.

"I am one of the best FREDders on Earth" -General Battuta

<Aesaar> literary criticism is vladimir putin

<MageKing17> "There's probably a reason the code is the way it is" is a very dangerous line of thought. :P
<MageKing17> Because the "reason" often turns out to be "nobody noticed it was wrong".
(the very next day)
<MageKing17> this ****ing code did it to me again
<MageKing17> "That doesn't really make sense to me, but I'll assume it was being done for a reason."
<MageKing17> **** ME
<MageKing17> THE REASON IS PEOPLE ARE STUPID
<MageKing17> ESPECIALLY ME

<MageKing17> God damn, I do not understand how this is breaking.
<MageKing17> Everything points to "this should work fine", and yet it's clearly not working.
<MjnMixael> 2 hours later... "God damn, how did this ever work at all?!"
(...)
<MageKing17> so
<MageKing17> more than two hours
<MageKing17> but once again we have reached the inevitable conclusion
<MageKing17> How did this code ever work in the first place!?

<@The_E> Welcome to OpenGL, where standards compliance is optional, and error reporting inconsistent

<MageKing17> It was all working perfectly until I actually tried it on an actual mission.

<IronWorks> I am useful for FSO stuff again. This is a red-letter day!
* z64555 erases "Thursday" and rewrites it in red ink

<MageKing17> TIL the entire homing code is held up by shoestrings and duct tape, basically.

 

Offline Avder

  • 25
Here you go:

Code: [Select]
==========================================================================
DEBUG SPEW: No debug_filter.cfg found, so only general, error, and warning
categories can be shown and no debug_filter.cfg info will be saved.
==========================================================================
FreeSpace 2 Open version: 3.7.2.11329
Passed cmdline options:
  -no_vsync
  -no_glsl
  -window
Building file index...
Found root pack 'C:\Games\FreeSpace2\root_fs2.vp' with a checksum of 0xce10d76c
Found root pack 'C:\Games\FreeSpace2\smarty_fs2.vp' with a checksum of 0xddeb3b1e
Found root pack 'C:\Games\FreeSpace2\sparky_fs2.vp' with a checksum of 0x164fe65a
Found root pack 'C:\Games\FreeSpace2\sparky_hi_fs2.vp' with a checksum of 0xa11d56f1
Found root pack 'C:\Games\FreeSpace2\stu_fs2.vp' with a checksum of 0xd77da83a
Found root pack 'C:\Games\FreeSpace2\tango1_fs2.vp' with a checksum of 0x4c25221e
Found root pack 'C:\Games\FreeSpace2\tango2_fs2.vp' with a checksum of 0x86920b82
Found root pack 'C:\Games\FreeSpace2\tango3_fs2.vp' with a checksum of 0x705e8d71
Found root pack 'C:\Games\FreeSpace2\warble_fs2.vp' with a checksum of 0xd85c305d
Searching root 'C:\Games\FreeSpace2\' ... 52 files
Searching root pack 'C:\Games\FreeSpace2\root_fs2.vp' ... 157 files
Searching root pack 'C:\Games\FreeSpace2\smarty_fs2.vp' ... 10 files
Searching root pack 'C:\Games\FreeSpace2\sparky_fs2.vp' ... 3027 files
Searching root pack 'C:\Games\FreeSpace2\sparky_hi_fs2.vp' ... 1337 files
Searching root pack 'C:\Games\FreeSpace2\stu_fs2.vp' ... 2355 files
Searching root pack 'C:\Games\FreeSpace2\tango1_fs2.vp' ... 32 files
Searching root pack 'C:\Games\FreeSpace2\tango2_fs2.vp' ... 15 files
Searching root pack 'C:\Games\FreeSpace2\tango3_fs2.vp' ... 10 files
Searching root pack 'C:\Games\FreeSpace2\warble_fs2.vp' ... 52 files
Searching root 'd:\' ... 0 files
Found 11 roots and 7047 files.
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...
  OpenAL Vendor     : Creative Labs Inc.
  OpenAL Renderer   : Software
  OpenAL Version    : 1.1

  Found extension "ALC_EXT_EFX".

  Sample rate: 44100 (44100)
  EFX enabled: NO
  Playback device: Generic Software on Speakers (Realtek High Definition Audio)
  Capture device: Line in at rear panel (Blue) (R
... OpenAL successfully initialized!
Initializing OpenGL graphics device at 1024x768 with 32-bit color...
  Initializing WGL...
  Requested WGL Video values = R: 8, G: 8, B: 8, depth: 24, stencil: 8, double-buffer: 1
  Actual WGL Video values    = R: 8, G: 8, B: 8, depth: 24, stencil: 8, double-buffer: 1
  OpenGL Vendor    : ATI Technologies Inc.
  OpenGL Renderer  : ATI Radeon HD 4800 Series
  OpenGL Version   : 3.3.11672 Compatibility Profile Context

  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".
  Found special extension function "wglSwapIntervalEXT".

  Max texture units: 8 (2)
  Max elements vertices: 2147483647
  Max elements indices: 16777215
  Max texture size: 8192x8192
  Max render buffer size: 8192x8192
  Can use compressed textures: YES
  Texture compression available: YES
  Post-processing enabled: NO
  Using trilinear texture filter.
... OpenGL init is complete!
Size of bitmap info = 742 KB
Size of bitmap extra info = 48 bytes
ANI cursorweb with size 24x24 (25.0% wasted)
GRAPHICS: Initializing default colors...
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 code = 5.
SCRIPTING: Inititialization complete.
SCRIPTING: Splash screen overrides checked
SCRIPTING: Splash hook has been run
SCRIPTING: Splash screen conditional hook has been run
Using high memory settings...
Wokka!  Error opening file (interface.tbl)!
WMCGUI: Unable to parse 'interface.tbl'!  Error code = 5.
Dutifully ignoring the extra sound values for retail sound 36, 'l_hit.wav'...
Dutifully ignoring the extra sound values for retail sound 37, 'm_hit.wav'...
Windows reported 16 joysticks, we found 1
Current soundtrack set to -1 in event_music_reset_choices
Wokka!  Error opening file (armor.tbl)!
TABLES: Unable to parse 'armor.tbl'!  Error code = 5.
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.3% 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)
loading animated cursor "cursor"
ANI cursor with size 24x24 (25.0% wasted)
Ships.tbl is : VALID
Weapons.tbl is : VALID
cfile_init() took 351
MVE: Buffer underun (First is normal)
Got event GS_EVENT_GAME_INIT (49) in state NOT A VALID STATE (0)
PLR => Loading 'Avder.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 'Avder.plr' with version 2...
PLR => Parsing:  Flags...
PLR => Parsing:  Info...
PLR => Verifying complete!
PLR => Verifying 'Avidius.plr' with version 2...
PLR => Parsing:  Flags...
PLR => Parsing:  Info...
PLR => Verifying complete!
ANI cursor.ani with size 24x24 (25.0% wasted)
PLR => Verifying 'Avder.plr' with version 2...
PLR => Parsing:  Flags...
PLR => Parsing:  Info...
PLR => Verifying complete!
Got event GS_EVENT_MAIN_MENU (0) in state GS_STATE_INITIAL_PLAYER_SELECT (37)
PLR => Loading 'Avder.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!
CSG => Loading 'Avder.FreeSpace2.csg' with version 5...
CSG => Parsing:  Flags...
CSG => Parsing:  Info...
CSG => Parsing:  Missions...
CSG => Parsing:  Techroom...
CSG => Parsing:  Loadout...
CSG => Parsing:  Scoring...
CSG => Parsing:  RedAlert...
CSG => Parsing:  HUD...
CSG => Parsing:  Variables...
CSG => Parsing:  Settings...
CSG => Parsing:  Controls...
CSG => Parsing:  Cutscenes...
CSG => Parsing:  Last Missions...
CSG => Loading complete!
CSG => Loading 'Avder.FreeSpace2.csg' with version 5...
CSG => Parsing:  Flags...
CSG => Parsing:  Info...
CSG => Parsing:  Missions...
CSG => Parsing:  Techroom...
CSG => Parsing:  Loadout...
CSG => Parsing:  Scoring...
CSG => Parsing:  RedAlert...
CSG => Parsing:  HUD...
CSG => Parsing:  Variables...
CSG => Parsing:  Settings...
CSG => Parsing:  Controls...
CSG => Parsing:  Cutscenes...
CSG => Parsing:  Last Missions...
CSG => Loading complete!
ANI 2_mainwalk.ani with size 209x477 (6.8% wasted)
ANI 2_mainflyby.ani with size 509x189 (26.2% wasted)
ANI 2_maincrane.ani with size 192x116 (9.4% wasted)
ANI 2_mainexit.ani with size 319x174 (32.0% wasted)
ANI 2_mainbarracks.ani with size 273x158 (38.3% wasted)
ANI 2_mainreadyroom.ani with size 231x145 (43.4% wasted)
ANI 2_maintechroom.ani with size 69x119 (7.0% wasted)
ANI 2_mainoptions.ani with size 337x206 (19.5% wasted)
ANI 2_maincampaign.ani with size 308x190 (25.8% wasted)
Got event GS_EVENT_QUIT_GAME (5) in state GS_STATE_MAIN_MENU (1)
PLR => Saving 'Avder.plr' with version 2...
PLR => Saving:  Flags...
PLR => Saving:  Info...
PLR => Saving:  Scoring...
PLR => Saving:  ScoringMulti...
PLR => Saving:  HUD...
PLR => Saving:  Variables...
PLR => Saving:  Multiplayer...
PLR => Saving:  Controls...
PLR => Saving:  Settings...
PLR => Saving complete!
CSG => Saving 'Avder.FreeSpace2.csg' with version 5...
CSG => Saving:  Flags...
CSG => Saving:  Info...
CSG => Saving:  Missions...
CSG => Saving:  Techroom...
CSG => Saving:  Loadout...
CSG => Saving:  Scoring...
CSG => Saving:  RedAlert...
CSG => Saving:  HUD...
CSG => Saving:  Variables...
CSG => Saving:  Settings...
CSG => Saving:  Controls...
CSG => Saving:  Cutscenes...
CSG => Saving:  Last Missions...
CSG => Saving complete!
Freeing all existing models...
... Log closed, Tue Aug 18 06:22:58 2015

Completely unrelated, but is there a way to run the game in 16:9 but have the hud conform to 4:3 dimensions?  I'd like my target view and weapons loadouts in closer to the radar for easier viewing.

 

Offline AV8R

  • 28
This is a post from another thread I had made that mostly explains this phenomenon. The info was taken from various other forums when I noticed the same thing:

That was back before my accuracy went to **** for whatever reason.  I can't use it effectively anymore.  Maybe it's the joystick (currently on x45, where before I had a Cyborg 3D gold), or this fuzzy direct input thing I've heard mentioned a couple of times.  I just can't nail down what's different.

On a few other message boards they had an explanation for this phenomenon. From the days of Windows 9x to now, the way Direct Input reacts to joystick movement has changed. It used to use absolute values from the joystick which would translate to instant movement in whatever direction (X,Y) away from 0 (zero - center) the joystick was moved. Whether you moved the joystick 25, 50, or 100% away from center and no matter how quickly or slowly you moved it, your ship would change direction based on input instantaneously. Conversely, releasing the joystick to center would instantly snap the ship to straight. This method actually made the joystick act more like a mouse.

Later, in order to make turning seem more "realistic" (and unfortunately, it really is), there was a delay added (attitude acceleration/deceleration) since it was felt that, realistically, it took time for a aircraft/starship/whatever to respond to input from its pilot based on the craft's speed, weight, drag, etc. The net effect is: if you were to slam the joystick 100% in any direction using the old Direct Input method, the ship would almost instantly turn in that direction whereas now it has to accelerate to full turn speed (which can take up to 1 second to accomplish) before reaching its maximum. Bottom line: this makes the joystick less responsive and has the effect of causing overcompensation when targeting - often overshooting the target you're trying to get a fix on (the ship has to accelerate into the turn but then has to decelerate when the target nears the reticle - the deceleration causing the overshoot).

Also, the effect is adjustable for game-designers to give a custom "feel" for various ships in a game (based on percentages from up of down from default, from what some have stated elsewhere). This makes it easier for designers to create different performance characteristics on the fly (for example, while the Valkyrie would be 5% less than default input values, the Medusa would be 40% less than default input values so it would seem "heavier" or more "sluggish" during directional changes).
« Last Edit: August 18, 2015, 06:12:58 pm by AV8R »

 

Offline z64555

  • 210
  • Self-proclaimed controls expert
    • Minecraft
    • Steam
AV8R: That's what we thought at first, but it isn't craft inertia in this case. With inertia, you *do* get an instantanious response from the joystick, but the ship needs a bit of time to accelerate up to the delta-theta.

What Avder is experiencing is some kind of bug with how FSO interacts with the hardware, and what's got me stumped is that it also appears on the Antipodes SDL-Everywhere builds.

Avder: What are your system specs for this machine? Specifically: OS brand and version, CPU, motherboard, amount of RAM, and video card. Are you using an expansion card to connect your joystick?

The debug should builds show your framerate, and should be at least 20 or 30 FPS.

Do you get the same lag when using the mouse?
Secure the Source, Contain the Code, Protect the Project
chief1983

------------
funtapaz: Hunchon University biologists prove mankind is evolving to new, higher form of life, known as Homopithecus Juche.
z64555: s/J/Do
BotenAlfred: <funtapaz> Hunchon University biologists prove mankind is evolving to new, higher form of life, known as Homopithecus Douche.

 

Offline Avder

  • 25
This is a post from another thread I had made that mostly explains this phenomenon. The info was taken from various other forums when I noticed the same thing:

That was back before my accuracy went to **** for whatever reason.  I can't use it effectively anymore.  Maybe it's the joystick (currently on x45, where before I had a Cyborg 3D gold), or this fuzzy direct input thing I've heard mentioned a couple of times.  I just can't nail down what's different.

On a few other message boards they had an explanation for this phenomenon. From the days of Windows 9x to now, the way Direct Input reacts to joystick movement has changed. It used to use absolute values from the joystick which would translate to instant movement in whatever direction (X,Y) away from 0 (zero - center) the joystick was moved. Whether you moved the joystick 25, 50, or 100% away from center and no matter how quickly or slowly you moved it, your ship would change direction based on input instantaneously. Conversely, releasing the joystick to center would instantly snap the ship to straight. This method actually made the joystick act more like a mouse.

Later, in order to make turning seem more "realistic" (and unfortunately, it really is), there was a delay added (attitude acceleration/deceleration) since it was felt that, realistically, it took time for a aircraft/starship/whatever to respond to input from its pilot based on the craft's speed, weight, drag, etc. The net effect is: if you were to slam the joystick 100% in any direction using the old Direct Input method, the ship would almost instantly turn in that direction whereas now it has to accelerate to full turn speed (which can take up to 1 second to accomplish) before reaching its maximum. Bottom line: this makes the joystick less responsive and has the effect of causing overcompensation when targeting - often overshooting the target you're trying to get a fix on (the ship has to accelerate into the turn but then has to decelerate when the target nears the reticle - the deceleration causing the overshoot).

Also, the effect is adjustable for game-designers to give a custom "feel" for various ships in a game (based on percentages from up of down from default, from what some have stated elsewhere). This makes it easier for designers to create different performance characteristics on the fly (for example, while the Valkyrie would be 5% less than default input values, the Medusa would be 40% less than default input values so it would seem "heavier" or more "sluggish" during directional changes).

Well, I think my video above eliminates DirectInput as the culprit.  That video was taken using the current final release, but the result is exactly the same in the antipode SDL release.

AV8R: That's what we thought at first, but it isn't craft inertia in this case. With inertia, you *do* get an instantanious response from the joystick, but the ship needs a bit of time to accelerate up to the delta-theta.

What Avder is experiencing is some kind of bug with how FSO interacts with the hardware, and what's got me stumped is that it also appears on the Antipodes SDL-Everywhere builds.

Avder: What are your system specs for this machine? Specifically: OS brand and version, CPU, motherboard, amount of RAM, and video card. Are you using an expansion card to connect your joystick?

The debug should builds show your framerate, and should be at least 20 or 30 FPS.

Do you get the same lag when using the mouse?

Well when I generated that log I just let it load until I got to the hangar like the instructions said.  However I've never noticed any framerate problems.  In fact I'd say that my FPS in any version of FSO with any mod has never dropped below 60. In fact I know my FPS is way above 30 because when I recorded that video my FPS got locked to 30 which is the recording softwares limit and I can see a clear difference between 30 and 60.  You'll notice I do disable shaders tho through the command line.  That's because when I downloaded the antipode release suddenly everything was invisible except for ship lights that have been added in the media VP mods.  Guessing it's just cause my machine is old.

Anyway, here are my specs:
Intel Core 2 Quad Q8300 2.5GHz
Gigabyte UD3P motherboard
8 GB Ram
AMD HD4850 with 1GB of ram.

Both the Sidewinder Precision 2 and the Saitek Evo are connected through USB ports on the front panel of my computer, which are themselves connected to a USB header on the motherboard.  The Sidewinder 3D Pro is connected through a Grendel USB adapter which is connected to a USB port on the back panel, as is the 360 Controller (built in ports on the rear of the motherboard)

Running Windows Vista 64 bit, believe it or not.  Got it for free while attending school.

As for lag with the mouse, nope.  As you can see when I fire for the 2nd time in that little video, the mouse responds pretty much instantly as expected.  As I said, the first time I fire in that video it's by bringing my hand back HARD against the joysticks trigger.  The second time I fired was by slapping my hand down hard on the left mouse button.   With the joystick, it fires instantly but takes a while to start moving.  In fact I pulled the joystick back to full deflection before any turning took place.  So it's not like the input isn't getting to the game in time.

As I am currently running my joystick through a script that emulates it as a mouse, I get some slight delay with it, but nowhere near as bad as if I were using a joystick directly.  Basically less than half the lag seen in the video above when I fire for the first time.   The video was made with my joystick selected directly in the launcher.
« Last Edit: August 19, 2015, 12:17:20 am by Avder »

 

Offline Avder

  • 25
Can add the Project 64 emulator with nrage 2.3c input plugin as programs that have no joystick input lag for both my saitek and xbox 360 controller.  My xbox 360 controller is also using custom drivers, so directinput all the way.

 

Offline z64555

  • 210
  • Self-proclaimed controls expert
    • Minecraft
    • Steam
Ok, I figured out the issue.

Code: [Select]
playerman/playercontrol.cpp: 378
if ( (Joystick_last_reading == -1)  || timestamp_elapsed(Joystick_last_reading) ) {
// Read the stick
control_get_axes_readings(&Joystick_saved_reading[0], &Joystick_saved_reading[1], &Joystick_saved_reading[2], &Joystick_saved_reading[3], &Joystick_saved_reading[4]);
--> Joystick_last_reading = timestamp( 1000/10 ); // Read 10x per second, like we did in Descent.
}

The polling rate is using a rather slow polling rate of 10Hz, which is fine if the framerate is like, 20FPS or less, but seriously noticable otherwise.

I'll see if I can refactor this a bit to go with a faster poll rate, so expect a test build soonish.
Secure the Source, Contain the Code, Protect the Project
chief1983

------------
funtapaz: Hunchon University biologists prove mankind is evolving to new, higher form of life, known as Homopithecus Juche.
z64555: s/J/Do
BotenAlfred: <funtapaz> Hunchon University biologists prove mankind is evolving to new, higher form of life, known as Homopithecus Douche.

 

Offline Avder

  • 25
A 10 hz polling rate?  And they used that same rate in Descent?

Weird.

Dont most games poll close to 60Hz?

And is the mouse polled differently somehow?

 

Offline z64555

  • 210
  • Self-proclaimed controls expert
    • Minecraft
    • Steam
Doesn't seem many folk had noticed the issue until recently, and whats weird is that the observed lag is twice that of what it's expected to be (200ms vs 100ms from the 10Hz polling).

FSO isn't limiting the mouse polling rate at all, it's whatever the OS decides to do.
Secure the Source, Contain the Code, Protect the Project
chief1983

------------
funtapaz: Hunchon University biologists prove mankind is evolving to new, higher form of life, known as Homopithecus Juche.
z64555: s/J/Do
BotenAlfred: <funtapaz> Hunchon University biologists prove mankind is evolving to new, higher form of life, known as Homopithecus Douche.

 

Offline Avder

  • 25
So what are you shooting for as far as polling?  Can it be dynamic and sync with framerate?  Or just go straight up 60hz?

Also I will happily tinker with the test build when it's ready.

And are joystick buttons polled differently?  I see it's labeled for axes.

 

Offline z64555

  • 210
  • Self-proclaimed controls expert
    • Minecraft
    • Steam
Yes, the lag seems to be more noticeable as the framerate increases.

So what are you shooting for as far as polling?  Can it be dynamic and sync with framerate?  Or just go straight up 60hz?

Also I will happily tinker with the test build when it's ready.

And are joystick buttons polled differently?  I see it's labeled for axes.

FSO has a timing system that is largely independent of the framerate, so its best poll rate would be no faster than the framerate (which is good). MageKing and I have run some tests at different poll rates, with 18Hz significantly helping and 60 and 75 being smooth. I'm concerned that the higher poll rates may actually bring down the framerate on older machines, which is why I haven't completely abolished the limit and let it be governed by the framerate.

Since you've stated that you have an older machine, I'd like you to run a test build that I've made.

This build removes the poll rate, and thereby has the joystick polling limited solely by the framerate. If you can, try to compare the frame rate of this one to another debug build to see if there's any major differences.
Secure the Source, Contain the Code, Protect the Project
chief1983

------------
funtapaz: Hunchon University biologists prove mankind is evolving to new, higher form of life, known as Homopithecus Juche.
z64555: s/J/Do
BotenAlfred: <funtapaz> Hunchon University biologists prove mankind is evolving to new, higher form of life, known as Homopithecus Douche.

 

Offline AdmiralRalwood

  • 211
  • The Cthulhu programmer himself!
    • Skype
    • Steam
    • Twitter
Ok, z64555, I know you didn't want to hear from me specifically, but with this test build the delay seems to have improved from about .5 to .75 seconds to about .25 seconds without a drop in framerate (which normally runs at 75hz on my system).
.5 to .75 seconds? How is that even playable?

And you still have a delay of a quarter-second with this build? .25 seconds is a bigger delay than I have without polling every frame. Are these measurements exact, or your "gut feeling" of how long it takes?
Ph'nglui mglw'nafh Codethulhu GitHub wgah'nagl fhtagn.

schrödinbug (noun) - a bug that manifests itself in running software after a programmer notices that the code should never have worked in the first place.

When you gaze long into BMPMAN, BMPMAN also gazes into you.

"I am one of the best FREDders on Earth" -General Battuta

<Aesaar> literary criticism is vladimir putin

<MageKing17> "There's probably a reason the code is the way it is" is a very dangerous line of thought. :P
<MageKing17> Because the "reason" often turns out to be "nobody noticed it was wrong".
(the very next day)
<MageKing17> this ****ing code did it to me again
<MageKing17> "That doesn't really make sense to me, but I'll assume it was being done for a reason."
<MageKing17> **** ME
<MageKing17> THE REASON IS PEOPLE ARE STUPID
<MageKing17> ESPECIALLY ME

<MageKing17> God damn, I do not understand how this is breaking.
<MageKing17> Everything points to "this should work fine", and yet it's clearly not working.
<MjnMixael> 2 hours later... "God damn, how did this ever work at all?!"
(...)
<MageKing17> so
<MageKing17> more than two hours
<MageKing17> but once again we have reached the inevitable conclusion
<MageKing17> How did this code ever work in the first place!?

<@The_E> Welcome to OpenGL, where standards compliance is optional, and error reporting inconsistent

<MageKing17> It was all working perfectly until I actually tried it on an actual mission.

<IronWorks> I am useful for FSO stuff again. This is a red-letter day!
* z64555 erases "Thursday" and rewrites it in red ink

<MageKing17> TIL the entire homing code is held up by shoestrings and duct tape, basically.

 

Offline Avder

  • 25
The polling change works beautifully, but I'm having some kind of weird axis problem with the test build:

For some reason while in game, whenever my throttle is at zero,  my ship will be at full bank right as well. Throttle at max results in no banking.  Twist axis doesn't do anything.

I have no idea how this is possible, because they bind correctly in the menus.

And yes I've verified they both work (input lagged) in the non-test versions.

 

Offline Avder

  • 25
I can also confirm that the joypoll change has no effect on framerates.

Did testing by playing fsport/media vp's 2014 and playing the mission "paving the way" in the simulator.  In the joypoll debug build I get ~30fps while looking at the asteroid field.  In the current antipodes 9 debug build I also get ~30fps when looking at the asteroid field.  In the non-debug version of antipode 9, I get 60fps, so I assume I would also get 60 in a non-debug joypoll build. 

Any chance of getting that, with or without the roll/throttle axis stuff fixed?  The X/Y axis action is considerably smoother and more responsive than my makeshift joy2mouse workaround that I've been playing with up until now.

 

Offline AdmiralRalwood

  • 211
  • The Cthulhu programmer himself!
    • Skype
    • Steam
    • Twitter
.5 to .75 seconds? How is that even playable?

And you still have a delay of a quarter-second with this build? .25 seconds is a bigger delay than I have without polling every frame. Are these measurements exact, or your "gut feeling" of how long it takes?

Did you see the video Avder posted? The game is still playable, just deficient in timely response with a joystick.
Yes, I did, and it's a much shorter delay than .5 to .75 seconds. The video shows a maximum delay of approximately .2 seconds (the Subach HL-7 fires 5 times per second).
Ph'nglui mglw'nafh Codethulhu GitHub wgah'nagl fhtagn.

schrödinbug (noun) - a bug that manifests itself in running software after a programmer notices that the code should never have worked in the first place.

When you gaze long into BMPMAN, BMPMAN also gazes into you.

"I am one of the best FREDders on Earth" -General Battuta

<Aesaar> literary criticism is vladimir putin

<MageKing17> "There's probably a reason the code is the way it is" is a very dangerous line of thought. :P
<MageKing17> Because the "reason" often turns out to be "nobody noticed it was wrong".
(the very next day)
<MageKing17> this ****ing code did it to me again
<MageKing17> "That doesn't really make sense to me, but I'll assume it was being done for a reason."
<MageKing17> **** ME
<MageKing17> THE REASON IS PEOPLE ARE STUPID
<MageKing17> ESPECIALLY ME

<MageKing17> God damn, I do not understand how this is breaking.
<MageKing17> Everything points to "this should work fine", and yet it's clearly not working.
<MjnMixael> 2 hours later... "God damn, how did this ever work at all?!"
(...)
<MageKing17> so
<MageKing17> more than two hours
<MageKing17> but once again we have reached the inevitable conclusion
<MageKing17> How did this code ever work in the first place!?

<@The_E> Welcome to OpenGL, where standards compliance is optional, and error reporting inconsistent

<MageKing17> It was all working perfectly until I actually tried it on an actual mission.

<IronWorks> I am useful for FSO stuff again. This is a red-letter day!
* z64555 erases "Thursday" and rewrites it in red ink

<MageKing17> TIL the entire homing code is held up by shoestrings and duct tape, basically.

 

Offline Avder

  • 25
I concur with the throttle anomaly. I had to set throttle at full on the keyboard to stop turning.

Throttle on keyboard had no strange effect for me at all.  It was some kind of weird axis play where my joystick throttle controlled both absolute throttle and roll. 0% throttle meant 100% Roll Right, and 100% Throttle meant roll neutral (no roll).

I debound both axes and have re-profiled my joystick back to having the twist activate my KB roll keys as a workaround.  Roll is considerably less important than yaw or pitch, but it would sure be nice to have it on my twist as analog controls  :)

Of course I guess I should mention that I've relocated my keyboard throttle keys to the 1-4 keys instead of the []\backspace keys.  Maybe that had something to do with keyboard throttle not doing anything weird for me?

And also am I correct in assuming that the joystick lag we're pinning down here will also be present in Diaspora?

And I'd just like to re-iterate my request for a non-debug build of this, roll/throttle fixed or not.