[Flaming_Sword]

Hi.

I'm about to bite off way more than I can chew - i.e. overhauling the interface.

In case you're wondering, yes, I've gone quite insane.

Obviously, this thing is going to be quite big, so I was wondering if I could get a branch of Antipodes to play with.

Planned task list:

• Learn C++
• Making code not suck
  
  • Consistency
  • Modularity
    
    • Frontend/backend separation
    • Preparation for eventual rendering overhaul (swapping out of backend code)
  • Reduction of hardcoding
  • Rework of EFF support along lines of new code
  • Loading time optimisation (particularly with new EFF code)
• Alternate TBL configurable interface
  
  • Based on features/goals from The_E's scripted interface
    
    • Compositing
    • "Widget" styles - screens assembled on the fly - including possibility of random background image each time
    • Widescreen support (removal of ugly stretching of the interface)
    • Animated screen transition effects - e.g. elements sliding in/out like in starcraft interface
  • HUD overhaul (sorry Swifty)

Pros:

Interface code won't suck (as much)

Cons:

High risk of things breaking - hence Antipodes
Long development time due to the scope of the project

Tell me if this is too crazy.

EDIT: amended task list

[FreeSpaceFreak]

I like it

Suggestion: a transparent interface screen background, with an EFF playing behind. Imagine, say, a command briefing with the Bastion flying by in the background. In order not to use this feature, modders could just make 0-Alpha screens (as it's been up till now) or a single-frame EFF background. Also, an animated mainhall possibility would be nice. (If the development time is long indeed, PCs will be able to handle that when it's implemented )

Another suggestion, perhaps not entirely related, is SEXPs for mainhall change (the current way of switching mainhalls is rather vague) and for entire interface change; would be useful for campaigns where the user switches factions in the middle.

[Flaming_Sword]

Currently, the code is horrible enough to make large EFF backgrounds unworkable. I should have a better idea of what's possible when I'm further along. However, it should be perfectly possible to say, have a small window in the background that shows the Bastion animation.

As for your other suggestions, the mainhall already has miscellaneous animations that fire periodically (or one-off). For example, the ships flying past the window in the top right corner of the Terran mainhall.

Mainhall switching, and even interface style switching should not be a problem. All I have to do is write the code...

[Tolwyn]

Me likes the idea of eff support for the HUD.

[Fury]

I seem to remember Flaming_Sword mentioning on irc that when he converted main hall animations to eff/tga, they loaded really slowly compared to the anis. Wouldn't there be significant loading time and RAM increase if all HUD elements would be converted to eff/tga or eff/dds?

[The E]

Yes and no. If you convert the anis in the standard mainhall to eff, they take up about 180 MB of HD space. This will, of course, increase loading times significantly.
Memory usage, however, seems slightly better. For comparison, the retail mainhall uses ~200 MB of RAM initially, which later drops off to ~77 MB.
The eff mainhall, while slower to load, uses only a constant amount of ~64 MB.
For reference, I used u1555 dds files.

[Fury]

Is there no good compromise between uncompressed DDS/TGA and compressed DDS? Because frankly, uncompressed DDS is so bloody big it's stupid. Has anyone experimented on DDS compression levels if there is any level suitable for interface without noticeable compression artifacts?

[FreeSpaceFreak]

DXT3 is alright, from what I've seen... DXT1 has a lot of artefacts when converting old PCXes, DXT3 somehow doesn't. Or I just didn't notice them

[Fury]

JPG support has many times been considered as a stupid move, but what about PNG support? I think it could be a viable alternative to TGA where DDS cannot be used due to unsupported dimensions, but where compressed image format could be used.

[Flaming_Sword]

This might be something for any loading/rendering overhaul, and outside the scope of this project.

I have planned (and started writing) in such a way that almost all the code (apart from backend rendering functions) is independent of the rendering code.

Hopefully, this will make future rendering changes easier i.e. it won't break the interface (much).

The_E has successfully tested u1555 DDS files for EFF to replace the retail ANIs, so that could do with some investigation.

[Tolwyn]

I did not notice any loading issues with my mainhall. Granted, it's less complex than the FS2 mainhall at the moment and my system has 8 GB of RAM.

[Aardwolf]

Item #1: Learn C++

 

[Goober5000]

I'm about to bite off way more than I can chew - i.e. overhauling the interface.

In case you're wondering, yes, I've gone quite insane.

[...]

Tell me if this is too crazy.

You seem to be telling yourself just fine.  Why don't you listen?

Yes, not only is this crazy, it's insane.  Especially for your first task after learning C++.  I recommend starting with something much, much smaller.

[Swifty]

# HUD overhaul (sorry Swifty)

What is this supposed to mean anyway? Are you going to rewrite the HUD yourself as well?

[portej05]

# HUD overhaul (sorry Swifty)

What is this supposed to mean anyway? Are you going to rewrite the HUD yourself as well?

As I understand it, there's some bits of his interface code that are applicable to the HUD code.
I don't think he wants the HUD as well!

[Flaming_Sword]

I'm about to bite off way more than I can chew - i.e. overhauling the interface.

In case you're wondering, yes, I've gone quite insane.

[...]

Tell me if this is too crazy.

You seem to be telling yourself just fine.  Why don't you listen?

Yes, not only is this crazy, it's insane.  Especially for your first task after learning C++.  I recommend starting with something much, much smaller.

That's half the fun!

Joking aside, I see this as a long term project to work away at while I learn. I figured that already knowing C makes it remotely doable. That and the current code bugs the hell out of me.

If you're worried about my ability you can take a look at the little interface fixes other people have committed to Trunk on my behalf as well as the code I've written for Antipodes #3 (which this is based on, by the way). Of course, Antipodes #3 is written in C and is nowhere near the scale of an interface overhaul. However, I like to think I have become a little familiar with how the current interface code works by digging through it while adding EFF support.

Care to suggest something else of a more suitable scale to work on in the meantime?

# HUD overhaul (sorry Swifty)

What is this supposed to mean anyway? Are you going to rewrite the HUD yourself as well?

As I understand it, there's some bits of his interface code that are applicable to the HUD code.
I don't think he wants the HUD as well!

I'd rather avoid the HUD, yes. Most likely what will happen is that I will modify your work to make it compatible with mine (or vice versa). If yours isn't out (or at least substantially complete) by the time I get up to it, then and only then will I rewrite it myself.

[Zacam]

Here's an idea. PNG support for the interface.

1024x768: You can have a 2.25mb TGA or Uncompressed DDS, or a compressed DDS that looks close to the 522 kb PCX screen you're replacing. Or you can have a 274 kb image with the same quality as the DDS and still support transparency where needed.

[Flaming_Sword]

I would like to add that this would be largely independent of the interface rewrite.

It would also actually have a chance in hell of actually being finished.

[Flaser]

Here's an idea. PNG support for the interface.

1024x768: You can have a 2.25mb TGA or Uncompressed DDS, or a compressed DDS that looks close to the 522 kb PCX screen you're replacing. Or you can have a 274 kb image with the same quality as the DDS and still support transparency where needed.

There's little point to this. PNG is not natively supported by videocards so you won't use less VRAM. On the other hand DDS is therefore can be stored in a compressed format in VRAM.

[Flaming_Sword]

Here's an idea. PNG support for the interface.

1024x768: You can have a 2.25mb TGA or Uncompressed DDS, or a compressed DDS that looks close to the 522 kb PCX screen you're replacing. Or you can have a 274 kb image with the same quality as the DDS and still support transparency where needed.

There's little point to this. PNG is not natively supported by videocards so you won't use less VRAM. On the other hand DDS is therefore can be stored in a compressed format in VRAM.

I think the point here was not to have 131mb of TGA/DDS for a new interface in each mod that features one. How much VRAM does an interface screen take up, anyway?

* Flaming_Sword shrugs