janwas
-
Posts
2.733 -
Joined
-
Last visited
Posts posted by janwas
-
-
Given that "nothing endures longer than temporary measures", I suggest we make config visible (i.e. storing in PERSONAL) for now, and I don't see any harm in making it permanent.
(Users will never want to look for these files on their own initiative, it'll only be in response to us telling them to look for them, so there's no value in the location being intuitive.)hehe. I actually know one crazy dude who has started 0ad with the express intention of having system_info.txt generated (there's some info there not provided by dxdiag).
Besides the issue of intent, I think the frequency of error reports might increase slightly if users have already seen those files when browsing through the personal folder.
And finally, what is the harm in putting anything of potential interest to the user in My Documents? I actually see a benefit: folders outside of that are potentially wiped out if someone does a system restore, whereas anything within My Documents is safe.
(This argument also applies to storing saved+recorded games in My Documents, which I now endorse.)
As to local vs roaming: I might actually change the interface to call the Windows function directly, since we call those functions exactly once. That would get rid of the boilerplate concern.
However, what I suggest is just storing everything in local. Who is going to expect a game they installed on two computers to maintain the same config on both? It's not even clear to me that that is a good thing (monitor resolution may differ). And I don't know if there is a Linux version that supports the same. If not, people would have to copy the config dir anyway.
Ooh, I am a bit concerned about the "0 A.D.". We're already buying into the "let's pray we support spaces correctly" game with "My Games", but at least that has a decent chance of success on Windows. However, if you change from 0ad, we should probably also rename it on other platforms, and that might also cause problems.
Is it that important? I don't mind 0ad, and precedent for that exists in the form of our URL.
Update (I hadn't seen Ben's post)
My Documents\OpenTTD is used for all content downloaded in the game, crash dumps, logs, saved games, scenarios/maps, and config files - anything created while the user plays the game. Not that we have to copy what others do, but it's a least some precedent.Thanks for the example! To be clear, I would think it is good to store potentially bulky and unimportant stuff (i.e. the cache) outside of my docs, because otherwise we would unnecessarily slow down any backups users make of it.
But pretty much everything else in my docs? Sounds good to me.
-
A quick search reveals:
(http://en.wikipedia.org/wiki/My_Documents)As of 2010 "My Games" (or "Saved Games" since Windows Vista) is becoming an increasingly common place for games (especially those published by Microsoft Game Studios) to store a player's saved game and settings files
(http://www.uesp.net/wiki/Oblivion:Directories)More generally: PERSONAL\My Games\OblivionNote that "My Games" does not localize.
Programmers can use the aforementioned SHGetFolderPath API function to get the value of PERSONAL.
I agree that PERSONAL (i.e. My Documents) is more appropriate for anything the user would want to see, and IMO that includes log files (especially crashdump) and at least for the moment config, because people are indeed changing them.
As per the above, we can gladly tack on a non-localized "My Games".
However, it would be nice to simplify your suggestion.
The current interface for returning paths requires a bit of boilerplate
to safely handle being called before static ctors, so adding interfaces for
both localAppData AND Personal would be a bit onerous.
Do we really care about the distinction between local and roaming? Does anyone actually use that? (Ever since we switched to a group policy at work whereby the desktop and my documents are stored on a server, Windows is rather slow to start unless I keep both of them very much empty
)I'm also not sure why saved games need to go in My Documents, since those are managed by the game. I imagine the only use for putting them in My Documents is being able to delete them easily. However, I don't see any harm in putting them in My Documents.
Here's a revised proposal:
Appdata: installation, cache, maybe remote mods (unclear who writes it there, though)
My Documents/My Games/0ad: config, logs, screenshots, saved games, local_mod
Sound good?
(@Philip: I hope this topic doesn't distract you for more than 5 minutes
) -
I am happy to change our "appdata" directory to any standard Windows location.
Please see the documentation for SHGetFolderPath:
http://msdn.microsoft.com/en-us/library/bb762181(v=vs.85).aspx
We are currently asking for CSIDL_APPDATA - see wutil.cpp:294.
Which one would be preferable?
(Although this function is "deprecated", note that the
newer known-folder functionality is only available
starting with Vista, which is unacceptable for us.)
-
I'd really like to find+fix this. I believe the last status shortly before leaving was that I'd managed to reproduce it more often and also added additional output for when it happens. Will resume work on it on Tuesday after returning.
-
The Aken driver provides access to I/O ports and mapping physical memory, which allows accessing hardware timers not supported by WinXP. Without this, we are prone to various timer bugs (skipping forward) and inaccuracies.
If interested, you can check out the source code - search for aken, mahaf, whrt.
Unfortunately the code signing certificate issued to me seems to have a problem, or I bungled the signing somehow. It used to work, but a Windows update has resulted in even tighter restrictions, so it currently refuses to load. If anyone is knowledgeable on this topic, I would appreciate any advice.
-
hrm, I'm torn between wanting to detect problems and avoid annoying messages.
A negative elapsed time can happen on multi-core systems if the timers diverge
(but there was a hotfix from AMD at least to prevent that) and we're switched
from one core to the other.
However, if it happens regularly, then something is awry. If that's the first
time you see it (and it certainly is the first time I see such a report), it
would probably be better to keep the warning in; otherwise, we could remove it.
-
Graphics memory is fine and useful, but the game only uses a grand total of a couple hundred MB.
The problem is that your graphics card is too _slow_. If there were no need for them, who
would buy separate graphics cards from ATI/AMD or Nvidia?
-
huh, I know of no such deliberate feature
It just so happens that unit commands are implemented in JavaScript and the camera movement is done from C++.
The behavior you observed may be due to the interpreter simply dying or running out of memory.
I realize this kind of thing is really hard to duplicate. For instance, the replay logger runs for the
duration of the game, there is no support for flushing it when something goes wrong.
If, however, you run another long game, would you mind telling us the JS script statistics,
accessible by pressing F11 twice? It's rather likely we are simply running out of heap space.
Maybe the others will have further ideas, too.
-
Hi. Regarding sound - are you using PulseAudio? There have been frequent reports of trouble with that backend; you can try configuring OpenAL to use ALSA instead.
The feedback mechanism is currently only for the computer configuration and does not collect any personal information. It results in the very helpful http://feedback.wildfiregames.com report. You can inspect the source code in source/tools/webservices.
-
Unfortunately the Intel integrated graphics are just too weak to run the game properly.
You can, however, try to disable some of the settings in config/default.cfg:
fancywater = false
shadows = false
shadowpcf = false
-
Thanks for the fix! That also works on Windows (MSC and ICC), which is surprising because I can't see them documented anywhere.
-
Added a WELL based on the GPG code that seems to match the behaviour of WELL512a.c; hopefully there's no blatant problems with it.
Looks good!
I guess I should move the mt19937s over to it, and probably switch the rand48s too (Math.random() in RMS and AI and simulation scripts) since why not.That'd be great
-
Good golly gosh, the Boost seeding code is opaque as always
The Diehard battery of tests is frequently used to judge RNGs:
http://www.stat.fsu.edu/pub/diehard/die-c.tar.gz
There's also a "dieharder" which I'm not familiar with:
-
Because you mentioned that downgrading Boost fixed it, I would presume this really is a Boost bug.
That aside, I really cannot understand why the over-hyped, over-sized (we're talking a significant chunk of L1 dcache) and overly long (2**19337 possible states is FAR more than the number of atoms in the universe) "Mersenne Twister" is still in use today. One of its developers had a part in developing the more recent WELL:
http://www.iro.umontreal.ca/~lecuyer/myftp/papers/lfsr04.pdf
They also provide an implementation: just remove the final conversion to double:
http://www.iro.umontreal.ca/~panneton/well/WELL512a.c
A second, somewhat simpler implementation has been described in GPG7: http://www.lomont.org/Math/Papers/2008/Lomont_PRNG_2008.pdf
Regardless of the Boost bug, I would welcome replacing MT19337 with this seemingly superior in all respects generator.
-
huh. Just FYI, I do refer to it as Null Ah Deh, and have yet to hear any comment that it sounds ridiculous
-
Our design predates the widespread availability of multiple cores and logical processors.
While we do have a few threads, it is very difficult to retrofit scalable parallelism into game engines.
-
Red Alert had a rule where buildings had to be placed within 2 tiles of an existing building. Since it was helpful to establish outposts, people built a long chain of really cheap storage silos to the desired location (a so-called "spider base"). That obviously defeats the intent, and the same is possible with our houses, therefore I think it might be a good idea to prevent that. Besides preventing this abuse, I don't see much harm, since houses would probably be built within the radius of CC or fortress anyway.
I'm messing with the entity templates now, but I'll wait to commit any changes for testing until the entity reordering is committed.A word of warning: if you have any local changes to those files, and then merely svn-update them to receive the changes from the entity reordering, then your SVN client is probably going to go bonkers and complain that it can't automatically choose between your changes and the reordering. That will insert lots of "<<<<<<< this is your version ======= this is the reordered version >>>>>>>" markers, which are a PITA to resolve. The easiest way to prevent this is to revert your local changes before updating; you can also revert after the update to fix those conflicts.
Apologies if you knew that already - not sure how often you use the text merging features of SVN.
-
Hey, congrats, looks good already, and I imagine territory borders near mountains aren't the common case, anyway.
Glad it was possible without resorting to more complex implementations
-
If I had known how much trouble delay loading would be, I might have Just Said No
At least one DLL - user32 - refuses to be loaded more than once (this can happen if you delay-load something that pulls in user32 before any of its other dependencies loads, and then unload it again), and now we have the OpenAL issue.
In this case, delay-loading OpenAL only helps when launching with -nosound or the old -quickstart, so it's safe to disable permanently.
-
heh, sorry for that shock
Die Siedler III is admittedly really old, like ~12 years, and 2D.Assuming that no nicer boundary-stone type thingies can be devised, there is yet another alternative:
We can have OpenGL evaluate the spline for us! I think the magic word there is GL_MAP_VERTEX_3.
That can be used to implicitly generate geometry. Quake III was doing this in a similar timeframe,
so I wouldn't imagine hardware compatibility to be a problem. IIRC, this was for Bezier curves
(i.e. Bernstein basis functions), but as Philip's demo has shown, the exact type of spline
doesn't really make a big difference.
This would avoid the need for polygonal approximation. I'm also hoping we can avoid having to
clip vs. terrain tris by lifting it high enough off the ground and introducing enough points
that it wouldn't dip into the terrain often. Perhaps the texture can be made `blotchy' enough
that it wouldn't matter tooo much if it sometimes disappeared below terrain.
// edit: I agree with Ben that a geometry-based solution (which includes the abovementioned
OpenGL evaluators) is preferable.
-
hrm. I liked Michael's smooth lines, but it seems surpringly tough to render them in 3D.
There is a not so crazy alternative: we could just place some "buildings" along the contour -
think tiny marker stones or something.
Obviously they would have to be tiny and not hugely detailed, since there are lots of them,
but we could reuse the building placement logic (except for flattening terrain) and
kind of dance around the smoothing problem, since there are gaps between the stones anyway.
"Settlers" did something like this: http://www.settlers3.com/strategy/multiplayer/images/romans/060.jpg
-
(there is probably an easier way to get this, but this is what I know) ;-)
We have some code to retrieve it, too
On Windows, it gets written into %appdata%\0ad\logs\system_info.txt . -
Philip helped me with some things and it works now!
Great news, congratulations
and thanks, Philip, for the assist!The patch looks good. Feel free to commit, as far as I'm concerned.
Attaching system_info.txt to verify it does whatever it needs to do.Looks good except for the CPU frequency. Intel CPUs mention their
intended clock rate in the brand string, but it'd be nice to measure the
actual frequency (to detect over/underclocking) at runtime.
We actually have code to do that, it's just not being called.
I intend to fix that later today.
-
Interesting, haven't heard of any similar reports.
Scrolling may expose additional objects. If you haven't seen them before, the game will first convert their data file to a faster representation.
Does it still happen in a game without an AI player? If not, then you're probably CPU-bound.
You can also press F11 several times to cycle through the in-game timing information we record. The hierarchical profiler will tell you where time is currently being spent. Do you notice any particular spikes or obvious changes after scrolling?
Modding 's gotta be sooo hard, or not?
in Game Modification
Posted
Thank you for your feedback! We have undertaken a bit of effort to ensure modding is possible or even painless, and I am glad to hear it has had a noticeable effect