Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Flaming_Sword on November 30, 2012, 09:28:06 pm
-
I figure I should get off my arse and do something about this.
Before I start, I'd like an idea of what features people want and why. From there, we can figure out something feasible that should make most people happy. Feel free to wish for the moon, just remember that delivery of said moon might take a while. :P
That's right, this is requirements gathering. :nervous:
-
I figure I should get off my arse and do something about this.
Hooray! :)
I strongly recommend reading through all three threads MjnMixael linked from here (http://www.hard-light.net/forums/index.php?topic=80792.0). They contain all the substantial discussion about the MNG format, and the requirements which led the community to favor MNG (before the lack of tool support caused it to lose momentum) are the same requirements which the community would want to see in the EFF container format.
One small requirement that I'd like to add is that any "EFF container" should have a different name. It shouldn't be called "EFF", nor should it have the .EFF extension. This is because people expect an .EFF file to be a simple text file.
-
One small requirement that I'd like to add is that any "EFF container" should have a different name. It shouldn't be called "EFF", nor should it have the .EFF extension. This is because people expect an .EFF file to be a simple text file.
I vote EFC (Effect File Container)
-
Do we really use it only for effects ? I think it would also be used for mainhalls and stuff.
-
Being one who uses these files more than most.. I intend to respond to this. I just haven't had time yet to think about and write out the list. I'll do it today.
-
EFF File Container. ;)
-
OK, here's my wishlist.
Alpha channel
Cross-frame compression (preferably having the ability to set a compression level on creation)
Keyframe abilities (ala ANI keyframes for interface useage)
command-line creation ability (this one is pretty dang important for me, actually, because of how many anims I make... see my persnal text to the left)
I'll agree to it not being .eff but being .efc or something.
I'm assuming this will be the case, but they should load into bmpman as a single unit like ANIs do for interface usage
That's all for now, I think.
-
Not sure if this falls under the container format or not but the ability to specify non default file names for the -glow, -spec, -normals. For instance TBP has debris effects that use the same glow maps but there have to be multipe copies of the -glow.dds files.
Still like to see the ability to read the files from either the container and a subdirectory with the container name. This way if you are working on something and want to distribute it to others for testing you can have it packed up but anything you change should still get read from the directory. This might be a problem with cfile though. I know it was discussed before.
Most importantly it needs an easy to use tool to view the files and the file information for each frame as well as the entire effect outside of FS2.
-
should probibly just make it a general material container so it can be used either way.
-
OK, here's my wishlist.
Alpha channel
Cross-frame compression (preferably having the ability to set a compression level on creation)
Keyframe abilities (ala ANI keyframes for interface useage)
command-line creation ability (this one is pretty dang important for me, actually, because of how many anims I make... see my persnal text to the left)
I'll agree to it not being .eff but being .efc or something.
I'm assuming this will be the case, but they should load into bmpman as a single unit like ANIs do for interface usage
That's all for now, I think.
So... like ANI but better. I like it! :D
Not sure if this falls under the container format or not but the ability to specify non default file names for the -glow, -spec, -normals. For instance TBP has debris effects that use the same glow maps but there have to be multipe copies of the -glow.dds files.
Still like to see the ability to read the files from either the container and a subdirectory with the container name. This way if you are working on something and want to distribute it to others for testing you can have it packed up but anything you change should still get read from the directory. This might be a problem with cfile though. I know it was discussed before.
Most importantly it needs an easy to use tool to view the files and the file information for each frame as well as the entire effect outside of FS2.
This stuff seems like it falls outside the intended scope. For example, this thing would be more about the packaging of said glowmaps than getting the game to use particular ones.
I'd say mjn.mixael's post says it all, unless someone else has anything else to add.
-
I will throw in that a tool to view them outside of FSO would not go unused, but I realize you need to create the format itself first.. then we can bombard you with more.
-
At the risk of getting shot down but just going to throw random things out there, warning i really have no idea what im talking about really:
having the option for lossless compression (something like PNG), for previewing work files pre-compression losing quality (even w/cross-frame compression? no idea how realistic this is), but also the option for lossy compression (something like DDS) to further reduce filesize if necessary would be nice, as currently EFFs have the option for both. Maybe kind of ties in to setting compression level on creation, I guess...
Also, in a similar vein, maybe a tool to batch-convert existing EFFs to such a format for efficient transition. (this might be a given, Iunno)
-
I figure the safest way to do it is to reuse as much existing functionality as possible.
To that end, I'm thinking a command line tool to convert to and from existing EFF. As far as compression between frames, I'm considering doing it the ANI way (optional). So you can still have PNG or DDS, but they are diffs from the previous frame rather than entire frames.
So we take an existing EFF (create diffs between frames to make it work like ANI as an optional step to save file space in return for no ability to run in reverse) and make a solid file out of that using a command line tool. Reverse the process to recover EFF for viewing outside. Tweak FSO a bit to treat EFF and the new format more like ANI in some cases.
Correct me if I'm wrong, but I could swear I added keyframe stuff to EFF to shoehorn it into the interface a long time ago...
Holy crap, this is starting to look feasible...
-
Yeah, EFFs have keyframe ability.
-
Would this help with BMP man limits? It sounds like it does.
-
Just one question. What could be done with this container format that cant be done on current trunk that would justify the work and bugs that would inevitably crop with this?
-
Just one question. What could be done with this container format that cant be done on current trunk that would justify the work and bugs that would inevitably crop with this?
Clean folders that don't have millions of loose frames in them, for one.
Also the container compiler could also check for missing/corrupted frames, which can be...difficult with EFFs (I have missed a frame numerous times, leading to CTDs >.>)
Also, cross-frame compression to reduce disk size.
-
Clean folders that don't have millions of loose frames in them, for one.
VP Files?
Also the container compiler could also check for missing/corrupted frames, which can be...difficult with EFFs (I have missed a frame numerous times, leading to CTDs >.>)
So a warning from the game that a frame is missing and the compiler doing the same isn't equivalent?
Also, cross-frame compression to reduce disk size.
Then why do we not implement an established video format that meets our requirements instead of reinventing the wheel?
-
Then why do we not implement an established video format that meets our requirements instead of reinventing the wheel?
We already had this discussion, actually. (http://www.hard-light.net/forums/index.php?topic=80792.0) Long story-short... we landed on MNG. Then no one wanted to do the work to implement it. Flaming_Sword is working on implementing something that will fill this role, any good reason to derail it?
-
Note that I'll be out of the country and away from my dev machine for 3 weeks starting this weekend...
That said, I'm leaning towards adding ANI features like the cross-frame stuff into EFF as a first step. That should result in smaller size on disk, and ANI behaviour is already there (I just have to make the new EFF stuff do the exact same thing). Then we can decide on packaging, which should result in the new format essentially being a superset of ANI in terms of features and able to use existing (tweaked or copied) ANI code. Code reuse FTW! :D
I should probably start a new thread for the implementation details...
-
Note that I'll be out of the country and away from my dev machine for 3 weeks starting this weekend...
Disappointing, but understandable. Have a good time, and don't forget about us when you come back. :D
That said, I'm leaning towards adding ANI features like the cross-frame stuff into EFF as a first step. That should result in smaller size on disk, and ANI behaviour is already there (I just have to make the new EFF stuff do the exact same thing). Then we can decide on packaging, which should result in the new format essentially being a superset of ANI in terms of features and able to use existing (tweaked or copied) ANI code. Code reuse FTW! :D
Awesome. :D