Modding, Mission Design, and Coding > FS2 Open Coding - The Source Code Project (SCP)

Might I make a suggestion?

(1/5) > >>

JC Denton:
Since I heard a few of the TBP staffers are worried about someone tweaking the POF code and rendering all their models obsolete, I have an idea to possibly avoid this problem.  It's kinda hard to explain, but in a nutshell, it involves adding a second filetype to the engine.

This second type might be called XOF (eXtended Object Format) (maybe?), and all work in POF recoding should be centralized into this one add-in.  This allows the engine to both understand the original POF format, plus allows modelers to make XOF models to take advantage of any new features the XOF code offers, whatever they may be.  Plus, if it's possible, let the XOF code be backwards compatible with older formats: if advanced features are available in the code but are not present in the model, it won't break anything.

Probably a few fixes for the current POF code (and not needing any funky new file formats) would be allowing textures to be something other than a PCX file.  This can be immediately useful for making animated textures in ANI format and allowing them to be mapped onto the models, as well as making "glowpoints" which are basically the navigation lights we saw in Homeworld.  Simple add-in to the TBL file can specify what texture to use, how big it is, and if it blinks and how fast it does so.  Also either ANI or PCX compatible.

If you're thinking that it might be just as easy to do the backwards-compatibility on the POF files rather than add a new file type, well, you're probably right, but this way allows us to keep a working object format while tweaking the XOF code.  Plus it'll give us a way to differentiate between old and new models, keeping compatibility at a maximum.

Nico:
would be better to just make the thing backward compatible. So the new pof have added data, and the old data can still be readable. Btw, why not using other format than ani for animated maps? anything would be better, ani are too big. I'm frightened when i think of 512*512 ani maps :p

_argv[-1]:

--- Quote ---Originally posted by venom2506
would be better to just make the thing backward compatible. So the new pof have added data, and the old data can still be readable. Btw, why not using other format than ani for animated maps? anything would be better, ani are too big. I'm frightened when i think of 512*512 ani maps :p
--- End quote ---


How about MNG? Nicely compressible, and code already exists to decode it. Oh, and it's standard, too. Woot! Maybe PNG should also be supported for non-animated textures, since it compresses well. JNG (linked to on the MNG page) would be good, too, since that's JPEG with alpha etc.

Using *NG would also be useful for the user interfaces graphics (briefings, most notably), because of alpha compositing. As you may have noticed, some of the command briefing animations have areas that are supposed to be transparent, but just look exactly like the background picture behind them. This looks strange in 1024x768. With alpha compositing, you have real transparency. You can also antialias the HUD graphics with alpha compositing.

JC Denton:
Well, it's not like we're going to have the hi-res Lucifer maps from FS1 all animated or anything.  Most animations would be for small areas, and even if they're going to cover a large percentage of the model, it'd be just as easy to make a small hi-res map and tile it.

And as for the *NG files, they look like a promising alternative to ANI files.  Although I didn't know that FS2 already had the code to interpret the formats.

If it does, then great.  If not, I don't know how much of a headache it would be to put it in.  But then, I'm no programmer, and quite clueless when it comes to C++.

_argv[-1]:

--- Quote ---Originally posted by JC Denton
And as for the *NG files, they look like a promising alternative to ANI files.  Although I didn't know that FS2 already had the code to interpret the formats.

--- End quote ---


It doesn't. I meant that *NG libraries exist, so you just need to use them. Using these instead of PCX/ANI should just be a matter of finding the image loading routines, where the PCX/ANI files get loaded, and bolting in some *NG loading code.

Navigation

[0] Message Index

[#] Next page