[Sticks]

So before removing features, pls. check if anyone was aware they existed!

This is part of the problem. Almost no one uses these obscure features. Almost all spec and glow maps are already grayscale, esentially wasting the extra 16bits entirely. You don't get any more gradations of gray in 24bits vs. 8bits. I'd see the other side's argument better if these were things people actually use. Everyone complains that this is some thing "we really really really need, please please", but I don't see it even being used to its full potential. Rather, it hurts the average user instead, when people tell noobs to download the ludicrously overbuilt MediaVPs, and then they come back with big issues.

Honestly, no one is threatening lawsuits if you use VPView to extract the textures from the mediaVPs, IrfanView to convert them to 8-bit versions, or using DXTBmp to compress them to DDS versions. If you have the hardware to support it I see no reason to force people to use lower-quality graphics....

And who's going to tell the new user to do that? "Hey, if it's running crappy, here's this 2 hour step you can perform."

I have to say I've actually been spoiled by fs2_open, because at times I'll find myself looking at a wall or something in Half-life and reflecting on how bad/compressed it looks compared to s2_open

Well, we're about to enter that era with the -img2dds flag. Not that I think that converting to DDS is a bad solution, I just think it skirts the issue, even if only momentarily.

The engine would be capable of showing rough, smooth, glassy, gloss and another myriad of surfaces.

Well, environment and normal maps would absolutely have to be 24bit. And you absolutely should not compress normal maps. So that's a load of textures for each object. Base, normal, spec, glow, env. It's only going to get more out of control.

[WMCoolmon]

And who's going to tell the new user to do that? "Hey, if it's running crappy, here's this 2 hour step you can perform."

If we change it, we'd have to do that anyway, unless the engine is going to automatically convert files. Of course it probably isn't a 2-hour process, just add all the -glow and -shine maps into IrfanView's batch conversion and make them all 8-bit.

Either that, or it's a process of redoing all the art so that it looks worse, which I'm sure people will be overjoyed to do.


This just seems...absurd. These features are crashing some people's computers. So what's the solution? Oh, take them out entirely so no one can use them.

Has no one noticed the massive thread dedicated to the new materials system, or do people simply not care? This is exactly the sort of thing that would be optional with it. Yet half the dev team is calling for 24bit glow/specmaps to be taken out entirely.

Nor do I see putting this in before 3.6.7 as being any more valid than putting the materials system in, as it technically breaks compatibility with older fs2_open campaigns (Gee, where have I heard this before?) and could easily cause bugs if it was implemented now.

Not to mention that I'm pretty sure that at least some of the glowmaps in the mediaVPs use colored gradients to make it appear that light from the glowy bits is falling on nonglowy parts of the hull, and my artistry has been confined to the MSPaint thread.

Plus, it'll probably take a LOT longer to implement, test, and bugfix this than it would to convert the files to 8-bit colour, but I don't see anyone volunteering.

Nor do I see why everyone talking about this needs the features to be taken out entirely and not simply autodetect if a texture only has one channel and apply it differently if it does (hell it might do this already)

[taylor]

OMG!  I can't believe it, I totally agree with WMCoolmon!  The world is coming to an END!!! Evacuate now!!

Sorry, bad joke.


I want to mention something that has been brought up briefly before but never really pointed out as a real option.   DDS doesn't mean a compressed, low quality image.  DDS is DirectDraw Surface and that can be anything from a compressed image to just an 8-bit alpha channel and everything else in between.  You can make a DDS image with an 8-bit color palette if that's all that you require and compression doesn't do the artwork justice.  The OpenGL code can tailor itself to the image being used right now and I'm sure that the D3D code can be made that way if it isn't already.  The DDS loader doesn't properly handle everything that you can throw at it but if people want to do this stuff then I'll gladly take an hour or two and make the needed changes to the code.

As far as -img2dds goes I don't know how many people have actually tested it out and can say that the quality is acceptable or not but as I mentioned, it's only a test of the code.  If you're happy using -pcx2dds in D3D then this is only a much better version of that.  Though -img2dds is somewhat dependent on the API being used it works and a higher level so you can have more control over it and apply it's memory usage savings to the greater area of the game.  The final version of the code could just have options for each file type if wanted so -pcx2dds can convert just PCX images, -ani2dds can just convert ANI, -tga2dds..., etc.  It's there now so we can better figure out how to make use of it.  I can tell you from just my perspective that on my slower Windows test machine I seriously enjoy the 52% decrease in memory usage and 30-40 FPS speed improvement in-game.  I like all the pretty pictures so I use them even if the computer can't really handle it that well.  Finally getting to have to pretty stuff, even if it is of slightly lower quality on some things, while actually having a playable game on that crappy computer is a great thing to me.

[Flaser]

IMHO the a good solution could be implementing support for 8-bit glow/spec.maps (since AFAIK there isn't) if there is a demand and make it *optional*.

So if the users want to, they can use the grayscale images and save mem while others could use the colored images.

Not as if using DDS wouldn't be just as liberating, but still if you have an irresistable urge to purge 16-bits of those files this would be a good aim without braking anyone's jewels.

BTW Bobb, should have some authority in the whole question as his Material system will replace the whole lot of this.

Currently for each and every pixel on a texture you can assign:
-A diffuse color
-A glow color
-A specular color (and intensity)
-A reflective color (and intensity) *am I right on this one?*
-Opacity

That's quite a lot. Many non-FS modders would salivate in anticipation if told a FREE (well *semi*) engine is availible that's capable of handling all of that.
When told that the engine can do anisometric LODing (superdetail boxes) and handle massive polycounts they would take us for fools...for that's too good to be true.

This engine is more capable than what we're actually aware of and many people outside the Freespace/HLP community would be glad to use it if they were aware of its potential.

[taylor]

Originally posted by Flaser
IMHO the a good solution could be implementing support for 8-bit glow/spec.maps (since AFAIK there isn't) if there is a demand and make it *optional*.

That's what I was saying.  Make an 8-bit, uncompressed, DDS and it will get used that way.  If you make a PCX then it has to be converted to 16-bit (very difficult to pick and choose what goes 16 or stays 8) but the DDS could be used as is.  That makes it optional, totally up to the artist, and it requires very little change to the code to work.  That would work easily for glow/spec maps and you could just make an EFF of the DDS images if you wanted a small, animated glow map.

EDIT: And I should say that using 8-bit DDS wouldn't save any memory over a compressed DDS.  DXT5 is a 32-bit image with a 4:1 compression ratio.  That makes it's memory usage the same as an 8-bit image of the same dimensions.  A 24-bit DXT1 has a 6:1 compression ratio so it's even smaller.  The compressed versions are faster for relatively modern video cards to use so if you can get by with the compression artifacts then you can have full color for the same memory used.

[Nuke]

i thought dxt1 had an 8:1 compression ratio.

i think its more troublesome for the engine to handel 8 bit texts when most video cards are designed and optimised to use 24 and 32 bit texts. dds is a format optimised for games, when you look at all the other image formats, they werent designed in such a streamlined manor. the fact that the texture is lossy is irrelevant, because rarely is the texel size gonna exceed the pixel size. hopefully the materials system would allow us to manually script how the individal maps are used. just because the game can handel difuse, spec, env, and glow maps for each and every texture, doesnt mean that each and every texture in the game has to use their own. the materials system should allow us to define a generic effect for a texture, or use their own custom maps for fine details.

[Sticks]

I'm not saying to destroy 24bits in its entirely. Just for glows and specs. If the majority (90%) of spec and glows are grayscale, why are we wasting 16bits per pixel?

That's my only point. The buck has to stop somewhere, or else there will be no new users eventually. Go ahead and change a couple spec and glows to 8bit and you tell me if you can see the difference.

[Nuke]

you could make something like an eff, but instead of frames of an animation, it litsts for a texture all the maps used. so instead of.

armorplate.dds
armorplate-shine.dds
armorplate-glow.dds

you have something like this

armorplate.whatever
--armorplate.dds
--genericmetal-shine.dds
--genericlight-glow.dds

hopefully materials will let you low end guys use something like that, you will still have env and specular, but they wont look as good. and sence multiple textures would share generic effects, it would greatly reduce memory consumption. but as far as im concerned i think the current system is really good and the materials system will make it better for high-enders and low-enders alike.

[taylor]

Originally posted by Nuke
i thought dxt1 had an 8:1 compression ratio.

Either or, though I don't remember the conditions which determine whether it's 6:1 or 8:1.  I'm mostly seeing 6:1 in my tests so that's what I go with.

Originally posted by Sticks
I'm not saying to destroy 24bits in its entirely. Just for glows and specs. If the majority (90%) of spec and glows are grayscale, why are we wasting 16bits per pixel?

Not sure what images you are looking at but I'm not seeing mostly greyscale, I'm seeing almost all color glows and specs.  Maybe 5% could be considered greyscale.  Getting rid of 24-bit color seriously limits how useful those features are and if the glows and specs are compressed DSS then you would be saving zero memory by going with 8-bit versions.  As flaser said, the current images barely touch on what the code can do.  Limiting color space to save memory is one thing but with the current code you can save memory and still have your color space if you only use compressed DDS.  If a compressed DDS of 24-bit color is only an 8-bit greyscale image then who the hell cares if you are wasting 16-bits of color, it's not using any more memory and it's more efficient for the video card to use than an 8-bit image.