Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Scuddie on January 19, 2005, 07:33:57 am
-
In all my menus in SCP, it always looks like this while using D3D and Anti-Aliasing. It doesnt matter what drivers I use, this has always happened. Except now, I am forced to use D3D because OpenGL doesnt like me anymore :(. Anyway, take a look, and tell me what you think?
GeForce4 128MB Ti4200 8X running in 4X mode
2600+, 512MB PC2700
Windows XP SP1, DX9.0c
Whatever nV drivers, it doesnt matter.
(http://img87.exs.cx/img87/706/d3dlines2du.jpg)
-
I think it's a known problem with either anti-aliasing itself or jpgtga (maybe?).
what are your command line flags?
-
C:\Games\FreeSpace2\fs2_open_3_6_5.exe
-spec
-glow
-pcx32
-jpgtga
-d3dmipmap
-dualscanlines
-ship_choice_3d
-targetinfo
-3dwarp
-ballistic_gauge
-snd_preload
-env
-alpha_env
-show_mem_usage
AA can be anything from launcher setting D3DMULTISAMPLE_2_SAMPLES, to forced at 8x, the results are the same, and it only happens in D3D. When I force AA off, the blue lines are gone.
-
Be sure to enable AA only in the launcher. Not in the driver, or a tuner (like aTuner)!
That fixed it for me.
-
If I disable AA in the driver, will it work in FS2_Open?
-
Don't disable, set it to application preference. Then it will be only used when a game is set to enable it. However, that probably won't fix the problem because I have them nevertheless.
-
-pcx32 - that's the guilty bugger. Dunno why anyone uses it anymore.
Switch it off, and bye-bye blue lines of doom.
-
Well, I'll be damned. It worked.
Although now everything looks like ****.
-
Why? Because it noticeably improves quality of interface.
-
Hmm...I never saw it that way - more like whomever tried to fiddle with the interface was too lazy to use a single palette (not that doing so isn't a *****) or that anyone really cared....
...though if it were so jped/tga/dds support would be already availible in the interface too if it isn't already.
PCX32 is a memory hugging beast with no real use - it makes all pcx take up 4 times the memory (8-bit --> 32-bit) and the only result is allowing each image to have a palette of its own - but if needed using tga or dds from the first place would be a lot better.
-
Originally posted by Flaser
PCX32 is a memory hugging beast with no real use - it makes all pcx take up 4 times the memory (8-bit --> 32-bit) and the only result is allowing each image to have a palette of its own - but if needed using tga or dds from the first place would be a lot better.
All true, not a problem to people who've got 1 GB RAM and 256 MB video RAM, or more. Such as myself. ;)
-
-pcx32 rocks.
But -pcx32 & AA cause the blue lines problem. You can disable either of them to fix it.
You can also enable AA in your driver settings, but it may mess up the fonts.
-
Just curious, is this a bug, or a limitation of the engine?
-
Originally posted by Flaser
...though if it were so jped/tga/dds support would be already availible in the interface too if it isn't already.
TGA can already be used on the interface. The others can't but that's only because CFILE filters them out rather than any technical limitation. It's easy enough to tell CFILE to let JPG/DDS be used but since they are compressed formats they tend to look like crap. I actually test all of my TGA, JPG, DDS loader changes against the initial splash screen so I know all of them can work for interface graphics.
And just for the record there are no strict 8-bit PCX palettes in the game. Every PCX is converted to 16-bit on load. Pretty much only font characters remain 8-bit and everything else goes 16-bit or higher. Of course those 16-bit and 32-bit palettes are still derived from that initial 8-bit palette so there is only that to work with. Lightspeed has a much better eye than I do but for me I don't see any visual difference in color between 16-bit and 32-bit PCX images. I don't use non-standard resolutions though and I suppose it could make a difference there.
-
While we're on the subject, is it possible to allow FSO to use PCX images that have 16-bit palettes from the get-go? In theory, it should take up the same amount of room in memory as those that are 8-bit initially and then loaded as 16-bit, but have better quality. Am I correct in this?
-
Originally posted by Trivial Psychic
While we're on the subject, is it possible to allow FSO to use PCX images that have 16-bit palettes from the get-go?
It's not supported by the format. PCX is 16 color (2-bit), 256 color (8-bit). 24-bit color is achieved by 8-bit images in 3 planes with no palette. The current pcx loader doesn't accept images with more than 1 plane so it's 8-bit only. Reading them as 16 or 32 bit is based on the same 8-bit palette so in a 32-bit pcx there is still only 256 different colors. An alpha channel is created but it's a fixed value for 32-bit so it would be a memory saver at least just ditch the alpha and make them 24-bit. Of course in the end you've still got a 16/24/32 bit image with a total of 256 colors in it. I think that most/all/any of the visual differences is in internal storage in video memory rather than how the file is read in the first place. It's just easier (little faster too) to send to card in the same format you to display with.