Spring for low-end and buggy GFX

[SpliFF]

Just thought I'd mention I started a project this week to make Spring playable on the new kernel OSS radeon driver. Although Phoronix gave Spring a Silver rating and says it works I've actually discovered the kernel "Command Stream" filter throws a bunch of errors after "Finalizing..." on my x1950xt and kernel 3.0.4. I'm almost positive it's S3TC/DDS related but could also be an issue with a shader or the FBO implementation.

It's difficult to catch the source of the error because the CS errors just log to dmesg and continue rather than "crash". That makes getting a proper backtrace tricky. I have discovered a drm.debug kernel option which I'll be trying as well.

Since I'll be digging into the Spring graphics stack I've decided to go further and make the GFX stack more configurable for "very low-end" GFX.

The process I've planned is to:

1.) Add new config options that explicitly disable shaders, S3TC, FBO's and DDS (the "LuaShaders", "AtiHacks" and "Compress Textures" options do not provide enough control). In the case of S3TC I'll either replace the texture with a standin texture (won't be pretty, but at least you can play) or uncompress the texture via OpenIL if possible. In the case of shaders I'll either disable the shader entirely or use a simple noop shader replacement.

2.) Add a new "Shaders" log section with lots of debug logging so I can try and find exactly what the CS parser is bitching about.

3.) Add an option that will allow the "Far Textures" implementation (which flattens 3D objects into billboards) to affect objects right up to the camera (user configurable of course). In practice this means units will be rendered as 2D sprites.

4.) Add an option that renders the map as a 2D billboard and allows spring to be played in "2D" from a top-down camera.

5.) An option that disables the teamcolor and tex2 shaders. Teamcolor can be handled with a widget like teamplatter or by looking at unit icons.

6.) An option that disables unit visuals altogether and ensures unit icons are always visible (only useful with games that provide clear unit icons). Might also need games to provide some generic icons for wrecks, resources, etc.

The combination of these options should reduce polygon counts and hardware requirements by a significant amount. The goal is not only to resolve the radeon issue but also to make Spring playable on IGP notebooks that would otherwise handle the CPU load but fail on graphics support.

I guess the question might be asked why anyone would want to play Spring with such a degraded graphics state. I have several answers to that.

1.) TA ran on significantly reduced requirements and it was still a very enjoyable game. There are also 2D RTS like C&C that were enjoyed by millions. If players wanted the latest glitz they'd be playing SupCom 2, DoW 2, C&C:Generals, etc rather than Spring.

2.) While spring has many gameplay features that are "3D-aware" most games are still essentially 2D games and are probably quite playable from a 2D overhead perspective. Also as a strategy game it usually isn't that critical to know what a unit looks like, only what it is. SupCom was quite playable from "strategic zoom" due largely to its good selection of unit and resource icons.

3.) AI and script development. If you're just messing around with AI and scripts the visuals probably aren't that important. This would let you script on the train or whatever using a crappy laptop rather than always needing your desktop.

4.) Running Spring in a VM. This may be useful for testing on in rare cases where the user can't run/compile spring on their primary OS. VirtualBox and VMWare both have limited 3D support that may be able to run a degraded Spring but not a "full" Spring.


So that's it. I'm hoping to achieve most of my goals in a fairly short window of a few weeks so I don't have to spend too much time merging other peoples commits (that was an issue with assimp).

If anyone wants to volunteer as a tester or provide their own solutions and suggestions I'd appreciate it. I'll be regularly pushing updates to my GitHub repo so you can track and test my work.

[smoth]

I wish I could but I don't really own a lot of low end anything. I have a really old windows xp laptop if that can help..

[AF]

If you post builds I'd be happy to give them a whirl.

If your faffing around with the map renderer, a map format that had no heightmap, metalmap, typemap, texture, etc, that merely took a name, skybox and a height width and depth, would be useful.

What could also be useful is caching the 2D billboards or allowing them to be included, so that when 2d billboarded units are enabled, we can have faster loading times

SpliFF's github account is here: https://github.com/SpliFF

[hoijui]

cool stuff!
even though i would like most to first see a proper separation of GFX from the rest, which would make all of this much simpler and architecturally nicer and more optimized. you would just add one or multiple additional renderers (implementations that include handlers for rendering everything).
that is not a few weeks thing of course.
so.. good luck!
i have a single code atom netbook with Intel 945 GFX for testing.

[MidKnight]

I have access to an HP tc4400 and a Mini 110. Drop me a line and I can test stuff out for you.

Best of luck!

[FLOZi]

IMHO 4, 5, 6 are game design choices, not user settings.

[SpliFF]

Those modes are intended to be used primarily when running a game on old GPUs, IGPs and software rendering that wouldn't otherwise handle the polycounts. It's more about providing a fallback rendering mode than enabling new forms of gameplay. Since teamplatter is a widget it wouldn't be game-breaking for a user to have no teamcolor shader.

I think only option 6 is really dependant on game support. 4 and 5 should really just be considered degraded rendering. If a game actually wanted 2D maps and units that game could simply provide 2D maps and models.

Unless you mean games might not want users to have access to these options but I'd consider that position unreasonable. I can't imagine how rendering in 2D would be cheating and I can't imagine why a user would enable that mode unless they couldn't run in full 3D. In that case it's a choice of "2D" or nothing which is really no choice at all.

[CarRepairer]

Those modes are intended to be used primarily when running a game on old GPUs, IGPs and software rendering that wouldn't otherwise handle the polycounts. It's more about providing a fallback rendering mode than enabling new forms of gameplay. Since teamplatter is a widget it wouldn't be game-breaking for a user to have no teamcolor shader.

I think only option 6 is really dependant on game support. 4 and 5 should really just be considered degraded rendering. If a game actually wanted 2D maps and units that game could simply provide 2D maps and models.

Unless you mean games might not want users to have access to these options but I'd consider that position unreasonable. I can't imagine how rendering in 2D would be cheating and I can't imagine why a user would enable that mode unless they couldn't run in full 3D. In that case it's a choice of "2D" or nothing which is really no choice at all.

'Nothing' might be the better choice. If using one of these modes completely breaks gameplay then it's better the user doesn't get a bad impression of the game.

[KingRaptor]

I don't really see any of these as fundamentally altering gameplay, and the user should know what they're getting into with (properly labelled) ultra-LQ settings.

[FLOZi]

Car made my point better than I could.

In all honesty my personal view is that making Spring more accessible to people who already have hardware they shouldn't be trying to run it on is not a good direction to take.

It's brutal, I know; but just how feasible is it to provide these ultra-low options without (further) holding back advancements at the top end?

[knorke]

It is for devs not for players. So you can play MP testgames with your desktop PC vs crappy laptop that usually can not run Spring, stuff like that. If somebody has a use for that, why not add it.
I dont think SpliFF will add a checkbox "[x] make spring really ugly" that players accidently check all the time
More like some obscure variables in springsettings.conf that normal players never notice.

[jK]

Car made my point better than I could.

In all honesty my personal view is that making Spring more accessible to people who already have hardware they shouldn't be trying to run it on is not a good direction to take.

It's brutal, I know; but just how feasible is it to provide these ultra-low options without (further) holding back advancements at the top end?

So true.
We already have enough trouble with the FFP rendering and it will take ages to replace them with GLSL. Adding even more of this just makes the code even more unmaintainable.
Also as already said all these things are game design decisions, so if you want those things you should start a new game project and code them in lua.
Not to forget that (2), (3) & (6) are already in engine, (5) doesn't make sense and (1) is invalid, too.

The wish to have a better experience with gallium drivers is noble. Still you try to solve the issue from the wrong end, you should:
1. encounter the bugs and what triggers them
2. then try to find a workaround
3. write small minimal demo to trigger the bug
4. send it to the gallium devs

PS: Making shader code optional is _totally_ wrong, the opposite way is to go. Also `Battlefield 3` has a 8800GT as _minimum_.

[SpliFF]

a.) It is feasible to disable features without adding complexity. We already do it for bump water, compressed textures, clouds, decals, lua shaders, 3D trees and shadows and we even expose the options to end users. If we didn't the Spring community would be even more decimated than it already is.

b.) We are not a high-end commercial game. It is unreasonable to follow the same approach of locking out low end users. EA's goal is to make lots of money and then abandon the game. Our goal SHOULD be to pick up the users the commercial games abandon (like mac and linux users) because we cannot complete head-to-head with studios having multi-million dollar budgets and teams of programmers working 30 hours a week with a room full of hardware and hordes of willing beta-testing slaves. Most of the Spring community are here entirely because an old commercial game was abandoned.

c.) Some devs are far too quick to push compulsory GLSL into the engine. It seems to me it gets tested on Nvidia under Windows 7 and Ubuntu then considered stable. When it fails on ATI you blame ATI. This is a consistent trend around here that's resulted in Spring becoming essentially unplayable on ATI, doubly so for OSS drivers. I woudn't be surprised to find that much of the code that sucks on ATI is explicitly discouraged by ATI due to the underlying hardware not being optimised for the case. In a perfect world everything would be OpenGL 5.0 compliant but it's not a perfect world.

d.) Regardless of your opinion on ATI products they are widespread, so is Intel IGP. Any effort to make spring playable on this hardware should be welcomed. Some attitudes around here are essentially the old Microsoft vs Netscape arguments where if it works on IE it must be Netscape that's broken, and vice-versa. I was designing websites in that period and the only practical approach was to design and test for both, regardless of your feelings. Anything less is a giant fuck-you to 50% of your users.

e.) Despite all the ATI bashing that goes on here I've found both the x1950xt and the HD6890 I own to be reliable and fast on every free and commercial game I've played EXCEPT Spring (I also own or owned many Nvidia products like the 8800gt so I have a point of comparison). It seems to me that the issue has more to do with the fact that ATI is a dirty word in this community than any technical failings. If as much time was spent fixing ATI issues as is spent insulting the buying decisions of every ATI user who raises an issue I'm sure they could have been resolved a long time ago.

f.) Yes, I will be reporting bugs to the DRI list but it's not practical to assume they'll be fixed in a reasonable timeframe. The whole mesa infrastructure has undergone some radical changes in the last year and will go through more when Wayland arrives. It's unlikely a complete and stable OpenGL 4.0 + GLSL implementation will arrive for a couple of years. What I'm proposing are sensible workarounds to this situation rather than wishful thinking or advice to go buy other products.

g.) Insisting people only play your game at high graphical settings is just rude and not particularly OSS friendly. The whole spirit of OSS is to provide users the right and ability to modify and use a program in a way that suits them. I utterly despise the idea that options be removed from the engine because a particular game maker wants everyone to see their latest bling regardless of whether that makes the game unplayable. It's utterly absurd because if someone can't even play your game then the quality of the graphics is entirely irrelevant.

h.) I'm not suggesting low-res be the default option. Anyone disabling a particular feature will know they're doing it and presumably they'll also know why.

i.) TA is about 15 years old now and it still looks better than most Spring games. It also runs on a TNT2 and handles about 6000 units on a P4. I find arguments that the Spring Engine NEEDS more high-end OpenGL features to be a trap. At what point do we have enough engine-side bling that we can stop breaking hardware compatibility?

j.) Spring's biggest issue is not a lack of bling/shaders. Spring's biggest issues is a lack of content and players. I can't believe people are seriously suggesting we artificially exclude players for ANY reason other than because they're making a nuisance of themselves in forums/games.

k.) The largest growth segments in PC hardware are notebooks, netbooks and tablets. While I accept that many run on ARM or lack sufficient CPU power a large percentage of this market, particularly most notebooks, have ample CPU power but lack a dedicated (or decent) GPU. Since most commercial RTS titles will not run on this hardware it's another segment Spring could fill if we weren't so obsessed with chasing the high-end.

l.) Regardless of the need for end-users to have these features it is important for developers to have them. Right now it's a pain to even determine what's causing my issues because I have no simple way to disable particular GL features.

m.) 2, 3 and 6 may be in the engine but they do not appear to provide enough control or information. For instance I can't find the option to set the far texture distance or unit hiding right up to the foreground. Last I checked they were locked to a particular range based on camera height. I was never intending to re-implement these features - only improve/extend them as required.

n.) If the Spring developer community universally feels that constantly chasing after the high-end is a smart move then you better tell me now. I don't want to fork but since Spring already does everything I need for my own projects I'd rather spend my time making my game accessible and stable. I can't do that if Spring breaks every time some new thing comes along and some developer decides to add it to Spring as some kind of pet project.

[AF]

I find the whole notion that this is something for the game maker to decide utterly absurd.

If a user has chosen to flatten their 3D world and play in 2D for the sake of hardware performance, then surely that's something for them to decide. Else we might as well start saying Spring Tanks was designed for Bump mapped water and will not play the same if that bump mapped water is turned off. I fully expect Knorke to agree with me on this example ( and I fully expect a special bump mapped water only edition that adds a 'bump mapped only' sign ).

Also:

HOW DARE YOU DENY ME THE ABILITY TO MAKE UBER LOW END 2D GAMES

[smoth]

If a user has chosen to flatten their 3D world and play in 2D for the sake of hardware performance, then surely that's something for them to decide. Else we might as well start saying Spring Tanks was designed for Bump mapped water and will not play the same if that bump mapped water is turned off.

wild exaggeration of the situation.

Fact of the matter is, if they cannot run the shaders, the probably choke on units trying to pathfind or any other sort of thing which TANKS spring's fps.

I can completely understand what spliff is saying from a developer point of view.. but for the players, no we need to straight up start setting fucking requirements: *YOUR PC IS TOO CRAP FOR SPRING* and spring closes.

period.

[AF]

In these cases how are we to determine a machine with terrible integrated graphics that has the capacity to run the game simulation at a half decent rate ( or better ).

Im sure that for some games minimum requirements will always be higher than the engines because of lua widgets shaders and other items.

Just keep in mind that this is an exercise in double standards

Claim: "We cant add XYZ to BA because it wouldn't work in BA"
answer: There's more to spring than just BA, if you don't want it, don't use it.

Or rather:

claim: "We cant add XYZ to the engine because it wouldn't work in my <insert game here>"
answer: There's more to spring than just your <insert game here>, if you don't want it, don't use it.

[AF]

I can completely understand what spliff is saying from a developer point of view.. but for the players, no we need to straight up start setting fucking requirements: *YOUR PC IS TOO CRAP FOR SPRING* and spring closes.

Spring is an RTS engine not a game. You set the requirements for your game.

[Kloot]

a) and yet every feature adds a code path to test, debug and maintain over time --> extra complexity

b) which is precisely why WE need fewer code-paths, each well-tested, not more

c) how many devss are there? how different many OS/hardware combinations exist among those devs? should they have to test on other platforms than their own, in addition to providing a free product in their free time? who pays for those?

d) we are not in the business of writing hacks and workarounds for every ATI or IGP bug, which you have clearly no experience with _at all_

e) 1) guess what, we can't "spend as much time fixing ATI issues" because we are not one of those "studios having multi-million dollar budgets and teams of programmers working 30 hours a week with a room full of hardware and hordes of willing beta-testing slaves", nor is it our responsibility to; 2) you are conveniently ignoring the major collection of ATI fixes the engine already contains so you can throw a bunch of BS in our direction, don't expect to be listened to in the future

f) the sensible approach for any developer, commercial or otherwise, is to not to be steered into making decisions by deficiencies in third-party code like drivers or by pressure from minority groups like people with inadequate (even by standards far predating 2011) systems

g) 1) granting the right to use and modify a program != being required to cater to the wishes of everyone who uses it, 2) insofar as we insist on a reasonable minimum baseline, it is because this is a 3D RTS GAME ENGINE for which certain assumptions about the scope, quality and capability of user hardware are allowed and necessary to be made, FOSS or not

i) 1) what Spring NEEDS is for code to be (re)written with the modern way of doing things in mind, which happens to be one of the reasons for "pushing compulsory GLSL into the engine" (none of it is in fact compulsory, so argument disproven); the same was true of TA 15 years ago; 2) at what point do we stop caring about the hardware we break compatibility with? after 5 years? after 10? 15? never? who maintains all the old code to keep compatibility intact, you?

j) and the lack of content would be addressed through these options how? by an imagined horde of now-excluded players that would start producing it en-masse if ony they could just run Spring degraded to the point of a commandline client on their machines?

k) unless someone is actively planning to port Spring to such an architecture (and there are no such indications, probably because it involves a lot of work that as usual nobody wants to do), it makes no sense to insert code on any hypothetical basis like this one

n) you have been told by two now that it's not worth the effort or such a good idea to support the extreme low-end, but don't seem to be getting the message --> do what you want, we obviously can't stop you through rational discussion

HOW DARE YOU DENY ME THE ABILITY TO MAKE UBER LOW END 2D GAMES

you are kindly referred to http://openra.res0l.net/ (which amusingly only has shader-driven rendering paths, HOW DARE THEY BE MODERN WHEN THEIR ENGINE MERELY RUNS CONTENT FROM ABANDONED OLD COMMERCIAL GAMES -- OH WAIT)

[smoth]

*edit*
you know what, What kloot said.

[jK]

I woudn't be surprised to find that much of the code that sucks on ATI is explicitly discouraged by ATI due to the underlying hardware not being optimised for the case.

Erm I read ALL published gfx related papers I get. So I know very specific what ATi advises and I even respect those things when I code. Still none of the bugs Spring triggered in ATi drivers were ever listed in any paper (except perhaps the POT issues).
And if they advise something, then it is to switch to a 100% shader-based renderer!!!

Regardless of your opinion on ATI products they are widespread, so is Intel IGP.

Oh my printer got a display! Spring must run there too!
Seriously, subnotebooks are widespread too. And 80% of them aren't even able to play Telltale games! Should we support them too?
Other project (including commercials!) exclude those not w/o a reason!
Like them we have to agree on minimum req. and for a _3D_ engine it's obviously that the machine must support rudimentary 3d capabilities at decent speeds.

If as much time was spent fixing ATI issues as is spent insulting the buying decisions of every ATI user who raises an issue I'm sure they could have been resolved a long time ago.

Who attacks the devs every month for their ignorance?
Who comes every month with a new forum thread what he wants to change?
YOU are wasting time instead of fixing/workarounding ATi bugs!

It's unlikely a complete and stable OpenGL 4.0 + GLSL implementation will arrive for a couple of years. What I'm proposing are sensible workarounds to this situation rather than wishful thinking or advice to go buy other products.

Removing things or replacing them with 15yo render techniques are no workarounds.

Insisting people only play your game at high graphical settings is just rude and not particularly OSS friendly.

No one said that. You can have one renderpath with multiple knobs to influence the performance (particlecount, terrain detail, ...).

Regardless of the need for end-users to have these features it is important for developers to have them. Right now it's a pain to even determine what's causing my issues because I have no simple way to disable particular GL features.

YOU GOT THE SOURCE!
You talk walls of text why you want to change stuff, but aren't even able to read/understand/modify the source? This explains even more why you write these walls instead of fixing the bugs ...

For instance I can't find the option to set the far texture distance or unit hiding right up to the foreground.

-> /distdraw 0


+ everything what Kloot said