OMFG HAVOK WILL BE FREE IN MAY!

[Otherside]

trying to keep support for really old systems is making it a pita to get new features that will appeal to new users which are probably running newer systems as they will probably play other online games(TF2/left4dead etc etc)

[el_matarife]

And I'm not saying let's go out and deliberately break older PCs. I'm saying "We don't need to be so careful about requiring features that have been standard on PCs for several years now." Netbooks and nettops with the nVidia ION platform have really put affordable modern gaming in the reach of nearly everyone. And if you've got a PC with a PCIe slot there's tons of affordable DirectX 10 / OpenGL 3 compatible cards.

[AF]

SSE support is sort of basic, it was only disabled because Rattle threw the toys out of the pram (he shouldn't have gotten a via cpu anyway), and the SYs disabled SSE support accordingly.

SSE is ancient technology. Theres no reason we cant build SSE 2 3 and 4 builds of spring if only for single player. engine_sse4.exe etc

[Tobi]

There's no reason to do so though unless someone measures sse2, sse3, sse4 builds to be significantly faster then sse1 build. (which I doubt)

Otherwise it's just premature optimization, since targetting higher SSE versions doesn't make more features available for developers in a language like C++ (so it can never save us, developers, time. (unlike for example dropping support for fixed function OpenGL pipeline at some point))

[KaiserJ]

wow, something technical that i actually know something about...

havok is pretty interesting to work with, i used it in a bunch of projects using director 3d. however, it does require tweaking, as unexpected events such as heads of lettuce flying off tables are a common occurence.

certainly is CPU intensive and wouldn't work too well with spring due to the strain (ragdoll and similar complex physics effects are really cool but i dont think their benefiets would outwiegh the performance drawbacks) but it's a heck of a nice thing to work with for FPS sorts of application... and hey, if kaiser was able to write compatible code, then ANYONE can probably do it.

[el_matarife]

There's no reason to do so though unless someone measures sse2, sse3, sse4 builds to be significantly faster then sse1 build. (which I doubt)

What's the best way to benchmark some experimental builds? I assume we could get buildbot to build us some MinGW 4.4 SSE2, SSE3, and maybe an SSSE3 build. I doubt we'll be able to require SSSE3 for a long while, but SSE3 may be plausible in another year or two. (Assuming when you said SSE4 you meant the 16 instructions Intel added on the Core2Duo usually referred to as SSSE3 http://en.wikipedia.org/wiki/SSSE3)

(unlike for example dropping support for fixed function OpenGL pipeline at some point))

The real barrier here is Intel's LOUSY OpenGL support. They don't even support OpenGL 3 on their newest chips and I'm willing to bet they probably never will. They'll write a software rasterizer for Larrabee that does DirectX 10 / 11 and OpenGL 2.1 and call it a day. Then the Larrabee will get ported to desktops as integrated video a year or two down the line still lacking OpenGL3 support.

http://en.wikipedia.org/wiki/Intel_GMA# ... d_chipsets

Would an OpenGL 2.1 pipeline be easier to maintain? That at least might be vaguely plausible at some point soon.

[Tobi]

It's mostly that it's easier to write new code of you can assume OpenGL 2.0 or 2.1 and/or write without fixed function pipeline at all.

For maintaining old code it doesn't really matter I think.

[jK]

We didn't had a 20% performance increase when enabling SSE, so we won't with SSE2,SSE3,SSE4,...
SSE is very complex and needs a lot of developer time to make usage of it, that's why many app's write performance critical stuff in ASM.
Just enabling a compiler flag doesn't here at all ...

IMO dropping Intel support in the future isn't that worse, their chips aren't able to run any commercial products why should we support them?! But that affects only new code, so only huge internal changes like a new map system & unit/object rendering system would break the compability with those gpus (it would affect also very old gpus w/o shaders etc.).

[el_matarife]

I'd suggest dropping support for pre-OpenGL 2 or 2.1 cards in a heartbeat, but all those new netbook systems with Atoms have the GMA 950 which only does OpenGL 1.4 and doesn't even have hardware vertex shaders. Intel has really put us in an awful spot, either Spring drops support for millions of brand new systems or you're stuck writing for fixed function for several more years.

Maybe we should try releasing a version of Spring that deliberately breaks on OpenGL 1.4 cards, then quickly release a patch while taking stock of the number of complaints. Pretty evil, I know, but how else are we going to get an accurate count of systems that would break? I really doubt a good hardware survey is in Spring's future, unless one of the lobby developers writes one and it asks to submit computer specifications on startup.

[Das Bruce]

Are netbooks really part of the target demographic? They never really struck me as gaming machines.

[el_matarife]

Are netbooks really part of the target demographic? They never really struck me as gaming machines.

I saw a thread in general discussion asking about running Spring on a netbook. My guess if that if people want to game on one, they'll buy something with the nVidia ION or whatever AMD comes up with. Unfortunately, some people may buy one then say "Hay I bet I could run Spring on this" then get really disappointed when it doesn't work.

[Journier]

neddie ran spring on a netbook with atom, it could barely run it at minimum settings.

i dont think youd lose alot of player base by losing that.

[hoijui]

well.. just want to say i am totally against that, breaking support for older systems and netbooks -> baaad!
first of all, at least 9 out of 10 netbooks have the intel platform. i have one too, and i plan to develop on it from time to time. i dont care if i ge 5 FPS or less, and that the map turns out white doesn't matter either.
well.. i understand that with this i am probably the only one, and therefore it is not a real argument.
BUT guys, you seem to miss the second and third world, where everyone has low budget cards, and you know.. even if they have the money, and will to spend it for on thier PC just to play games(spring) better/at all, a lot of ppl dont know that you can change computer parts, or they have notebooks...
these changes you suggest here are just not worth loosing these people, just for a 1% increase in FPS on a high end system, or some more graphic shiny stuff. One of hte most important advantages of Spring over SubCom for example is, that i can play it on all my systems, and SupCom only barely on one. We should rather extend old system support, then remove it!

[AF]

Can we not have the best of both worlds and use ogl 2.1+ for all new stuff and just have those who cant do it run in compatibility mode using only the basic stuff that uses 1.4?