[Zacam]

Ah. Well, in that case, I heartily agree.

[portej05]

ya know, I was just thinking about this.
I think this all points at an endeavour which we keep putting off, but that has to be done eventually.

Thorough engine documentation.

I don't just mean the randomly asserted FS Wiki stuff we've currently got (e.g. table structures for the modders), but more at the structure and use level.
Going through the engine to detail this stuff would probably be worth it in the long run. Even if we only gain a better understanding of limitations.

On that note, is the POF format, the VP format and other formats and their identifying characteristics actually formally documented anywhere?

[chief1983]

The original POF format is documented somewhat, but it's been expanded since then.

[Commander Zane]

I'd find it humorous if after another five or even another entire decade of the FSU Project it still played the same as it did since it first came out, it would be like playing Asteroids with X3: Terran Conflict's graphics.

[Narvi]

Hah, there isn't much in the way of polishing or expansion you could do to the actual gameplay.

FS2 got it right in one go.

[chief1983]

I'd find it humorous if after another five or even another entire decade of the FSU Project it still played the same as it did since it first came out, it would be like playing Asteroids with X3: Terran Conflict's graphics.

Something like this?

[portej05]

The original POF format is documented somewhat, but it's been expanded since then.

Has the whole thing been documented, and where can I find it?

(and the VP format, and the table formats, and the etc...)

[blowfish]

The best documentation you're going to find for POF structure and table files is the code itself.  As for VPs, the wiki may hold some answers

[portej05]

If that's the case, I'm not going anywhere near code that deals with POFs.

[blowfish]

It's pretty easy to understand the basic structure of the files, as well as the layout of many of the simpler chunks.  And this is coming from someone who isn't really a hard core coder   I'd imagine the structure of the BSP data is a little more difficult to understand, but that's another matter

[portej05]

The BSP data is read as a binary chunk from the POF file, and then hard coded offsets are used within those data blocks to navigate around. There's no formal documentation anywhere on the BSP tree (other than a brief explanation at the start of code blocks as to what it expects at each offset - but this changes function to function...).

Problem with just reading the code is that if you miss something during reverse engineering, you've wasted a lot of time, and you'll spend a long time defending your code (and ultimately, it'll be yanked out and circular filed).
Also, the POF format has changed (apparantly) since retail, which doesn't help things.

[Zacam]

The biggest change I think was Kazans additions (via PCS2) for SLDC chunks.

[portej05]

Which I'm guessing wasn't fully documented, it was just coded?

[Zacam]

We don't need no stinkin docs.

[Spicious]

Weren't glowpoints added at some point too?

You could always try traipsing through the pcs2 code as well.

[Nuke]

If that's the case, I'm not going anywhere near code that deals with POFs.

theres also the pcs2 source, which is a little bit better organized

[Fury]

Any chance of fs2_open receiving working SSE2/3/4 and x86_64 support to give our poor CPU's some breathing room while rendering engine is being overhauled?

[Nuke]

64 bit would be nice

[portej05]

64 bit would be nice

Can't happen without a fair little overhaul - there's a number f places in the engine that make assumptions about 32bit prcessors. Also, you can't use inline assembly in a 64bit build (so int 3 needs to be changed - DebugBreak IIRC)

[Spicious]

It needs inline assembly?