[Aardwolf]

So, it seems that the FSO rendering engine is kind of outdated... even with the fairly recent addition of GLSL support, it fails at many simple things like proper draw order / depth sorting.

I, for one, believe that it would be better to attempt a ground-up rewrite of much of the rendering code, rather than be limited by the capabilities currently available, and having to deal with increasingly messy code as small patches and improvements begin to mess with each other. The idea is to do a big project now rather than suffering indefinitely from the obsolescence of the rendering engine.

I believe this is doable, mainly because it was done to give FSO OpenGL support.

Discuss.

I personally have a decent amount of experience with OpenGL, so I could in theory assist with such an endeavor, but since I'm in a year-round college, even during the summer I can only offer freelance contribution...

[redsniper]

Have fun.

[The E]

I am The E, and I like this.

First thing to do then would be to identify all the data that goes into the engine from the AI, player handling etc., as well as finding out what data it sends back out. Don't know a thing about rendering engine code, though, so I have no idea how much work would be involved...

[Aardwolf]

Seems you don't know exactly what I'm talking about. 

[Fury]

Lately inefficiency of texture rendering in fs2_open has been revealed to me. If anything, that part of the code needs serious overhaul. But like almost everyone here, I can't help at all.

[Nuke]

i think its something that should be done. but nothing im qualified to work on.

[Tolwyn]

I think one should fix existing bugs first before taking on a greater challenge.

[Nuke]

what if the ancient rendering engine is the source of those bugs? i mean you can spend time debugging old, inefficient, poorly organized code, or you can use the time to re-code things which should have been deprecated years ago.

[Nighteyes]

I totally agree
"stupid" things like not rendering large frame effects properly, not being able to have differant blending options for effects, and using to many resources to render a them...

[Tolwyn]

What you say would apply if at least gameplay affecting bugs are fixed. Which isn't the case.

[TrashMan]

Since we're at this subject - if multile maps share the same normal map (or glowmap or shinemap), you still have to make a "different" one for each map, thus wasting much more memory and slowing things down.

Would it maybe be possible to somehow enable map sharing? (I dunno, like maybe a text file with the name of the "original" map, followed by the names of all other maps that share it's normals, glow or specular maps)

[portej05]

What you say would apply if at least gameplay affecting bugs are fixed. Which isn't the case.

That said, sometimes we're having trouble tracking down those monsters - there's apparantly a laundry list of multi issues to look at soon as well (including behaviour changes from retail->FSO).

I'd support this endeavour - I had a look through some of the rendering code this afternoon and have barely recovered.

[Sushi]

If you do, it's branch time! And it would have to stay as a "branch" for a long, long time...

 IMHO it's probably not really feasible, since so much of the game and modding functionality is built around the current rendering engine, quirks and all. But I'd be happy to be proven wrong.

[Echelon9]

Such efforts would almost certainly have to be undertaken in the context of a 3.7.x (or similar branch), with the note that backwards compatibility would be deprecated where it conflicted with the interests of re-design and re-coding of a modern OpenGL engine.

[Flaser]

IMHO this is a *must* for the long term developability of the engine. However as of right now, there are no qualified coders to carry out. Moreover this will be a long term project with results at a far off time...

...so yeah, branch it is, and time to learn OpenGL in a C++ environment. Another thing that could be done would be the objectification/modularization of the existing code to better suit further development.

[portej05]

* portej05 dons armour and flak jackets, buys tank and thick concrete bunker

[castor]

Is it even possible to "rip out" the current engine and replace it with something better (the level of modularity that exists there)?
If it is, would it be possible to replace it with something that already exists?
If it isn't, won't the new engine be a mess too? Unless you rewrite a lot more than just the engine?

[DaBrain]

I had a look through some of the rendering code this afternoon and have barely recovered.

 

You just revlead that you have knowledge about rendering code... (run!)


But honestly, how should this be realized? When should the rewrite begin?

There are many more questions concerning this.
FS2 is multiplatform now, should we stick to OpenGL?
Which version? 3.0, 3.1, or the new 3.2?

I suppose we cannot just take another rendering engine with a suitable license and put it into the game without more effort than writing a new one.

[Fury]

I have this itchy feeling Kazan will burst in any moment now yelling "Told ya so!" while holding a neon sign reading "Ferrium".

[Mongoose]

You do have to wonder when conversation along these lines goes from "upgrading FS2_Open" to "coding a brand-new space sim engine."