Spring + decoupled renderer

[imbaczek]

if you feed spring with a script.txt as a command line parameter (like the lobbies do), it'll start the game without any user intervention. should help you with testing.

[Relative]

it might not have the blazing FPS it does in other games, but the actual performance level is far from 'poor', even if less than expected.

Well its still annoying that the 7000 and 6000 series perform better than the 8000 series by quite a large margin in FPS...

Anyway, although I understand very little about what's being said, good luck!

[Stealth870]

Quick question. If you split up the renderer (GPU stuff) with the gamelogic (CPU stuff) does that mean your project also opens the door a little more to someone who would like to do the same as you for the other half? i.e. Clean up the CPU code and perhaps add proper multi-core support or just general optimizations with less hassle?

[Felix the Cat]

If the renderer is completely decoupled, doesn't that mean that programmers could (if they wanted to) create different builds of Spring with different renderers that would have the same simulation? Doesn't that then mean that the discussion of "this engine sux lol" "no it dont it's awesome" "yes it does i can't run it on my comp from 97 its specs are too high" is a bit moot, since a low-spec and a high-spec version could theoretically be created and be compatible with one another?

[SinbadEV]

If the renderer is completely decoupled, doesn't that mean that programmers could (if they wanted to) create different builds of Spring with different renderers that would have the same simulation? Doesn't that then mean that the discussion of "this engine sux lol" "no it dont it's awesome" "yes it does i can't run it on my comp from 97 its specs are too high" is a bit moot, since a low-spec and a high-spec version could theoretically be created and be compatible with one another?

That would be between 4 and 7 kinds of awesome... depending on implementation. A full decouple could make dedicated servers easier, could allow much easier porting to other systems (Mac or a console system), could allow good multi threading support in such a way as to not lock up the computer when alt-tabbing... could allow specific renderers to be developed for ATI vs NVidia architectures.

[smoth]

Using Ogre or Horde might have a considerable CPU impact, because you have to go from spring -> opengl to spring -> general 3d engine -> 3D engine OpenGL implementation -> opengl

Spring is usually already CPU limited, so I wonder if that is a good move.
Plus I think you'd get a lot more credit for abstracting and refactoring the model rendering and then adding a better common 3D model format.

+9001

[AF]

Why none of you picked up on it earlier when he first mentioned dll's and so's is beyond me <_<

[Frans]

could allow good multi threading

I like that alot!

Also, having that fancy pipeing thing that required opengl2.x to work, that i also decided to skip over, also seems good, and having more then one renderer so you can support older computers as well also seems good.
also, not limiting ourselves to just opengl as well could be good... depends on how good stuff such as directx is.

[Relative]

directx

*Linux users rage against the dying of the light*

[REVENGE]

directx

*Linux users rage against the dying of the light*

Haha, nice reference.

[sparkplug]

for what it's worth, Ogre3d I've always found to be a fantastic engine. I'm not sure what was meant by it having functionality split among too many branches... There is only one main development branch, then (well thought out) independent plugins. Just because some other engine rejected it doesn't mean it was a good decision