How hardware requirements could be reduced further

[Mr War]

It'd only be a small help but it'd be pretty straightforward to make a deliberately minimum poly tile set to reduce strain for low end machines and/or poorer broadband users.

Low poly factions could also be made but that's a lot more work.

Edit (tomreyn): Split and renamed thread since this is a different discussion

[will]

If you want low-poly, there are standard algorithms for simplifying meshes and the engines could do it at load-time

[Mr War]

Dumb question maybe, but with online games, would it be possible for different players to be playing with different tile sets? Is that data local or via server?

[softcoder]

Would have to use the same tileset for network games as the tileset objects (models linked to the tileset) and other things could make the game play differently.

[Omega]

How would you reduce the poly count on tilesets further? Most tilesets are pretty much as low as you could practically go. I mean, the trunk has four sides, and the leaves/branches are all a single plane each.

[Psychedelic_hands]

You could get just as much gain; with MUCH less work, by just making the textures a lot smaller. Textures are just as, if not more costly than the poly-count.

Maybe there could be an option for that for MG to do that automatically? Though, then it would be better if MG adopted GAE's power of 2 textures only thing. ( Which is a bit of effort for the modders if they haven't been doing that already, but it's worth it.)

[Omega]

You could get just as much gain; with MUCH less work, by just making the textures a lot smaller. Textures are just as, if not more costly than the poly-count.

Well, to the extent of my knowledge, texture size would be very dependent on RAM and VRAM, but shouldn't impact frame rate at all. That's the case in Skyrim and several other games, so I'd assume so in Glest as well.

Though, then it would be better if MG adopted GAE's power of 2 textures only thing. ( Which is a bit of effort for the modders if they haven't been doing that already, but it's worth it.)

While that wouldn't do a thing for faster loading or better performance, it would incite better stability for older cards, and there's absolutely NO reason to use non-power of 2 textures, so I agree, MegaGlest should enforce the usage of power of 2 textures (GAE will refuse to load the game if textures aren't power of two, purposely). Every commercial game I can find uses only power of 2 images, so should Glest.

[will]

What are the intentions regarding preaerving aspect ratio on hud and loading screens?

(My laptop is widescreen)

[Omega]

What are the intentions regarding preaerving aspect ratio on hud and loading screens?

(My laptop is widescreen)

Loading screens were stretched in vanilla Glest (background.tga; I'd just make a regular resolution image and then resize it to a power of 2). The same could be done with the HUD (surely it must already do something like this, since there's only one HUD image for 4:3, 16:9, and 16:10 resolutions. Alternatively, to prevent degradation from scaling, it's possible to only use part of the image (leaving the rest transparent - adding about 1 kb to the image), eg:

[Mr War]

basic tileset compare with same machine/set-up, same faction etc. I can get higher FPS if I move to a corner of map etc but all these stats are starting location etc, so quite fair.

bamboo forest
FPS 65
Pollies 30k
Vertex 60k

spring
FPS 111
Pollies 61k
Vertex 71k

Scrubland
FPS 92
Pollies 63k
Vertex   86k

Dark Forest
FPS 75
Pollies 23k
Vertex 43k

Is the sound a factor?

[Mr War]

How would you reduce the poly count on tilesets further? Most tilesets are pretty much as low as you could practically go. I mean, the trunk has four sides, and the leaves/branches are all a single plane each.

by polly I mean triangle. Trees in most tile sets are anywhere between 160-700 pollies and statues etc are 600-1500ish. Open them in G3DViewer to see what I mean. Flowers and grass seem particularly high polly for what they are.

I tried to make Bamboo Forest tile set faster by reducing the TGA size and pollies of the tree models and it made no difference. Then I replaced the grass with riverside objects (both unmodified from Dark Forest) and that almost doubled my test view.

[titi]

This all also depends on the graphics driver! Trees use transparent textures and i have the feeling the more detailed they are , the more trouble they cause for some drivers ...

[will]

https://developers.google.com/native-client/beta-docs/3D-graphics#openGL is interesting, generic advice about how to get the best from hardware accelerators in general.  The classic draw loop we've inherited is pretty much anti-optimal these days.

[Coldfusionstorm]

Ofc we should use more graphic card features, All major games do this...Why WOULDNT you use the GFX, just make a option for turning the new mode off.

[will]

Philip` has said that 12% of 0ad users do not have the modern GPU features.  88% do have modern API hardware.

The newer platforms - android, chrome, iOS etc - and the newest OpenGL 4 do not support - as in won't compile - the old legacy APIs that that 12% need us to use.

We are going to end up with a modern OpenGL/GLES 2 codepath and, as a separate compilable unit, legacy code.

Our current engine is firmly in the 12% legacy territory, even though we have started to move over to VBOs and such.  We really need a fresh tidy new start on the modern OpenGL/GLES 2 codebase.

We have lots of features we want to add, such as moving over to bone animation e.g. MD5 and fancy water and bumpmaps and such.  Are we going to support these new features by adding them to the 12% codepath as well as a different implementation in the modern codepath?

This is a very strategic decision that should not be taken lightly.

My personal vote is to abandon those users who do not have the new OpenGL APIs available.  Sorry, but I think that's the pragmatic reality.

[Bloodwurm]

Funny how this thread on lowering the hardware requirements is turning out to be a "let's require more" topic.

I think that one major question people should ask themselves is what makes for a good game?
Graphics? Eye candy? Gameplay? Multiplayer? Replay value? Story? Audio?

I personnally think that rooting for "graphics" dominance is the way of the past. Social games have demonstrated that outright.
Games like Minecraft also. I believe a minimal goal should be achieved for graphics, but I don't think "dumping" the 12% is going to help Megaglest in any way. (Then again, who are these 12%? People with 10 year old machines?)

Don't want to be bitchy but... can you really afford to cut loose part of your players at this stage? I mean, is Megaglest StarCraft or something?

I totally understand the fact that sometimes, hard choices need to be taken and seen through, but I don't believe Megaglest is anywhere near that crossroad yet.
There are a lot of professional engines/games out there that offer several settings and the disabling of gfx cards features if unavailable. It does complicate the lives of the dev and content creators.

But that's what you'll want to do if you want to be able to get as much players as you can.

My 2 cents, no harm intended.

[John.d.h]

I agree with Bloodwurm on this one -- the point of having a game be cross-platform is that it can be accessible to the greatest number of players, and increasing requirements would be the opposite of good. If I were unable to run MG because of hardware requirements, I would likely never play again because it might be another five years before I get a decent upgrade (and no offense, but I'm not buying a new computer just to play it).

[Omega]

Funny how this thread on lowering the hardware requirements is turning out to be a "let's require more" topic.

The irony is seething.

Anyway, studies show that some people still browse with internet explorer 6. I don't even take IE 6 into acknowledgement when designing web pages. They're a minority, and if they're going to be so stubborn to not upgrade to a better browser, to hell with them. Admittedly, upgrading graphical abilities is a bit trickier. I'm sure the majority of our audience reaches and exceeds the minimum requirements. Yes, there are some who don't, there was a thread not long ago where a user with a computer significantly below the minimum requirements was trying to get MegaGlest to run well.

At this point, we only have 0AD's statistics. Is there any way we could find the same for MegaGlest? 0AD is a "bigger" game, but also incomplete, still being in the alpha stage. I'd expect we'd see similar numbers, but that may not necessarily be the case. If it turns out only 3% of players are using such outdated technology, that's quite different than 12%, for example. Is there any way an accurate method of finding this sort of information out? Obviously just asking forum members to post would not work. It'd be a bit of work, but I'd be interested in seeing what kinds of players the game should be tailored to.

With that being said, going with a 12% number, I can't help but agree with Will in abandoning those with such outdated machines. Does anyone who owns such a machine honestly expect to be able to play modern games? I doubt most of the commercial releases, if any, would work on their computer. Yes, graphics are a small part of what we look for in a game, but why should we hold back what could improve the game (in whatever way) for the majority of players, just because of a minority that need to update their computers. Should the game move to newer technologies, those who still cannot upgrade their hardware can always use the older versions (likely without the multiplayer), though I'm sure anyone even half-way serious about gaming would use at least a half decent PC. Heck, you can pick up a laptop for less than $300 that easily meets the minimum specs.

With that being said, I'd rather wait and see what percentage of MegaGlest players don't have these modern GPU features. After all, if the number ends up like 20% or something, as much as I'd like to see the utilization of modern features, that's simply too many players to cut out.

I don't suppose there's any practical way to branch out to satisfy everyone, is there?

[tomreyn]

If there can be a compatible legacy branch (I doubt it) then I would think that having a current/default branch which depends on newer OpenGL versions is perfectly fine (but I bet it would involve rewriting a lot of code). Excluding an assumed eighth of our player base, however, doesn't seem like an acceptable option to me, though.

On a side note, it would be good to know how the stats were compiled, what kind of GPUs these 12% use and whether the hardware they use is so old that it can be safely assumed that their other hardware components will not allow them to play the game properly anyways (think RAM/CPU shortage, minimum hardware requirements).

[will]

I reread my posts and its easy to misunderstand my motives.

I have a very bad integrated Intel card on one laptop, and some slightly-better integrated ATI thing on another laptop.  My prototyping of faster model drawing and terrain and such has always been motivated by trying to make glest/gae/mg run at a better and more playable framerate on my low-end graphics.

A few years back both OpenGL and Direct3D decided a break with the past was necessary to better gain mechanical sympathy.

Basically, the API that glest uses and the way it uses it is not the best way to get performance.

My own prototyping shows me that I can nearly double the framerate using attribute vbos and shaders on my Intel card.

However, this API break is really fundemental.  Having two codepaths, one for people without modern drivers (note, not necessarily meaning people with rubbish GPUs; most people with rubbish GPUs do have modern drivers, and would massively benefit from a graphics pipeline that better utilised it) is a serious undertaking.

Who is going to maintain the 'legacy' OpenGL codepath we inherit from Glest - back when that was the proper way of doing things, lets be clear about that - when we put in a completely new clean modern codepath for the 88%?

[treba]

if we use a ogles pipeline, we can make mg run in the browser one day