Spring for low-end and buggy GFX

[MidKnight]

I applaud your initiative, SpliFF, but I have to agree with everyone else that getting Spring to work with the very low end is an impractical eandavour.

Simpler engine code is good! Maybe you could do some optimization-bugfixing type work instead?

[jK]

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).

You aren't the first one having problems with it. But once you do it right, it becomes easy:

just needed once:
git remote add spring_master git://github.com/spring/spring.git

regularly:
git fetch spring_master
git stash push
git merge spring_master/develop #may ask you to fix merge conflicts
git stash pop
git push

[SpliFF]

jK. I just offered to do the work and you guys are basically telling me you won't merge it because I want to allow features to be disabled instead of spending the next 10 years of my life trying to push fixes through Mesa. You continue to dismiss supporting Intel IGP despite them being standard in 95% of laptops and having minimal shader support. I accept that ATI are pushing for shader based implementations but then their priorities are to sell new GPUs, not support older ones.


Kloot, I have no issues with having a rational discussion. What's happening here is a difference of opinions/priorities. If you've made up your mind that removing FFP code from the engine is essential to future maintenance then I'm certainly not expecting you or jK to maintain it.

On the other hand, regardless of your reasons (or my ignorance as you insist on putting it) I still feel strongly that targeting the "primary" gaming market (high-end desktop) at the expense of other potential targets (mobile computing, work/school machines, second-hand pc's, poorer communities, "family" computers, pure OSS systems, VM's, etc) is a mistake. It puts Spring games into direct competition with hundreds of proprietary RTS games that already provide a better visual experience. Ultimately though I'm firmly in the "gameplay before graphics" camp when it comes to RTS games. If a solution to making Spring playable on low-end machines meant rendering the entire game in gouraud shading or sprites I would support it.

My proposed solution is not to create a bunch of new code - my solution is to make some existing features optional and in some cases remove some hard-coded restrictions. I honestly didn't expect this much resistance since most of the changes I'm proposing should be trivial to implement (or in some case already implemented as you and jK point out).


smoth, MidKnight: Crap GPU != crap CPU. Some of the most powerful computers in the world have no GPU. In a more realistic scenario it is VERY common for a dual-core notebook to come with crap onboard graphics (Intel GMA, Radeon Mobility, Nvidia Go/M series) unless you specifically purchased it for gaming.


Anyway, we seem to have reached a crossroads in our priorities and I don't suppose any amount of arguing is going to change your minds at this point. The only reasonable course of action I can see is to either:

a.) Create a "low gfx" Spring fork and host it independently to give game devs a choice of engines.
- or -
b.) Switch to another engine like Warzone2100 that better aligns with my priorities and runs perfectly on my 1950xt/KMS setup.

This is not at all a position I wanted to be in but I really do feel that strongly about this. At the end of the day I have a game in development and I want it to reach the widest possible audience. I don't see that audience being exclusively a bunch of spoilt rich kids on Windows 7 with the latest Nvidia GFX or Ubuntu with proprietary drivers.

Don't get me wrong. This isn't one of those vicious rage quits we often see around here. It really is a case of a difference of priorities and I accept my opinion may not even be in the majority. You just have to understand the game I'm working on does not need shaders or even any GL 2.0 extensions. It doesn't even need 3D at all. I don't want it to have an engine imposed requirement for anything more than an entry level GPU (probably GeForce 4, GMA 3000, ATI 1300 and up). I realise Spring already exceeds those minimum specs by a significant amount and I could have accepted that but the idea that Springs minimum requirements will be pushed even further to 8800 levels makes me very nervous for reasons I've elaborated on enough.

[Kloot]

I still feel strongly that targeting the "primary" gaming market (high-end desktop)

audience being exclusively a bunch of spoilt rich kids on Windows 7 with the latest Nvidia GFX or Ubuntu with proprietary drivers

Is your view of the world seriously this warped, or do you just like misrepresenting our positions to make yours seem stronger? Even if each single line of FFP/ARB rendering code was dropped right now, tempting as it might be, OpenGL 2.0 (which all our current GLSL shaders target) is still SEVEN YEARS old! The spoilt rich kids have looong since moved on from when that edge was cutting, it's really fair game for us now. I am sorry the situation re. open-source drivers is what it is (a byproduct of capitalism, like the poorer communities and spoilt rich kids) and that not every person on Earth has the ability to run Spring, but we are not here to establish Utopia.

entry level GPU (probably GeForce 4, GMA 3000, ATI 1300)

You realize that of the chipsets you just mentioned, one of them is from 2002 and doesn't even qualify as "entry level" in anyone's book anymore?

Some of the most powerful computers in the world have no GPU

Yes, except the difference is they aren't intended to run modern games (or any game whatsoever), much like the Intel-equipped laptops and people who buy them should know better than to try anyway.

Switch to another engine like Warzone2100 that better aligns with my priorities and runs perfectly on my 1950xt/KMS setup

I occasionally follow WZ's development, and they have much the same problems we do (a code-base littered with inefficient, obsolete techniques slowing progress), and much the same talks/efforts to get rid of them, so take from that what you will.

TLDR: we are not going to make a GF8800 a minimum requirement (that would be stupid, and I don't know where you even got the idea), but we are also not going to bend over backwards for the Intel crowd and assorted others

[smoth]

I can understand allowing spring to run with features disabled... but the rest of your post reads with exceptional bias and hatred.

so here are a few points:

1: I agree with everything kloot is posting.

2: this isn't about rich vs poor.

3: you are about graphics over gameplay... that's nice, what if the graphics are key to gameplay? ability indications, ui, unit differentiation.. etc are all key to gameplay. You are woefully ignorant on this point. Sure BA might be fine. Because you keep slipping up and talking about the game, I will assume you are talking about BA.

4: the reason we have graphics cards and things like open gl is because doing software rendering AKA CPU for graphics is painful. There is a good reason why the industry abandoned it over a decade ago.

5: You are all mad and shit, don't be, I was supportive of your points but I agreed with kloot as well. After this last post, I am disinclined to support this perspective at all. You need to realize point #3 is very important.

[AF]

Kloot, my statements are in reference to the results of the work, and the flawed points against put across by content developers.

The actual how and what of engine development, which make up the bulk of what you are using to move against this, is not what I am referring to, and I daren't as I have insufficient knowledge to participate in a discussion of ATI hacks and the current engine pipeline.

If a low end 2D mode is done using shaders in the current rendering path, so be it, it's not for me to decide how it's done, I'm only concerned with what arrives at the end.

[AF]

3: you are about graphics over gameplay... that's nice, what if the graphics are key to gameplay? ability indications, ui, unit differentiation.. etc are all key to gameplay. You are woefully ignorant on this point. Sure BA might be fine. Because you keep slipping up and talking about the game, I will assume you are talking about BA.

We already have game breaking features if you take these points. Lets turn the unit draw distance to zero and the radar blip distance to 0 and watch as 90% of our games become unplayable.

As I said, you provide the minimum requirements for your game. The engine simply constrains how low you can go. There's nothing stopping you hiding the settings program in the Gundam installer and putting a custom settings dialogue in Zs game startup code ( and tbh you should do this anyway regardless as it'd be epicwinsauce )

[smoth]

I like how you tell me how my game should be designed af.

no I think settings should be done with an ingame menu like all games do.

I have no issue with what spliff wants to do outside of the issue of maintenance like kloot keeps talking about. Spliff could up and leave then we have all these hacks in the engine. Jk's work is hard enough without having to step around a whole arseload of hacks.

however, I do agree that rather than crashing the game SHOULD at least try to dumb down the gfx first.

I am at work and my computer is busted so I am not going to have hte time to debate this with the level of pendantry you may require. Frankly I think kloot has it covered, his points are very solid. What about resolution? my game will be unplayable at 800x600. The ui can scale but not that well. Yet tons of people try to start spring in 1024x768 on shit webnotebooks.... and crash with no meaningful error. I hear about it all the time. We content developers are more aware of user issues just starting spring than you think. You think I don't want every gundam fan to be able to play GRTS? that is a stupid assumption. However, the line has to be drawn somewhere and until the engine allows us to to detect users who cannot run the require settings, we cannot insulate them from a bad game experience.

icons mode? it is terrible I played in in once because I am a huge fan of ogre battle. It still has little to do with say all zakus being teamcolored... which one is CHAR? the fast one? but they are all standing still.. maybe the ui can show it? nope because that is disabled to because the user disabled it trying to force gundam to work on his e-book..If these options are added to the engine I would ignore them or force players to exit gundam if they are set. However, at the same time I see kloots counter points as very valid and like I said, spliffs rage is completely unwarrented. you are arguing the wrong points af.

[smoth]

*edit double post*

[zerver]

Supporting lower end systems can only be a good thing, provided that it does not cripple higher end systems in any way of course.

It has been said before, but since Intel does not (intend to) have any generic OpenGL support (only support for specific applications and games) it is useless to try to make any bugfixes there. A waste of time.

[AF]

no I think settings should be done with an ingame menu like all games do.

If you re-read my post I think you'll find this is exactly what I suggested, so I'm kind of puzzled why you ellaborated =s

[smoth]

Supporting lower end systems can only be a good thing, provided that it does not cripple higher end systems in any way of course.

It has been said before, but since Intel does not (intend to) have any generic OpenGL support (only support for specific applications and games) it is useless to try to make any bugfixes there. A waste of time.

FUCK INTEL! I just needed to say that..

[smoth]

no I think settings should be done with an ingame menu like all games do.

If you re-read my post I think you'll find this is exactly what I suggested, so I'm kind of puzzled why you ellaborated =s

Z's start up code is a start script, not an in game menu

[Tim Blokdijk]

... a proper separation of GFX from the rest ...

How feasible is this? Will this allow SpliFF to do real low end stuff and still keep the modern graphics code maintainable?

[SpliFF]

Firstly I'm not raging. I just have priorities Spring doesn't meet and I'm trying to deal with that. The raging is coming from people who are basically saying my priorities are stupid or utopian or whatever. Secondly I'm not proposing anything particularly complex.



Internal the engine already has 98% of the code I need:

2D Sprites: Handled by the "far textures" code which makes billboards out of distant units. Just has some hardcoded restrictions.

Icons instead of Units: Already there but has some hardcoded restrictions related to the camera height I think.

More Logging: The log systems are already there but I need some extra logging to determine what Spring did at the moment the driver started complaining. jK claims it's there but I'm not seeing anything even with a debug build and log level on debug.

Fake/Null Rendering: There is already code in the bitmap handler that creates a fake 1x1 texture for use when a tex2 is missing. I simply proposed it also be used when the user disables S3TC support via a config variable (I suspect S3TC is causing my crash). Yes it would make shit ugly but I could still do my AI testing and debug whether S3TC is causing my crash.

Disable Shaders: An option that does exactly what LuaShaders=0 does but for ALL engine shaders.

2D Map: Of all the options I brought up this is the only one that really needs any significant new code. Even then that code is essentially draw a big-arse billboard as a tri-strip and render the map texture on it (sub-divided as appropriate). The units would float above the map following their normal 3D paths but with a top-down camera, no perspective and shadows disabled it would essentially not matter. Only water would really be an issue (your subs would appear to be above the surface).

Convert DDS: Another proposal that might need some extra code but again minimal. The "heavy lifting" would be done by OpenIL (DevIL) which is already linked into Spring. The process is essentially check a config variable and then pass the texture to OpenIL for conversion to BGRA or whatever is appropriate, bypassing the entire nv_dds pathway.

All this talk about maintainability and complexity... I just don't buy it. It sounds like exaggeration from people who are already planning to rip out the code I just mentioned in favour of an "all shaders" implementation. Also it was jK who mentioned 8800 as a minimum, though i just realised it was in relation to Battlefield 3, not Spring.

I also don't get all the talk about end-users. I was never on about putting these options in SpringSettings. They're basically things you would add to your spring config by hand, ie, for experts or users who are advised to try it due to Spring not running at all.

As far as game devs go it seems the fundamental disagreement here is the sentiment that "It would be better if Spring crashes than look bad". I simply do not support that position and nothing will change my mind about it. You can do what you like with players of YOUR games but I want the option for players of MY game. If I need a separate engine to do that then so be it.

I'm just going to go ahead and make the changes on my GitHub repo. That will solve my immediate issues. When my game is ready for a release I'll simply merge the latest Spring release and bundle my own copy of the Spring engine. That way everyone gets what they want.

For people asking what I mean by "game" I'm talking about this done on Spring. It's the whole reason I joined this community but I keep getting sidetracked by RL and other projects such as Assimp, UpSpring patches and my Lua AI. With the addition of Assimp, Spring is now entirely suitable for my needs with the exception it doesn't run at all on my home PC with OSS ATI graphics and I have no plans to upgrade it (I do my gaming on another PC with better hardware but inconveniently located for my dev work).

[MidKnight]

SpliFF: Just go do it. It's a lot harder to argue with code than it is with words.

[SpliFF]

I've already started. I was just trying to make sure my intentions and reasons were as clear as possible. I feel like this thread got hijacked by people who think I'm doing something that will ruin Spring for everyone. I don't want any negativity to frighten off people who might otherwise help me with testing or any misinformation or misunderstandings to get in the way of a potential future merge back into mainline Spring. To be honest that's more an issue for devs and players of other Spring games since I was always planning to build and ship the engine and the lobby with my game so I'm not having to update my game in step with the official releases (even if that means running my own lobby server).

[jK]

I feel like this thread got hijacked by people who think I'm doing something that will ruin Spring for everyone.

You can't ruin Spring cause you don't got git access. We think:

• You write walls of text to make Spring & the current devs look ATi, OSS & Intel unfriendly and directly blame us for the bugs with their drivers.
• You just try to bias public opinion with your forum threads.
• You waste your time with wrong things instead to fix/workaround the bugs themselves.
• You aren't competent enough to talk about renderpipeline things. Then again what isn't yet can still become, but you are already flaming Spring's 3d rendering for >1year (?) now and still don't know much more, so chances are low.
• You did a well job with Assimp support, but now go into the wrong direction.
• You should use Lua!!!

[SpliFF]

[*]You write walls of text to make Spring & the current devs look ATi, OSS & Intel unfriendly and directly blame us for the bugs with their drivers.

Every time ATI problems come up you blame ATI and the user for choosing it. When Intel comes up you laugh. What else do you expect me to think?

[*]You just try to bias public opinion with your forum threads.

My opinions were attacked first. I'm defending them.

[*]You waste your time with wrong things instead to fix/workaround the bugs themselves.

I post bugs to DRI/Mesa group but they have a list of issues 50 pages long. I started this thread to announce my own workarounds.

[*]You aren't competent enough to talk about renderpipeline things. Then again what isn't yet can still become, but you are already flaming Spring's 3d rendering for >1year (?) now and still don't know much more, so chances are low.

I haven't met a dev here who doesn't think Spring's rendering pipeline needs a rewrite, including yourself. Also I know a lot more than I did a year ago. Not as much as you or Kloot and certainly not enough but to say I haven't learnt anything is just wrong.

[*]You did a well job with Assimp support, but now go into the wrong direction.

I'm still happy with my direction. I want to support Intel users etc even knowing it's more work.

[*]You should use Lua!!!

For what exactly? The issues I'm talking about are built into the engine code.

[jK]

[*]You should use Lua!!!

For what exactly? The issues I'm talking about are built into the engine code.

Map Rendering, Unit Rendering, just any rendering can be done in Lua.
90% of the things you outlined can and should be done in Lua.