Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: RandomTiger on September 27, 2002, 01:19:27 pm
-
Take a look at this site:
http://openil.sourceforge.net
-
The question is: Would it be useful or not?
-
well once implemented we would be able to load precisely 1.265 full craploads of image types
-
Which you wouldn't really want to do.
Wasn't tga support for textures going to be implemented or not?
-
If you are talking about the DX8 branch Im running into complications and Im considering all my options.
-
If that library can be used to load image data into the same kinds of structures the engine uses, then it could be a relatively easy way to get cross platform support for bitmap and targa files. (Remember, eventually people want a Linux port and a Mac OSX port. Direct X8 wasn't designed with cross platform use in mind.)
-
Why exactly would we prefer, or even need, TGA and BMP over 32 bit PCX, anyway? Is there some sort of compatibility thing I don't know of? I can understand using the TGA alpha channel, I suppose......
-
OpenGL-style syntax.
Yeeech. DX8 will do nicely.
-
Originally posted by aldo_14
I can understand using the TGA alpha channel, I suppose......
Thats why then! :p
-
So why BMP?
-
Just having an alpha channel in your texture buys you nothing. Without proper rendering support for sorted alpha objects (difficult) it'll do nothing but buy you lots of wacky rendering screwups.
Having alpha in texture != having transparent objects (not without a good deal of work above and beyond support for the texture itself).
-
I say go for it anyway. I'll be right here to grin like an idiot no matter what. :D
-
I have had to work on sorting transparent objects for this type of problem before so theres no need to totally rule it out.
However realistically it would have to be fairly limited system.
I wish card makers could come up with some sort of magic solution to that problem. Its soooo annoying.
-
Transparency is evil. Ideally you need to draw everything except the transparent stuff, then draw the transparent polies in a back-to-front order for correct rendering. assuming transparent polygons will be part of the models, that is a pain to implement, and think what happens if poly-counts start rising. sorting 1000s of polies each frame isn't nice (Of course you can use frame cohesion for your advantage there, but that kind of idea is painful in itself)
Just a small note, aldo, PCXs come in 8-bit or 24-bit colors (Well, that's except older formats with less colors), so no alpha channel there.
By the way, RandomTiger, are models drawn in a front-to-back order? since they're BSPs. it's simple to do, and the reduced frame-buffer access should yield some preformance increase.
-
Your right, pain the the ass. But if limited system was chosen to be implemented as part of a larger restructure to the graphics engine it could be OK. Perhaps we could steal some code from somewhere else to handle it:)
I guess people would have to choose what they wanted, transparrency functionality or a whole host of other things.
Im not despairate to implement it, I just know I could do a limited system.
Things seem to be rendered back to front and we will have to leave it this way I believe. Otherwise it will mess up the rendering of transparrent textures.
-
I guess you're right about the drawing order - Since most pixels tend to have adepth-complexity of 0 (just space), the speed gain probably won't be worth the hassle, since it'd be fairly small.
-
Originally posted by aldo_14
So why BMP?
Many 3D modeling programs use bitmaps for textures but don't support pcx files. (For example, Truespace 1) It would be easier to just copy files over rather then have to convert bitmaps into pcx files. Not all graphic programs support saving pcx files and of those that do some don't save/convert them very well. (Gimp being the best I've seen.) And Direct X 8 don't mean diddly for the Linux/Mac ports.
-
MSPaint!!!!!1