Recent Update, or other change, breaks Fieldrunners (Mouse Lag, etc)

[CLBrown]

I have been playing this game for ages... first on my Roku, and later on Steam. It's been one of my favorite time-burner games.

Unfortunately, recently (as in, within the past several months...) something changed in the program. I'm currently running it on two different Windows 7 (64-bit) installations, plus on a Win 10 laptop. All show the same symptoms.

Basically, the mouse behavior has been broken. I'm not sure why, but it seems to be pretty much universal on ANY machine using more than one USB input device of any kind... the more devices, the worse the "mouse lag" becomes.

My guess? The team "fixed" it by "optimizing" some part of the code... and the "fix" screwed things up. We've seen this before on other games.

Anyone else having the same experience, and discover a solution (other than disconnecting and disabling all other USB input devices and similar devices)?

[jim.buck]

Is it stuttering like noted in other threads here? Or just simply a second or two (or more? or less?) behind what your actual hand is doing? If so, how long does the lag feel?

For what it's worth, the game has not been updated since December 6th, 2012. (Damn, it does not feel like 5 years ago! :( )

[CLBrown]

Originally posted by jim.buck:

Is it stuttering like noted in other threads here? Or just simply a second or two (or more? or less?) behind what your actual hand is doing? If so, how long does the lag feel?

For what it's worth, the game has not been updated since December 6th, 2012. (Damn, it does not feel like 5 years ago! :( )

It's not a simple "lag" as much as almost a "slide-show" speed mouse recognition. Every roughly second or so, the mouse seems to be detected by the program.

This is entirely new behavior. The last time I played this on the computer was about three months ago, and the problem did not exist at that point. Then, recently, I tried running it and started seeing this behavior.

The game itself seems to run... the graphics are fine, the calculations seem normal, no crashes, no glitches. Just the mouse issue. However, since the game ENTIRELY controlled via mouse (well, mouse and two keyboard buttons)... this is a pretty big deal.

I hadn't played it on my PC in a while because I played it regularly on my Roku 2 XS. However, that recently died, and I replaced that with a new Roku... and apparently Roku has eliminated "motion gaming support" on all their newer model players, so Fieldrunners was gone on that. Imagine my chagrin at discovering that it's not playable on a PC anymore, either. (sigh)

I can help you diagnose the issue if there's additional information I can provide to you. I'm not quite sure what info you might need, however. Feel free to ask, in any case.

I'd love to have this game running again.

[jim.buck]

Hmm, I don't really have any ideas other than the obvious - anything change with your PC in regards to hardware/software/drivers/etc.?

[CLBrown]

Originally posted by jim.buck:

Hmm, I don't really have any ideas other than the obvious - anything change with your PC in regards to hardware/software/drivers/etc.?

Nothing whatsoever. Plus, this is on all three computers (with wildly different configurations) I have STEAM on. One running almost new hardware, running Win7-64 Ult, one on five year old hardware, running Win7-64 Ult again, and one on a two-year-old laptop, running Windows 10.

The older machine has a lot more USB devices attached, and the "slideshow mouse" behavior is worst on it. The laptop has the least USB devices attached, and the "slideshow mouse" behavior is the least significant (but still enough to make it unplayable) on that system.

Anyway... since F.R. was originally designed to run on mobiles (Oddly, I can't seem to find the original one in a form able to be played... according to Google Play, anyway... on my Galaxy S7, I can't try it on there. Even though I suspect, strongly, it would run just fine!)

[CLBrown]

Originally posted by jim.buck:

Hmm, I don't really have any ideas other than the obvious - anything change with your PC in regards to hardware/software/drivers/etc.?

Actually, now that I think about it... ONE thing has changed. I'm running newer nVidia drivers, which put the "NV overlay" over the program when it runs. I get the little "flag" in the upper right corner telling me that "Alt Z" will take me into the nVidia overlay. This is something new, and something COMMON between all three machines (at around the same time). It's possible that the nVidia overlay isn't behaving nicely. I have no idea how to test whether this is the case, short of removing my current drivers and putting in some older ones (which might still not work, without going in and manually removing 100% of all nvidia files and registry entries, as I'm sure you understand). But this IS a common thread, and does represent the one thing that has changed... in all cases, which interacts with this program in some manner.

[jim.buck]

There is no way to exit the overlay program (like something in the notification area of Windows, by the clock)? Also, do you happen to have USB gamepad plugged in? Try unplugging those, if so, and see if that changes anything. (An early theory was that connected controllers would mess with it.)

As for other platforms.. yeah, on iOS, it is still the original Objective-C-based codebase. I converted it to a C++ codebase for PSP back in 2009 (oh, my, over 8 years ago! I'm not liking this thread making me realize how old this stuff is ;) ), and that C++ codebase continued life for all the non-iOS platforms (android, roku, C++-converted-to-html for html5 version, Steam for Windows/OSX, and probably something else I am forgetting) while iOS still uses the original Objective-C codebase.

[SX]

Hi,
Same here. The mouse slideshow lag makes this game unplayable and I'm also using nVidia (I had AMD in the past). :(

[CLBrown]

Originally posted by jim.buck:

There is no way to exit the overlay program (like something in the notification area of Windows, by the clock)? Also, do you happen to have USB gamepad plugged in? Try unplugging those, if so, and see if that changes anything. (An early theory was that connected controllers would mess with it.)

Nope, nVidia has actually removed the tray icon in recent releases entirely, because it supposedly was adding too much system overhead. So, instead of fixing the problem, they just pulled the little tray icon app (which, I suspect, wasn't really the issue).

The various other vNidia tools... such as the "overlay"... are now part of the driver installation package, and there seems to be no obvious means of disabling them.

Then again... very, very graphics-intensive programs don't seem to be impacted by this... in fact, I have seen this issue with no other program besides Fieldrunners (1)... so it likely isn't so much an issue with "too much system resources consumed" as it is "some direct interference between an element of the PC implementation of Fieldrunners and this system."

I understand you (from what you've written so far) don't seem to have access to a "debugging installation." In fact, it almost sounds as if you're not employed doing this anymore (I've worked with a number of devs over the years who still personally support things they created in the past but are no longer paid to support, so this would not be atypical). If so, I of course will not make any form of "demands" on your time... in any case, whatever assistance you can provide will be appreciated.

As for other platforms.. yeah, on iOS, it is still the original Objective-C-based codebase. I converted it to a C++ codebase for PSP back in 2009 (oh, my, over 8 years ago! I'm not liking this thread making me realize how old this stuff is ;) ), and that C++ codebase continued life for all the non-iOS platforms (android, roku, C++-converted-to-html for html5 version, Steam for Windows/OSX, and probably something else I am forgetting) while iOS still uses the original Objective-C codebase.

I'm a mechanical R&D guy, myself... and the stuff I develop remains in use and production for years beyond when I worked on it, typically. Decades in many cases. So, my worldview does seem to be a lot longer-term than that of the typical software guy... ;)

To me, something eight years old is still relatively new... that's roughly when it begins to be treated as "mature, with all the major bugs worked out." :)

I doubt I'll ever be able to fully "grasp" the so-much-shorter lifecycle pushed these days in software. Then again, I run DOSBox, a couple of VMs, and use the full-on MS Compatibility Toolkit (with all the various obscure tweaks) to run software that "officially" cannot be run at all anymore... and have discovered many of the "tricks" used to prevent software (Doom3, Thief3, etc) which WILL run on "older" OS's from doing so (in those two cases, the sole culprit was the icon resource size embedded in the EXE, believe it or not!... by removing the icon resource from the EXE, the programs ran just fine in Win9x... despite being "XP only" at the time.)

So, from that standpont... F.R.1. is actually something which seems like it ought to be an easy fix. But yeah, I'm 90% convinced it's some interaction between the PC-port's "shell wrapper" (whatever that was) and the current nVidia driver bloatware.

[Zentory]

I've got these mouse problems too. I can move the mouse cursor and if I move the mouse really slow the cursor follows without any lag. If I move the mouse faster, the cursor lags.
There are two other devices pluged in. A XBox controller and a STEAM Controller (only the usb dongle). But if I turn on the STEAM controller, the mouseproblems are fixed till the controller turns off automatically after some minutes. At this moment the mouse problems are back.
Maybe this information helps the dev.

[jim.buck]

Yeah, I'm not contracted any more to work on Subatomic stuff for a while now. Last thing I did for them was FR2 on PSVita, which is 3 years old this month. I do have the source code to FR1, and I did make an attempt at commenting out any controller code to see if that was a problem, had someone on the forums here test the updated .exe, but he still had the problem. Unfortunately, yeah, at this point, I am only really able to just troubleshoot via some questions on the forum unless Subatomic were to enlist me again for this issue.

I am not sure if it can help track this down at all, but I used SFML for interfacing with the OS.. using whatever version of SFML I had at the time. I don't know if it had any known issues. I wasn't doing anything fancy, just using it in the most basic and straightforward of ways (i.e. tell me when the mouse does something, tell me when the keyboard does something, tell me when to render the next frame, etc.). Also, I was developing FR1 using Visual Studio 2008 on WinXP, and I don't know if that combo of older SFML, older Visual Studio, and older Windows OS is playing weirdly on a Win7/10.

Interesting what Zentory says above about it working ok when a controller is *connected*. That does jog some memories of forums posts some years ago about that being a fix (why that would fix it, I don't know, but that may have been the reason I tried a version of the .exe that disables all controller code in SFML). Do you have a controller you could try connecting to see if that kicks FR1 to not do anything weird with the mouse?