Spring RTS Engine

Hi.

I would like to ask why in requirements is:

128 MB Nvidia Geforce 6xxx graphics card (onboard graphic cards are not supported)

Why onboard graphic cards are not supported?
There are some technical reason for that?
Is just question of missing implementation in spring?
Can I solve it somehow? (Like creating proper implementation to support that).


Thanks a lot for answer.

mtfk wrote:Hi.

I would like to ask why in requirements is:

128 MB Nvidia Geforce 6xxx graphics card (onboard graphic cards are not supported)

Why onboard graphic cards are not supported?
There are some technical reason for that?
Is just question of missing implementation in spring?
Can I solve it somehow? (Like creating proper implementation to support that).


Thanks a lot for answer.

Your question is kinda weird... the short answer is that Spring doesn't support most on-board video-chipsets because it doesn't... if you are asking if it was a design choice I don't think it was beyond "No one wants to bother putting in all the effort required to make Spring work on low end video hardware" ... The reason it works best with nVidia is that the majority of the early code contributors use nVidia and it works pretty well with most ATI cards because they are pretty compatible with the way nVidia does stuff. If you are wanting to try to make Spring work on low end-hardware and on-board chipsets I don't think anyone would stop you... but that part of the engine is pretty entrenched so even if you do the code you contribute may be not be accepted anyway.

I don't know about the current situation but at the time that was written on-board graphics cards were extremely primitive and simply lacked features Spring needs.

Appearently ati/intel drivers also suck and it would require working around their bugs. (this makes stuff harder to maintain)
See some threads like
http://springrts.com/phpbb/viewtopic.php?f=12&t=27003
or faq http://springrts.com/wiki/FAQ:trouble#T ... ooks_scary

Intel onboards still suck.

sinbad has it wutie wrong, nad KDR still gives mostly a wrong impression. knorke got it quite good.
think of it like this:
spring is like... a very good symphony orchestra (eg. the famous London one). you are a hill-billy farmer, and your integrated graphics card is your cow-stable.
now.. you invite the orchestra.. and they are actually comming, to perform in your stable, among the cows, withing.
when they start playing, and it sounds not as supposed, you get unsatisfied, and you start giving them tips, and trying to show them how to play.
it's the perfect simpsons story.

it is not the matter of spring, if spring does not run on your bad GFX card. try inviting AC/DC to your stable, and see what happens.

Thanks a lot for answers.

I just wonder how spring is build. Because nowadays there is lot of onboard graphics card which are really good (performance) so I wonder why spring does not support those cards.

I totally understand that some cards are really crappy.
But do You have some list of graphics card features which are necessary to run spring?

Because I want to create game base on spring engine and I just wonder how many graphics cards (and what kind of ) I could support.

Spring runs on my netbook. With an Intel 945 card, 1.6Ghz Atom processor.

But its not actually playable in any real sense. I can start a game, make a few units, screw around a bit. But not a 5v5 DSD

mtfk wrote:Thanks a lot for answers.

I just wonder how spring is build. Because nowadays there is lot of onboard graphics card which are really good (performance) so I wonder why spring does not support those cards.

I totally understand that some cards are really crappy.
But do You have some list of graphics card features which are necessary to run spring?

Because I want to create game base on spring engine and I just wonder how many graphics cards (and what kind of ) I could support.

it isn't about some arbitrary decision, it is about driver support for shaders, video memory and general power.

But if you stripped spring of everything.. the textures, the shadders, the sky the everything, you could make it..

So it is just question of good performance of graphic card not bad implementation or missing implementation.

I will test few graphics card and I will see how it works.
If You know if there is possibility to improve this part of engine for onboard graphics card just give me know.

onboard graphiccards is just a ly, accept it. Those are not graphiccards at all, just some additional chips, but they share ram with the mpu, and even rely on the mpu for some calcs.. so its basically what they called "software" rendering back in the old days.

We really do a lot stuff here to support old hardware (the devs can sing you a song on this one).. but some of those crippled onboards, they are just not worth the effort.

Onboard graphics chips are not for 3d applications. They are so you can make pretty powerpoint presentations and colorful documents in word.

Just because it has the ability to display something in 3d doesn't mean that it can do it well at all, and in this case, the specifications of onboard gpus are laughable and frankly, no one wants to support super shitty hardware. This is a full 3d engine. These are not flash facebook games. (Though technically with html5, lots of work and voodoo it would be possible to put spring in a browser window)

mtfk wrote:So it is just question of good performance of graphic card not bad implementation or missing implementation.

YES, congrats, spot on, 95.6 points!

mtfk wrote:If You know if there is possibility to improve this part of engine for onboard graphics card just give me know.

...
you the memento guy or something?

i guess you did not get it:
AC/DC s something like Supreme Commander.
try running supreme commander on your GFX card, and see what happens.
there are good reasons for that to happen, and thye can not be "fixed" in Supreme Commander.
.... your first sentence was right, rest is wrong.

if you want something as powerfull and potent as Spring, oyu will not find an other engine, or be able to make one yourself, or improve any engine that will work ok on any shitty GFX cards.
just use a more low-tech engine then.

hoijui wrote:just use a more low-tech engine then.

Total Annihilation Engine comes to mind.

I think the important point here is that Spring does not explicitly try not to support onboard gfx. It is more a consequence of these cards having insufficient performance or bad OpenGL drivers, that are incompatible with NV/ATI. You can play Spring on e.g. Nvidia ION, but that system does probably not have the muscles to handle a big game.

If you are going to play the normal 8v8 battles that take place every day you need a CPU that is roughly 50% as fast as a Core i7 2400K to keep up, and that is pretty fast. Gfx card wise you only need something average - even a passively cooled card works, if you pick a good one.

It's even like this: to make Spring run better on onboard/lowend NVidia/ATi GPUs you need to use more OpenGL3&4 features (cause those are a lot faster), but then you lose Intel&Mesa support (supporting both in the same code is nearly impossible).

Still nobody here is stopping anybody from forking spring code, and then do a complete rewrite. Its a free world.

The best way of fixing this is to start writing stable Intel drivers that actually work

I know this thread was rezzed by a spammer... but... good news for Intel chipset users

http://blogs.valvesoftware.com/linux/

Essencially... steam is coming to Linux which means that Valves developers are working on improving OpenGL support for Linux... including fixing the OpenGL support in Intel Graphics adapter drivers... conceivably this could mean that steam will "fix" whatever is wrong with the Intel OpenGL implementation which could... theoretically... make Spring run better on Intel graphics adapters under Linux.

They also have plans to work on the nVidia and ATI/AMD drivers apparently so we could all benefit.

Working with hardware vendors

We’ve been working with NVIDIA, AMD, and Intel to improve graphic driver performance on Linux. They have all been great to work with and have been very committed to having engineers on-site working with our engineers, carefully analyzing the data we see. We have had very rapid turnaround on any bugs we find and it has been invaluable to have people who understand the game, the renderer, the driver, and the hardware working alongside us when attacking these performance issues.
This is a great example of the benefits that are the result of close coordination between software and hardware developers and should provide value to the Linux community at large.