Huge framerate drop in the presence of certain objects (SVN)

Miramor · Post by **Miramor** » Sat Aug 25, 2007 7:45 pm

Using today's SVN (forget which revision) - my framerate is very high and gameplay is very smooth most of the time, even when I'm being swarmed by a dozen fighters. However, things larger than fighters tend to slow me down drastically whenever they enter my field of view.

Planets don't cause much of a problem. Neither do mining bases; refineries slow the framerate a bit more, but not that much. Capships and fighter barracks produce a very obvious reduction in framerate.

The worst are jump points though. When I'm a few km away from a jump point, and it's in my field of vision, the game slows down to about one frame every five seconds. I don't really understand how this is possible, as a jump point is displayed as a simple wire frame, but it is definitely the case.

Is this some kind of trouble with the new graphics tweaks, or what?

(I've noticed other weird stuff too, like debris clouds from destroyed ships being displayed with a giant white square in the background - some kind of issue with transparency or something.)

Post by **hellcatv** » Sat Aug 25, 2007 8:10 pm

what OS and more importantly what video card?

Did you build it yourself?

try moving programs/default.fp somewhere else

Miramor · Post by **Miramor** » Sat Aug 25, 2007 8:17 pm

Linux, i945GM onboard video with 256 MB shared RAM (512 MB total system RAM plus 2 GB swap). Using options that ought to be appropriate for this video card, unless "High Detail" is now configured with a Geforce 6 series card in mind.

Where exactly should I move default.fp?

Post by **ace123** » Sat Aug 25, 2007 8:37 pm

Move it to your desktop or somewhere as long as it's not in the programs folder.

Miramor · Post by **Miramor** » Sat Aug 25, 2007 8:46 pm

Okay will try.

Miramor · Post by **Miramor** » Sat Aug 25, 2007 9:14 pm

Nope, doesn't do anything.

pheldens · Post by **pheldens** » Sat Aug 25, 2007 9:17 pm

Miramor wrote:Nope, doesn't do anything.

If you use dri on radeon r300 (possibly also 200)
You should Enable "disable_lowimpact_fallback"
with driconf.

Maybe the intel driver requires a similar option.
(this prevents software fallback for advanced gl line rendering in the jumppoints)

Your machine is a bit underpowered, you need more ram.
No idea about the intel open driver performance.

Miramor · Post by **Miramor** » Sat Aug 25, 2007 10:02 pm

Underpowered? VS is designed to run reasonably well on Pentium 3 boxen with 256 MB RAM and less than 32 MB of VRAM. That's the claim in the readme anyway. If VS claims to run properly on low-spec hardware and doesn't, it's a bug.

(Thanks for the tip on disable_lowimpact_fallback. Driconf doesn't show an option for that, but I could see what happens if I edit into .drirc. It probably won't be recognized but I figure it's worth a shot.)

Miramor · Post by **Miramor** » Sun Aug 26, 2007 1:01 am

Nope, that doesn't work... thanks anyway though.

pheldens · Post by **pheldens** » Sun Aug 26, 2007 1:10 am

add that in ~/.drirc
<application name="vegastrike" executable="vegastrike">
<option name="disable_lowimpact_fallback" value="true" />
</application>

Miramor · Post by **Miramor** » Sun Aug 26, 2007 2:04 am

That's pretty much what I did, just didn't make it application-specific:

<option name="disable_lowimpact_fallback" value="true" />

winthrowe · Post by **winthrowe** » Sun Aug 26, 2007 4:38 am

I'm experiencing the same issue on a core duo 2ghz with 2gig ram, gentoo linux
OpenGL vendor string: ATI Technologies Inc.
OpenGL renderer string: ATI Mobility Radeon X1400
OpenGL version string: 2.0.6747 (8.40.4)

using SVN revision 11348;
revision 11339 was the last version I played that worked.

I tried the ~/.drirc as suggested above, with no difference, but removing default.fp and default.vp got it running properly again.

Post by **hellcatv** » Sun Aug 26, 2007 8:18 am

first update--I made some performance enhancements....
but ATI is way more strict about GLSL compliance than nvidia...so it may help if you keep both the default.fp and default.vp files there
then run

vegastrike >& errlog.txt
then go ahead and send it to hellcatv@hotmail.com

Just so you folks know...I'm working on shaders that should allow normalmapping and bumpmapping support on cards newer than the Radeon 9600...
older cards should have graceful fallback of course----but I'm not focusing on that until I have all the features I want in it....

pheldens · Post by **pheldens** » Sun Aug 26, 2007 11:52 am

winthrowe wrote:I'm experiencing the same issue on a core duo 2ghz with 2gig ram, gentoo linux
OpenGL vendor string: ATI Technologies Inc.
OpenGL renderer string: ATI Mobility Radeon X1400
OpenGL version string: 2.0.6747 (8.40.4)

using SVN revision 11348;
revision 11339 was the last version I played that worked.

I tried the ~/.drirc as suggested above, with no difference, but removing default.fp and default.vp got it running properly again.

This doesnt work on closed source drivers. It was for mesa dri.

Miramor · Post by **Miramor** » Sun Aug 26, 2007 10:29 pm

hellcatv wrote: optimization of fragment programs... no longer activated if the mesh has exactly one (1) texture... eg turrets, animations, atmosphers, jump gates, etc... until they need them. Also make it not reload the program constant IDs every frame unless the program has changed

Hey, that looks like it might be relevent. Can anyone tell me if there's been a big performance improvement when rendering jump points following this update?

Post by **hellcatv** » Mon Aug 27, 2007 11:25 pm

I just committed a whole host of fragment shader improvements...
including automatic fallback of shaders....
it has 3 shaders to choose from
1) advanced (has all the features we want: normal/bump mapping, per pixel lighting, etc)
2) normal (has all the features VS used to have but in a single pass to improve speed)
3) fixed function (actually slower than 2, but for cards with really primitive capabilities. Needs to rerender polygons over and over to generate desired effects)

if it finds 1 goes too slowly it will try 2...if that goes too slowly it will fallback to 3.... generally 2 would only be too slow if the driver hiccups...or the card is a 3dfx card or something ancient.

We need folks to test this on hardware old and new...see how annoying the fallback procedure is, etc....

Miramor · Post by **Miramor** » Sun Sep 09, 2007 11:30 pm

Well, I just installed the SVN today... Not sure about jump points yet but I'm definitely getting huge slowdowns with fighter barracks in view, the game in general is much more sluggish than last I checked, and RAM hoggery is much worse.

Maybe an option should be given for massively reducing (e.g. down to WCP-type levels) the detail on ships and bases? Less powerful computers shouldn't need that, but at this point it seems like they do.

(Also - mentioned this in the thread on "hanging" startup - it seems that VS is regenerating the universe on each launch of something; launch speed does not improve after it is first run.)

Post by **ace123** » Sun Sep 09, 2007 11:45 pm

I think the lower detail levels are broken lately... but it seems there should be a reasonable fallback.

Post by **klauss** » Sun Sep 09, 2007 11:59 pm

Miramor wrote:(Also - mentioned this in the thread on "hanging" startup - it seems that VS is regenerating the universe on each launch of something; launch speed does not improve after it is first run.)

Diffcult to fully explain, but that's because of the main menu - it makes VS not save the generated universe. It's easily fixed, but I'm not sure it would be that much of a nice thing: someone should start a new game, immediately save, then commit the save file as New_Game. I wouldn't do that because I'd like every new game to be different (because it's generated each time), but... it's a tradeoff I guess.

Miramor · Post by **Miramor** » Tue Sep 18, 2007 5:20 am

Update: tried going to a jump point today with latest SVN. In addition to the general performance issues mentioned in the "Slideshow Vega Strike" thread, jump points still seem to kill the framerate.

(Is there something in vegastrike.config I should be changing, now that the shader thing has been done?)

Post by **hellcatv** » Tue Sep 18, 2007 10:02 am

what video card do you have---can you paste the part of the log where it says GL_ARB_multitexture and stuff ina big row

bassmannate · Post by **bassmannate** » Sun Sep 23, 2007 1:35 am

Not sure if it's still relevant. I'm having the same issue. I'm not sure what objects cause it. I DO know that when I change to a view that my ship is visible in, my framerate drops from around 50-60 to 5-7. I'm using today's latest revision (can't remember what number).

I'm running Linux. Here is the output of glxinfo (vendor string data)
OpenGL vendor string: Tungsten Graphics, Inc.
OpenGL renderer string: Mesa DRI R200 20060602 AGP 8x x86/MMX/SSE2 TCL
OpenGL version string: 1.3 Mesa 6.5.2

As you can see, I'm running the open driver. This is on an ATI chipset. The system itself has 1 GB of ram. Can't remember how much video memory. I am running this on low graphic detail at 1024x768.

Trying to think of what else you may need...If I think of anything before you guys, I'll post it. Otherwise, just let me know. I'll be glad to dig up some system info. Sounds like I'm not the only one with these problems in svn.

Oh yeah. Duh. You might want processor info.
Intel Pentium M 1.60 GHz

Video card is ATI Radeon R250
Still can't find how much video memory that has.

Post by **hellcatv** » Sun Sep 23, 2007 2:33 am

I think if you leave it looking at your ship for a while it will eventually kick down into a lower shader---
or you can try removing the programs/ driectory that holds all the shaders

bassmannate · Post by **bassmannate** » Sun Sep 23, 2007 2:49 am

Didn't work. I did notice when I exited this time that it was giving me these errors in the terminal:

Code: Select all

Mesa 6.5.2 implementation error: User called no-op dispatch function (an unsupported extension function?)
Please report at bugzilla.freedesktop.org
Mesa 6.5.2 implementation error: User called no-op dispatch function (an unsupported extension function?)
Please report at bugzilla.freedesktop.org
Mesa 6.5.2 implementation error: User called no-op dispatch function (an unsupported extension function?)
Please report at bugzilla.freedesktop.org
Mesa 6.5.2 implementation error: User called no-op dispatch function (an unsupported extension function?)
Please report at bugzilla.freedesktop.org
Mesa 6.5.2 implementation error: User called no-op dispatch function (an unsupported extension function?)
Please report at bugzilla.freedesktop.org
Vertex3f: 3

Not sure if this is a problem with vegastrike or a problem with my driver.

Edit: Did I mention that I have low FPS when my ship is in view in a launch bay or ship upgrade screen?

bassmannate · Post by **bassmannate** » Sun Sep 23, 2007 10:28 pm

Ok, I got an error log from when I play. Here it is.