historic_bruno

Thanks! Now that's interesting, is that a netbook? The AMD C series is apparently CPU with integrated GPU, so I think concerns of performance are valid, integrated Intel graphics for instance tends to perform relatively poorly (and worse, has buggy drivers). I would still suspect drivers or overheating (especially with it causing shut down), but you could test both by trying other strenuous 3D games on the same hardware on Linux.

That sounds like a very inefficient approach to the problem. I think for that case it would almost be better to somehow adjust the mesh itself to conform to the terrain. We could also consider myconid's work with grass that was rendered by shaders.

Could you find and attach system_info.txt from the game's log directory? That will give us more detail about your system specs.

Fixed in r13536

Ok, that looks like the problem indeed, we should have a fix for A14.

Can you confirm it's a regression from A13?

Thanks for providing the crash logs. What is your graphics card, is it using Nvidia Optimus with both integrated and discrete graphics? Unfortunately the crash log doesn't tell me, because it's crashing early while detecting the graphics card, but the call stack is identical to #1952: > nvd3d9wrap.dll!724c89b4() [Frames below may be incorrect and/or missing, no symbols loaded for nvd3d9wrap.dll] pyrogenesis.exe!wmi_GetClassInstances(const wchar_t * className=0x01323a28, std::vector<std::map<std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> >,tagVARIANT,std::less<std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > >,std::allocator<std::pair<std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > const ,tagVARIANT> > >,std::allocator<std::map<std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> >,tagVARIANT,std::less<std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > >,std::allocator<std::pair<std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > const ,tagVARIANT> > > > > & instances=[1]([...](...)) Line 123 C++ pyrogenesis.exe!wgfx_CardName(wchar_t * cardName=0x0015e978, unsigned int numChars=128) Line 143 + 0x13 bytes C++ pyrogenesis.exe!gfx::CardName() Line 45 + 0x17 bytes C++ pyrogenesis.exe!RunHardwareDetection() Line 226 + 0xa bytes C++ pyrogenesis.exe!InitGraphics(const CmdLineArgs & args=, int flags=) Line 933 C++

Great, glad it's working for you again

We'll need more information to troubleshoot the crash. Can you run the game in gdb? When the seg fault occurs, it should break into gdb and then you can post the full back trace here (command: t a a bt full). That will provide some clues.

Is this reproducible? Can you provide the commands.txt log from that game? It can be found in sim_log inside the log directory (they are ordered by process ID, sorting them by date sometimes helps find the right one)

Thanks for responding and it's good to hear that's still important Actually even very small differences across platforms matter to us, because we do a hash of our binary simulation state to detect if a client goes out of sync. Even one bit difference is an OOS (as I've discovered recently where NaN can have different internal representations possibly due to JIT behavior/bugs? - which is fine according to the spec, but a headache for us). This is why we are implementing our own Math functions for trig, pow, exp, etc. Assuming the last comment from this bug report is still valid, and like Philip I can't blame you all if it is.

Something worth investigating if we upgrade Spidermonkey, we've been having a discussion about Spidermonkey floating point math (spurred by #1633, #1990 and #433), does the new Spidermonkey still try for consistent floating point rounding on different platforms? In the past, some people cared enough to find and fix any discrepancies that popped up, but that bug report is 4 years old and surely much has changed.

The date for feature freeze has been pushed back a few weeks to allow us to get more into A14, you can follow the planned release dates here: http://trac.wildfiregames.com/roadmap The multiplayer lobby is looking unlikely at this point, there are too many questions, but we'll see.

That might be possible if we cached the pathfinder's terrain passability at the start of the match. Entity position would use the actual updated terrain, I suspect that would look decent. The difficulty sanderd17 brings up is that Atlas in fact reuses the gameplay logic from matches, so we have to add more special cases for Atlas-specific behavior.

This is a huge change, we're basically dropping support for lots of older compilers if we do this, and I don't know if the gains offset that. Syntax is a small thing really, people have been reading ugly C++ syntax for decades, it won't kill us. Boost is a dependency of the game, so unless C++11 adds everything we need from Boost (unlikely), does it really matter if C++11 adds a few of them? So it seems to boil down to performance, can we get some measurements of C++ boosting the game's performance in practice? Also let's make a list of known compilers that do and don't support this, and which OSes will be affected. Maybe we can get Philip to provide updated usage stats of the game and see how many people use those OSes (approximately anyway).

http://trac.wildfiregames.com/ticket/21 - I really think we need to test and consider carefully terrain changing during the game. Currently it's not something we even need to worry about (Atlas is a special case, so we do have to handle dynamic terrain modification in the engine, but Atlas is also buggy).

That's strange, I don't see that error. Do you have any local modifications? Also, by latest revision do you mean r13496? Does this problem occur for earlier revisions?

Excellent work again you two, I hope we can get these new creatures in the game soon?

How would anyone know it was a significant problem in 0 A.D. without data to show it? In particular I'd like the discussion about 0 A.D. memory fragmentation to be steered toward determining if it's a significant performance problem (we can all agree it is in theory).

Are you both using the exact same version of 0 A.D.? If so, it would be helpful to see both of your oos_dump logs, you can find them in the game's log folder (look for oos_dump.txt, and you may need to zip it first, if too big to attach here)

Should be fixed in r13489, please test!

Very very nice!

That crashlog is the same as the first you posted (same timestamp and contents), from some point when incorrect drivers were installed, they look correct now (hopefully you installed them from the official AMD site http://support.amd.com/us/gpudownload/windows/legacy/Pages/legacy-radeonaiw-vista64.aspx). It sounds like a different issue, if the computer freezes or turns off during the game, it's likely not going to create a crash dump. Any chance it's overheating your graphics card? You could use some utility to monitor the temperature during the game. It could also be some other defective component, like the power supply or motherboard. Definitely try some other demanding 3D games to see how it holds up, if they are OpenGL based it's even better. Lastly, you could try disabling some of the game's advanced graphics settings to test if that makes a difference.

I don't see what translation necessarily has to do with modders, unless they also want to be translators, but those are two separate groups with different needs. The way I see it, the only people who should care about translations are: 1) Non-English players who need them 2) People who actually translate the game 3) Programmers who implement the translation system Frankly, group (1) won't care in the least how it's implemented, as long as it works. Group (2) will care, and we have several of them saying we should use a standard system, and they are providing links to communities and tools built around such systems. Group (3) will do whatever needs to be done, so I think the focus shouldn't be on what's simplest to program today, but what makes translation work as well as possible now and in the future. If I'm understanding the concept correctly, we will have in either case a tool that extracts translatable strings from the game data (XML, JS, whatever) and creates .po or .txt files. So the average modder need not know anything about translations, they will write their mod following the conventions of 0 A.D. wrt/ translation support, and then whoever from group (2) does the translating will use the same process as those translating on the game proper. As far as I'm concerned, the average modder shouldn't care or need to care much about the process of translation (unless they are also a translator, in which case they approach it from that p.o.v rather than modding) We're not a proprietary project. And on the contrary, my experience with 0 A.D. is that the clever solutions programmers came up with over the years, to avoid using existing 3rd party libraries and obvious solutions, tend to become very complicated over time and are now the most fragile parts of the engine, because nobody in a few hours of work can foresee all the issues of a complex system that others have encountered over potentially decades of development, and they're no longer around to maintain that fragile code. From a simplicity perspective, if you look at the patch on http://trac.wildfiregames.com/ticket/67, that solution doesn't look particularly more complicated than yours, most of the patch is source for the tinygettext lib, so we're using other people's work there instead of our own, while the changes to the engine itself for GUI XML support are trivial. Can you explain why that approach would be noticeably less efficient than yours, as I understand it's only a matter of loading the .po's into a dictionary instead of .txts? We can benefit from compiling the .po's into binary .mo's for faster loading, if necessary (in fact my suggestion would be that we integrate that into the archive builder and preconvert them for releases, like we already do with XML, DAEs, and PNGs). (Of course we can't have a fair comparison until both approaches are working with the same data, GUI pages will be messier to translate in any case than entity templates, and we don't yet know how the approach of #67 will extend to entity templates) Can you elaborate on our needs that gettext doesn't meet but that your solution does? Nothing hand wavy like "it's easier for modding" without evidence that modders should be constrained by our choice of translation system. So far the argument is sounding like we need to justify using the proposed arbitrary .txt format and get around its shortcomings, and create another tool to convert between .po and .txt to work with everything that's already compatible with gettext, which is a very strange angle to approach this from. ...which historians are we speaking for? If you're saying non-programmers don't want to edit XML files, I fully agree, that's why we should have a GUI-based entity editor for Atlas. That is certainly worth putting effort into and part of having an easily moddable game. Currently an entity editor really only needs to be an XML parser with a GUI generated from the schema, anyone could write that and someone should, it becomes more complicated if the actual text data of the entity is replaced by a key into a proprietary .txt file that needs a custom parser and dictionary. For the historians, finding the correct entity to change would be no more difficult than searching by plain English keywords, kinda the way the object panel of Atlas works now. But there's always the simplest non-technical solution: we could have the historians create a Trac ticket with their suggested changes, which a developer commits in the appropriate file. Or they could ask which file to modify and how to do so, I think if they did this once, it wouldn't need explaining twice, it's not exactly rocket science to figure out the entity template naming conventions and as you say, Notepad++ is more than up to the task (if they make a mistake, that's why we have SVN/git) Any evidence that text loading and storage is a performance bottle neck in 0 A.D.? Honestly, I would be delighted if that was the case, it would mean we squashed all the other more serious one. What about evidence that using a gettext-based solution will be noticeably slower than yours? (As I've said before in discussion of the GUI system, I get like 800+ fps on the main menu, so there's clearly some wiggle room there, and I haven't seen any evidence that game lag is caused by text display/rendering/storage)

I believe it already filters by entities with UnitAI, i.e. only mobile units, so that wasn't the problem, rather it was a special entity used by formations. It should be fixed by r13484, please test