Ykkrosh

Adding lines of code to run doesn't sound very helpful when the problem is the game won't build... #535 has some information from Bob who had a similar problem.

Infinitely parallelising simulation updates wouldn't help that much anyway - even in its current poorly-optimised state, most of the time is usually spent in other areas (mostly graphics, some GUI, etc). Probably most of the engine would have to be redesigned else it'd be bottlenecked by some serial code and wouldn't get much improvement. But we should revisit this when we start our next engine and 8+ cores is the min spec

Our Mac support is currently not very good - we need Mac developers to help test and fix things and make it all work properly. I think it should be possible to compile the latest release on 10.5, but probably not 10.4 (I expect its tools are too old, and it definitely won't work on PPC) and probably not 10.6 (there are some 32/64-bit problems in the build system). Eventually we ought to have some precompiled bundles, but we don't have the expertise to set that up yet.

In that case they'll have to move, but they still shouldn't move to the exact opposite point. E.g. if you have a formation like [1] [2] [3] [4] [5] [6] [7] [8] facing upwards, with infantry in the front rank and archers behind, then tell it to move downwards, currently what happens is 1 will swap with 8, and 2 with 7, and 3 with 6, and 4 with 5. Instead it should swap 1 with 5, 2 with 6, etc. I guess what might be reasonable is to first determine what type of unit should go in each slot, and then for each type the goal is to minimise the worst-case time that any unit will take to reach its assigned slot, so that the formation will be completed in the quickest possible time. Hopefully that means it'll do the right thing when first creating formations, and when turning. Add a bias to prefer units moving forwards to reach a slot and then it'll probably react more nicely with a unit at the front being lost and the ones behind it moving up to fill in the gap. Not completely certain it'll work in practice, though.

Thanks to Christopher Tozzi there's now a development snapshot PPA for Ubuntu, which should get updated weekly with the latest version from SVN, for people who want to follow the development more closely but don't want compile it themselves. No guarantees about stability or bug-freeness or anything, but hopefully it'll be usable most of the time.

I've added a basic version of the AoM-style group movement thing now. Select a group of units, tell them to walk somewhere, and they'll arrange themselves in a line formation (and run to catch up if necessary) and then move to the destination as a group. (This isn't intended to be proper formation support - there's no choice over the shape, and the units leave the group when it's reached the destination, and there's no attack/defence bonuses or anything. This is just temporary loose formations used for travelling in groups without everybody crashing into each other. Proper formations can reuse a lot of the code, but they'll come later.) Also I made the vertex pathfinder about 6x faster - it's still not great but hopefully it'll be a problem less often. There's lots of missing stuff, particularly: * Different unit types should go to different parts of the formation (ranged behind infantry etc). * Non-move commands (attack, gather, etc) should probably move in formation until close to the target, then break up into individuals. * Moves over long distances should switch to a narrower column formation to improve mobility. * Turning by 180 degrees should make units just turn around in place, not all run to the opposite point in the formation. * It assumes all grouped units start near each other, which isn't necessarily true. * Run speeds need tweaking. Are there any of these problems or any problems I haven't noticed (especially any newly-introduced bugs), that ought to be fixed soon (like within the next couple of months), or is it adequate for now?

Yeah, I'm not very good at scheduling, and I've been busy with some pathfinding changes and haven't had time to focus on anything else

In common mesh formats, a vertex can only have a single position and UV coordinate and normal vector. If you have two faces joining at the same position but with a sharp edge (i.e. non-equal normal vectors) then that requires two vertexes at that position. Same if they have different UVs where they join.

Yeah, the synchronisation overhead would probably defeat any of the performance benefits if we tried to do much multithreading with the current engine since there's too many dependencies between the code, and it would add a lot of complexity. There are architectures that can make it more feasible but it'd be very hard to switch to them. There are some cases where we should add threading to improve latency (in the networking code), and some small areas where we possibly could use it to improve multi-core performance (like pathfinding, and maybe some graphics code (like skinning)), but it's probably more worthwhile spending time optimising single-core performance first.

We can't fix anything when we can't reproduce the problem ourselves - we have to rely on people who have the problem to debug it. We can't fix bugs in graphics drivers anyway, since they're not our code and we don't know anything about them. There are some known bugs like this which are fixed by updating to newer (not-yet-released) drivers, but I have no idea if that's the same problem you're getting.

That's just the .pmp file, need the .xml file too

I think that error with cpu_CAS is caused by the build system mixing 32-bit and 64-bit incorrectly, but I don't know how to fix it properly. We need some developer with OS X 10.6 to debug and fix these issues.

They're all rendered the same - CRenderer::RenderShadowMap calls m->terrainRenderer->RenderPatches and then renders the models too. (Ah - I guess I should say hello, then )

See this one - I believe the shadow on the left just above the water is cast by the hill. Shadows ought to be identical unless you either have ancient hardware (like pre-GeForce3) or buggy drivers (which seem quite common). You should be able to create a map in Atlas, raise a steep square section of terrain, stick some objects at the top and bottom to make sure it doesn't get buggily culled out, fiddle with the lighting settings, and see the terrain-on-terrain shadowing. At least it works okay for me . You can also open the in-game console (not in Atlas) (with the ` key) and enter "?renderer.displayFrustum=true" and it should display the shadow map on the screen.

Patches on Trac are very welcome . (Might take me several days to get around to checking and committing them though, since I want to concentrate on some other work first.) Non-fancy water improvements are good, since we want to continue supporting low-end hardware - ideally it should match the approximate colouring of the fancy water as closely as possible (since people writing maps don't want to tweak the settings for both modes), just without any of the fragment shaders. I have no idea how possible it is, though. I'm not aware of anyone actively working on graphics code now (very little has changed since about 3.5 years ago) so there shouldn't be any conflicts. Terrain will cast shadows already (though #504 means it breaks if you're unlucky with the frustum culling) - are you thinking of that or something slightly different?

You can change the key settings - look in binaries/data/config/default.cfg and create a local.cfg saying hotkey.bigscreenshot = "F3" or similar.

Ah, so the call to glGetTexImage causes some state change in the texture that makes all subsequent usages slow? I guess that makes sense if it's a VM forwarding its GL calls to the host machine (using Chromium?), since reading back texture data would break its attempts to optimise rendering by storing all the texture data on the host. Sounds like it's possibly an architectural feature rather than a driver bug, so it's worth fixing our code. (The crashes sound more like bugs, though). Presumably the same problem will be triggered by Atlas's terrain texture previews (in GetTerrainGroupPreviews), so ideally we should try to avoid that too. Yes, and that's fine . When we don't have the original we don't need to change anything. We'll still get improved quality for the hundreds where we have the originals, and for all textures added in the future.

Hmm, I wasn't aware of that problem, but I see a comment in the code saying "this is horribly inefficient (taking 750ms for 10 texture types)" and I can imagine some drivers will be particularly bad at these operations. It looks like this only happens on first load, so it shouldn't affect runtime performance - is that right? It might be nicer to continue getting the default colour from the texture data rather than requiring an XML file for every single texture, since the default is often reasonable. That sounds like it should be straightforward with a slightly rejigged texture loading system - it can just grab a pixel from the lowest mipmap level (since we'll guarantee all terrain textures are DDS with explicit mipmaps) before we send the data to OpenGL. That way we can avoid needing an extra file for metadata about each texture. I'll see if I can do this when I change that code.

I tried to write some instructions here, which might possibly give some indication of where it's hanging.

Hmm, I think 2005 is probably too old to read the debug information files. I'll see if I can look into this debugging thing some time tomorrow (if not for this case then for future debugging). The uninstall should delete everything except local .cfg files and screenshots, so it sounds like a system thing. Did Atlas stop working immediately when you updated the drivers? What exactly does it display on the screen when you start it?

Those .cfg files are optional (and not present by default) and won't hurt. The editor runs as part of the game engine, so it uses the same log files. I don't have any ideas as to why it'd stop working . Maybe it'd be useful to run the game in a debugger to see what's going on, but unless you've got Visual Studio installed that's a pain - I guess we should figure out some instructions on how to use WinDbg to help with this kind of thing.

By my count it's at something like 7.5GB for the entire art/trunk/ directory, which is indeed 100+ MB.(Probably best to use the web interface to browse, and then only check out subdirectories that contain particularly interesting things.)

Yeah, when we don't have a higher-quality PNG version then there's no reason to convert the current DDS files. I don't know what proportion we can't easily find the originals for, but it looks like there's quite a few PNG/TGA/BMP/PSD files in the art SVN that we can use without much bother.

That's pretty much exactly what I'm proposing here (applied to the official content too, not just user-made mods)The harm of the current DDS files is described in the first post - compression artifacts, incorrect mipmaps, non-ideal mipmap filtering. Most textures are okay, so there's no rush to replace every single one, but some cause compatibility problems and should be fixed soon, and if we can incrementally replace many of the rest then we can improve the game's graphical quality. Switching every texture from DDS to PNG only adds about 10% to the total checkout size. The release packages will just contain the automatically-converted DDS, not the PNG, so it wouldn't make any difference there.

Nobody's objected to this yet, and I think it's still a worthwhile thing to do. So I'll suggest the following: * From now on, artists should upload all new textures as PNG, not as DDS. The GUI and actor XML files can reference the .png filenames and it should already work fine. * Gradually, DDS files should be replaced with the original uncompressed PNG files. (Don't open the DDS and save it as PNG - only replace it when we have a higher-quality uncompressed copy.) * (If we also have the PSD/etc source files then those should go in the art SVN repository instead, but I don't think they're so important.) * I should do this in the next month or so.