Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Grug on March 10, 2005, 06:36:14 am
-
I'm just wondering, why can't we replace ani's with gif's?
Do we need a license to use gifs?
I would of thought it would of been a much better way to handle animations in FS2.
Much more dynamic, and user friendly. More apps widely available.
I would think that it would be a large performance increase using gif's instead of ani's on glowmaps / textures too.
So what's up, why hasn't anyone suggested this before?
-
Why aren't you replacing ani's with eff's?
Gifs do indeed need a licence. EFFs don't. Taylor is working on a format for CB_Anims IIRC so ani is on its way out as that's the only place EFFs don't work at the moment. Why introduce GIFs at all?
-
And GIFs have the same limitations as ANIs...
So EFFs would indeed be the best...
But what about MNGs? *joke*
-
Ah, un-informed I am... as usual. :doubt:
You know, the SCP really needs a news editor or something. To post on HLP and the main site the latest developments etc.
I never hear about things until I come across them in the forums, see it in the highlights, or ask something and get told it was made several months ago. Sigh
Don't dare point me to the wiki either, because that is a) A pain in the ass to update b) Never updated
Anyway, what's the story on EFF's?
-
EFFs, I believe, store the animation as individual frames (i.e. named anim0000...animxxxx) using an EFF (ASCII type) file which defines the filename, number of frames and fps (and is thus used to load the frames and animation).
-
Are there performance gains as well, with eff's? I take it eff's have no color limitations as ani's?
-
If you use DDS for the EFF if you gain quite a bit of performance over ANI. This is the way I fixed the 'near smoke' stuttering for low-end systems.
If you use DXT1 or S3TC you can even save half the memory over the ANI effect. (or was it four times less?)
You won't need lods for the effects anymore, as the CPU usage is very low to non-exsistant anyway. So you can save even more memory.
Now the drawback is the compression which looks horrible for some effects. Even though there is not color limitation, it will probably look worse than ANI for effects with a small amount of colors.
So you should decide which format you want to use on a per case basis.
The Nova explosion here is an EFF effect:
(http://img75.exs.cx/img75/2760/wow5ei.jpg)
http://www.hard-light.net/forums/index.php/topic,31170.0.html
I can PM you some instructions and tricks for EFFs if you need them.
Edit: The shockwave is also an EFF effect. :) But I think most people know and use it already...
-
If you've got some tips for EFF's maybe we should make space on the Wiki for them... :)
Probably should put a list of supported formats somewhere too.
-
cause .gifs look like crap.
-
Originally posted by DaBrain
[/url]
I can PM you some instructions and tricks for EFFs if you need them.
Would somebody be willing to just post a thread or readme on it? I'm curious about these as well.
-
Originally posted by Carl
cause .gifs look like crap.
Only if you have more than 256 colors. :p
Or use a crappy compression prog.
-
Slightly off-topic... Taylor once spoke of an interesting option for improving textures for low-end systems. Since the original pcx format is 8-bits, but is converted into 16-bit memory, there is a possibility of using 16-bit tga files instead. These would take up the same memory footprint as the 8-bit pcx files, but it would have the full 16-bit color depth from the source files. If we wanted to make FSO more appealing for those will low-end systems, we could make 16-bit tga versions of all the textures that Lightspeed & co. have made.
-
Originally posted by Trivial Psychic
Slightly off-topic... Taylor once spoke of an interesting option for improving textures for low-end systems.
Continuing the off-topic, topic... I've got some basic code in CVS to convert 32 and 24 bit TGAs to 16-bit on load though it's not enabled yet. It's not perfect (transparency issues) but it does work. This was done mainly in response to Bob's hi-poly herc which only has TGA textures and so requires -jpgtga to show the model properly. If not using -jpgtga then you would only see the thrusters and it's *really* difficult to shoot the ship down.
Planets and background nebula look like crap with this code but if not using -jpgtga then it will try and load PCX files before the TGA versions. This needs a good bit of testing but I haven't put out the call yet, plus not many people volunteer to not use -jpgtga for any period of time.
As far as image quality goes, here is a before and after of Bob's Herc (top is 32-bit, bottom is 16-bit using the same graphics). This is in OpenGL mode, hasn't been tested in D3D yet but should be about the same. The obvious difference is that the cockpit isn't transparent (and I used too low of a JPG quality setting on save ;)). The less obvious difference is that it's using half the memory, the exact same as if it were PCX but with nearly identical color quality as the 32-bit TGA version. Only DDS textures would give lower memory usage.
(http://icculus.org/~taylor/fso/pics/herc-32.jpg)
(http://icculus.org/~taylor/fso/pics/herc-16.jpg)
-
Originally posted by Solatar
Would somebody be willing to just post a thread or readme on it? I'm curious about these as well.
This is a PM I wrote to J.P. to help him with his warp effect:
DaBrain wrote on 03-01-2005 07:03 PM:
I hope I can help you a bit with EFFs.
Ok, first things first:
EEF is not a format like ANI. It's not only one file.
Here is an example:
My particleSmoke02 effect.
The EFF is named ParticleSmoke02.eff
This is what's in the file(open with Notepad):
$Type: DDS
$Frames: 52
$FPS: 28
In other words not very much.
(Just create *.txt and rename it to *.eff)
The first frame is called: ParticleSmoke02_0000.dds
The second one: ParticleSmoke02_0001.dds
(structure xxxxx_000y x=filename y=frame number)
The last frame is: ParticleSmoke02_0051.dds
DDS Converter 2 is your friend:
http://eliteforce2.filefront.com/file/DDS_Converter;29412
The perfect format for EFFs is S3TC.
Go to the options and select Vendor: S3 DXTc fomat: DXT1
And select Less memory usage
Do not use mipmaps. FS2 doesn't use pre-generated mipmaps.
Ok, this is it. It's far more simple than the ANI stuff and has many advantages over it.
One of them is that you won't need to create lods for your effect.
Of course you don't have to use DDS files for EEF effects, but TGA or other uncompressed formats (even PCX) are far larger when loaded into texture memory.
If you have any questions, just ask me.
You can also send me the frames, I can convert them for you.
It takes only a few seconds.
~DaBrain
-
Hmm...
BTW what are the best formats for each job and what do you need for compatability?
Should I:
1) Stick with jpeg's for ship textures? (Except a tga for the cockpit?)
2) Stick with 24bit tga's for effects, or can I use jpegs as well?
3) Use tga's for backgrounds / nebula's? Or jpegs?
Or should I use DDS for all? or other etc?
Should modders aim for compatability with both low and high?
Update:
Thanks for that info DaBrain :D
-
1) IMHO, never use JPGs if you can help it. The compression results in icky artifacts.
2) DDS files are horrible for nebula art; they don't handle gradiants very well.
3) If you can, use DDS files over JPGs for ships in general. They're natively supported by video cards, resulting in faster performance and less memory usage all around.
4) TGAs are the best quality for anything.
5) PCXs are good if you're only using 256 colors (You can only use 8-bit -color PCX files) and can't use DDSes.
6) PCX and DDS files are supported by *everything* that can run fs2_open.
I'd say
1) Make all textures as TGAs
2) If they're big, try out other file formats to see what gives the best quality vs filesize, and include that with the TGAs. FS2_Open will automatically use the TGAs if -jpgtga is specified, otherwise, it will use the smaller DDS/PCX files.
Edit: Woo, psychic powers again. *Hides his seeing orb*
-
lol. Thanks.
Damn timewarp... :doubt:
It took me ages to reply too, because I kept getting:
"Sorry! The administrator has specified that users can only post one message every 30 seconds.
Even though I'd posted at least several minutes ago...
-
Originally posted by WMCoolmon
I'd say
1) Make all textures as TGAs
Yeah, but keep that file only for yourself. You should rather double it's size and compress it via S3TC. The compression will get four times better, while it still uses only half of the memory TGA would use.
-
As I see it the policy should be:
1) -Always make TGA-s since they offer the best quality and work for everything.
-These files also act as reference material for future development, if you can save all the layers separetly for developers
2) -Convert the TGA to DDS - if no artifacts are evident or too serious release the file for general use
-Even if there is a drop in quality release them as optimized files for low end systems
3) -Forget ani-s. They are a waste of memmory. EFF-s can hold both TGA and DDS. Unless your effects heavly relly on gradients try to use the later.
-
I don't think I'l use TGA for textures ever again...
Effects may looks much better as TGA, so it's the still the best choice for effects, But a standard texture won't be hardly affected by the compression.
Keep in mind "How close to the ship would you have to be to notice the difference?"
This slight difference is not worth eight times the memory use!
Not even for high-end systems.
Save some memory for animated effects.
-
I personally have been using DDS for everything. I keep the fully layered PSD files as backup, though, so it's not an issue if I need to have TGA quality........
-
Do VP's get priority over eff's? I'me trying to make new explosions and I followed DabRain's instructions to the "t" with no success. Are the eff and dds files suppose to be in the same folder?
-
Originally posted by DaBrain
(http://img75.exs.cx/img75/2760/wow5ei.jpg)
Oh I ****ing hate you.
GIVE THAT TO ME!
-
Originally posted by Omniscaper
Do VP's get priority over eff's?
Two different things so this isn't an issue. EFFs on the disk get priority over EFFs in a VP though.
Are the eff and dds files suppose to be in the same folder?
Yes. They also should be in the data/effects/ folder, either on disk on in a VP, to work properly.
-
Is there a tutorial on EFF's creation, besides DaBrains. Cuz now I'm just getting frustrated.
My steps:
Opened notepad, put in
$Type: DDS
$Frames: 67
$FPS: 25
Saved the file as a text document with the name ABexp05.eff.
Made 67 frames in PS named ABexp05_0000 - ABexp05_0066 in DDS format DXT1 settings. No alpha.
Put ALL files in data/effects folder.
Changed the fireballs.tbl to use that file. (Because naming all the files after the original exp05.ani didn't do anything)
I get this error:
Error: Could not load abexp05 anim file
File:E:\Languages\Visual Studio Projects\Visual C++\fs2_open\code\Fireball\FireBalls.cpp
Line: 559
Call stack:
------------------------------------------------------------------
------------------------------------------------------------------
What am I missing here. I'm using an official build. Is there a launcher setting I'm forgetting?
-
I should change that to
"Error: Could not load abexp05 anim file, good luck finding out why, cause I'm certanly not telling you"
-
Originally posted by Omniscaper
Made 67 frames in PS named ABexp05_0000 - ABexp05_0066 in DDS format DXT1 settings. No alpha.
The frame filenames have the .dds extention, right? It will add that (when loading DDS) when it tries to load the individual frames so it may not be finding them. And you are sure that Notepad didn't put a txt extension on the .eff file when you saved it? It will do that and then WinXP may not show the txt extension later unless you uncheck "Hide extensions for known file types" in folder options. The bmpman code will strip off all extensions and try it's own but CFILE will have issues finding it in the first place if it has a txt extension. And I assume that you are running at least 3.6.5 since EFF wasn't officially supported until then (you said "official build" so I wanted to make sure).
Everything else looks fine. If it's still not working post a link to the files and I'll take a look. Also, if you run a debug build it will put info on whether or not it's processing an EFF properly in the log. You can take a look at that and maybe it will give some clues as to what's going on. DaBrains tutorial is dead on and has all the info needed to make a working EFF. No launcher setting is needed unless you are using TGA or JPG files for the EFF. In that case you have to use -jpgtga just like normal. I keep joking that I made the thing too simple since no one can figure it out. ;)
-
EDIT: Crap, wrong topic
-
SON OF A *^%(*&^%(&
Wasted 1 hour of my LIFE!!!!
THANKS TAYLOR!!!!
-
Originally posted by Omniscaper
Wasted 1 hour of my LIFE!!!!
Which problem was it? We need to get that mentioned in the tutorial so no further LIFE is wasted. :D
-
EVIL WINDOWS NOTEPAD SPAWN!!!!
I'm turning off extension hiding now. XP *****. $#*%&(@*^!@!#&%@)#*%#(*&
::calm::
Vodka anyone?
-
Yeah, extension hiding is one of the first goddamn things I turn off when using XP and doing any sort of file browsing.
-
lol.
Tis always the obvious problems that catch people. :p
Still 67+ files in the effects directory is still a bastard for clutter. Isn't there someway we could store all the files as one?
Aka one file with many layers, or maybe a zip containing all the files?
-
you mean like a VP file? :p
-
Even in vp files it would be cluttered. Unless you had one for each animation... which is a bit redundant, but could work I guess...
-
Originally posted by Grug
Still 67+ files in the effects directory is still a bastard for clutter. Isn't there someway we could store all the files as one?
It's been debated, I'm against it at this point though. It would make things nicer but it's not really a big deal when the files get in a VP. With the frames as separate files all of the existing image loading code can be used. If they were in a single, large file then we'd need new/modified loaders for every file type. The EFF stuff was meant to give the most flexibility possible since ANI was so restrictive. Having them in separate files makes them easy to use later for editing or adding/deleting frames. Another reason is that, like you say, it's a lot of files in one place. It's a deterant from making really large effects. An EFF can take up considerably more memory than an ANI and the more frames you have the more it hurts in game. I think that some of the current ANI glowmaps are using way too many frames and therefore using too much memory. They look good but could probably be cleaned up some to save everyone a bit of RAM.
-
Can we use eff's for everything that .ani's were used for?
Including techroom stuff and particle, explosion animations?
How do you put the data in to tell it to loop / bounce back / single play etc.?
-
Originally posted by Grug
Can we use eff's for everything that .ani's were used for?
Nope. Particle effects, weapon effects, explosions & ship textures. Can't be used for talking head animations, anything briefing related, anything interface related (buttons, mainhall), or techroom stuff. If it could we would imposing more restrictions on what you can do with it. That's where the problems with ANI came in and what EFF is trying to avoid. There will be another format just for those things which isn't well suited for effects but great for the big movie type animations.
How do you put the data in to tell it to loop / bounce back / single play etc.?
You don't with EFF. It's up the particular code using it to decide what to do. It's that way with ANIs now too so that's not new. Particle stuff and ship textures and some weapon effects get looped, other weapon effects and explosions play once. Since the code doesn't care what you tell the EFF to do (except the FPS) it's useless to include that info in the format.
-
Ah k.
So what plans are there to replace .ani for the usually larger mini-movies etc?
Some type of open source movie format?
Would it still exclude sound?
-
Originally posted by Grug
So what plans are there to replace .ani for the usually larger mini-movies etc?
Some type of open source movie format?
Would it still exclude sound?
The replacement is pretty much like ANI but a series of JPG images instead. JPG has a quality problem obviously but it's a big saver on space so mods that use it will be much easier to download. It's going to be based partially on the smjpeg format but modified to be much closer to ANI. That way it will properly support ping_pong and reverse play. It still isn't going to have sound. I've debated that one with myself but not having sound means it's a *lot* easier to use as a replacment for ANI.
I've got the format mostly worked out and the code partially implemented already. When I'm done it will go up for discussion before going in CVS so if it's decided to change it then I'll do so. I don't know that everyone is going to be completely happy with what I have in mind but it plugs into the current code without big rewrites of anything or special case handling and addresses the two problems people want fixed: more colors, smaller disk footprint (easier to download).
-
Can the code be easily expanded to use something different, like...not JPEG?
-
Originally posted by WMCoolmon
Can the code be easily expanded to use something different, like...not JPEG?
It includes an image type specifier in the header. That's in addition to the file format part of the header. It's not really needed but there anyway. This is also based on the all-in-one EFF idea that was under consideration but I stopped working on. That's why it's there, I just haven't removed it. The individual frames are complete files, not just the data part. That's done so that individual compression and palette settings can be used. The frame data follows a uint with the size of data in that frame. That much data is read into memory and sent off to be decoded by a the jpeg reader that reads from memory rather than disk (already done when I did the new jpeg decoder).
Other than the fact that it's only ever sent off to a jpeg decoder there is nothing that prevents us from using multiple data formats (providing it's always the same for that animation). And other than the decoder part everything else is in animplay.cpp. The only exception is that it can't use DDS since it has the power-of-2 restriction. JPEG is good to go now but that still leaves PCX and TGA as something that could be used. Using either of those does nothing for disk space though which was one of the requests for any new format.
Uhh, really long way of saying "Yes, other formats could be used." I should really figure out how to say things in a more efficient way. :rolleyes:
-
Kewl.
What's everybody's problem with jpeg's?
Really, there is only minor picture glitches. Unless you use MSPaint to save your jpeg's they are fine for quality on the max setting.
Stop your complaining wmcoolman. :p