|
|
here are my command line parameters: fs2_open_3_6_9.exe -spec -glow -2d_poof -cache_bitmaps -ship_choice_3d -wcsaga -snd_preload -ambient_factor 100 |
|
|
I took a closer look today (must have been 4 hours I spent trying to figure out what was wrong ;) ). I get a glimpse of asteroids at nav1, then they start to make erratic movements ("buzzing like flies") and then they are gone. This seems to be related to the global speed of the asteroid field (I am not sure what it is for). At any rate, replacing 4 with a zero did the trick. Here is the bit of the FRED code: #original entry $Density: 256 +Field Type: 0 +Debris Genre: 0 +Field Debris Type: 0 +Field Debris Type: 1 $Average Speed: 4.000000 $Minimum: 22000.000000, 6500.000000, -50000.000000 $Maximum: 39000.000000, 10500.000000, -46500.000000 #replaced with... $Density: 256 +Field Type: 0 +Debris Genre: 0 +Field Debris Type: 0 +Field Debris Type: 1 $Average Speed: 0.000000 $Minimum: 22000.000000, 6500.000000, -50000.000000 $Maximum: 39000.000000, 10500.000000, -46500.000000 P.S. I did not try, but this might as well fix the "popping up" (I wonder for a better term.) effect I have with asteroids. |
|
|
Try: http://icculus.org/~taylor/fso/testing/rc7dot9x.rar It shouldn't make a difference in the speed problem, but it restores the lighting falloff that non-HTL had. This makes asteroids more difficult to see the further away that they are since it lowers the light applied to them. It should lessen the effect of them popping in and out of view until I can finish coding up a proper fix for post-3.6.9 builds. |
|
|
I'll try it asap. What can we do, apart from waiting for a fix? Revert to FS2 asteroids? Reduce texture resolution? |
|
|
Well, I think that the MediaVP asteroids had non-power-of-2 textures (ie, like 800x600 or something like that), which makes then slower to use. You can just resize them to a power-of-2 size and see if that helps. I had done this for my own MediaVPs (even though I don't need to, my video card supports non-power-of-2 textures natively) and thought that it possibly could be the cause of the some of the slowdown. The problem is that the game should handle the non-power-of-2 textures just fine, but perhaps it's hitting a bug or something and only some cards/drivers are able to trigger it. I've been through the code and can't find a reason for the slowdown at all. If it's linked to "$Average Speed" in any way then I sure can't figure out how. |
|
|
hmm... you couldn't upload your texture maps, could you? And I am not sure if our asteroids are up-to-date. My Media VPs date back to May 2006, although I am not sure where I get them in the first place. As I mentioned this before, only slower GPUs are affected by this (and only at 64x time compression). I'll check the POFs and texture maps next. |
|
|
I just checked: texture maps are power of two (1024*512). Asteroid models have around 7k polys in lod1, 120 in lod4. |
|
|
I can't run the executable on my subnotebook. Upon launch it will switch into pause mode (you can see the briefing screen in the background). I can do nothing else but start the task manager and kill fs_open.exe. |
|
|
Okay, I just replaced MediaPack VP asteroids with the low detailed asteroids from FS2 VPs. Voila. Everything works. Then again, if I use VP asteroids and fly manually (32x time compression) to the asteroid field, everything will work just as fine. If I set time compression to 64x asteroids will start to make very erratic movements after a few seconds. Then they seem to fill my screen and vanish. If I wait a couple of minutes they will respawn. Somehow it reminds me of Star Trek and the warp drive :) |
|
|
Try this and see if it also remedies the problem: http://icculus.org/~taylor/fso/misc/ast-test.rar This is the hi-poly asteroids, textures, and IBX files from my own VP set. If it fixes the problem then we'll just assume that there is some issue with the MediaVP asteroids/data and leave it at that. |
|
|
nope. 32x - fine, 64x - bad :) |
|
2006-11-28 09:59
|
screen0022.jpg (52,009 bytes) |
|
2006-11-28 10:00
|
screen0023.jpg (51,733 bytes) |
|
2006-11-28 10:00
|
screen0024.jpg (42,322 bytes) |
|
|
I doubt I can record a video clip to show how it really looks like. I wish I could. Here are a couple of screenshots. |
|
|
I don't know if this can be related to it. I can assure that general game accuracy is lost when you start increasing time compresion. Till 16x it 'always' works fine. But if you make it higher, specially at 64x, you get quite strange behaviours. For example while testing my loved Derelict's 'The Stars are Right' (0000962), I always use time compresion till the Moloch arrives. If I left a high factor enabled I can see at least the following issues: + When the Argo with the engineers undocks from the Ganimede Ring, it follows its waypath quite erratically. + When the Moloch arrives from subspace, it stops at a different position than with 1x. + Beams accuracy is lost. As an example, the SD Lucifer usually misses the facing Sobek. (I have always thought that this effect was unsolvable and fully known). |
|
|
it seems to happen only on low end systems. |
|
|
Well, my PC is not a Mega-Ultra-High-Tech Core 2 Quad with two overclocked SLI 8800GTX GPUs, but it isn't VERY bad: P4 HT 2.8 GHz + RAM 1.5 GB DDR400 + nVidia AGP 7800GS So if the time compresion issues are related to PC specs, it shouldn't appear here. |
|
|
I should have made myself more clearly :) I was refering solely to the asteroid vanishing while using time compression 64x (which we do in autopilot mode). @taylor: regarding the asteroid appearing in certain distance on a Geforce6800. I am not sure if I had it before. It might be just an effect of time compression (asteroid respawn), because not all asteroids are affected by this. |
|
|
The asteroid (dis)appearing thing is just old code which needs to be replaced. It has nothing to do with the persons computer, or even time compression, but old code which is fixed at saying that beyond 3000 meters any asteroid can appear or disappear. As we keep upgrading the engine and the graphics involved, it becomes far easier to actually see asteroids that far way in perfect detail. That's why I restored the asteroid lighting fall-off in newer builds, it does a little to help hide the problem. I'll get it fixed to work more appropriately after 3.6.9 ships, but it's just too big of a change to do before then. As far as time compression goes, I'm pretty sure that there is an inaccuracy there somewhere which is attributing to the problem. Since many calculations are based on the framerate, with time compression factored in, when you get to the higher time compression levels the accuracy of the math becomes a big issue. I don't know that we can do much of anything about this though, except maybe disable anything above 16x, but I don't think that would work out very well for mods. This is just too big of a problem to come up with a remotely sensible solution for by the time 3.6.9 ships (ie, any day now). I think that the best fix for the time being is to help reduce the inaccuracy of the math. As you already noticed, changing the average speed of the asteroid field to 0 fixes the slowdown. That is a float value, so a setting of 0.7 (for instance) is valid, and should still give the asteroids some movement. The point though, is that the smaller the number the lower the chances of floating point error in the velocity and position calculations for the asteroids. See if just reducing the average speed variable does the trick, instead of setting it to 0, and hopefully that can hold everyone over until we can figure out how to deal with this issue better in the code. |
|
|
I'll try. All I can tell for now is that 2.0 did not work. Of course, we could limit time compression to 32x as it works perfectly. Then again, it will have some impact on the game play seeing, that it will double travel time between navpoints. We could, of course, offer old asteroid models for those, who experience the problem. Or we could remove lod1 on the asteroids and see what happens. At any rate, I'll try 0.7 for the average speed. Tolwyn out. |
|
|
no change is visible :( |
|
|
would it be possible to either limit time compression to 32x globaly or on a mission basis? |
|
|
uhuh, bad news. I believe, that there are two effects, which concern autopilot now. 1. disappearing asteroids 2. performance drop They can occur at the same time or separately although there seems to be some sort of connection. Then again, using old asteroids fixed number 1 for me, but I never experienced number 2. ScoobyDoo from our team reported slow downs for some time now. I believe, that it is related to the asteroid field. He conducted some testing today and was able to confirm my suspicions. I believe he has a Geforce2 card. So, what should we do? Set average speed of the asteroid field to zero? This solves disappearing asteroids AND performance drop, but the overall impression of the field sucks. It becomes static. Offer a fix for those who have the problem? (Altered core.vp available on setup). Of course, another possibility would be to limit time compression to 32x, but that will virtaully double travelling time between nav points. |
|
|
We aren't going to put code hacks in to deal with this (ie, making 32x the max autopilot speed). And since the speed drop only affects certain people apparently, there will be no code changes to deal with that until the exact cause of the slowdown is known. Anything else code related (to properly deal with the disappearing problem) will deffinitely wait until after 3.6.9, and probably won't happen until after Kazan has time to do that asteroid field redo that he was talking about. Unfortunately this just isn't a big enough of a deal to get any real coder time until after 3.6.9 goes out. In the meantime I guess the only option is for you to do whatever you need to do to address your user group. Whether that is mission changes, or using different asteroid models, is up to you. Altough I don't actually anticipate that this will have any sort of affect (at least not positive), try out this VP and see if it does anything: http://icculus.org/~taylor/fso/misc/asttest.rar |
|
|
is it the same vp you gave me a week ago? And yes, this seems to affect a very low number of people, although I can't tell this for certain. In FS2 you usually do not use time compression and asteroid fiels are also very rarely used. |
|
|
It's nearly the same filename (didn't do that on purpose), but it does have a few minor changes. It has a new asteroid.tbl which changes the detail level bumps, the same texture maps that you tried before, and slightly modified asteroid POFs which fix the radius values (just in case). But as I said, I don't really expect this to make much, if any, difference. But since we don't know exactly what the problem is, any change is worth a test to see if it makes any sort of a difference. It will either do nothing, make the problem worse, or make the problem better. In any of those cases it at least provies a clue as to what the actual problem might be. If the radius change helps then it could be physics related, in which case the fixed data might be all that's needed. If it doesn't help then we've just ruled one more thing out. |
|
|
okay, I inserted it into the beta folder. Since it starts with a it will be used instead of prologue_core/ships. Result: same as before. I'll ask someone, who experienced slow downs, to test the VP file. |
|
|
Give this build a try: http://icculus.org/~taylor/fso/willrobinson/Xt0222-win32.rar It should reduce the popping problem. I tweaked the routine there to base its distance checks on the radius of the asteroid field box rather than the fixed 3,000 it used previously. Also, it will now bounce asteroids that are less than 30% past the radius boundary and still in your view. The "bounce" is where it simply reverses the asteroid direction rather than warping it to a different location. So now it is still going to "pop", but it should be far less noticeable. Let me know if this new behavior is acceptable, or even whether makes any difference in this case. |
|
|
My work on this is in the Xt tree, but one of the other devs will need to go through it and figure out if what I was doing was right and/or finish/replace it. |
|
|
This issue can be closed, because time compression is no longer used. |
|
|
that still doesn't mean we should ignore it happened in the first place |
|
|
Tolwyn, any chance you can verify, just for S&G's, that this doesn't still happen with a newer build and an older copy of your project that uses the time compression? |
|
|
Is there any further update on this issue? Last comment was on 09/10/2008 (DD/MM/YYYY) |
|
|
As I said, no longer relevant for Saga. As far as I am concerned, this can be closed. |
- Anonymous
