Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: mjn.mixael on March 21, 2011, 04:31:00 pm
-
Firstly, I don't intend this post as a "hurry up" or "how's the status", just to be clear. This is an overview of my findings from a long series of tests and a substantial amount of research.
I am still very much in support of MNG being added to FSO still, but I do have a lot of concerns about the format. It has a lot of positive sides to it. MNGs, in my tests look really great and in many cases they are 50% smaller in file size than EFF sequences. :yes: All in all, I am very happy with the format...
When it works...
As discussed here (http://www.hard-light.net/forums/index.php?topic=72090.0) there are were at one point many tools for creating MNGs and a few for playing them back. And therein lies the problem. MNG, while a great format, may as well be considered a dead format as for as the general populace goes. When MNG died, so did most of it's tools. Many of them never really got off the ground enough to be even considered in the realm of reliable. Trust me, I tried every single one I could find. I did all this testing because I have hundreds of ANIs to test it on, and to save you guys the trouble.
However, the problem gets more complicated because there are even fewer MNG players out there. I tried as many as I could find as well. The end result showed varying degrees of success. Some MNG files would work in players but fail in others. Programs that should seemingly have reliable support (Like IrfanView) didn't work at all for any MNG file I could throw at it.
Eventually in my testing, I landed on MNGSV as my player of choice. It successfully played back the most MNG files I could throw at it, 6/10 in my tests. None of the others came close. IrfanView was an incredible 0/10. So, with my player chosen, I began a thorough search of an MNG builder and finally landed on AdvanceCOMP. Using MNGSV as my playback tester, I tested each builder with the same sporadic grouping of my FS1 and FS2 ANIs. AdvanceCOMP scored the best with about a 45% success ratio.
:no:
All that to say that there isn't much support out there anymore for MNG files. Both MNGSV and AdvanceCOMP seem completely ignored these days as far as development. If we are going to get MNG support, then I want to stress that we are going to need reliable tools as well. As it is, I can't really tell if it's AdvanceCOMP or MNGSV that is failing. It should also be considered that maybe the MNG libraries are unreliable. But that's getting out of my realm of knowledge.
At various times I thought certain things were hindering the creation, like having capital letters in the name or something. Finally though, I just started creating MNGs from PNG sequences labeled ####.png. Still no good. I tried different levels of compression, different types of PNG files. In the end, I never could tell if/why one would play and another wouldn't...
Finally, I'm linking to the download pages of MNGSV (http://entropymine.com/jason/mngctrl/) and AdvanceCOMP (http://advancemame.sourceforge.net/comp-download.html) as both of them also have the source up for download. Perhaps that could be a start to making reliable tools? I'm also linking to a few MNG files I've already created. There are two large MNGs and two small MNGs, one of each works and one doesn't. Figured that would help with any testing that might go on.
Non-Working MNGs (http://www.mediafire.com/?hubbd5yag4pm2ec)
Working MNGs (http://www.mediafire.com/?8tqr4jkmamza68c)
-
This topic != Jpg discussion
Broken JPG discussion goes here. (http://www.hard-light.net/forums/index.php?topic=74691.msg1477763#msg1477763) Where the coders were waiting for a question to be answered. One that I can't be arsed to answer because I don't use JPG for EFF files.. so don't expect me to bother to do that testing.
-
Also, I think you are severely misunderstanding the point of MjnMixaels inquirys. All this says to me is that if we're going to go ahead with implementing mng support, we will probably be forced top roll out our own reader library and conversion tool.
I think I expressed my distaste of this notion pretty clearly, the point it crystal clear to me, I'm completely against using a dead format, not to mention building completely new compression and playing programs so it can run...
it would be better to just add support for video playback in the command briefings, its a long term solution, and for now, EFF+PNG will do just fine IMO
-
Actually... EFF+PNG won't work for several ANIs. Period.
"2_tech_gti_tag_missile_c####.png"
More than 32 characters. Many of the FS2 ANIs suffer from this. There's no getting around it... EFF without a container is not ideal... and since creating a container has already been discussed and dismissed, MNG is a better option.
-
Why just not rename them then ? It's not like if FSU couldn't edit some tables and missions to go along with the file rename.
-
We could, yeah. But that's not the point.
The argument for MNG support are thus:
1. MNG offers rudimentary video compression similar to .ani, thus saving space
2. MNG files are single files, instead of having hundreds of pngs lying around
3. While the format isn't in general use, it is a standardized format, meaning that there is a very clear spec we have to implement
4. It is easier to plug MNG into the animation handling code than it is to extend ogg theora support.
In short, nighteyes' objections are based on his personal biases, not objective reality. I also note that the bug report he gave still lacks details that we asked for. If his bug isn't fixed, it's his fault.
-
Why just not rename them then ? It's not like if FSU couldn't edit some tables and missions to go along with the file rename.
Well, things could get complicated pretty quickly. The hi-res Anims are totally optional, especially given the large download sizes. Now.. say someone doesn't want the Anims, but they get the rest of the MediaVPs. Now they have missions and tables that call for renamed Anims that don't exist in the retail VPs.
Well, we could include those missions and tables with the hi-res Anims, however, by doing that we force ourselves to duplicate those missions and tables and keep both sets updated side-by-side. That is because we couldn't force people who want updated (bug-fixed) missions to download the Anims VPs.
And so on. It's a good and true thought, but not practical the way things are currently set up.
I'm not trying to be completely rude here, but we already discussed "Why MNG" over other options here. (http://www.hard-light.net/forums/index.php?topic=71913.0) If you have other reservations, please read through that thread before we end up having the same discussion again in this one.
-
Supporting a format thats dead for all intents and purposes would be majorly stupid. If you want a long-term solution to replace ani-files, then please think up a solution that SCP can actually support with limited resources that they have. As controversial as it is, even Flash would be better choice here than MNG. But depending where eventual interface overhaul goes, HTML5 might become a viable option. Now these could be called long-term solutions, not MNG.
The more SCP would have to support 3rd party formats/libraries/whatever, the worse the solution. The less they have to work to maintain something, the better.
Now, an interface built on HTML5 and rendered by built-in rendering engine like Gecko or WebKit would certainly give modders extemely high moddability, but I doubt we'll ever get there. Especially since the stop-gap seems to be LUA scripting where you still need something else to play videos, like Flash.
And make no mistake, I hate Flash because of its security issues and afaik you need $$$ to pay for software to create Flash videos. :doubt:
-
:sigh:
To my calculation we have people against using another proprietary format, people against a dead format, people who don't even want a new format, and people who want a format that would require far more work than we have the man-power for...
I'm tempted to just give up and stick with ugly ANIs...
-
Dead format = bad
Proprietary format = bad
Open format with incompatible license = bad
Not much choices out there unfortunately. I just said Flash as an example, I don't believe for a second it even has a chance making it in. But from technical standpoint, it'd still be better than MNG. From what I gather, because MNG is mostly dead format, supporting it would be a major task to SCP. It simply isn't worth it.
Assuming we get LUA scripted interface finished, I believe Diaspora at least is working on this? In any case, with LUA scripted interface it should be possible to use video files for animations, such as ogg that we already use for cutscene videos. Regardless, it is a well known fact that current interface is obsolete, archaic and simply insufficient for current, not to mention future needs of modders. Replacing ani format with equally bad, or worse format isn't going to help anyone. Something like HTML5 based interface could in theory support all needs, since you basically build it like a website. But HTML5 is still nothing more than one of many alternatives, it's just one that's been stuck in my head from earlier discussions we've had on the subject.
-
I understand all that, however this is more about a format to.. for example... release all my FS1 and FS2 Anims in that doesn't look like crap and still take up tons and tons of file space.
Not to deter any of what you are talking about.. but seriously.. who knows when that kind of interface support will be available.
-
Is it a major task for us to support png, jpg, or ogg? No. All we need is a reference implementation of the functionality provided by libmng that we can plug into our codeside interfaces. Once we have that, maintenance is done, especially if we roll our own version.
I would like to ask everyone to stay calm and leave off the FUD. Because while Fury has several good points, the amount of work (and subsequent maintenance) integrating a framework like WebKit would cause is orders of magnitude more complex than adding support for MNG.
Also, I think that Flash and HTML5 are good candidates to replace/enhance the current interface code; however, the issue of having to have a good format we can use to handle animations is separated from that.
-
I understand all that, however this is more about a format to.. for example... release all my FS1 and FS2 Anims in that doesn't look like crap and still take up tons and tons of file space.
Not to deter any of what you are talking about.. but seriously.. who knows when that kind of interface support will be available.
I understand that too, but wasting SCP developer time to support a file format such as MNG is waste of time. If you want a short-term solution, you need to suggest a better format. Otherwise you don't have any other option than to either use ani, or eff with jpg or png until we have viable long-term solution in place.
While I don't have any idea when Diaspora is going to be released, maybe this year for all I know, but I know that Lt. Cannonfodder was and more than likely still is adamant about having better interface that what FSO currently has in trunk. Which means that first release of Diaspora will have sufficient LUA scripting support for interface because Lt. Cannonfodder doesn not want to re-create the interface after the first release. Which again means that there is sufficiently high chance they've also added support to play animations in some other streamable format than ani since they are quality whackjobs.
Which again means that you probably don't have to wait longer than until Diaspora's release to get what you want. Or perhaps you can even convince them to chime in and tell us about it, maybe even release the code patches if they haven't done so already.
But as for this being the solution for FSPort and Mediavps, well, that's another catch. I don't have the slightest idea how much scripting and how much new interface art you're going to need to embed videos into existing FS1 and FS2 interfaces. But hey, that might be a good opportunity to re-create the interfaces in much higher quality and package them with fsport mediavps and fs2 mediavps while at it.
Is it a major task for us to support png, jpg, or ogg? No. All we need is a reference implementation of the functionality provided by libmng that we can plug into our codeside interfaces. Once we have that, maintenance is done, especially if we roll our own version.
To me it really sounded like you'd have a lot of work to even get MNG implemented, more work than jpg/png/ogg. Ultimately, it's up to the coders like yourself whether you want to go through the pita. I wouldn't, but that's just me.
Also, I think that Flash and HTML5 are good candidates to replace/enhance the current interface code; however, the issue of having to have a good format we can use to handle animations is separated from that.
HTML5 has canvas and javascript for animations. And of course, it should be easy enough to embed videos such as ogg that we already have supported.
-
Yes, it is a lot of work. More work than it took to get libpng in. But it's also work that has rather large benefits, and that is less of a challenge than rewriting the interface code to run on HTML5,
-
I would still like to hear what is/will be Diaspora's solution to the problem, chances are they have already a solution at some stage of progress.
-
Eventually in my testing, I landed on MNGSV as my player of choice. It successfully played back the most MNG files I could throw at it, 6/10 in my tests. None of the others came close. IrfanView was an incredible 0/10. So, with my player chosen, I began a thorough search of an MNG builder and finally landed on AdvanceCOMP. Using MNGSV as my playback tester, I tested each builder with the same sporadic grouping of my FS1 and FS2 ANIs. AdvanceCOMP scored the best with about a 45% success ratio.
I guess I'm the only one who read this part... its not just implementing FSO to be able to use MNG, that part might be relatively "easy", what about building from scratch/fixing the MNG file builder and player, as they are BOTH broken?!
MNG in itself has many good qualities, but as Fury said, its not a long term solution...
-
First, we have to implement a reader/player ANYWAY. Building an application to make these files is trivial, given that there are plenty of reference implementations already available.
Also, unless something drastic has changed, you are not a coder. Don't tell us what is easy and what is not. Also, this "long term solution" you keep referring to is so long term, that we cannot even start to make an estimate on when it's done. Getting mng support is, by comparison, far easier, even if we have to make our own converter that is guaranteed to work.
-
i think i would ditch mng all together at this point. the point of supporting said format was if i remember correctly "standardized format" and "available tools" both of which seemed to have gone up in a poof of smoke some time since then. if the consensus is "implement it anyway and make out own tools" then you may just want to consider coming up with your own format that meets all the specs required.
-
...
Yes, because creating and defining an entirely new format is easy.
Please, go ahead. I expect to see your spec and reference implementation soon.
MNG HAS a reference implementation in the form of libmng. All that is required is a content creation tool that can reliably produce valid mng files.
-
i think i would ditch mng all together at this point. the point of supporting said format was if i remember correctly "standardized format" and "available tools" both of which seemed to have gone up in a poof of smoke some time since then. if the consensus is "implement it anyway and make out own tools" then you may just want to consider coming up with your own format that meets all the specs required.
The point of a new format was for streamability, file size and quality. The reason we went with a standardized one is because it's easier, and it still is.
EDIT: On a further note.. this thread isn't about IF we should include MNG. There are already enough SCP staff on board with this that those of you who think it's a waste of time don't need to even bother. This post was to type up everything I've learned about MNG for the staff who ARE working on it. Please stop muddying up this thread.. especially if you have absolutely no intention of helping.
-
To be more precise, the requirements are:
1. full support for 32 bits of rgba colour depth
2. Compression. Resulting file size should be less than an equivalent eff with png files.
3. The reader must be compatible with the eff/ani code.
4. Keyframe support similar to .ani
If you can write that, please, go ahead.
-
well what i was thinking of would not do #1. really i kinda think 32bit rgba sounds overkill.
what i had in mind is this:
use a block compression system similar to dxt1a. these blocks would be 4*4 pixels and take up 8 bytes for 4 bits per pixel. these blocks use 16 bit (565) color and thus would not be 32 bit rgba, but still much better than 8 bit.
blocks would contain 2 5'6'5 colors, and a 2 bit color index per pixel (two other colors would be interpolated at decode time)
format:
-file
-animation header
-frame header
-blocks
animation header would contain:
image resolution -desired resolution in pixels
block resolution -desired resolution in blocks (will be greater than or equal to resolution/4, difference will be used to mask unused block pixels as transparent)
framerate -frames a sec
animation length -in frames
keyframe definitions -not sure how to approach this part yet (im thinking offset of the frame header and some kind of identifier)
frame header:
block map (size would be (brx*bry)/8 bytes) -would contain a 1-bit map of the image blocks, logical true bits would indicate blocks that are contained in the frame. on keyframes all blocks would need to be updated and the map would contain all ones (except for unused bits).
blocks -the compressed 4x4 blocks. at render the block map's bits will be iterated through, and for each 1 encountered the next block in the sequence will be read, decompressed, and rendered to buffer at coords derived by the bit index of the block map and data from the header.
mind you this is just a preliminary outline. i dont want to design the whole format if it wast going to be utilized. i figure compression will be better than dxt1a in a container format. i may also look into other block compression algorithms to see if i couldnt find something better, though that would not change the rest of the format. using the dxt1a style blocks would only supports 1 bit transparency. it would support looping but would mostly be intended for forward playback from any keyframe or loopback to any keyframe. streaming should be possible, provided the header is loaded and the animation sequence instance is initialized. nothings coded yet, but this isnt the first time i came up with a file format from scratch.
-
using the dxt1a style blocks would only supports 1 bit transparency.
Um.. that scares me. Now.. granted it's a bit above my ability to understand, but it sounds awfully similar to the ANI transparency limitations which drive me up a friggin wall.
-
well thats whats in my head. if you want to half the compression i could use a dxt5 block (8bpp or the same size as ani). and like i said there are other block formats out there that i havent looked at yet. what i had in mind was something that can do everything ani can do and look better while being smaller. i didnt know you guys were after "eXtreme detail (tm)!" :D
-
I don't believe DXT has necessary image quality for this purpose, as this is supposed to be used in command briefing animations and such. These should be streamed off the disk, not loaded to memory as a whole and then played. DXT in most cases has way too much compression artifacts, particularly with gradients. Not saying DXT couldn't work in some animations, but people shouldn't be stuck with it if they want animations without readily visible compression artifacts.
Libmng supports jpg and png, so you get better compression in the form of jpg when frame quality is not a huge concern and png when you need or want the best quality. The fact that these files would take as much memory as uncompressed files shouldn't matter because they're supposed to be streamable, hence I don't see much point in having DXT as anything but an option, which libmng doesn't support.
But if someone intends to make their own file format to suit the needs of ani replacement, then it really should be flexible in terms of use.
-
i would only use dxt's block compression schemes, thats not to say i will be using the dds file format. say you take a 440*200 cbani. this animation would be roughly 110*50 blocks in size. keyframes would always have all blocks defined, consecutive frames would only update blocks that change significantly enough. so if only 50% of the second frame has changed from the first frame, then only 50% of that frame need be stored (this is in addition to the block compression). this could be streamed for forward playback (this method of compression would not allow reverse playback without precaching). only the file header, current frame header(s), and frame buffer(s) need be stored in memory. no more than a few frames would be buffered in ram at any one time, during playback the file handle will be left open until the the playback session is ended, at which time the handle is closed. keyframing would be handled as a stored offset of the frame header of the keyframe.
i dont like the idea of container formats for image files of some format. they lack any form of inter-frame compression, which is how video formats manage a pretty good compression to size ratio. mng i believe does this, my only objection to that format really is the unavailability of existing tools. my alternative really isnt much better, as it only exists in the mind of a rather unfocused hack-coder, and would probibly take me forever to write proof of concept code anyway. i said before (in the previous mng thread) that mng looked good on paper, and if you guys think it will be easier to code and support (despite the difficulties with the format) than a from scatch format, have at it.
*edit*
i was looking at the compression algorithms for dxt5's alpha channel, and if i encode all four rgba channels in the same way, i can compress down the blocks to 16bpp. something like this is used with bc5 normal maps to improve quality over dxt5nm (except using 2 channels instead of 4). if i limit the color table in a block to 2 bits (instead of 3) per pixel, i can drop the compression down to 12bpp. this should still result in better quality than dxt1 since all channels are encoded separately. still looking at alternatives to dxt1a blocks which would provide more quality at a minor expense to size.
i can also do a variation on dxt1 where the two 16 bit colors are replaced with two 32 bit colors, while keeping the 2-bit color indexes. this would result in the block weighing in at 6bpp. also the 2 bit per color index could be up-sampled to 3 or 4 bits at an extra 1 or 2 bits per pixel. this could improve quality but may lead to some bizarre artifacts however (alpha would intrude into the color space). i could avoid this by using 2 bits for color and 2 bits for alpha (8bpp).
-
A full 8-bit alpha channel is needed to allow transparency effects as are possible with MNG.
-
you guys are probibly set on mng at this point so im having some fun with this idea of mine.
block compression works by reducing the color space in a block to a specific range. same would be done with alpha. the block (8bpp) would only contain 4 shades of each color, however this is interpolated between the min and max value present in the uncompressed block at compression time. so the highest alpha value and the lowest alpha value in an uncompressed block would be identified. two other intermediate values would be interpolated and these colors would be indexed between 0-3. keep in mind that a block is only 4x4 pixels, so 4 shades of alpha could cross the whole block and look just fine. on a long alpha gradient there wouldnt be much variation in the alpha, and a hard edge would map out to a wider range and produce a sharp dropoff (which would have been desired in that instance). the 12bpp format would do this on all channels while the 8bpp would only do color and alpha ranges. the 16bbp format would provide bigger ranges (8 shades instead of 4) for each color, and within a 4x4 block you are unlikely to get that much variation.
at this point ive mostly broken away from the dxtc standards and have been looking at other formats loosley based on them. heres what i like most so far.
8bpp block:
4 byte rgba min
4 byte rgba max
4 byte pixel color index (2bpp x 16)
4 byte pixel alpha index (2bpp x 16)
pros:
smallest size block
good alpha range (better than dxt3 but not as good dxt5 alpha)
better color than dxt1 (888 instead of 565)
cons:
color not as good as alpha
12bpp block:
4 byte rgba min
4 byte rgba max
4 byte pixel red index (2bpp x 16)
4 byte pixel blue index (2bpp x 16)
4 byte pixel green index (2bpp x 16)
4 byte pixel alpha index (2bpp x 16)
pros:
same quality across all channels
better color than 8bpp format
cons:
bigger
same alpha quality as 8bpp format
16bpp block:
4 byte rgba min
4 byte rgba max
6 byte pixel red index (3bpp x 16)
6 byte pixel blue index (3bpp x 16)
6 byte pixel green index (3bpp x 16)
6 byte pixel alpha index (3bpp x 16)
pros:
best quality
alpha quality on par with dxt5 alpha
better range on color channels
cons:
huge!
more range than pixels (almost)