0.5.0 release still disobeys no smooth lines

Miramor · Post by **Miramor** » Sat May 03, 2008 5:51 am

I've just installed and started playing around with 0.5.0, and one of the first things I noticed is that it is *slow*. Immediately thereafter, I noticed that Atlantis looked a little bit too smooth around the edges, in spite of my using the "High Detail" (TNT) setting with smooth_lines="false".

Sure enough, a trip to the 17-ar jump point brought my frame rate down into the single digits, and revealed a very smooth-looking wireframe. Here is the proof:

As you can see the jump point wireframe is smoothed.

(The fonts are also smooth, but this is because I have high_quality_font enabled; that option does not affect performance in any perceptible way, and text in the game is frankly unreadable without it.)

The SVN log earlier mentioned changes to make smoothing/no smoothing options more widely obeyed, for the benefit of players with old or slow video hardware; however, it seems pretty clear that those changes did not have the intended effect, and things like jump point wireframes are still being smoothed regardless, to the detriment of anyone not equipped to make full use of antialiasing. This problem really needs to be fixed once and for all.

Post by **ace123** » Sat May 03, 2008 6:37 am

Are you sure you modified the right setting? Is anything different at all when you set the smooth_lines flag to true? (What types of things listen to the smooth_lines option, and which parts still smooth regardless of what you set?)

It seemed to work fine for me, and nobody had mentioned anything to the contrary.

Post by **safemode** » Sat May 03, 2008 12:35 pm

the nicest shader drops framerate significantly unless you have a new 8000 series or better nvidia card or radeon equiv. Go either simple or off. My 6600 requires simple

Miramor · Post by **Miramor** » Sat May 03, 2008 6:50 pm

I've got shader off. I'll try with smooth_lines="true" and see where that gets me.

Is smooth_points="false" also necessary to unsmooth lines at this point?

Post by **ace123** » Sat May 03, 2008 11:31 pm

I don't thiink many things even look at smooth_points, but you might want to turn it on for testing,

Miramor · Post by **Miramor** » Mon May 05, 2008 5:57 am

Here are the results from turning off smooth_points:

I also tested with smooth_lines enabled, to see if something somewhere had gotten reversed.

As you can see, the wireframes in both screenshots are smoothed, and the framerates suck.

What's up here? This bug was fixed... And it keeps coming back. Forgive me for saying so, but I'm starting to see why mentioning Vega Strike on the CIC forums can get you banned.

Post by **ace123** » Mon May 05, 2008 9:12 am

Ah, so it happens on meshes... It could be because of vertex buffer objects or display lists, caching the GL state. GL State is really nasty because unless you set each and every piece of state before doing any GL operation, some things can get really weird.

I can see if adding a glDisable(GL_LINE_SMOOTH) right before the bfxm loader runs... if it happens when the display list is called I can try filling the mesh_ files with glDisable's and see if I can track down where it is needed when I have free time.

I don't stop by the CIC forums, however Gemini Gold does show up fairly often on their front page. Vega Strike the game has definitely diverged from wing commander, and the average system specs of the developers have slightly increased :-p I did test it to make sure it worked at a reasonable framerate in software mode (Retro Graphics) but obviously some in between setting would be nice

It would also be cool to have these jump points be drawn by the HUD. This was proposed a few months ago and it shouldn't be too hard to do--maybe I'll look at doing something like that after school is over in a few weeks.

Post by **safemode** » Mon May 05, 2008 12:54 pm

if we have an to turn on smoothing, then smoothing should be disabled in gl_init and the only places we should gl_enable it is within conditionals related to the option. we should disable it right after any operation that could have had it enabled by the option.

VS will get you banned on some forums where there are flame wars frequently about changing some game's engine over form whatever to VS's.

Retro mode uses more resources than regular high quality modes. This is because Retro mode isn't intended to be lower quality, it's supposed to emulate the old WC2 era graphics . It still needs much work.

Are you sure you're even using hardware acceleration? what's the framerate when you're viewing empty space or other things like planets and stars in the distance? Even if smoothing lines caused a perf hit, you'd have to be using a matrox G450 or something for some minor antialiasing to hit your GPU that badly. For instance, my <20 dollar Nvidia 6600 will do >120fps in empty space and usually not less than half that anywhere else. you shouldn't be in single frame rate unless stress testing the game with total_war or not using hardware accel.

charlieg · Post by **charlieg** » Mon May 05, 2008 1:16 pm

Miramor wrote:What's up here? This bug was fixed... And it keeps coming back. Forgive me for saying so, but I'm starting to see why mentioning Vega Strike on the CIC forums can get you banned.

If discussion of a bug in software you don't pay for upsets you, then by all means go back and enjoy the CIC hatefest where saying anything slightly out of line gets you banned, a line defined by the immature admins who like to treat people they don't know like crap, to make themselves feel better. (The CIC was the worst forum I have been on, and I've been on a *lot* and disagreed with a *lot* of people. The guys who run it are complete assholes.) Please do not use the CIC as a metric for anything around here. Stick to reasonable terms.

This issue seems more like a misunderstanding and - if you keep talking about it - will probably get resolved satisfactorily. Not everything can be done right first time, or second or third, but these guys are working hard to get it right in the long term!

Miramor · Post by **Miramor** » Fri Jun 13, 2008 2:37 am

Apologies for seemingly storming off in a funk, I had other business to take care of...

At any rate, I recently tried the 0.5 binary for Linux, and it still gratuitously disobeys settings not to smooth lines. Other users seem to be running into this problem as well, and furthermore the (second) patch to get it working no longer applies - it seems to have been applied in SVN before 0.5.0, in fact, in spite of not working at all.

The big problem I see here is that, every time this bug has been patched up, the patch has stopped working within a rather short amount of time. I have to ask, how much do GLEnable/Disable calls get messed around with during the average month or so of Vega Strike SVN development, that a regression crops up again and again like that?

Post by **ace123** » Fri Jun 13, 2008 7:10 am

GLEnable and Disable do not get messed around with too much, but all it takes is one call to enable without a corresponding disable, and the OpenGL state is messed up.

The patch that was added does indeed not work. Yes, the bug was very likely never fixed in the first place.

However, neither I nor many of the developers cannot test this on any of the computers I own (the ATI, Nvidia and Intel cards I have all run fast enough to make any effects of smoothing unnoticeable), so as I said, I was working blind when I applied the patches.

There's no harm in adding a few extra glDisable()'s. However, unless I know which line turns it on, I won't know which line to put it on so as to fix it.
I could turn it off at the beginning of each display loop, but it's not likely that will change anything if it gets turned on again in the middle somewhere.

If you are up for a bit of a challenge, could you try compiling the source yourself, then go to "star_system.cpp" in the src folder, go to about line 315, and add a "glDisable(GL_LINE_SMOOTH);" line at some point about halfway through the function (which goes down to line 488).

Then, see if compiling and running that makes it faster, if so, you have narrowed down half of the drawing code. Keep splitting it up and recompiling until you have spotted the trouble spot.

I can try breaking on glEnable and glDisable, or in the corresponding GFX function...it's possible that there is an obvious place in the code that someone missed.

Miramor · Post by **Miramor** » Sat Jun 14, 2008 3:21 am

Thanks... I assume, BTW, that your monitors have too high a resolution for you to tell when jumpgates are smoothed/unsmoothed?

(If you're playing at 1600x1200, yeah, you probably wouldn't notice. At 1024x768 though, smoothing vs. no smoothing of jump gates is pretty visible - that might help you keep track of whether a potential fix is working.)

Also - there is no star_system.cpp in the src folder, only star_system_generic, star_system_jump, and star_system_xml. I'll assume for the moment it's star_system_generic you're talking about...

Edit: the function at line 315 in star_system_generic.cpp is four lines long, clearly not the one you're talking about. Which function should I be adding the glDisable to?

Miramor · Post by **Miramor** » Sat Jun 14, 2008 3:40 am

Okay I'm going to try disabling all instances of GL_SMOOTH_LINES and GL_SMOOTH_POINTS in gl_state.cpp... Problem is I can't compile the source, there's no configure script and no valid makefile, and I can't use RPM. How do I compile using the source tarball?

Also - would it be possible to stick all the GLEnable/Disable stuff in one source file in some future release, or would that not be feasible?

Post by **loki1950** » Sat Jun 14, 2008 2:38 pm

there's no configure script and no valid makefile,

Is there a bootstrap.sh if so run that to generate the configure and make files.

Enjoy the Choice

Miramor · Post by **Miramor** » Sat Jun 14, 2008 2:47 pm

Nope...

Code: Select all

$ ./bootstrap.sh
bash: ./bootstrap.sh: No such file or directory

Miramor · Post by **Miramor** » Sun Jun 15, 2008 12:29 am

Okay, SVN contains the necessary stuff to compile. But the source tarball doesn't, that needs to be fixed.

Anyway... I made a list of all the files currently containing glEnable references for smoothing. Here:

gl_init.cpp
gl_state.cpp
hud.cpp
particle.cpp
glut_support.cpp
painttext.cpp

For now I'm going to solve my problem by turning every instance of glEnable(GL_SMOOTH_LINES) or GL_SMOOTH_POINTS into a glDisable, but that obviously is not a good solution for those who want smoothing available. I hope you guys can go through those files and see if there's anything weird going on in them; it shouldn't be too difficult, as none of them contain a lot of glEnables for GL_SMOOTH_LINES or GL_SMOOTH_POINTS.

Breakable · Post by **Breakable** » Mon Jun 16, 2008 8:21 pm

Well it seems safemode was right and all thas is needed is disabling the smoothing in gl_init. I am not able to test it much, because my laptop goes belly-up every 5 minutes from the heat that we have here in Larnaca.
Please don't take my words at face value, ant test the attached patch instead.
And don't forget
<var name="smooth_lines" value="false"/>
<var name="smooth_points" value="false"/>
<var name="sparkesmooth" value="false"/>
in your configuration file graphics section.

I am guessing the problem with previous patch was that the OpenGL remembers its state ( as I understood from forums) and the smoothing was disabled by previous run of vegastrike when testing it. So the previous patch did not initialize the smoothing state in the beginning and only disallowed initialization during run. So the result was opposite - the smoothing was always on on other machines. I have no real knowledge of OpenGL, so please don't believe me and check instead

.

Please test this well. Use a profiler! =]

Post by **ace123** » Tue Jun 17, 2008 7:56 am

Wow--I should have thought that the GL state might just be enabled by default. That would explain why taking out all the smooth calls in the code didn't actually solve the problem for everyone.

This should get applied to trunk--and smooth lines should be set to false in the Low graphics settings. I can't do it right now since I'm not at my desktop machine with VS checked out.

It would also be cool if we got a good configuration editor so we could have checkboxes for all these things.