[ARSPR]

Now, I don't have GLSL support enabled (no shader 3 support on this vieo card) so perhaps that may be contributing to the issues, but I am having major LOD issues.  The Arcadia, Manticore, Orion, Argo... everything but the GTF fighters look like absolute garbage.

In other words - this takes it back to worse-than-retail quality if you don't have shader 3 support.  Is normal mapping entirely replacing the old high-resolution ships?

I haven't taken a look at your screenshots but I bet you are suffering ForceWare issues. It's neither mediavps nor Fsopen fault. (at least no known fault). With 169.25 or 169.21 ONLY GLSL renders fine. -no_glsl rendering is FUBAR.

Read this thread: http://www.hard-light.net/forums/index.php/topic,50345.0.html

[MP-Ryan]

I haven't taken a look at your screenshots but I bet you are suffering ForceWare issues. It's neither mediavps nor Fsopen fault. (at least no known fault). With 169.25 or 169.21 ONLY GLSL renders fine. -no_glsl rendering is FUBAR.

Read this thread: http://www.hard-light.net/forums/index.php/topic,50345.0.html

That might be true if I wasn't using an ATI video card and driver =)

Interestingly, I tried Taylor's 1207 Xt build and it seems to definitely improve the 3.6.10 mvp visuals over the 1028 build (but has accompanying stability issues, being experimental... 3 crashes out of 4 attempted loadings of the Dunkerque mission).  That build allows me to launch the game without shutting off GLSL (I believe the build now does it automatically?).  There are still serious issues at distance, and in the mini-window for targeting (the models have no detail), but it's better overall.

Note that the visual downgrade occurs only with the actual models; the weapons effects, planets, backgrounds, etc are all very pretty.  The models/textures are just uglified.  EDIT:  And the thrusters are "blocky" at the edges, though I think that may have been mentioned by someone already.

[MP-Ryan]

Here's the side-by side JPG comparison, taken from the ship lab in roughly similar position (sorry I didn't get it closer but the lab kept crashing on me).  The 3.6.10 textures look almost "blurred" compared to the 3.6.8zeta.  I used the Orion so you can see it drastically, but the same holds true for most, if not all, ships.

Build: fs2_open_3_6_10_debug-Xt_1207.exe (occurs in the non-debug too, I was just using debug to try to track down the crashing)

Flags:  C:\StrcApps\FreeSpaceOpen\fs2_open_3_6_10_debug-Xt_1207.exe -spec -glow -env -mipmap -nomotiondebris -normal -img2dds -no_vsync -cache_bitmaps -dualscanlines -targetinfo -rearm_timer -ship_choice_3d -snd_preload -fps

System:
AMD Athlon Thunderbird 1.33Ghz
128 MB Radeon 9500 Pro (NO SM3.0 support)
512 MB SDRAM
Windows XP
Radeon Catalyst Omega Drivers based on 7.10 series (I'm about to try the most recent release).

[attachment deleted by ninja]

[MP-Ryan]

And in a bizarre turn of events...

1207 build + new graphics drivers (7.12 Catalyst) = Graphics on par with or better than 3.6.8
1207 build + 7.10 catalyst = Slightly blurred, indistinct texturing
1028 Build + 7.12 = Slightly blurred, indistinct texturing
1028 Build + 7.10 = Ugliness.

And in another round of bizarrity, despite the fact that this card still does not have SM3 support, the 1028 build no longer crashes when GLSL is enabled with the 7.12 driver set.

Though I noticed that pilot files used in 1207 don't like the 1028 build either.

So.. anyone able to make some sense of this mess and explain the graphical ugliness?  Keep in mind that the 3.6.8 zetas remained pretty and distinct throughout.

[taylor]

There were a ton of changes between 1028 and 1207, including several complete rewrites in the OpenGL code, and a completely new system added to the OGL code as well.  I'm assuming that there are driver bugs at work there, and some of the code changes may have just gotten around them, or made them worse (as some other people have already reported).

GLSL is automatically disabled if it's not supported, but it also checks to see if you have a SM3.0 compatible card now before even trying to get used.  If it doesn't think you can do SM3 then it just skips GLSL altogether.

Pilots should be the same between the builds though.  However, ARSPR has already sent me a test case that appears to mess up pilots, so it's on my todo list of things to check out before I release the next build.

[Darklord42]

Here's the side-by side JPG comparison, taken from the ship lab in roughly similar position (sorry I didn't get it closer but the lab kept crashing on me).  The 3.6.10 textures look almost "blurred" compared to the 3.6.8zeta.  I used the Orion so you can see it drastically, but the same holds true for most, if not all, ships.

Build: fs2_open_3_6_10_debug-Xt_1207.exe (occurs in the non-debug too, I was just using debug to try to track down the crashing)

Flags:  C:\StrcApps\FreeSpaceOpen\fs2_open_3_6_10_debug-Xt_1207.exe -spec -glow -env -mipmap -nomotiondebris -normal -img2dds -no_vsync -cache_bitmaps -dualscanlines -targetinfo -rearm_timer -ship_choice_3d -snd_preload -fps

System:
AMD Athlon Thunderbird 1.33Ghz
128 MB Radeon 9500 Pro (NO SM3.0 support)
512 MB SDRAM
Windows XP
Radeon Catalyst Omega Drivers based on 7.10 series (I'm about to try the most recent release).

Ive mostly noticed that too and I'm using a Nvidia card.  Thing is if you look at the Orion even closer, then the normal maps appear and suddenly it looks fine.  Just not at the distance that the tech room displays.  The larger the ship the larger the distance.


Also I noticed that the Perseus Lod 2 and Lod 3 were reversed,  not that it matters much, but you may want to fix that

[fsphiladelphia]

Once I follow all of the installation instructions, and select the new 'MediaVP' folder as a mod, I need to throw a -adveffects into my command line in order to get all the bells and whistles, correct?  I'm installing right now, and I can't wait to see all the changes!!

[fsphiladelphia]

.pof files -- there were two posted in this thread, one for a particular capital ship and one for a cargo container -- what do i do with the .pof file after I've downloaded it?  Where does it go?

Replaceretailstars.vp -- where does that go?  Do I just drop it in the new 'MediaVP' folder, and does it require a command line flag to be activated?

last question -- Orion Nameplate missions -- where do those .fs2 files go, and do they require any sort of command line flag?

Sorry for so many questions, just want to make sure I'm doing everything correctly.

[Jeff Vader]

Once I follow all of the installation instructions, and select the new 'MediaVP' folder as a mod, I need to throw a -adveffects into my command line in order to get all the bells and whistles, correct?  I'm installing right now, and I can't wait to see all the changes!!

...No? Try -normal and -height.

.pof files -- there were two posted in this thread, one for a particular capital ship and one for a cargo container -- what do i do with the .pof file after I've downloaded it?  Where does it go?

Replaceretailstars.vp -- where does that go?  Do I just drop it in the new 'MediaVP' folder, and does it require a command line flag to be activated?

last question -- Orion Nameplate missions -- where do those .fs2 files go, and do they require any sort of command line flag?

Sorry for so many questions, just want to make sure I'm doing everything correctly.

Pofs to \mediavps\data\models. Vps to \mediavps\. fs2s to \mediavps\data\missions.

No weird extra command line flags required.

[fsphiladelphia]

Once I follow all of the installation instructions, and select the new 'MediaVP' folder as a mod, I need to throw a -adveffects into my command line in order to get all the bells and whistles, correct?  I'm installing right now, and I can't wait to see all the changes!!

...No? Try -normal and -height.

Ah, ok, I was already doing this.  Just double checking.  Also, thanks for the info re: the pofs and the mission files.

Time to see how it looks/what the fps is.

[MP-Ryan]

There were a ton of changes between 1028 and 1207, including several complete rewrites in the OpenGL code, and a completely new system added to the OGL code as well.  I'm assuming that there are driver bugs at work there, and some of the code changes may have just gotten around them, or made them worse (as some other people have already reported).

Well, without GLSL the newer build appears to be better.  That said, I also tinkered around with the 7.11 Catalyst drivers and it restored the Orion in 1207 to that comparative to the 1028 build - that is, blurry crap.  Without normal mpping we appear to get some funky detail visual issues, but I've no idea why if the textures included are all the same as the earlier mediaVPs plus the newer ones - if anything, shouldn't it revert to just using the original textures if normal and height mapping isn't present?

GLSL is automatically disabled if it's not supported, but it also checks to see if you have a SM3.0 compatible card now before even trying to get used.  If it doesn't think you can do SM3 then it just skips GLSL altogether.

OK, that explains why I don't need the flag in 1207.  It doesn't explain by 1028 now launches with the newer driver set.  That must have been a bug in the old 7.10 set.

Pilots should be the same between the builds though.  However, ARSPR has already sent me a test case that appears to mess up pilots, so it's on my todo list of things to check out before I release the next build.

If I try to run 1028 with a pilot that has been used in 1207, when I click Select the game just hangs with the select button highlighted (the process starts eating 100% CPU).  It doesn't crash - I have to force a quit through the task manager processes.  Something isn't liking going back to the older build.

[fsphiladelphia]

Just installed the new updates and checked it all out, so far, so good -- everything looks amazing, Fps decent (staying over 30 in traffic).  Kudos!

[Topgun]

here are the replaceretailstars.vp suns in dds.

[attachment deleted by ninja]

[Herra Tohtori]

here are the replaceretailstars.vp suns in dds.

If I may say, I don't see any reason to use DDS format for the star bitmaps. Quite the opposite I can think at leat two reasons why not to do so.

First reason is that the stars have a lot of gradients in them instead of sharp, distinguishable features like model textures. DDS does not do well with gradients, it adds a lot of artefacting and looks generally sucky in many cases. Example further as comparision image pair.

Second reason is that the advantages of DDS don't really show themselves in sun bitmaps.

The advantages of DDS format are mainly reduced memory signature and ready mipmaps for the GPU to use. These are very useful features when there are a lot of textures to be rendered either on models or effects, on varying distances. However, when you consider that there are only perhaps two, three or on some rare occasions couple more sun bitmaps in a mission, and all of them are basically set on static distance, both of these advantages become redundant. Not to mention that the star bitmaps (well, those at least) are only 512x512 sized. That's only fourth of a 1024x1024 resolution texture, which many ships use. DDS compression cuts the ship texture memory use to about 1/4th, which means that one 512x512 star bitmap in TGA takes about as much GPU resources as one 1024x1024 ship texture in DDS.

There are many ship textures used in a typical FS2_Open mission. And I do not remember seeing many missions that use more than two or three suns, so I'd say trying to reduce the GPU memory load by compressing sun bitmaps is more waste of quality than win in performance.

I do not think having the sun bitmaps as TGA's will have measurable effect on performance even on older computers. I could be wrong though, so I'd appreciate if someone could either confirm or dispute these arguments, but if it is as I suspect, the disadvantages of DDS are in this case more prominent than the advantages. Thus I would prefer the stars to be distributed in TGA format.

And as you can observe, the compression does bad things to gradients.

Uncompressed TGA (saved as PNG for obvious reasons):



Same image compressed to DDS (probably DXT1c) and saved as *.PNG for same obvious reasons):



...I rest my case. And remember that if the stars are ever upscaled by mission background designer, the DDS compression artefacts just grow more apparent.

I appreciate Topgun's effort, though; this just happens to be one of the worst uses for DDS format I can think of.

[Topgun]

all that is true. but for people who use img2dds (like me), the result is both better looking and (i think) less resource intense.

[Herra Tohtori]

all that is true. but for people who use img2dds (like me), the result is both better looking and (i think) less resource intense.

Fair enough, let's consider the possibilities then...

Does the -img2dds cmdline argument make the game prefer DDS textures if both DDS and TGA are present in the files? I know that normally the TGA file overrides DDS, but in case of "compress uncompressed files" being enabled, is the engine smart enough to detect that there actually IS a compressed file available and use it instead of preferring the TGA, then compressing that (quite unnecessarily) and using the end result?

I guess with this logic it could be beneficial to make -img2dds cmdline argument reverse the TGA/DDS priority order so that DDS textures would be used as a preference when enabled, and when -img2dds is not enabled the TGA's would override the DDS files, like at the moment they do. I'm not sure if this is already the case, but it would seem sensible to me to make it so if it isn't already...

If that could work, then it would be possible to include both DDS and TGA star bitmaps in the VP: Those who don't use -img2dds would automatically use the TGA version, and the -img2dds users would benefit from having the actial DDS files (which apparently despite the atrocious compression artefacts are better than the result from the compression made by FS2_Open, if I interpret Topgun's post correctly).


Apart from this I would still suggest using the TGA ones for the mediaVP's, or not to use them at all, cause it doesn't really serve the mediaVP's purpose to have bad-looking effects in them, and those DDS suns definitely classify as such in my books.

Of course, I would prefer all light effects to be in TGA format, like the subspace effect, thruster plumes, beams and (to lesser extent) other weapons fire and explosion frames. I really prefer a drop of few frames per second to pixelated smooth gradient effects in otherwise kick-ass effects.

However, I understand that the savage olden computers are not so englightened as mine, and thus their users cannot enjoy the comfort, and enlightenment of true uncompressed light effects... so I understand that compromizes must be made.

[Wanderer]

That is sort of the idea. Take a look at LS nebulas. There is compressed DDS version in effects vp and uncompressed DDS version in adveffecs.

[Topgun]

I thought 3.610 just used dds first, if there was no dds then it would convert tga to dds. am I right?

[fsphiladelphia]

How do you load the replaceretailstars.vp?  just place it in the MediaVP folder and do nothing else?

[Topgun]

yes, but if it still doesn't work, name it aaa-replaceretailstars.