View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001022 | FSSCP | gameplay | public | 2006-08-05 20:49 | 2010-12-09 22:48 |
| Reporter | castor | Assigned To | taylor | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | unable to reproduce | ||
| Summary | 0001022: Game speed issues on Linux | ||||
| Description | The speed/pace of gameplay under Linux is less than that of the retail FS2. I dont get this problem on Win98 builds 3.6.9RC5 or recent CVS head (OGL). The speed difference is most prominent on the perceived ship maneuverability and primary weapon fire rate (behaves like a negative time compression was in effect). The "slowmo" effect is not continuous, rather it seems to be triggered on/off (mostly on) as "circumstances" in the game change. However, I could not by any consistency find the actual "trigger" for it. According to the FPS counter it seems to be independent from rendering speed, as I get consistent 100+ FPS even during the slowmo periods. I don't get this problem with FSO 3.6.7, so I tried to track down the date the related changes were committed: co -r "fs2_open_3_6_7" fs2_open => OK co -r "fs2_open_3_6_9" fs2_open (on 3rd of Aug) => NOT OK co fs2_open (on 3rd of Aug) => NOT OK co -D "2005-12-16" => OK co -D "2005-12-17" => NOT OK So it seems that the changes made between 16th and 17th of Dec 05 are somehow related. As a possibly related observation, I noticed that similar slowdown occassionaly takes place under Linux even in 3.6.7, when ships are warping in (but there the normal speed is always resumed after the warp sequence has ended). Some things I've tried out: Media VPs - occurs with both 3.6.8 and retail VPs resolution - occurs with 640*480 and 1024*768 bitdepth- occurs with both 16 and 32 bits fs2 options - occurs with no options as well as with -spec -glow etc.. ingame detail - settings for model, texture, lightning etc. detail makes no difference | ||||
| Additional Information | * HW: Athlon-xp 2500+, Radeon9550 * Xorg 7.0 * fglrxinfo: OpenGL vendor string: ATI Technologies Inc. OpenGL renderer string: RADEON 9600 Generic OpenGL version string: 2.0.5946 (8.27.10) | ||||
| Tags | No tags attached. | ||||
|
|
Make sure that v-sync is enabled and try again. There is a sleep issue (maybe with the game, likely with SDL and some distros) where the timing gets a bit strange with higher FPS. The code hasn't changed with regards to the sleeping from when it works and when it doesn't which is why I like it's at a SDL/distro level. |
|
|
Ok, I now tried it with v-sync enabled -- no avail. I'll try and tweak it a bit more on tomorrow.. |
|
|
I now tried with using the SDL-stuff from www.libsdl.org (instead of the Debian/etch versions), but it didn't change the situation (I'm not familiar with the SDL, maybe I need to configure something somewhere..). But it appears that your thoughts about "higher FPS" timing problems coud be right; when I up the resolution to 1280x1024 to get the FPS below 90 or so, the problem disappears. Unless it has something to do with the resolution itself (edit: nope, its not the resolution, runs ok with 1024*768 too when I slow it down enough with FSAA). Funny problem, I think its the first time I need to INCREASE screen resolution to get a game run faster :) edited on: 08-08-06 12:20 |
|
|
why are we calling sleep taylor? the code itself already handles variable time by storing the incremental time between frames for time-dependant simulation calculations |
|
|
@castor: When using v-sync, make sure that it's not disabled at the driver level (the NVIDIA env variable, etc.) since if it is then the game can't actually enable it properly. I think that something may have changed in some SDL version, since this just all of a sudden starting happening even though there had been no code changes to the game. I just started using v-sync and ignored the problem, but I do really need to work out a fix for it (there are a few that already exist). @Kazan: Sleeping is required to keep the framerate from going out of control. It's only ever called when the framerate goes over the limit for that screen (120 in the in-mission case). |
|
|
we should really figure out why we have to cap the framerate.. because physics engines that operate on incremental time (game physics) have the properties of a reimann sum - the greater n the more accuracy - n being fps in the case of games. |
|
|
Damn, v-sync wasn't really working like Taylor guessed. Modifying xorg.conf alone (with aticonfig) wasn't enough, I had to edit ~/.drirc too, as post 0000050 in this thread describes: http://www.rage3d.com/board/showthread.php?t=33862507&page=2 Everything works fine and smooth now, Thanks a lot! |
|
|
@castor: Yep, thought that might have been the case. Just telling everyone to use v-sync isn't a good long term solution though. I'll just keep this open and work on it again post-3.6.9. @Kazan: It's mainly just to keep the game from running wild with system resources. There needs to be some control on it and sleeping when the game gets processing really fast allows for that. It wouldn't be as much of an issue if the engine were multithreaded, but since it isn't then it's a big deal to keep control of the thing. |
|
|
so basically it's to protect operation systems that cannot preemptively multitask even if they claim to *cough*windows*cough* |
|
|
Multitasking is one thing, using 100% of the available system resources when you don't need to is another. It's just bad programming to let your process run wild like that. Each OS has it's own set of issues with preempting. Not one of them works perfectly, it's a trade-off, but that doesn't mean that we are doing the wrong or cheap thing by capping the framerate. Going multithreaded fixes most of the issue, but that's not going to happen any time soon. There is an unbelievable amount of code we use that isn't thread-safe, not to mention the fact that each OS has it's own little issues with regards to how threading needs to work. Having it sleep is simply the best solution for now, and it cuts down on the amount tearing at the least, when v-sync isn't used. |
|
|
Is this still an issue? It's one of the oldest in mantis. |
|
|
I don't have the proper hardware to test it anymore, but I guess this could be closed since nobody has seen the problem in a long long time (afaik). |
|
|
And closed. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2006-08-05 20:49 | castor | New Issue | |
| 2006-08-05 21:27 | taylor | Note Added: 0006385 | |
| 2006-08-05 23:12 | castor | Note Added: 0006386 | |
| 2006-08-08 16:03 | castor | Note Added: 0006396 | |
| 2006-08-08 16:09 | Kazan | Note Added: 0006397 | |
| 2006-08-08 16:20 | castor | Note Edited: 0006396 | |
| 2006-08-08 17:50 | taylor | Note Added: 0006398 | |
| 2006-08-08 17:50 | taylor | Status | new => assigned |
| 2006-08-08 17:50 | taylor | Assigned To | => taylor |
| 2006-08-08 18:12 | Kazan | Note Added: 0006400 | |
| 2006-08-08 18:41 | castor | Note Added: 0006402 | |
| 2006-08-08 18:55 | taylor | Note Added: 0006403 | |
| 2006-08-08 19:12 | Kazan | Note Added: 0006407 | |
| 2006-08-08 19:52 | taylor | Note Added: 0006411 | |
| 2006-08-29 03:22 | taylor | Severity | major => minor |
| 2009-06-07 15:33 | portej05 | Note Added: 0010960 | |
| 2009-06-07 15:33 | portej05 | Status | assigned => feedback |
| 2009-06-10 17:30 | castor | Note Added: 0010972 | |
| 2010-12-09 22:48 | The_E | Note Added: 0012528 | |
| 2010-12-09 22:48 | The_E | Status | feedback => closed |
| 2010-12-09 22:48 | The_E | Resolution | open => unable to reproduce |
