dual monitor support

[Originway]

Can we get dual monitor support the way Supreme Commander does it?

[Jorzi]

That won't be an easy feature to implement, you would have to rewrite both the renderer and the user interface pretty much from scratch.

[Emdek]

Jorzi, rewriting of user interface would be useful anyway and in the preferred scenario "game scene" would be simply a "view widget" (as in MVC pattern) displaying data provided by single game model (so there could be more than one or none - like in dedicated servers).
But personally I think that best way to achieve that would be to start nearly from scratch, reusing some code (like network protocol etc.), core concepts and assets. All of them could be updated in the process to be more future proof and most important - easier to maintain (even "perfectly" working code is useless if it couldn't be easily maintained in long term).
Well, but apparently that is not going to happen since this would require a lot of work (mostly planning) and there would be big risk that such attempt would fail. So we should at least "slowly" (as evolution instead of revolution) cleanup current code and make it more modular, with stable API to let them communicate, not exposing implementation details if not needed, to allow to gradually replace them if needed.

[Rman Virgil]

......So we should at least "slowly" (as evolution instead of revolution) cleanup current code and make it more modular, with stable API to let them communicate, not exposing implementation details if not needed, to allow to gradually replace them if needed.

Yoggi Berra said it best - "It's like deju vu all over again." The exact strategy we arrived at some months before the source release in the Winter of 2004 (original community knew 6 months before the rest of the world did through the SlashDot official announcement). Confirmed emminently viable after release and actually followed through on in Chojun's 2200 fork from the original v.1.10 source code.
.

[Jorzi]

Unfortunately in open source it's always a compromise between what "should be done" and what people are actually doing. As well as the non-coders not really caring about what they don't see...

[Emdek]

Jorzi, not always, but surely too often.

[Jorzi]

Well, a small group can probably manage to avoid this, but in a group effort, one will inevitably be confronted by the following question: "This guy made a working patch that solves our problem even though it does not really conform with our coding guidelines, should we accept it?"

[Emdek]

Exactly, if it's possible then the perfect solution is one man project.
And the remedy for group effort is extensive planning phase, designing "perfect" API which hides implementation details and allows to work on different modules fully separately (at least before merging phase ).