Ykkrosh

I've committed a first attempt at this, which just reports hardware details on startup and lets you type in messages. The data gets stored on a server, but I need to do some more work in order to present it usefully.

Thanks - that says "Mobile Intel® 965 Express Chipset Family" so it should support fragment shaders (hence water reflections) on Windows if you install up-to-date graphics drivers. This'd be the minimum supported Intel chip under proposals #3 and #4 (except on Linux with very recent drivers). Hmm, do you mean it renders incorrectly with shadows enabled? What does it look like? Which OS is this on? In other news: I'm currently working on the code to report users' hardware details (after they opt in) - that seems to be going okay, so hopefully the extra information will help with making decisions here

Could you perhaps upload the game's system_info.txt? That might give some useful technical details. (%appdata%\0ad\logs\system_info.txt on Windows, ~/.config/0ad/logs/system_info.txt on Linux, I think; if the behaviour differs between OS then both could be interesting )

From this commit, it seems GLSL fragment shaders actually are sort of supported in Intel 915/945 on Linux, and recently enabled by default. They violate the spec due to hardware limitations but it sounds like it should work okay with simple shaders. (Doesn't help Windows users, though.)

The main menu's already got a button that links to the web site, but not many people seem to go to all the bother of registering and activating and posting just for quick feedback. There's a button for IRC webchat too and that seems to get more quick feedback ("just played the game and love it", "Nice game!!! Congratulations but in my Acer aspire one the game was slow....", "hEY aDD GAME SPEED CONTROL", "YOUR ALL MEANIES!", etc), but that's still only about 0.1% of the people who download the game. So I think it'd be interesting to make it as trivial as possible to send feedback and see what happens. We don't need to spend any effort maintaining it - just dump it all as a big list on a web page, accessible to WFG members (since making it public would invite spam and privacy concerns). In the worst case we can ignore it entirely and remove it from the next release, but I think there's a chance it could be useful.

Yeah, it'll probably be full of garbage, but that's fine - it's easy to skip over the useless messages and there might be occasional interesting comments or bug reports in there . (And the messages wouldn't be made publicly visible, so that people will have less incentive to abuse it.)

Yep, definitely. I'm thinking it would say something like: Help improve 0 A.D.! You can automatically send us anonymous feedback that will help us to improve performance and compatibility and to fix bugs. [ Enable feedback ] [ See technical details ] in a box on the main menu screen (stuck on the left side so it doesn't block the buttons, probably). That message will always be displayed, until you enable it, at which point it'll change to say: Thank you for helping improve 0 A.D.! Anonymous feedback is currently enabled. If you want to send a message to the developers, you can enter one here: [ ] [ ] [ Send message ] [ See technical details ] [ Disable feedback ] The "technical details" button will describe exactly what data we'll send, and what we want to use it for. The message-sending feature is mostly just for fun - it seems nice to let people communicate back, and we can easily produce a listing of all the messages that get submitted.

Played around a bit with libcurl. It has an asynchronous API, but unfortunately DNS resolution isn't always async and can easily block for hundreds of milliseconds, so I think it's better to run the sync API in a thread. Apart from that it seems nice and easy to POST some data.

I think this is because some textures got renamed, and the tool used for generating release packages was looking for the old name. r8919 should fix the bug.

Out of interest, what graphics device does your old computer have? (If you've got easy access to it and have run the game on it then system_info.txt in the logs directory would say.) I experimented a little with fragment shader performance on Intel GMA 4500MHD (i.e. pretty slow non-gaming mobile GPU from 2008) on Linux (Mesa 7.10, xf86-video-intel 2.13.0). I made a map with 300 of hele_wall, filling the screen at default zoom. I replaced FastPlayerColorRender with a shader like void main() { vec4 tex = texture2D(textureMap, gl_TexCoord[0].st); gl_FragColor.rgb = gl_Color.rgb * tex.rgb * mix(playerColour.rgb, vec3(1.0, 1.0, 1.0), tex.a); } I disabled vertex shaders (since they conflict with fragment shaders in the current renderer design). I disabled terrain rendering, and shadows. I ran at a resolution of 2960x1440. It ran at around 7fps, and enabling the fragment shader (vs the original multitexturing code) made it about 10% slower. Disabling texturing entirely made it about 10% faster than the multitexturing. I think I can possibly conclude that fragment shaders are slightly slower than equivalent multitexturing in this specific situation, but only by a little - it takes a lot of objects and a very high resolution to make performance be fill-rate limited, and then the texturing/shading is still only a small fraction of that. In normal viewing conditions (i.e. not artificial worst-case settings) the difference will be negligible, so there's no practical problem here. (The difference may be radically different with different OS/drivers/hardware, of course, so it's hard to conclude anything in general.)

Hmm, sounds like consensus I don't really want to try implementing this before sorting out the graphics compatibility stuff, though - it'd save half the work here if the compatibility fallback paths were removed first. Probably best to wait and do all the graphics work at once.

I've kept computers far longer than 3 years myself . With proposal #3 we'd still support NVIDIA cards that are 10 years old (similar for ATI), and Intel chips (which have historically been unusable for gaming) that are 4 years old. With proposal #4 we'd support NVIDIA cards 8 years old (and still 4 for Intel).

The coding's not that simple in reality . Well, for disabling shadows it is since we already support a no-shadow mode and just need to enable it. But for <4 texture units we'd need a whole separate rendering environment that doesn't try using the non-existent units and that still renders something sensible (i.e. doesn't break gameplay by making objects visible or invisible at the wrong times), which is hundreds of lines to maintain and test (and it won't help anything except a ten-year-old Radeon). (See e.g. FastPlayerColourRender vs SlowEtc here. Not even that Radeon will need the Slow path so it's pretty much a total waste of energy.)

Per discussion on IRC: The 965 didn't always support GLSL shaders, but it does with newer drivers, and we can tell users to upgrade their drivers, so that's okay. Apart from the GeForce4, we don't remember any problems that were resolved by the fixed-function renderpath, so I don't think it's apparent that we need to keep it for compatibility with buggy drivers. It would be great if we had real data about the compatibility and performance issues, rather than having to guess. We don't have the resources to test on a wide range of hardware ourselves, but we could get users to do it (as part of this). In particular it can report their GPU and driver capabilities; and also it could report some rough performance figures (perhaps by a very simplistic mechanism like capturing the in-game profiler's output a few seconds after they first launch a map). That should give us thousands of data points to make more informed judgements about what hardware is commonly used and has good enough performance to be worth supporting. If we do this, it'd be very useful to get it into Alpha 4, so we could start collecting data immediately and use it as a guide before Alpha 5. I'd guess that implementing this might delay the release by a week (hopefully a bit less), but I'm currently thinking the extra two months of data (compared to waiting until the next release) might be worth that.

I had a 945GM - it ran, but (if I remember correctly) very slowly. It was enough to develop the game but I don't think it would really count as playable. I only get ~20fps on a 4500MHD, which should be well over twice as fast. I don't have any exact performance figures for the 945, though - does anyone here still have access to that hardware? In the absence of additional data, I think it seems the 945 will be too slow to ever run the game acceptably, so there doesn't seem any value in maintaining compatibility with its feature set.

It'd be kind of irritating to do the work for the new rendering approach and then switch back to the old way, but it'd be trivial to actually do the switch. Without the distance fog they'll just be black on black, so you wouldn't see them at all. If we added distance fog then we'd probably multiply the distance fog colour by the visibility fog texture so it'd still be black on black.

I was thinking a bit about our OpenGL system requirements (in terms of capabilities rather than performance). We need GL 1.3 features at an absolute minimum - anything older than that (e.g. the pre-Vista Windows software GL driver) is never going to work. We currently want GL 2.0 features a maximum - we don't use anything that's not part of the 2.0 core (except for GL_EXT_framebuffer_object, as an optional optimisation for shadows). I think it's worthwhile that we support fairly ancient graphics hardware. Particularly on Linux it seems people often have old low-end systems, and I imagine they'd appreciate a new game that supports their OS and doesn't expect them to buy a new gaming graphics card. (I've seen quite a few posts on the forum from people with low-end graphics so it's not just hypothetical, though I have no idea of the relative numbers.) But one consequence is that our renderer has got quite convoluted, with high-performance paths and lower-performance multipass/software-emulated fallback paths in several areas. That makes it inflexible - if someone wants to add a feature like better fog rendering (which I probably do), they need to edit something like six RenderModifiers (which set up the GL texture state) and four ModelVertexRenders (which set up the vertex array state). Other possible feature additions (e.g. adding normal maps) or complex bug fixes will face similar difficulties. It also makes it hard to test, given the number of independent alternative paths - there's something like 3 shadow modes, 2 player-colour modes, 2 vertex-processing modes, 2 VBO modes, 2 FBO modes, etc, so there's no way to verify every combination. So I think I want to propose raising our requirements, in order to remove some of this compatibility code. (I'm not sure I agree with all of these proposals, but I want to see what other people think ) Proposal #1: Always require >= 4 TMUs (i.e. GL_MAX_TEXTURE_UNITS). Currently GL only guarantees 2. Our code is compatible with 2, but shadows are disabled unless you have 3 (since recent fog-rendering changes). If we always require 3, we can get rid of SlowPlayerColorRender, which saves ~150 lines of code and one path. If we require 4, we should avoid problems when adding better fog rendering to models. This will prevent the game rendering correctly on GeForce4 MX and Radeon 7500 and older. (Newer Radeons, and GeForce3+ and Intel GMA 900 have >= 4, so they'll be fine.) (NB: GeForce4 MX counts as older than GeForce3, but otherwise "older" basically means "lower number".) Proposal #2: Don't support shadows without GL_ARB_shadow and GL_ARB_depth_texture. Non-depth-texture shadows don't support self-shadowing. On my Intel 4500MHD they're hugely slower than depth-texture shadows; on my GF8 there's no difference. For low-end hardware we should probably have a totally new shadow system that just draws grey blobs under units and buildings, so there doesn't seem any value in keeping this fancier shadow system working there. This would save some tens of lines of code throughout various functions, and would save another path to test. We'd lose shadows on Intel 865G and Radeon 9250 and GeForce4 MX and older. Proposal #3: Always require GLSL vertex shaders (i.e. ARB_shader_objects and ARB_shading_language_100 and ARB_vertex_shader). When vertex shaders are available, we use them for lighting and for instancing (an optimisation when rendering the same geometry in multiple positions). Without them, we compute lighting in software and disable instancing. If we require vertex shaders, we can get rid of FixedFunctionModelRenderer (~400 lines) and one major path. We'd lose compatibility with Intel 945G and Radeon 9250 and older. (We'd still work with Intel 965G, Radeon 9500, and any NVIDIA). Some old drivers emulate vertex shaders in software but that shouldn't really be slower than our own software processing. We might hit some bugs like this if newer drivers haven't fixed them, in which case we should just find and fix our bugs. So the risks aren't entirely trivial, but I think the simplification to the code and added flexibility would be significant. Proposal #4: Always require GLSL fragment shaders (i.e. ARB_fragment_shader). Currently we only use fragment shaders for fancy water; everything else uses the cumbersome multitexturing system (in which it takes about 12 lines of code to multiply a texture by a colour). If we required them, we could incrementally rewrite all the existing multitexturing code to be far simpler and cleaner and more flexible. Compared to requiring vertex shaders, we'd lose compatibility with GeForce3 and GeForce4. (Intels and Radeons shouldn't be affected). I have no idea of the performance effects on old hardware, or whether it's particularly buggy with old drivers. (New hardware almost certainly implements multitexturing on top of shaders, but I don't know if early implementations (e.g. GeForce FX) or Intel ones are much slower with shaders.) We've stated GeForce3 as our minimum requirement, but we stated that in like 2003. The Unity hardware survey (which is far less gamer-focused than the Steam survey) puts the GF4 at 0.1%, and GF3 at 0.0%. That's not a lot (and it'll only decrease over time). I liked my GeForce4, until it burnt itself out (in like 2006), since it was nice and fast and did everything except pixel shaders, so I'd be sad to abandon it, but maybe it's time to move on

Yeah, terrain decals are definitely something we need - shouldn't be terribly complex so I think it's safe to work on the assumption that we'll have them eventually

How should buildings on the edge of fog be rendered? (Especially when we have giant ones like the pyramids.) If I remember correctly, the AoM/AoE3 approach is that the building pops into visibility once its central point is out of the fog, and maybe(?) it changes all the terrain directly under the building to be visible. An alternative is to do something like this (the building on the left) - apply the fog texture to the buildings, exactly like how it's applied to the terrain. Probably the building would always get rendered, initially in pure black (so you could only see it where its silhouette covers a visible area) and then gradually becoming fully lit as you approach it. (You won't be able to select the building, or see dynamic changes to it, if it's still in the fog - it'll only be interactive once it's at least partially in a visible region.) I think that looks nicer, but I don't know if there's subtle gameplay/artistic problems with it. Are there other games that do something like this? If not, why not? (The implementation in our engine is tedious (since there's like a dozen different model-rendering modes - I've just hacked it into one for now) but not particularly complex, and it shouldn't affect performance significantly.)

Hi - sounds like an ambitious project The code and data are open source so you can use them however you want (with the usual restrictions of providing credit and not misrepresenting the original work). We want to keep focused on just developing 0 A.D. - I think we probably wouldn't want to incorporate features that add significant complexity to the engine that won't be used by our game (since complexity will hurt when we're adding other features), but if there are simple changes that make the engine work better for other games then I'd be happy to include those. If you need more radical changes then it'd probably be better for you to maintain a separate fork of the engine code, so you'd have the freedom to do whatever you want with it, and you should still be able to merge improvements to 0 A.D. back into your copy of the code. Using an existing game engine definitely sounds easier than starting from scratch, and hopefully 0 A.D. is reasonably extensible so it shouldn't be an impossible starting point - it'd be interesting to see what happens with this project

Yeah, that's definitely not good - it's just something we haven't implemented yet . The current plan is just to flatten the terrain underneath the building (and forbid construction on strong slopes so that there's not a lot to flatten - there could be a maximum of e.g. 1 metre height variation in the tiles underneath the building). Hopefully that'll be adequate.

That's a consequence of the placement preview not being recomputed until you move your mouse. I guess it should get recomputed every turn, which'd fix this. Fixed.

Committed some code now - the AI should try to train some female citizens, collect some resources, build some houses and a barracks and some farms, and train some soldiers and send them to the enemy civ center. In terms of strategy it's terrible - this is mostly just a proof-of-concept for the low-level systems, and someone probably needs to redesign it to work decently as a player, but that can come later

Been working slowly on various stuff. Currently I've got a (rubbish, poorly-designed) AI that can build buildings, which is nice. E.g.: (Oasis) (Belgian Bog) (The left images show which tiles can be built on (i.e. aren't off the map, underwater, on steep slopes, or blocked by trees or rocks or buildings). The right images indicate each tile's distance to the nearest non-buildable tile, so brighter tiles have plenty of space for large buildings. The AI computes that to discover which tiles have enough room, then combines it with some other data so it prefers tiles close to its existing buildings, to discover the best valid location for building.)

In the current implementation, individual units don't really have a meaningful front - they can turn instantly to walk or to attack in any direction. There's not much value in getting a bonus when attacking from behind if the enemy will instantly turn to face you. But we've planned to have directional bonuses for formations, since those will have meaningful sides and can only turn slowly, so you won't achieve much by attacking a phalanx from the front.