Spring on low-end laptops

[SpliFF]

As part of a rendering system overhaul I need to know what sort of rendering features to backport for low-end graphics systems. This is a pretty subjective thing so I'd like to hear feedback from users of low-end hardware (I'm talking embedded chipsets like Intel 945M found in older laptops). I'm only interested in laptops, I'm not going to spent a week coding something because you're too cheap to shell out $20 on a budget AGP/PCIx card for your desktop.

There's not much point maintaining features that nobody wants so the first thing is to determine what CURRENTLY runs on these systems and what sort of things you disable anyway.

For example, does anybody with older chipsets enable shadows? There's no point me backporting shadow code if the people who need it have it switched off anyway.

Please post here the following information:

Your graphics chipset and CPU model: I need to know the full chipset name (like Intel 945M, ATI Mobility Radeon X1400, etc... not who made your laptop - ie, Toshiba).

Your spring settings: Primarily in regard to resolution, shadows, unit lod, shaders, decals, etc..

Your average FPS: If you don't know, guess.

Max Units: The average number of units you get in game before the game becomes unplayable.

ETU (Estimated Time to Upgrade): How long you think it'll be before you upgrade to a modern laptop.

Post your feedback now or else be prepared to hold your peace if you suddenly find your graphics options reduced. I'm only interested in ensuring Spring remains playable and having a yardstick to measure FPS increases/drops against the current system.

[Forboding Angel]

For fps, next time you're in a decent sized BA game, just press B (or if you're running the new RC, alt+b).

[manolo_]

Acer Aspire Timeline 1810TZ-412G25n

Intel Pentium SU4100 1.3GHz
2GB RAM
250GB HDD
Intel GMA X4500MHD
Win 7 HP

spring-details: all on low
mod: XTA
lua: all activated (including iceui)
nearly: 20-30 fps at start

when im home, ill make proper tests

[SeanHeron]

Intel(R) 82852/55 GM/GME Graphics Controller, 64 Mb Ram

Though admittedly (and as I stated elsewhere just yesterday) I do have major errors in map display. I basicly only run Spring to test stuff on this comp, I don't actually play.
So giving this setup the axe would certainly not be moaned about by me! (I guess you might see me as "definitely beyond worth supporting" - ie bottom end cutoff).

Oh, by the way - I personally cut down the settings to whatever keeps the game running well (and that always means shutting of shadows, even on my playing rig). I think as long as you can still run the game (and at a semi-decent resolution, fps, number of units), most people will be fine to reduce the graphics settings as far as necessary/ to what is supported.

Further info (on the above graphics card):
OpenGL - version 1.4 according to Springs Infolog ("[ 0] GL: 1.4.0 - Build 4.14.10.3775")
Here's the Dxdiag info

[==Troy==]

What are the chances to get decent FPS on the EEE PC / alternatives models?


At the moment as far as I can tell the Windows + Spring on them gives about 5-10 fps on a medium sized game, and Arch + spring is 10-20 at best on the same sized game.

Both have problem that the ground is not textured.


Netbook : ASUS EEEPC 901
vid : Intel 945GME
settings : ALL possible on lowest. native (1024*600) resolution.
ETU : never. or until Google netbook will be released.



Speaking of google netbooks, as far as it goes they will boast 2.0 Ghz dual core ARM CPUs (and those are twice faster than intel of the same frequency, due to RISK vs CISK). And with Nvidia Tegra 2 vid, spring should be totally playable on those.

[aegis]

chances of syncing across cpu architecture?

[SpliFF]

As far as netbooks go I think it's a reasonable possibility I can make the game playable with flat color units (ie, your units are all in your teamcolor, no textures, ambient lighting only, sprites/triangles for projectiles). You'll probably hit CPU limits long before graphics cut out, particularly with bigger mods.

Interestingly however, players of mods like Kernel Panic probably won't notice any difference.

Older netbooks, phones and PDAs will probably never be a reasonable target, however I have no objections to providing an ultra-minimal graphics mode either. It's quite possible mini-mods like KP will be playable on some devices.

Spring's interface is far too complex to ever be converted to 2D, so a minimum level of 3D support will always be a requirement.

Ground texturing on older netbooks isn't a valid goal either, as it will always require a minimum amount of texture memory and throughput to handle large maps.

It's hard to guess the effects of ARM / Atom on sync. It's hard to predict if these targets will see enough testing and development to become stable in MP. On the other hand single player might work ok.

[aegis]

atom is x86, so it'll act just like a desktop processor

[SpliFF]

x86 or x86 "compatible"? There's a difference, except to marketing people. It would have to always produce identical results to desktop Intel/AMD. If it can then yeah, it should work.

[AF]

A widget that remove the texture map and instead uses shading, a basic, higher terrain == lighter colour + higher slope == lighter colour, with a slight hue disparity, combined with markers for where to place mexes, supcom style that are visibile. This would let you render all features in the same block colour and have them tinted by colour according to their resource value like the prospector widget.

thus, a textureless game of spring, with no shaders or shadows or lighting beyond default OGL lights, yet aesthetically appealing..

[Neddie]

The Atom is x86, and there are some which are x86-64 - these latter (230 & 330) are desktop Atom processors and need not concern you.

Also, Kernel Panic is a game, and a damn fine one.

[hoijui]

Desc: ASUS EEE HE1000
CPU: 1.6 GHz Intel Atom Single Core N280
Screen: 1024x600 TFT
Graphics: 945GME Calistoga 82945GM/E (GMCH) 533/667 MHz Integrated GMA 950 graphics core (Max. 250 MHz 3D Render)

As much as i know, the vast mayority of netbooks are comparable to this, as they have:
Atom single/dual core CPU, Intel 945G* graphics

As the linux driver for this graphic card is crap,
you should only use windows testers (average FPS x4 of Linux on same system).

I did a short test of spring under windows on this machine before removing the OS.
Can not remember the FPS, but someone else said it drops dramatically when zooming out a bit,
and starts at 15-20FPS (max) with low settings.
I think it is mandatory already to set Shadows=-1 for this card, on all OSs.

I agree with others: if you can turn a graphic feature off, and still play spring,
we do not need support for it on old/crap cards like these.

[jK]

I would like to drop the whole Intel/FFP support, most commercial games don't run on them why should spring?
-> minimum for the GPU: GLSL shaders (no fugly combiners anymore)

Btw even when you drop the FFP support, a new model renderer should be modularized enough to easily integrate new render methods. So ppl should be able to re-implement it themselves (with less features).

[==Troy==]

I would like to drop the whole Intel/FFP support, most commercial games don't run on them why should spring?

Because spring is nowhere near commercial games in gfx featureset? And the appeal of spring is different from the commercial games.

[jK]

I would like to drop the whole Intel/FFP support, most commercial games don't run on them why should spring?

Because spring is nowhere near commercial games in gfx featureset? And the appeal of spring is different from the commercial games.

BA player?

[AF]

Just because we currently are not XYZ, does not mean we can use that as justification for not becoming XYZ

E.g.:

We dont have shadows in our game, therefore we should not implement shadows

We have shackled ourselves with support for intel chipsets that are weak, therefore we must not unshackle ourselves.

If you are on a desktop machine you have no excuse, the only issues are machines like netbooks and laptops that are stuck with a particular gpu.


I agree with JK, the renderer should assumme GLSL and implement a secondary module that implements basic rendering of geometry, which can be used as a basis for a third module for cards that don't support GLSL. The basic renderer can be kept for uber low end gpus, or as a basis for the start of new renderers, eg an OpenGL ES renderer.

[Pxtl]

iirc, most large-scale Spring games really strain the processors of older machines - the video card isn't the big bottleneck there. I would be surprised if the EEE machines could handle the processor requirements, much less the video ones.

[hoijui]

yeah.. i do not think anyone will argue they are really useful for playing.
but as stated, some devs use such machines for testing, for example SeanHeron and me. HughPerkins only had an EEE PC, and did all his work for spring on it, and i guess there are more.
An additional low-tech renderer sounds fine to me, though it could be a problem for mod devs... then again, they will probably need better machines anyway.

[Auswaschbar]

ATI Mobility Radeon 9700M on my laptop, lowest settings
I use it for testing often, doesn't give high fps but enought for regular 1v1.

[CarRepairer]

Graphics chipset and CPU model:
VIA C7-M ULV processor (1.6 GHz, 128 KB L2 cache, 800 MHz FSB)

VIA Chrome 9
Up to 256 MB of shared system memory for Windows with 2 GB of system memory.

Spring settings:
Lowest.

Average FPS:
1-10

Max Units:
2

ETU (Estimated Time to Upgrade):
4 years.


Running Windows Vista Business, at 1280 x 768. Nearly no graphical problems (except teamcolor gets confused sometimes, strangely). Game is unplayable. Small games are speccable.