Εγκατάσταση Steam
Σύνδεση
|
Γλώσσα
简体中文 (Απλοποιημένα κινεζικά)
繁體中文 (Παραδοσιακά κινεζικά)
日本語 (Ιαπωνικά)
한국어 (Κορεατικά)
ไทย (Ταϊλανδικά)
Български (Βουλγαρικά)
Čeština (Τσεχικά)
Dansk (Δανικά)
Deutsch (Γερμανικά)
English (Αγγλικά)
Español – España (Ισπανικά – Ισπανία)
Español – Latinoamérica (Ισπανικά – Λατινική Αμερική)
Français (Γαλλικά)
Italiano (Ιταλικά)
Bahasa Indonesia (Ινδονησιακά)
Magyar (Ουγγρικά)
Nederlands (Ολλανδικά)
Norsk (Νορβηγικά)
Polski (Πολωνικά)
Português (Πορτογαλικά – Πορτογαλία)
Português – Brasil (Πορτογαλικά – Βραζιλία)
Română (Ρουμανικά)
Русский (Ρωσικά)
Suomi (Φινλανδικά)
Svenska (Σουηδικά)
Türkçe (Τουρκικά)
Tiếng Việt (Βιετναμικά)
Українська (Ουκρανικά)
Αναφορά προβλήματος μετάφρασης
For what it's worth, the game has not been updated since December 6th, 2012. (Damn, it does not feel like 5 years ago! :( )
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.
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!)
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.
Same here. The mouse slideshow lag makes this game unplayable and I'm also using nVidia (I had AMD in the past). :(
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. 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.
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.
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?