Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Omniscaper on February 01, 2004, 09:28:40 pm
-
I've been doing some tests with big Trek battles. DDS showed much improvement in loading time and in game ship arrivals. The same battle with PCX was quite a chugger for my PC and I assume its much worse for lesser muscled machines.
Is it ill-advised to continue my conversions using only DDS for performance reasons? I'm uploading DDS textures for all current Trek ships. And I'm tempted to do the same for the entire Freespace texture set. How would you balance PCX's uncompressed 256 color palette to DDS's expanded palette and compression? I've also noticed that the file size for DDS is higher, yet it improves on loading times.
I'm aware that many of my conversions are not so optimized for the last generation of PC's and is pushing current builds to their limits. I really can't do any more for the meshes I'm dealing with when it comes to reducing subobjects. I think creating single meshes out of these models would just radically increase poly numbers. Textures seems to be a factor that I can do more about. How should I handle textures, as to improve performance and efficiency of HT&L. DDS seems to be one method to improve efficiency.
-
I really can't do any more for the meshes I'm dealing with when it comes to reducing subobjects. I think creating single meshes out of these models would just radically increase poly numbers
From what I understand, increasing polys won't really slow down the HTL engine much while increasing subobjects does. Unless it's like 10X the polys it's probably better to reduc subobjects.
-
These Trek ships usually have a minimum of 10k. I've already seen 18k models. IRC, isn't there a poly-limit to a single mesh? Or was that a subobject?
-
A quick search on HT&L limits yields this from our wizard Bobboau
I just completed a stress test on the new HT&L engine FSO is useing, and it is at least 6 times as fast, probly more than an order of magnatude, meaning you can now ad at least one more zero to the number of polys to can have on a ship (fighters were about 2-500, now 2-5000, capships were 1-2000 now 1-20000) and expect good frame rates, the new HT&L engine, likes the following,
use as few textures as posable,
(use exsesivly large textures (1024X1024) if needed for this, it's that big of a deal)
use as few subobjects as posable (this is no longer a visual quality thing)
high poly counts are now encoureged, even if there is no good reason for them,
lower LODs should remain fairly low, we could just add one super detailed LOD on top of what is alredy there
sic
-
per subobject limets are gone now, though im sure if you try hard enough you can breake it
-
yep some info would be useful. I'm also waiting for DDS so I can port all my stuff ;)
-
What exactly do you want to know?
DDS is a compressed 32 bit format.
This means it has a lower file size than an compressed one like TGA. The real benfit is that *some* cards can store as DDS in videomemory.
pcx files start off 8 bit and small but they have to be expanded to at least 16 bit in system and video memory. 32 bit if -pcx32 flag is in use.
-
a) is it implemented properly? last time i tried DDS wasnt displayed (some builds ago, though)
b) does the DDS alpha transparency work with planet background images?
c) Any bugs / restrictions that I should know of?
-
You did a great report on particles for me Lightspeed, you or anyone else who has the time could do the same with DDS. You tell us!
The alternitive is that coders do all the testing and research and we get less coding done.
a) In D3D it seems to on my system.
b) In theory it should do as long as you construct your alpha channel properly. Pure green will not form alpha in DDS (unless we code it that way). However many people seem to say it doesnt but I never got a proper report on this.
c) Dont know.
-
Okay, i'll do some testing. I know pure green wont work (and that's a good thing -- since you have a proper alpha channel), but any alpha channel i tried on TGAs resulted in the planets not shown at all :(
So... I'll test and be back :)
-
Originally posted by Lightspeed
any alpha channel i tried on TGAs resulted in the planets not shown at all :(
I know it works OK on interface art in the main hall so in theory it should work anywhere.
-
Put anything you find in mantis with as much detail as you can.
Would be good if you could enter the particle stuff there as well.
-
alright, i might be stupid, but the game will not recognize any DDS i saved. It will not even try opening it, it will revert to the .PCX image.
I've tested with planet images.
Any command line i need? Do I need to remove the PCX?
About the transparency. TGA transparency does work with ship textures and effects. It will NOT work with planets, though :(
-
I've been converting the existing textures to DDS for the last while. They wouldn't work for me unless there was no like named PCX file in the maps folder.
What options are you using when you save the DDS image?
-
ahh... stupid file preferences again.
I hate when FS2 does that.
Some Coder fix this please?
Have the order:
DDS
TGA
JPG
ANI
PCX
If you do not fix this, I cannot convert anything since FRED won't work with anything else than PCX. (so I always have a PCX set of everything there) - For now I cannot use animated textures / backgrounds due to this problem.
-
DDS works for me as does alpha in TGA for planets
http://mysite.freeserve.com/thomaswhittaker/c_code/freespace/planetalpha.jpg
http://mysite.freeserve.com/thomaswhittaker/c_code/freespace/planetf.rar
FOr fred just use pcx placeholders, the game should load whatever its ment to. Remember OGL doesnt yet support TGA or JPG.
-
Thats the problem. I have PCX placeholders for FRED, but if I want to implement DDS or ANI files i'd have to DELETE the placeholders before starting the game EVERY TIME.
If you would set the PCX to be checked for last, it would be easy to get DDS and ANI to work in-game.
thats weird I did the same thing you explained and it didnt work with planet TGA backgrounds (although that was some time ago). I'll do tests with the latest builds and see if it works now.
also, I'll give DDS a quick try (by temporarily removing a PCX from my folder - please fix that, k?) :)
-
I had some odd experiences with DDS, for example they couldn't be left inside a VP file like Sovymega.vp (or whatever the high qual. sovreign file was called). If I did, I got a big black blank in space firing phasers! ;) I had to manually put 'em in the maps directory for them to work.
-
The code *is* set to look for PCX last, I cant seem to recreate your problems, therefore Im afraid I cant fix them until I have more info.
Try to narrow down the exact details for me, tell me your exact setup with us of vp files, mod use and file extension locations etc.
Perhaps you could even scrub your freespace dir, start from scratch and keep changing things until you find out what causes this.
I'll try and do some tests with loading files straight out of vp files.
But the more testing you leave down to me the less coding I get done.
-
I can narrow it down perfectly.
I know whats causing the problems.
It's the following:
Example A:
I have two files:
TerranFighter-glow.pcx
TerranFighter-glow.ani
Of course, I want to use the animated file, but I keep the PCX one as a placeholder.
When I start the game it will use the PCX texture. If I delete the PCX texture, the ANI file will be used (if no PCX texture is any of my VPs).
Example B:
I have two files:
Planet_01.pcx
Planet_01.dds
When I get in-game the game will use the PCX file, not the DDS file it should use.
Example B (take 2):
I try with TGA:
Planet_01.pcx
Planet_01.tga
When I get in-game the TGA file will be displayed correctly.
The game looks for files in this order:
- It first checks for TGA
- if that fails it checks for JPG
- if that fails it checks for PCX
- if that fails it checks for ANI
- if that fails it checks for DDS
now, if you want to use ANI or DDS files you will have to remove all PCX files that could be found and used instead. However as FRED needs a placeholder PCX file you cannot get the right file to work in-game while still keeping FRED operative.
You see the problem?
-
Example A, thats different code outside the scope of what Im looking at for now Im afraid. The ani stuff is not my code and I dont want to mess with it until I have a better understanding of it. So lets put that asside for a second.
Lets make sure we are all working from the same base, I have uploaded a new build (link in sig) which is up to date and has lots of lovely bug fixes.
Now what I need to know is:
1. Do planet transparences work on your machine with the tga I posted above?
2. Is the DDS file that you cant get to load, is that in a vp file or just in a 'real' directory?
3. Is this a mod, ie making use of the -mod flag to divert the loading process to different dir? If so give details.
4. Could you give me a link to what you use to make your vp files.
-
Bump, I want to fix this but still need more info.
-
Bump
-
don't worry I haven't forgotten. Should be able to test today :)
-
Cool, keep me informed.
I really want to resolve this stuff for the next build.
-
Regarding the file precedences, the best thing would be to keep the existing file location system and make the file type system secondary to that. Currently, it seems that the file types are considered before file locations, which can cause problems. For example, I was trying to disable the nebulas in the FS2 open VP a few months ago; I tried dumping all the original PCX nebulas from the sparky file into \data\effects but the game still kept reading the TGAs in the FSO VP. Eventually, I had to resort to making a new VP without these nebula files.
So the way it should be is that any isolated files are used ahead of files inside VPs and files in VPs with earlier (alphabetical) filename positions are read ahead of those in later ones, just as it used to be, but if the game reads both TGA and PCX versions of the same file in the same location, then the TGA is used.
-
Originally posted by RandomTiger
Cool, keep me informed.
I really want to resolve this stuff for the next build.
email sent :)