Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Solatar on October 19, 2002, 08:54:28 am
-
As the title suggests. Will the next source code release support .pcx files that are 16.7 million colors? Or can we have it support TGA format for backgrounds and skins and engine glows? or does fs2 already support it. Because if it does, I'm doing something wrong.
-
I believe tga's are already supported to an extent already, however Im not sure if it will be 32 bit in the engine.
32 bit tga's is something I intend to implement in the DX8 upgrade.
-
About the DX8 upgrade. Will we be able to use .ani's as backgrounds? I think this is supported to an extent already also, as the supernova in the last mission in fs2 was animated.
I just got Summoner, and I found some awesome flares that look like suns, and I really want them ingame.
-
When the DX8 branch is merged into the main code it should have all the functionality of fs2_open.
So if fs2_open can do it DX8 can too.
However sounds like it might be quite a slow thing to use an ani for a whole background.
Could you show me a screenshot or two of the supernova ani background thing you are talking about?
-
Actually, all that happens in the supernova is that the sun pcx gets bigger. I don't think it is a real ani.
-
Yeah, I think you are correct. That would be why right before you die, the sun looks really pixely.
-
Do we really need to go as far as 32-bit? Can someone check, say, the performance difference (esp texture cache/ memory use, I guess) vs 8 and 16bit coloured files? Because i'm not sure that there will be a significant noticeable difference between 16 and 32 bit images.
-
How much hard would it be to implement 32bit. I mean, if we are improving the graphics, why not go all the way with 32 bit.
We can get some extremely awesome backgrounds with 32bit. Also, better suns, and engine glows. Engine glows are awesome but we can make them even better than the engine glow MODs out there.
Missile trails. We can make exremely life-like missile trails.
-
Give me time :)
-
Sounds like FS2 is becoming quite graphically intensive.
I hope T&L support helps with performance, perhaps even MMX/SSE/SSE2/3D Now! support is a possibility?
Oops, went a bit off topic but nobody notices I hope...
-
Originally posted by Mr. Fury
I hope T&L support helps with performance, perhaps even MMX/SSE/SSE2/3D Now! support is a possibility?
If done properly it should make FS2 run that a much much faster rate. However thats a huge job so dont hold your breath.
However I believe it can be done in stages which means we can slowly increase efficiency at the same time as adding features.
So the two will probably neutralise each other to an extent.
-
A little OT, but I ain't good with acronyms. What is T&L?
Yes, fs2 is becoming very graphicaly intensive. We should get V to let us sell it.:D
-
T&L, short for Hardware Transform & Light.
The Freespace 2 engine was obviously developed from FS1 and probably games even before that. It works the old style way.
When a ship is drawn it is projected from 3D into 2D and then passed to the graphics card. This isnt what the card wants, it wants the polys in 3D so it can do the projection itself. Because its doing it in dedicated hardware means its many times faster.
So basically this, and things like it are being done by the CPU when they should be passed to the GPU of the graphics card.
Implementing HT&L will speed up the 3D operations significantly and give the PCU more free time to process logic and other stuff, therefore increasing the speed of the game again!
Why havent we done this? Its very difficult and would require a total restructure all all engine code, cooperation between DX and OGL systems and possibly the loss of software and glide engines.
I personally at some point am going to try once we have DX8 ready, DX8 will make everything a lot easier than it would have been in DX5. I have done a little coding on this already (before I got into DX8) and I personally estimate it will make the D3D8 upgrade like a walk in the park.
-
RT, you forgot to explain T&L :)
It stands for Transformation and Lightning.
If handled by hardware and not software, it increases performance quite a lot.
-
What I would like most is support for background bitmaps as large as we like. 256x256 just isn't good enough for a low-orbit planetary assault or refugee mission. I have a 2000x2000 Death Star II that I want to see in-game.
-
Yeah, other than more colors, we also need higher resolution. I agree, you can't just make a background bigger, it looks really bad. We need support for things like 2000*2000 resolution.
As well as 16.7 million color TGA's, BMP's, and if somebody is really obssesed, TIF's
-
Eh, please don't forget that not everyone's graphics cards can handle that large textures.
-
Perhaps we can use texture sections, still a low res option would be good.
-
2000*2000 and very large ones like that were for backgrounds.
-
Some cards maximum texture size may not go that high, not sure how crap a card would have to be for that to be the case.
-
Well, I've just been using that as an example, Galactic Emperor mentioned it. I need support for 16.7 million colors though.
EDIT: Even thought the technology in the T-V War wasn't that great, I'm going to try and make the graphics and sound better than fs2.
-
I know, be patient (or learn to code).
-
I'll be patient, cause I can't code.
-
Originally posted by RandomTiger
Some cards maximum texture size may not go that high, not sure how crap a card would have to be for that to be the case.
Umm... IIRC Voodoo 1, 2 and 3. TNT1 for example can't support that big textures.
Ooops... I was wrong about TNT1, which supports 2048x2048.
V2 is 256x256 tho... Oddly enough V3 also supports only up to 256x256.
http://www.reactorcritical.com/chips/chip-tnt.shtml
http://www.reactorcritical.com/chips/chip-voodoo2.shtml
http://www.reactorcritical.com/chips/chip-voodoo3.shtml
-
Seriously, we need to set a minimum system spec...
-
Holy crap! 256 for v3, thats rubbish.
Yet again voodoo manage to surprise me.
I think you are right about a min spec.
-
Hey RT... how about adding some code (assuming that DX8 or FS2 does not already have this) to scale down textures if lower-end graphics card is found?
I mean, surely there is some ways to give players with high-end systems a lot of eyecandy while giving lower-end system users good performance with cost of lower quality eyecandy?
I am not sure how latest FPS games, say UT2003 does this...
Did they include two or three different sizes of textures?
-
Non, you are right I believe. Most games start with big textures and rescale them as possibly even keep a copy for next time the game is run.
Hopefully I can get something like that in however its likely it would only be for tga's and not pcx's.
-
About transformation and lighting, and why it's better to do in hardware.
First of all, transformation is the process of transforming all the vertices according to the current view point. what does that mean? If you move forward, in reality, what is done is that every vertice is moved backwards by the amount you moved forward, which has the same result. If you turn to the right, in truth, every vertice is rotated to the left by the amount you turned right. Basically, transformation is the process of rotating and moving all the vertices in a scene (except that moving the vertices is called Translation). Lighting is, of course, finding the amount of light hitting each vertex according to the positions of light sources. These calculations are essential to every 3D application.
Before there were consumer-level graphics cards, and before those cards had T&L capabilities, all those calculations were done with custom code different for every game, tailored to meet the specific demands of that game. When the first graphics cards came to the consumer market, they were simply raster devices - you gave them screen-coordinates of vertices (vertices which have already been transformed, and projected from 3d coordinates to screen-space (which is 2d)), along with Z values for the Z-buffer, texture coordinates, lighting values, fog values, etc. and they drew the 2d polygons.
The programmer could use the functions built into the APIs for handling transformation and/or projection, but they were simply slower than doing it with your own code. FreeSpace 2 was coded like that.
The problem is, to use T&L, you HAVE to use the built-in API functions, since they automatically use what's available (If you haev T&L capable hardware, they use your hardware, otherwise, the CPU), and, while it not sound like so much from how I describe it, it is a huge amount of work that requries massive re-structuring of the code
-
Originally posted by Hades
Yeah, other than more colors, we also need higher resolution. I agree, you can't just make a background bigger, it looks really bad. We need support for things like 2000*2000 resolution.
As well as 16.7 million color TGA's, BMP's, and if somebody is really obssesed, TIF's
int(2000/256)+1 = 8 seperate bitmaps 256x 256.
why dont you just split them up, then do a little math on what posistions to put them.
seems 10 units on scale x,y=1 and division x,y=1 is the size of a 256 bitmap in fred2.
Just verfied this with a borderlined box.
-
Originally posted by DTP
int(2000/256)+1 = 8 seperate bitmaps 256x 256.
why dont you just split them up, then do a little math on what posistions to put them.
seems 10 units on scale x,y=1 and division x,y=1 is the size of a 256 bitmap in fred2.
Just verfied this with a borderlined box.
Problem with that is that FS2 is still going to draw the bitmaps in such a funny way that the object will get skewed as you manuver. I think its the way that the space area is drawn (its on a sphere or something). Bitmaps would almost need to be drawn on 2D planes for something huge to look good.