[Nico]

I've made many, many maps, and I can tell you you can't see the difference at all when you convert to 256 colors ( well, if you don't use photoshop, that is ). huge waste of resources, if you ask me. and bigger files just to make lazy moders happy...

[CptWhite]

it would benefit backgrounds venom , file sizes wuld be kept the same if we used the dx format, talk to phreak about that...

[phreak]

well it only works in opengl.  i want to talk to RT about using it in d3d.  the d3d version should support everything

[EdrickV]

Originally posted by RandomTiger


Um... quality?

Do you really need to use millions of colors in a single texture? 256 provides for quite a bit of color choices, as long as you use a good program to save the image in indexed mode. It's not like you're making photo realistic ships after all.

[phreak]

well the image code converts an indexed image into a 24 bit bitmap in memory and then swizzles it into a 16 bit 1555 (ABGR) bitmap.  The opengl mipmap function doesn't like 1555 textures.  so if we were to use ansiotropic filtering, we might as well support 24 or 32 bit textures along with 8 bit.

instead of swizzling down to 16 bit, we can keep the 24 bit data. but i think that will kill voodoo support and we don't want that to happen now do we

[EdrickV]

Originally posted by PhReAk
well the image code converts an indexed image into a 24 bit bitmap in memory and then swizzles it into a 16 bit 1555 (ABGR) bitmap.

Ohhhkay, why is the game converting an 8-bit image into 24-bit in the first place? Why not just convert it to 16-bit if that's what it's going to use? Doesn't sound very effecient. As far as Voodoos, I doubt they would suffer if DirectX/OpenGL code was changed (since people with a Voodoo are likely using Glide anyways and can't use OpenGL) if the Glide code still works.

[phreak]

scratch that.

it loops through every pixel and does a 8-24-16 conversion. it doesn't convert it so its a giant 24 bit bitmap.

with some persuaion we could make have it go from 8 to 24 from ogl/dx

[Sandwich]

Only advantage IMO to using anything above 16-bit images (65,536 colors) is to use 24-bit, with the extra 8-bits allocated to a greyscale 256-shade alpha (transparency) channel. Then again, how often would we be able to make use of a semi-transparent area? Perhaps allocate the 8 bits to glow maps then - that or bump maps. Either/or, doesn't matter. Was it TGA that supported 24-bit + 8-bit alpha channels?

[Flaser]

Actually 16-bit is already more than enough for almost any kind of picture you'd like to create - more colors can be created in 16-bit than what you're eye can tell from one-another.
Goind to 32 bit has only 1 major thing as Sandwich said - ituses 8 bits for transparency data.
24bit on the other hand uses 8-8 for R,G,B so it does not support transparency.

As for the whole resolution issue - higher resolution is always better since all the lines are straighter. On the other hand it always takes more power.
The later option -mappings and ect. - however would take more power IMHO.
Higher maps are good at close distances - however this one's most important for cap-ships, since the problem with them is that the textures are streched onto huge polys, and end up wiht low DPI (dot/inch) - even for 640*480 they would need better maps.
Using more textures was already mentioned.

As for multiple resolutions:

How about using vector graphics - I mean if all the HUD was done in vector graphics then it could run in any resolution, even the size of all the gagues could be fine-tuned for everyone.
However that would be a load of work and mostly new hardcoded support of 2D vector graphics.
On the other hand an outside application could be used to create the apropiate .pcx-s from vector-g. each time the resolution is changed in the launcher.
Finally high-resolution HUDs can always be scaled down in a similar method - or even in-game as it was already suggested.

As for scaling up/down I can't believe the lack of attention to certains tricks:
Any video player program does it, they simply show a pixel more times to fill up the screen. Those are the grindy - ugly looking scaleups - however there are a whole buch of blur tricks to refine that image.
DivX for instance uses such things, so does ordinary MPEG-1.
Even a 3*3 Average matrix can have good results.

I think we need a codec or video format guru who has knowledge of actually how those filters work.
Than it's only putting these filters into the code and we can even scale up .ani-s.

Actually a whole range of those filters are supported by DirectX so we simply have to acces them.

If I sound pompous, than I'm sorry.
I'm no DX programmer, I don't know the exact hierarchy DirectX functions and layers, I was merely commenting on things used every day in video manipulation.

[Fry_Day]

Actually 16-bit is already more than enough for almost any kind of picture you'd like to create - more colors can be created in 16-bit than what you're eye can tell from one-another.
Goind to 32 bit has only 1 major thing as Sandwich said - ituses 8 bits for transparency data.
24bit on the other hand uses 8-8 for R,G,B so it does not support transparency.

That's just plain wrong - they didn't set the number 16.7 million colors completely arbitrarily. the human eye CAN differentiate much more than 65536 colors, ranging to at least a few hundred thousand different shades (Something that is based on actual tests), and since there are only 15 bits for the color textures, there are only 32768 different colors.

Of course, the main advantage of 32bit is actually that since you have more color precision, when using transparency and other effects, you lose less data (For example, when running in 16-bit, you can often see lots of pixels with wrong colors due to running out of enough precision in particle effects in some games), but of course, that has nothing to do with textures. On the other hand, I'm not sure, but multitexturing (which doesn't write to the framebuffer before doing a blending stage) might depend on texture bit-depth, though I'm not sure about it at all.

[Sandwich]

Well either way, I've seen plenty of semi- and not so recent games with graphics options for 16 or 32 bit rendering, as well as 16 or 32 bit textures. How difficult would providing an such option be?

[EdrickV]

The game actually has a 32-bit color depth option it looks for. That dates back to the original FS2 source code. (And the launcher I built a while ago includes that in it's graphics mode list.) I'm not sure if it's actually used for anything though. The main thing being talked about here is 32-bit textures which is a different issue.
That "32 bit" setting is ignored for Glide BTW, it's still checked for and will set a variable to 32 but that variable won't get passed to the graphics init function when Glide is selected, thus my launcher didn't include a 32-bit Glide mode. (Which makes since as the cards don't support 32-bit mode.)

[karajorma]

IIRC the human eye can differentiate between about 1 million colours.

[RandomTiger]

OK, I have a great deal of respect for anyone who can make something look as good as you guys do with 256 colours but I think you'll find that using 32 bit colour makes it a damn sight easier.

Secondly you do realise 64 bit colour will probably be the norm for gamers in a few years.

D3D FS2 currently uses 16 bit textures but renders the scene in 32 bit. DirectX has some nice bits of code to let you read in GTA's and JPG's into 16 or 32 bit textures in one line of code. I had this implemented in the DX8 code but took it out (god knows why). I'll post the code and perhaps UP can put it back in.

Phreak, dont let D3D hold you back, go for it.

[Flaser]

64bit?
Unless you're putting multiple textures into a single file I don't see the point.
Even 24bit seems enough 2^8*2^8*2^8=2^24 colors, that's 16.777.216 colors - 16.7 million is more than enough.

[Fry_Day]

Flaser, actually, 64 bit gives 16-bit FP (floating point) precision for every color channel, which is a great deal of help when using any sotr of per-pixel effect, since the dynamic range of colors is no longer in the 0.0-1.0 range, meaning you don't have to fear overflows during computations. of course, it isn't applicable to textures, really, which are just fine with 24bit + alpha, but for a framebuffer and internal calculations? It's heaven.

Edit: The best example you can see for a lack of dynamic range, even with 32-bit colors, is gamma. If you set the gamma really high, you'll see that darker pixels tend to be green. With FP colors, you'll be able to set any reasonable gamma without that problem.

[Flaser]

Now I see what you mean, and it's entirely different from what I thougt.
This is no longer a simple 64-bit color description.

[RandomTiger]

At the end of the day 32 bit is very desirable but since all the data is 256 colour pcx only a crazy man will remove support for it.

Conclusion: Lets have best of both worlds.

As for the res things my experiments continue, but I expect I may need a new font bitmap to solve some edge problems.

[MLeoDaalder]

Hello,

And sorry to "bump" this thread. I just recently was able to acquire the game.

And I just like to give my 2 cents in this matter, I don't know if it has been solved yet, I am still a newbie at FS2and I haven't read all of it yet, but I can do programming (if you look at my site you will see that I am programming a game of my own).

I have  a Diamond Viper v770 Ultra 64MB and I would really want to run the game anything other than 640x480, simply because that resolution has some bugs with me. Like the image is shifted to the left, I could compensate for that, but then I would need to undo that the minute I stop. So I don't like that.

So I would prefer at least 800x600 or anything larger. I have run a game called Bridge Commander at 1024x756x32 with 5 models with 16000 polygons and a couple of 2024x2024 maps and all featurers on (mip mapping, glows, specular, motion blur, etc, etc). This without slowdown.

And I can run JK2 at maximum and JK3 without sound both without slowdown.

Now I think you can compensate for the crapy textures with Mip Mapping. You can do that with both OpenGL and DirectX. And if you only use that on the UI (User Interface) then even lower end systems can use them. If you also use Anti ani something then it would save you a lot of texturing problems.

It would be even better if you use that on all the textures, but such a thing should be configurable.

Now I do have an aged system, but I do hope to get a better one in Februari next year. These are my specs:
Pentium 3 550MHz
128MB RAM
Diamond Viper v770 Ultra 64MB (not updated drivers, does anyone knows where to get them?)
DirectX 9.0a

Thank you for your time,

[karajorma]

What's wrong with 1024x768? Too slow?