-
Posts
2.733 -
Joined
-
Last visited
Posts posted by janwas
-
-
using the generic name "timer" in the global scope is more likely to conflict with other code
True. It's on the back burner for now as I've already left for Singapore; we'll see what the new employer's policy is.
And yes, naming is especially hard for this kind of miscellany. jwlib isnt so bad, cbloom appararently reached the same conclusion with cblib
Cool, thanks! I am looking forward to seeing this data.I failed to do this earlier, but I've added it now, so I'll wait another while then look at the data.
-
PPC support is not even on the table, unless a community enthusiast wants to develop and test that When we say "universal" we are only meaning 32/64-bit Intel.
Yes, just to expand on this a bit - there would probably be some additional pain due to byte alignment and endianess (PPC is stricter/different on both counts). That's why we have always assumed only x86/x64 would be supported.
-
To expand a bit more on Philip's entirely correct reply:
The message just means the platform/BIOS does not provide a HPET, so activating it understandably fails
r10858 will indeed stop this from appearing, because we would no longer even check for the HPET (unless the user takes additional action by invoking aken_install.bat).
I am not sure why the error code isn't resolved into an error string - that's worrisome and will be investigated tomorrow.
-
Cool, glad you fixed it
I am a big believer in symbol information in general.
It is apparently possible to force a PDB to match:
http://stackoverflow.com/questions/744870/how-can-you-change-an-age-mismatched-pdb-to-match-properly
That looks too crazy even for my taste, though, so it'd
be nicer to always commit PDBs of any code of ours that
might possibly crash
I don't think the AtlasUI symbols depend on wxW -
did you have any particular problem in mind?
-
Thanks for mentioning so. That is indeed the expected behavior on Win7 x64.
The error message is misleading or false in that the driver is not unsigned - it is just not signed with a special Microsoft certificate.
You can work around it by enabling test mode (see aken_install.bat) or launching the game with the -wNoMahaf command line switch or updating the game to the most recent SVN revision, which no longer attempts to start the driver. (It will still be accessible if you have used aken_install, though.)
-
OK. If it's difficult to repro, perhaps we can see the problem from this crashdump once the symbols are available.
It's great that you posted it
-
Bummer, sorry to hear that.
Presumably you were running with the latest binaries from SVN?
Unfortunately we don't have symbols for AtlasUI.dll in SVN.
@Philip - would you please add them?
-
I think it would be enough to just report timer_Resolution.
(Incidentally, a colleague asked to namespacify timer.h, turning it
into timer::Resolution etc - any objections?)
The current code only allows choosing one timer (the best
available) and it'd be a spot of a bother to get them all.
However, we can still deduce a lot from that - presence of
an HPET can be gleaned from the chipset (i.e. CPU), and
I would recognize the other timers based on their frequency
(because the CPU frequency is also known).
Let me expand on the 1 ms. That's only if somewhat calls timeSetPeriod
and speeds up the timer interrupts to 1 kHz, which can slow down
the entire system by 10-15% and reduce "battery run time on mobile
systems by as much as 25 percent" [http://download.microsoft.com/download/3/0/2/3027D574-C433-412A-A8B6-5E0A75D5B237/Timer-Resolution.docx]
Certainly not an ideal solution, but it's still better than the
default of 15 ms (!), which is just terrible. And I suppose the
driver, while evil, may still be an attractive option on WinXP
laptops with semi-decent graphics cards.
As to falling behind, here's someone mentioning > 5 s slippage in about
30 minutes play (= 2777 ppm), which apparently took down their
network protocol:
http://osdir.com/ml/games.devel.windows/2002-09/msg00000.html
That's FAR worse than thermal drift, which is on the order of
200 ppm for a really grungy oscillator, and maybe 20 ppm for a
decent quartz.
However, if the network protocol is quite robust to such things,
then we can maybe forget about the slippage. I have no idea why
the previously mentioned game had that problem, but doubt it was
because the developers were idiots.
Good point about the spirit of the GPL. As you can tell, I really
hate the new driver signing hoops, especially because it's to
prevent circumventing DRM (which is truly something that removes
user control). As is, the driver was designed to provide all the
requisite possibilities and therefore not require changes.
Unfortunately that does bring the security issues with it :/
Changes to the driver are actually still possible - the current
signature is no better (actually apparently worse) than some
self-signing thing that could fairly easily be managed.
aken_install would still need to enable test mode, and
additionally just install a certificate.
That said, I agree about the insecurity and scariness. Again, it
comes down to how we balance that vs. battery life or timer problems.
Maybe we'd be best served with some kind of opt-in thing, which
is basically what aken_install already is. I have therefore
disabled StartDriver by default in mahaf.cpp.
Anyway, it certainly would be interesting to get that data
on the number of people with bad timers. Would you please
add timer_Resolution to the hwreport?
-
Thanks for joining the forum to post your concern!
I imagine the similar winring0 library also removed most of its
functions after version 1.3 for these same reasons.
Let's begin with the signature. You will find it to be
basically OK and trusted by a root certificate, so the
driver's integrity and source can at least be established.
However, Vista and Win7 have apparently started requiring
an additional bit in the certificate, and I'm not clear
on which. "Basic Constraints" and "Key Usage" are marked
with an exclamation point, so those are probably the
culprits. "Digital Signature (80)" looks OK - maybe they
also want an additional one for kernel-mode drivers, but
I haven't come across mention of this and don't see which
of the other possibilities it would be.
Basic Constraints is AFAIK used to limit the chain length,
and I can't do anything about that. Indeed one problem we
are facing is that the certificate is from Fraunhofer,
but I will be leaving their employ within 2 weeks, having
finished my PhD. We therefore cannot count on changes to
the certificate or driver.
Now let's look at the situation concerning driving loading.
Due to the above issue, x86 Windows Vista and later will
refuse to start the Aken service. The x64 versions of
Windows are even more restrictive - they require signing
with a additional "cross certificate". On all of these
systems, the driver will not load unless the user disables
CodeIntegrity checks (resulting in a warning ever time such
drivers load) or enables test-signing mode (which
aken_install.bat is equipped to do). The latter is also a
security hazard in that it allows anything with a semi-decent
(even self-signed) certificate to load. Ironically enough,
the bone-headed attempts at securing the system by effectively
disallowing independent drivers lead to less security. You
will find a similar approach here:
http://www.freeotfe.org/docs/Main/impact_of_kernel_driver_signing.htm
On WinXP x86, the driver will actually load without user
intervention - unless the command-line argument -wNoMahaf
is given. That system is also where normal users' need for
the driver is greatest, because the time source may only have
a resolution of 1 or more ms (too low for game usage) and even
fall behind over time.
So, where to go from here? On the one hand, we could argue
that WinXP is totally insecure anyway because everything
basically runs as Admin. mahaf.cpp could easily examine the
Windows version and act accordingly. We can also throw
up our hands and say we'll do timing as badly as other
games - though problems have been reported, at least we
won't be alone. For example, -wNoMahaf could be made the
default by means of a windows shortcut. It could also be
done from within the game code, but hopefully in such a
fashion that the apps at work don't need an EnableMahaf()
call to be added. On that point - again, I will soon be
switching jobs, and the new employer is quite careful with
IP rights. It is possible that I will no longer safely be
able to contribute to 0ad - that will need to be discussed
with them first. (It would be a shame, because then the
codebase - which I am sure will continue to see use - would
fork and no longer be updated.)
One final point - the driver is also used at work to provide
access to the performance counters, some of which are not
available in VTune/Parallel Amplifier (e.g. Nehalem uncore
for bandwidth/memory controller measurements). This requires
write access to the MSRs. Moving all the logic into the driver
would be possible, but another huge change that won't happen
quickly, i.e. within the next 2 weeks.
So - what's y'all's opinion? How shall we proceed?
-
Hi! Unfortunately you'll need more than an integrated graphics card to run the game.
It's most likely a video-related crash, possibly because the driver is erroneously reporting support for an extension we require.
Please give it a try on a system with a dedicated graphics card and ensure your driver is up to date.
If it still crashes, please also upload the .dmp file (very important for analyzing other types of crashes) and we'll have a look.
-
These questions are all directed at Philip, but maybe I'll save him some time
IIRC, the shaders were intended to simplify the code and reduce the number of combinations that had to be implemented.
Shaders sometimes decreased the performance, but can also lead to improvements vs. equivalent fixed-function stuff.
I do not know the rationale for the OpenGL3+ extensions. They're not currently in use - perhaps only for completeness or for other applications.
We could print the extensions, but I am wondering as to the intended application.
It would be possible already to grep for ogl_HaveExtension and gather the list, and then match that against those reported in logs/system_info.txt .
The capabilities database requires an analysis tool to be run on the server; that needs to be triggered manually, and I guess it hasn't been done in some time.
-
Let me add to that a little bit. The one-time conversion to DDS/S3TC is actually rather compute intensive if you care about quality, because it involves finding the optimal 2 colors for every 4x4 block, which is quite a bunch of combinations.
If you suspect or would like to probe for other slowdowns, you use the TIMER_ACCRUE functionality documented at http://trac.wildfiregames.com/wiki/EngineProfiling .
Anything that gets into the gigaclock range after a minute or two is something we should look at
-
A minor note on telling whether apps are 32-bit: you can see the Task Manager process listing. If "Image Name" ends in "*32", it's running in 32-bit mode.
That applies to about half of the processes I currently have running, so we're in good company
-
That's a very good point. I don't see a way to get commented-out names into Doxygen.
There are not THAT many unused parameters, but I agree they should be mentioned in Doxygen.
The commenting-out idea is dead in the water as far as I'm concerned.
Any ideas for better (but still short) names for the macros?
-
We have two macros for annotating code and preventing unused argument/variable warnings.
void Function(int argument1, float UNUSED(argument2))
{
ASSERT(argument1 == 0);
UNUSED2(argument1);
}The first argument is used only in debug mode, so we need UNUSED2 to suppress the warning.
I never did like that name for the macro, but UNUSED_VARIABLE is a bit too long, and naming
UNUSED differently would be even worse in that regard, because it sometimes occurs several times in parameter lists.
I just had a simple idea - how about replacing UNUSED() with a C-style comment: float /*argument2*/ ?
That shortens the parameter list and leaves the UNUSED name for the current UNUSED2.
Any objections or suggestions for further improvement?
-
Great, thanks for sitting down and implementing this! Very useful feature indeed (for optimizing build orders >:-) ).
-
Thanks for the report, this will serve as a warning to anyone wanting to upgrade
A search for that error message didn't turn up anything. Might want to report it to the SVN mailing list.
In the meantime, it's probably best to check out a fresh working copy with 1.7 (or downgrade as you've mentioned).
-
Thanks for the report! I was not aware about the restriction on definitions and still haven't found any mention of it.
The closest is http://www.mail-archive.com/commits@stdcxx.apache.org/msg00960.html, which also use the separate DEFINE/DECLARE approach. It's ugly, but preferable to possible pessimization via throw(), so I'll go with that approach.
Am about to commit a fix; sorry about the breakage.
-
I concur. There used to be some trouble with the resulting project, but we ruled out the new Premake4 stuff as the cause, and it has since been fixed.
-
Yeah, I think we agree on that (cache in appdata, everything else that's writable/generated in my documents).
I was just pointing out that the Program Files option is going against the rules and intent.
If you are thinking along the lines of making modding easy (hence everything in Program Files) - is that desire covered by the current option of checking out via SVN and having the entire game tree reside in one directory? I imagine that's what most people do who are seriously inclined to tweak and play around with things.
Those two options might suffice, without requiring any additional logic in the installer.
-
The question is whether we value the Windows Software Logo requirements, which very explicitly forbid writing data in Program Files and demand Appdata instead:
http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=3859
-
Thanks very much for this information! As noted in the ticket, I have found the cause; a fix is upcoming.
-
Thanks for the report; it'd be great if you would look into this!
It could be a problem within SDL, but that's a bit less likely because it seems to happen on the OS X backend, too.
If you see any gremlins lurking within out input handling chain (starting at lib/input.cpp), I will be happy to give it a look and/or apply a patch.
Incidentally, if you see this problem again, it should be possible to work around it by pressing+releasing the same `stuck' key.
The problem does not arise with mouse scrolling because we check each frame whether the mouse is near the border. Once the mouse returns elsewhere, movement will stop immediately.
-
Sorry guys, but that's how it is
We have gone to considerable effort to support OS X at all in the code. Recent work on a new+improved build system has allowed the use of Xcode. Since we lack a developer on the team with OS X who can look into the release process, fix OS X-specific issues and provide binaries at the time of an alpha release, we have to hope someone in the community can do so. That's all we can offer at the moment.
aken.sys security concerns
in Game Development & Technical Discussion
Posted
Interesting, thanks for the data. Looks like 9 people with the TSC (though the 1.5 GHz one is quite a low frequency).
The vast majority is apparently running Linux, which reports 1 GHz. Also interesting - they probably scale the
TSC. 4 are using the HPET - unsure whether on Linux or via Aken (and one of them has the frequency hopping thing enabled,
which is why it doesnt exactly hit the frequency of the classic PC master clock). 2 using PMT, which is rather buggy and bad.
It'd really be good to combine this data with OS. Then we've got (most likely) 4 Windows users where QPC is returning TSC/1024.
2 poor guys are most probably using our TGT fallback - that's the one with miserable millisecond resolution and the falling-behind bug.
This is regrettable - I'd love to ask them what hardware they are on. Can we get at that data?
Finally, we have 4 people with 1 MHz (why aren't they combined into one bin) - not sure what that one is, probably Linux again.
It looks like 2(PMT)+4(scaled TSC)+2 TGT out of ~15-20 Windows users would benefit from HPET (the ones with scaled TSC only slighty).
Does seem worthwhile for them. Interestingly, the majority is running Linux (or Mac, I have no idea what they report).
Really do need the OS info to draw a conclusion