DOOM 3 BFG Technical Note [pdf]
fabiensanglard.net
fabiensanglard.net
New players would always attempt to spam the BFG in a crowded room, then duck behind a corner or run away. Due to the mechanics of the BFG, this is the opposite of the correct strategy.
A short time after a BFG impact with any surface or object, the game basically performs a cluster of hitscans radiating from the player in the direction the shot was fired. Thus the most effective BFG strategy is to stand to the side of an entrance to a crowded room, shoot the BFG at a wall, and strafe toward the entrance until as many enemies as possible come into view.
Get the timing right, and you turn the room into an uninhabitable no-man's land until your six shots run out (ten if you grab the ammo backpack).
I miss those days :)
I'm curious what sort of performance they run into in MT environments--lockless applications are handy with linked-lists.
Look at 6.3.2 for software prefetching. Like the rest of the paper it's very x86 centric but most of the concepts apply to other architectures.
Thanks for posting the article and thanks for pointing out the section on linked lists. I agree that that section is really interesting. In what sense do you mean lockless applications - applications built around compare and swap primitives or something else?
I can't really follow what:
"byte otherMembers[64]" is used for.
What useful data is stored in there? If pointers are 32bit and cache lines are 64bit, the comment:
"// over a cache line worth of other members"
doesn't really make sense because you can only fit two full addresses per cache line.
It's a shame that the idList type he is suggesting in favour of the other types, a resizeable heap array, is not declared in the body of the pdf. Might be worth looking it up.
The distinction between non-intrusive and intrusive linked lists is new to me, I didn't know there was a word for that!
This is the best "link" I've found on them:
So:
byte otherMembers[64];
is 512bits of addresses to other members, that will hold 16 32bit addresses.
From the article: "In the case of an array with pointers there may still be a cache miss when reading the ‘valid’ flag but there will be at most one additional cache miss every 16 pointers"
so idList must use operator[] to sensibly iterate over otherMembers.
class idMyClass {
bool valid;
byte otherMembers[64]; // over a cache line worth of other members
idList< idMyClass * > myObjects;
for ( int i = 0; i < myObjects.Num(); i++ ) {
if (myObjects[i]>valid ) {
}
}IMO this class is politically incorrect, there is no mention of the "tail".
Does that mean it's "about to take off?" I guess we'll just have to wait and see. I certainly hope so. Games have always meant pushing technological boundaries, so if games get big on Linux it will hopefully move the whole OS forwards. Finally, the year of the Linux desktop is upon us! (...don't worry about those pesky locked-down mobile devices)
Well... a man can dream, at least.
A good C# developer knows the runtime and their compiler, the same way a good C++ developer does. Yes there is a performance gulf between what a good C# programmer can do and what a good C++ developer can do (although the size of that gulf is an argument for another day!), but there is also a huge performance difference between what a good C# developer does and what an average C# developer does.
As an example, my team has a log file that is consumed by other multiple teams. Log file parsers have been written in either C++ or C#.
The log file has a bunch of discreet entries in it, each one of which is independent of the others and measures in the tens of bytes.
One of the C++ parsers tries to read the entire log file it at once. It is dog slow and just chokes on larger files.
One of the C# parsers relies on the file system to predict future reads and just pulls the file in entry by entry.
The C# parser is faster and doesn't have file size limitations.
(On a related note, I have worked with C++ UI frameworks that are heavier weight than C# UI frameworks!!)
My point is, a good developer is a good developer, independent of the language.
(That said, some of the analysis of cache performance impressed me, instruction count is not everything!)
For example: I'm not generally a Java guy and I'm not an Android expert, but I once had to create an android touch interface to some custom hardware... and it had to run on one of the first "embedded tablet-like" systems available (this was 2009-ish).
In a month or so, I went from knowing nothing about Android and being extremely rusty with Java to:
- Doing nifty tricks in Java to make code DRY and maintainable
- Writing a fancy flashy Android app
- Using the NDK to write a native component that integrated the app with a couple of device drivers
- Deeply investigating the performance characteristics of the Dalvik VM and tuning all sorts of things (both in the OS and in my code) to keep things working smoothly
Could I do any of this again right this second? Nope. I've moved to other projects and other technologies and all this has been swapped out of my head. But the point is that I could get back there again if I needed to.
As a "good developer", you would no doubt experience something similar in this situation. If someone sat you down with a poorly-performing game, some C++ code, and pointed you to enough reference information and profiling tools, in a few weeks you, too, would be talking about cache misses and alignment boundaries and SIMD intrinsics, and...
The funny thing about tech jargon is 99% of it sounds like gibberish even to those of us who've been there before! Don't be too hard on yourself :)
http://s09.idav.ucdavis.edu/talks/05-JP_id_Tech_5_Challenges...
edit:
http://mrelusive.com/publications/presentations/2012_siggrap...
DWORD error = GetLastError();
error = error