Ykkrosh

Day 1 Worked on improving the engine support for saved games. As a basic introduction: The problem is that the game has a load of complex data structures storing its representation of the world in memory - data about units like their positions, hitpoints, the paths they're moving along, and hundreds of other things, along with each player's resource counts and the explored regions of the map and so on. All that data needs to be flattened into a string of bytes that can be saved into a file, and it needs to be portable between different computers. The saving process also needs to be comprehensive: if we forget to save one minor bit of data (perhaps we fail to store the wing positions of a butterfly), the game will play out differently when you load it back (perhaps a tornado will no longer form), causing unpredictable buggy behaviour. (Not that we actually have tornadoes in the game. Or butterflies.) As an example of the data we need to save, this is a female citizen: The engine already supports most of the functionality needed for this, but it's hard to verify that it doesn't have a few bugs hiding in it. I've now added some code that developers can enable to test the correctness of the saving/loading code. It'll automatically save the game after every single state update (about 5 times per second), load it again into a second copy of the game, run the gameplay update code on both copies, and verify that the result is the same in both cases. If we ever forget to save some data that will affect the behaviour of the simulation, the two copies should get out of sync and we can detect and debug the problem. Running in this mode is noticeably slower than normal but still quite playable. I've also added a quicksave/quickload feature (press shift+F5 to save, shift+F8 to load) which provides another way to test this code. One known problem is that animation state is not saved - if a unit is walking when you save, it'll slide across the ground while standing perfectly upright after you reload. Also there's no support for saving AI yet, and it'll explode catastrophically if you try it in multiplayer, but the rest of it should work. Now I'm working on extending the networking code to support transferring large files between players, with the aim of letting players reconnect to a multiplayer game if they crash or temporarily lose their network connection instead of having to abandon the match. One of the already-connected players will automatically save their game and transfer it to the new player, who will load it and then can continue with the match. This file-transfer code should be reusable for some future features too, like automatically downloading maps if not all players have it installed. It's half working now, so I'll try to finish it off tomorrow.

A while ago we asked for donations via Pledgie to support a developer doing full-time work on the game for a month, and had a great response. I'm currently able to devote that time to the project (I've just finished a PhD, and haven't sorted out long-term employment yet and can wait a while) so I'm going to start doing that now. This isn't meant to detract from the open source development of the game - instead it's an added opportunity to tackle some of the larger problems that can benefit from more concentrated work than usual. I'll use this forum topic to record my progress, so people can see what their donations are funding and hopefully get a vaguely interesting view into the development process. Detailed technical discussions should probably go in separate topics to keep things organised, but comments are generally welcome here My current (but quite flexible) plan of tasks to focus on is: Saved game support - particularly to allow players to reconnect to a multiplayer game after a crash or network failure, since large gameplay testing sessions are often annoyingly interrupted by dropped players. Saving single-player matches is also a frequently requested feature. Better tools for measuring the game's performance. We want to optimise various aspects of performance - overall framerate, consistency of framerate (i.e. avoiding occasional pauses that make the game feel jerky), better utilisation of multi-core CPUs, etc - and I think it's worth investing in new ways of recording and analysing performance so we can improve it more effectively. Better engine support for AI scripts - mainly to increase performance in various ways, and to fix some other areas that cause pain for AI scripters. More efficient pathfinder - one of the current algorithms can perform particularly badly with large numbers of units in a small area (e.g. melee battles), and needs to be redesigned to provide much better performance in those cases. This should be enough to get started with

The server hosting the download links was down for a few hours earlier today, so you might have been unlucky and hit that problem. It should be working again now

Hmm, I think the most relevant part is the main thread at 0 Id: 1d4c.1fc8 Suspend: 1 Teb: 7efdb000 Unfrozen "main" ChildEBP RetAddr 005cf428 773831bb ntdll32!NtDelayExecution+0x15 005cf490 77383a8b KERNELBASE!SleepEx+0x65 *** WARNING: Unable to verify checksum for C:\Windows\SysWOW64\atioglxx.dll *** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\Windows\SysWOW64\atioglxx.dll - 005cf4a0 6908085c KERNELBASE!Sleep+0xf WARNING: Stack unwind information not available. Following frames may be wrong. 005cf4b8 698bb436 atioglxx!DrvPresentBuffers+0x43dc 005cf530 698f0747 atioglxx!DrvPresentBuffers+0x83efb6 005cf544 698d767f atioglxx!DrvPresentBuffers+0x8742c7 00000000 00000000 atioglxx!DrvPresentBuffers+0x85b1ff but that doesn't look abnormal to me (it looks kind of like it's rendering and waiting for vsync, which is what it should be doing). Was the game frozen at the white screen before you did the "Break" in WinDbg? If so, I'm still not sure where the problem is occurring

Yeah, alpha 7 needs "CONFIG=Release" (or (the default) Debug); the current SVN version needs "config=debug" (or (the default) release). The inconsistency is a bit annoying, but at least it'll be consistent after the next alpha release

Looks like those debugging instructions need updating for 64-bit versions of WinDbg (which are the default on 64-bit Windows). I've updated that page now (the "If you are on 64-bit Windows" steps are new) - if you could try it again, that will hopefully give more useful information Also it might be helpful if you could open "%appdata%\0ad\logs\" in Explorer and post the system_info.txt file.

r10419 makes it mostly work for me in Linux in VirtualBox 4.1.4 with 3D acceleration enabled. (Occasionally the entire VM crashes though, so it's not perfect - 3D support in VirtualBox seems somewhat experimental.)

Jason recalls correctly - it has no effect on performance, it was just changed so the map fades nicely to black at its edges. We probably ought to design the skyboxes so they are black at the horizon (i.e. if you look horizontally along the ground, it'll be black below the ground and fade to colour above the ground), after changing the renderer so we don't waste half the texture for storing that blackness. (Actually we could probably do it entirely in the renderer by blending a fade-from-black texture at runtime, to save the effort of changing all the graphics (other than cropping the side textures in half), or something like that.) You can change the black by editing "skycolor" in the config file (see binaries/data/config/default.cfg).

Hmm, that doesn't sound like an expected problem. Could you try following the instructions on this page to find where the game is freezing? (It might help to press alt+enter to switch to windowed mode first.)

The Fedora 14/15 packages of the game say that they've been compiled now. Can't test it myself, so please let us know if it works or not

Oops - looks like you have an Nvidia motherboard (but ATI graphics card, which is the important thing), and I got confused by all the mentions of Nvidia OpenGL renderer string: Mesa DRI R600 (JUNIPER 68BE) 20090101 TCL DRI2 OpenGL version string: 2.1 Mesa 7.10.2 Hmm, other people have used the same drivers and I don't think anyone has reported the same problem, so I'm not sure why it'd fail . Maybe it's a problem in interacting with this particular hardware, since it seems more modern than what most people have tested with - has anyone here got experience with similar things? Those R600 drivers are largely obsolete now and replaced by Gallium-based drivers, but I can't easily see any way to switch to them on existing versions of OpenSUSE, so I'm not sure what to suggest.

The output of "glxinfo" may help too. If you're using the proprietary Nvidia drivers then the game really ought to work fine. If you're using the Nouveau drivers then it's not really expected to work (since they don't have full OpenGL support yet). It looks like you do have some text, on the buttons. Those are RGBA font textures, and it seems to be just the alpha-only font textures that aren't working. Yeah, we don't use any font support from outside of the game (window manager or external font files etc) - they're just pre-generated textures and should work identically anywhere.

stokescomp on IRC pointed to this bug causing errors like "Failed to mark '...\docs\internal' absent: item of the same name is already scheduled for addition" when upgrading. Might be best to wait for 1.7.1 which ought to fix that bug.

I happened to be playing Dragon Age (for, uh, research) and noticed that its unit rings always get rendered in front of terrain (e.g. they're still visible if there's a hill or wall between the unit and the camera), though rendered normally relative to units (i.e. not always in front). That solves the problem of the rings sinking into bumpy terrain and disappearing - they're visible even when underground. It'd also be consistent with our silhouetting of units - units behind hills are still meant to be visible, so their selection rings should be too. I think we could find a way to implement that effect for the selection rings if it'd look good. Also, as an attempt to record what I remember of a recent IRC discussion: it may be best to use this new single-quad-per-ring system for units (since they're small but there might be hundreds and they need to be reasonably efficient), and switch to the existing static line system (used for territory boundaries etc) for buildings (since they're large, and the rings ought to conform to terrain to look good (probably, unless the render-in-front-of-terrain effect would work here too), and there won't be many at once and they don't move every frame so they can focus on quality over performance).

I've not had any luck yet getting someone to change the libenet configuration, so I filed a bug which hopefully someone will notice

I just upgraded from TortoiseSVN 1.6.12 to 1.7.0 (on 64-bit Win7) and upgraded the working copy, and it seems to have worked with no problems. This is with the non-public SVN URL, not the public read-only one; I'm not sure if that would cause a difference.

Could you possibly post a screenshot, too? (Broken drivers are known to cause problems with everything except text being invisible, but I don't think I've heard of only the text disappearing, so I'm not sure what way it's breaking.)

The macro is valuable for Doxygen - we run it with PREDEFINED = "UNUSED(x)=x" so that it knows the names of the unused parameters, and I think using comments would break that. (Also I think using comments is more ugly than the current macros, but that's not a particularly technical argument )

It looks like the default settings for the 'games' project on the OpenSUSE Build Service was changed to not include Fedora. I've changed the '0ad'/'0ad-data' packages to re-enable Fedora - hopefully that'll work fine and be uploaded within an hour or so. Edit: Actually it might be longer - need to find someone to re-enable the libenet package too, before the game will build.

The main thing we use shell scripts for is to automatically build some third-party libraries that aren't ubiquitous enough to assume the user will already have them - the rest is just done with Premake (which runs some Lua to generate Makefiles). I don't particularly like the current system, but I'm not really sure what would work better (without e.g. entirely replacing Premake with CMake, which I played with a while ago but seemed like probably too much effort to be worthwhile) - do you have any specific suggestions that would likely work well? (I'm happy to implement people's suggestions if they sound worthwhile and they don't want to work on it themselves ) With our current system, you could symlink build/workspaces/gcc/ onto a tmpfs and I think that should basically work. Not ideal, though. We only have pre-built Windows binaries - the ones in SVN's libraries/*/lib/ are so developers on Windows can compile the game without having to separately download a libraries package, and the ones in binaries/system/ are for non-programmer developers (e.g. artists) on Windows so they can get the latest version of the game without compiling themselves, and also so programmers can use the .pdb files to debug crashes from non-programmers running those pre-built executables. It's all in SVN so that the binaries stay in sync with the code and data files, and people won't have to worry about running special update scripts instead of standard TortoiseSVN. Again, I don't particularly like the setup but I wouldn't want to change it to something that's less convenient for Windows developers, and don't know what would work better We use binaries/data/ for that, so it's still separated but a bit more nested (for historical reasons). Moving binaries/data/ to data/ and moving binaries/system/ to bin/ (or bin/win32/ or something) could work, but I'm not sure what the benefit would be. "./update-workspaces.sh --with-system-enet" uses the non-bundled copy, and there's a patch to add "--with-system-spidermonkey". We use a quite substantially patched version of FCollada so there's no non-bundled support. Non-bundled NVTT could work except the latest release has some bugs and no distro seems to ship a sufficiently patched version, so it's been safer to stick with bundled, but that could be changed. None of the other things in libraries/ are used on Linux (they're only for Windows). Do you mean linking the different modules of the game, or linking to third-party libraries? For the latter, I thought that just depends on how those libraries are compiled (which isn't our responsibility). For the former, I'm not sure what the point of dynamic linking would be - the only reason we split the code up at all is to allow parallel builds in MSVC on Windows, and it all gets statically linked together at the end since all we want is an executable. So I'm unsure what you're suggesting

Just click the relevant "Instructions for ..." link on the release announcement - if you're on Windows then it's a simple downloadable installer and shouldn't be a problem at all . Then it has a menu screen and single player skirmish mode with AI enemies, so it should be easy to get started and try it out.

iOS doesn't even support Java; it's mainly Objective-C and C and C++. Android's NDK supports C++ too. The main effort would probably be in porting all our rendering code to OpenGL ES, and then dealing with CPU-specific features, and then worrying about how to get adequate performance at least on high-end devices, and then worrying about how to make a sane input system and UI.

I don't think we should be particularly wedded to our current design by thinking the gameplay will be perfect, but I do think at our current stage we should focus on getting a complete implementation of some (any) design, and redesigning already-implemented features won't get us any closer to that, so probably best to avoid much redesign now if we ever want to finish . But once we do have a complete implementation (maybe during beta releases or something), it could be fun to do prototypes of radical new designs as mods - I think the idea in this topic (and the alternative combat system too) should be fairly easy to do, at least if we ignore AI and don't worry about pretty UI, and then people could play with it and see what ideas are fun in reality, and after the first final version of 0 A.D. we could maybe spend more time developing the successful ideas into a new variant of the game.

Saving will be just as easy to implement for multiplayer as for single player. The trickier part is loading . (I guess we'd have "saved games" in the map list on the game setup screen, and the host can select a saved game which they have, and then it'll download it to every player before starting the match, which is a bit of a hassle but should be feasible.)

It's included by source/pch/engine/precompiled.h which is included by those source files when building with the correct include paths. (That's probably a good reason to build with Premake on all platforms, so we don't get unexpected problems due to subtly incorrect build configurations )