GL graphics artifacts/errors

[safemode]

it's not "windows" you'd have to worry about. It's Explorer and it's the apps that actually render the images you're using that have to understand file types and not just look at stupid extensions.


in any case, the source (master) images will be under the correct extension of their filetype, (png or jpg, after we go through and rename appropriate files). You shouldn't be editing data images anyway. Always edit/generate Master images and export to data4.x.

[Miramor]

Today I encounted a huge glitch, which looked like a segment of a hollow cube viewed from the inside. The thing managed to follow me through one jump, though it didn't follow through a second jump. Here are some screenshots:







It looks like it might have been part of the background or something.

Also, following the appearance of this glitch, the "space hag" death screen showed as a solid white screen; on docking with starships, the hangar background was replaced with an (expanded) image of either a robotic bartender's head or an Andolian Schroedinger; and occasionally, lines of small (~ 10 pixels across) colored squares would appear on the screen while I was in a starship or station, or on a planet.

[jackS]

We just committed (a few minutes ago) a fix to a texture bug that crept in ~ a week ago, so that seems the likeliest culprit.

[safemode]

Nvidia FINALLY fixes the DXT5 bug

http://www.nvnews.net/vbulletin/showthread.php?t=111460

173.08 seems to do the trick. I'll be able to remove the workaround code when it goes stable...

[loki1950]

Great is there 32 bit fix yet as that's what i need.

Enjoy the Choice

[safemode]

if you're seeing DXT5 bugs you should have told me so i can add you to the black list.

all you need to do is give you GL renderer string and GL Vendor string I believe. that should contain the card and driver version.

The workaround is not bit specific, and the new drivers aren't bit specific. so 32bit or 64bit shouldn't matter.

[LukeX717]

I'm also having the "performance problem" and jumpy behaviour (with big objects in front) - on Vega Strike 0.5.0:

When a unit fills the majority of your screen (be it a base or planet) the framerate drops to half of what it is when there is space and only distant units filling the screen. This occurs even when you're stationary. This is with both Very high and regular High detail mode and has occured since I first started working on VS. Video card is nvidia 6600, using nvidia's drivers.

I see also stuttering motion while maneuvering the ship. (Maybe even slowdown, but I am not nure) For me this ocurs in any detail level from low to extreme, with averange and nicest shaders. There is no problem with simplest shaders, if using highest driver performance settings. Video Card: Sapphire (ATI) Radeon X1550 512M with its drivers. OS: WinXP SP3.

Investigation:
Initial checks indicate an increase in cpu usage when framerate drop occurs by over 30%. for instance, if cpu usage was 30-40% before, now it suddenly becomes 70%, with no change in action, just an increase in the filling of the screen of the unit. Drop in framerate occurs even when framerate is locked to vertical refresh, and with quality settinsg turned way down. Occurs on High, very high and medium detail settings.

With averange and nicest shaders I also experience an increased cpu usage. However it is moderate: 42% instead of 37% (of a max 50% dualcore). No increase with simplest shaders.

Something really strange:
By just setting Anti-Aliasing from lowest (2x) to 4x (highest would be 6x), the framerate reduction and jumpy behaviour occurs also with simplest and with no shaders!

I suspect some type of manual blending or mucking of texture data when a unit takes up a lot of the screen, or maybe that mucking simply becomes overwhelming in that situation. Or perhaps a GL setting that doesn't like my card.

It occurs on my ATI card too. But it does not occur on the same system if I use the weak onboard Intel graphics instead.

Resolution: Not Resolved.

[LukeX717]

I updated the above description.

[bgaskey]

the X1550 is not really a very now card, so I wouldn't expect it to work that well with 2x or 4x AA and shaders on. It probably just doesn't have the processing power to play on those settings. It would probably be much smoother without AA, and with just standard shaders.

[safemode]

To play VS in it's current incarnation of shaders and rendering pipeline, you need a young card to play in the top end quality settings. It may not "look" like you would, but anything older than 2 years old, will most likely see some sort of slow down or stuttering related to rendering when using the nicest shader or anti-aliasing etc.

This has less to do with clockrates and size of ram, as much as it has to do with how many threading units your card supports and how many shader units etc. Generally anything in the Nvidia 6xxx series era, should be using Simplest shader. 8xxx series and newer can use Nicest.

[LukeX717]

Maybe the X1550 really isn't good enough.

However, I have 72-131 frames/sec if using fastest settings (no AA) and simplest shaders with the planet Atlantis in front.

Just changing to averange shaders (still no AA), results in 33 frames with the planet Atlantis in front and maneuvering isn't fluent any more: the motion changes, with impact on game play. With the onboard graphics from Intel I had (as I remember) only 18 frames/sec, but imho it was fluent enough and had no impact on game play.

So its weird to have the onboard graphics "outperform" the PCIe card although having lower frame rates!

[bgaskey]

Yeah that's not right. The standard shaders shouldn't be that much more intensive than simple... With my geforce 6200 I've seen some of the same stuff with normal shaders on. Maybe they are just that much more complex and our cheap cards can't handle something in them anymore?

[LukeX717]

I suppose so. But there seems to happen something 'more'. Remember the VS CPU usage increase. Maybe VS tries to 'feed' the graphics card with data while it is already overworked? (I'm no gl developer so I can't tell)

[safemode]

planets are a known issue being worked on currently. The problem is that they're so big they're outside GL's Z buffer the way we currently render things (single pass). So, basically, culling doesn't work on them. Hence, lots of excessive drawing and gpu operations when viewing planets in a close fashion.

This is also the source of the ring issue.

be patient, klauss is brewing up a fix i believe.

[bgaskey]

Yeah he has added a lot to the gl branch in svn over the past few weeks it seems like. Cool new shaders and stuff too. Can't wait, the game's already beautiful.