The Intel performance situation revisted
-
- Lead Network Developer
- Posts: 2560
- Joined: Sun Jan 12, 2003 9:13 am
- Location: Palo Alto CA
- Contact:
Hi,
The patch you linked to should have been applied a long time ago.
I'll check one more time to be certain.
Unfortunately I'm not sure how to change the way it does Vertical syncing. I heard that switching to windowed mode or to fullscreen might change the way the V-Syncing works.
If not, you might have to look in your driver settings, though I suppose you have already tried that.
The patch you linked to should have been applied a long time ago.
I'll check one more time to be certain.
Unfortunately I'm not sure how to change the way it does Vertical syncing. I heard that switching to windowed mode or to fullscreen might change the way the V-Syncing works.
If not, you might have to look in your driver settings, though I suppose you have already tried that.
-
- Developer
- Posts: 2150
- Joined: Mon Apr 23, 2007 1:17 am
- Location: Pennsylvania
- Contact:
the patch is definitely committed. It just only effects those cards that actually was limited by gpu related to the anti-aliasing. This isn't the case really for most cards though. Something else is bogging down the card when in front of a planet or large unit. We're talking 110fps down to 50. not 50 down to 20 ....though the really slow cards will have that occur. Something is definitely overworking the gpu, and it's not anything to do with smoothing lines, as far as we've been able to tell.
Ed Sweetman endorses this message.
-
- ISO Party Member
- Posts: 410
- Joined: Tue Jun 26, 2007 7:15 pm
Are you talking about a recent commit, or the one mentioned in Breakable's thread? That one somehow never got through - if it had, my applying Breakable's patch to SVN 11940 would not have fixed anything.
Re planets and large ships overworking the GPU, I'm actually not seeing much of that - although my FPS never really gets above 30 when using high/very high detail, what with the backgrounds in space. What makes my computer cry is having multiple ships in view; one Ox won't hurt my framerate, even close up, but half a dozen Koalas will do very bad things.
Re planets and large ships overworking the GPU, I'm actually not seeing much of that - although my FPS never really gets above 30 when using high/very high detail, what with the backgrounds in space. What makes my computer cry is having multiple ships in view; one Ox won't hurt my framerate, even close up, but half a dozen Koalas will do very bad things.
-
- Lead Network Developer
- Posts: 2560
- Joined: Sun Jan 12, 2003 9:13 am
- Location: Palo Alto CA
- Contact:
Not really sure what you were doing, but I get this when I try to apply it
Are you saying that *reversing* (i.e. trying to apply it but specify the -R or type "y" for those) the patch fixes the problem?
I can see a few possible reasons that might be happening, but before I start speculating about that I need to know exactly *how* you applied the patch (paste the terminal output).
Can you make sure you are reverted first too? Type "svn revert -R ." to revert the whole directory (very dangerous if you have any changes you want to keep: type a "svn st -q" to see changes)
Code: Select all
patch -p0 < moreRespeckForDisableSmoothLinesAndPoints_.dif
patching file src/gldrv/gl_state.cpp
Reversed (or previously applied) patch detected! Assume -R? [n] y
patching file src/gldrv/gl_init.cpp
Reversed (or previously applied) patch detected! Assume -R? [n] y
patching file src/gldrv/gl_globals.h
Reversed (or previously applied) patch detected! Assume -R? [n] y
patching file src/gfxlib_struct.cpp
Reversed (or previously applied) patch detected! Assume -R? [n] y
patching file src/gui/glut_support.cpp
Reversed (or previously applied) patch detected! Assume -R? [n] y
patching file src/gui/painttext.cpp
Reversed (or previously applied) patch detected! Assume -R? [n] y
patching file src/gfx/hud.cpp
Reversed (or previously applied) patch detected! Assume -R? [n] y
Hunk #3 succeeded at 373 with fuzz 1 (offset 18 lines).
patching file src/gfx/particle.cpp
Reversed (or previously applied) patch detected! Assume -R? [n] y
I can see a few possible reasons that might be happening, but before I start speculating about that I need to know exactly *how* you applied the patch (paste the terminal output).
Can you make sure you are reverted first too? Type "svn revert -R ." to revert the whole directory (very dangerous if you have any changes you want to keep: type a "svn st -q" to see changes)
-
- ISO Party Member
- Posts: 410
- Joined: Tue Jun 26, 2007 7:15 pm
Oh... Reversing? Yes, that is exactly what I did.ace123 wrote:Not really sure what you were doing, but I get this when I try to apply itAre you saying that *reversing* (i.e. trying to apply it but specify the -R or type "y" for those) the patch fixes the problem?Code: Select all
patch -p0 < moreRespeckForDisableSmoothLinesAndPoints_.dif patching file src/gldrv/gl_state.cpp Reversed (or previously applied) patch detected! Assume -R? [n] y patching file src/gldrv/gl_init.cpp Reversed (or previously applied) patch detected! Assume -R? [n] y patching file src/gldrv/gl_globals.h Reversed (or previously applied) patch detected! Assume -R? [n] y patching file src/gfxlib_struct.cpp Reversed (or previously applied) patch detected! Assume -R? [n] y patching file src/gui/glut_support.cpp Reversed (or previously applied) patch detected! Assume -R? [n] y patching file src/gui/painttext.cpp Reversed (or previously applied) patch detected! Assume -R? [n] y patching file src/gfx/hud.cpp Reversed (or previously applied) patch detected! Assume -R? [n] y Hunk #3 succeeded at 373 with fuzz 1 (offset 18 lines). patching file src/gfx/particle.cpp Reversed (or previously applied) patch detected! Assume -R? [n] y
Uhm. Crap. Looks like I wasn't just wrong, but *exactly* wrong.
-
- Lead Network Developer
- Posts: 2560
- Joined: Sun Jan 12, 2003 9:13 am
- Location: Palo Alto CA
- Contact:
-
- Developer
- Posts: 2150
- Joined: Mon Apr 23, 2007 1:17 am
- Location: Pennsylvania
- Contact:
-
- Hunter
- Posts: 95
- Joined: Sun Nov 18, 2007 1:19 pm
It should be pretty easy to see if the smoothness is still on - the shield lines should be non-smooth.ace123 wrote:That's a good find, that means we might be on to something.
I noticed that the patch removed a few places where "glDisable(GL_POINT_SMOOTH)" was called, so perhaps the smoothness setting is staying on even though the option itself is disabled.
If so adding a glDisable(GL_POINT_SMOOTH) on startup could improve the situation. I would add it, but i dont known where.
-
- Developer
- Posts: 2150
- Joined: Mon Apr 23, 2007 1:17 am
- Location: Pennsylvania
- Contact:
there are other directives that can be effecting aliasing in the game
glDisable/glEnable control these:
GL_POLYGON_SMOOTH
GL_LINE_SMOOTH
GL_POINT_SMOOTH
then glTexParameter can set bilinear/trilinear filtering for textures,
All of these need to be made to adhere to the options we set.
I know where they need to go. I'll take another look at what we're doing and such when i get home today i guess.
edit:
ps: there are no shield lines on the HUD anymore. Update your VS and data4.x
glDisable/glEnable control these:
GL_POLYGON_SMOOTH
GL_LINE_SMOOTH
GL_POINT_SMOOTH
then glTexParameter can set bilinear/trilinear filtering for textures,
All of these need to be made to adhere to the options we set.
I know where they need to go. I'll take another look at what we're doing and such when i get home today i guess.
edit:
ps: there are no shield lines on the HUD anymore. Update your VS and data4.x
Ed Sweetman endorses this message.
-
- Developer
- Posts: 2150
- Joined: Mon Apr 23, 2007 1:17 am
- Location: Pennsylvania
- Contact:
edit: nevermind. It seems that the patch's source/change order is wrong, and it may be obscolete already. I'll double check again when i get home, i discounted it's need before because i noticed changed it made were already in the files, and i saw no reason why it would be in the wrong order because that would mean the removal of some variables the patch seems to add, that relate to holding smoothing options.
It seemed more likely they would get added in the fix, so i thought the order was correct and thus, the patch had already been applied. Perhaps only parts were applied. Perhaps what was really wrong had been fixed a different way.
It seemed more likely they would get added in the fix, so i thought the order was correct and thus, the patch had already been applied. Perhaps only parts were applied. Perhaps what was really wrong had been fixed a different way.
Ed Sweetman endorses this message.
-
- Developer
- Posts: 2150
- Joined: Mon Apr 23, 2007 1:17 am
- Location: Pennsylvania
- Contact:
just got home, it appears a lot of the smooth options that get set in the game simply aren't mentioned in the config file, so defaults are used and the defaults turn them on. I'll experiment more today and see how it goes with putting them in the config file and disabling/enabling them.
Ed Sweetman endorses this message.