Coder Corner

People should play their game in slow-motion to finally see all the animation / blending / transitions / camera problems that they fail to see at normal speed.

“But Pierre, nobody notices those small defects at normal speed!”. Well, I do, and it bothers me.

Well. I still have viruses here. The Globat guys don’t bother answering anymore. I’ll drop those clowns ASAP.

I’m trying not to follow the trend around me. I’m trying not to succumb to the dark side. I’m trying not to say bad things about Spain. But seriously, there are a lot of basic things that just fail to work here.

This morning, I tried transferring some money from my spanish account to my brother’s french account. Something that took literally 5 minutes in Switzerland.

Here, it took 2 people and 30 minutes to tell me that “it doesn’t work”. They asked me to leave my stuff here and come back at 14:00. They seemed genuinely surprised when I told them I couldn’t come here at 14:00 because, you know, I have to work.

So I’ll try again tomorrow morning. Oh, and the only reason why I don’t do it online is because their website doesn’t work either.

I go away one week, and then I get 485 comments to moderate. All spam, save for 2 of them. I should just ban comments alltogether, would make my life a lot simpler

Bug reported in KP :

“I can’t jump while moving backward + left or right! However the jump works when moving forward +left or right”.

Well, change your keyboard. After investigation, this is neither a DirectInput nor a Win32 problem: it’s a low-level keyboard issue. Some keyboards don’t support the key combination, period. Others, USB keyboard in particular, seem more friendly (and the bug doesn’t happen with them).

Quick test to see if your keyboard is “bad”:

• run this exe from the DirectX SDK: \Program Files\Microsoft DirectX SDK (August 2007)\Samples\C++\DirectInput\Bin\x86\Keyboard.exe
• create an Exclusive, Foreground, Immediate device
• press keys S, D and Space simultaneously.

If it says: “Data 0×1f 0×20 0×39″ you’re good, go play KP. If 0×39 is missing, you’re screwed. Like me.

…I seem to remember this wasn’t an issue on an ST, but I’ll shut up.

EDIT: this is really a low-level keyboard issue…

When I was programming demos on ST, the most important (yet tacit) rule we had was the “one VBL rule”. All demos had to run in one VBL = Vertical BLank, i.e. in one frame, i.e. at 60 Hz (or 50 Hz on european machines). It was just unthinkable not to run in one frame, we’d have been the laughing stock of the whole ST scene.Games however, didn’t bother - partly because it was more complicated to create a full game than a demo, partly because demomakers at the time were kind of more talented / advanced / stubborn than their counterpart game programmers. The result anyway, is that most Atari ST games ran at very poor framerates. The only ST games I can remember running at 60 Hz were Goldrunner, Return to Genesis, Bio-Challenge, and the out-of-this-world Enchanted Lands. Needless to say, those programming pearls shone like stars compared to the mass of pale-looking ST games. Sometimes the game only worked because it was fast. Could you imagine Goldrunner running at 30 Hz? I can’t. They can’t either.

The main reason why I liked console games so much more at that time, was because they all felt better. Smoother. More polished. And, you guessed it, they all ran “in one VBL”, i.e. at 60 Hz. Alex Kidd? Gynoug? Shadow Dancer? Thunderforce III? Zillion? Power Stone? Soul Calibur? Etc, etc, they all ran at 60 Hz, because it was the norm. And for me it was a proof of quality, I could buy a console game my eyes closed and be sure it would fly on my machine.

Nowadays…. Sigh.

It makes me grin when some programmers tell me things like “Pierre, 60 Hz is for PC games! On consoles the hardware is not as powerful, so the typical target framerate is usually 30 Hz”. …… What a load of BS. “Typical” for PC programmers trying to port their stuff to consoles, certainly. Just drop your super heavy, super generic, super bloated, super dynamic deferred-lighting, reduce the useless post-processing effects, and maybe things would run better on your “less powerful” hardware.

Consoles = 60 Hz, else go back to the drawing board.

http://www.acm.org/ubiquity/views/v7i24_fallacy.html

Kind of old but I feel like posting it anyway.

What’s the deal with alpha-sorted polygons those days? I hear more and more that engine X or Y doesn’t support them because “it’s too slow”. Errr, hello? We even sorted polygons on 8 Mhz Atari STs, I assume you can manage to do the same on a 3 Ghz multi-core machine? Sure the number of polygons has increased, but so has the CPU speed. So what’s the problem?

• the first problem is that they don’t use the right algorithm. If the number of polygons and the CPU speed evolve in parallel, the ratio only remains constant with an O(n) sort. Since they insist on using qsort, well, they’re doomed before the race even starts.

• the second problem is that they don’t generate their sort keys efficiently. No, you don’t need that square root. No, you don’t need the distance to the camera position. You need a simple dot-product: the vertex projection on the camera’s forward vector.

• the third problem is that they sort everything each frame. It’s useless. Sort the index buffer once, and only sort it again when the view direction has changed significantly. You don’t need an exact sort each frame since the whole process is not accurate to begin with (each triangle is sorted according to a single witness point). So it means you need to actually sort stuff only once in a while - or all the time but over N frames, if you prefer.

• the fourth problem is that they sort at runtime. You don’t have to. As we just said the sorting is approximate, so you can precompute 8 sorts/index buffers for the 8 possible octants in which the view vector can be, and simply pick up the correct one at runtime. This has been used countless times in countless demos on Atari and PC. Seriously old skool. It certainly increases the memory used, but here’s my deal for you: drop the STL, and you’ll win back all the memory you need to include those precomputed sorted buffers. The number of transparent objects shouldn’t be huge anyway, so this is usually not a problem. Especially since those sorted buffers can be easily compressed like crazy, and decompressed to the actual D3D index buffer only when the view vector changes.

So, what’s your excuse already?

It’s not just that I don’t like the STL, it’s simply that I don’t need it.

If I need a basic container (linked list, vector…), the STL doesn’t help much because I can use my good old versions from 10 years ago.

If I need a more advanced container (e.g. a map), the STL doesn’t help much because custom versions are way faster anyway.

If I need a sort, I usually want a radix. Here again the STL doesn’t help.

If I want to disable exceptions for performance reasons, the STL doesn’t help.

If I want to save memory, the STL definitely doesn’t help.

If I want to debug my code easily, if I want to avoid “byzantine syntax” in my code, if I want to keep my compile times low or avoid insane code bloat, again, the STL fails.

So, really, why exactly should I bother? Just because it’s “standard” ? Are you insane? What does that buy me exactly? Isn’t that a lot of troubles for very dubious benefits?

STL horror stories on top of my head:

• the “contact stream” in the old Novodex SDK: we needed a dynamic vector where we could push_back both floats and ints (something like an int encoding a number of floats, followed by the actual floats). It was originally implemented with a templated array. Replacing it with a vanilla Container from ICE reduced the exe size and gave a small framerate boost.

• the VC6 implementation was a joke, but the new ones aren’t that much better. The bug is in the template theory: everything is (or can be) inlined. Take a simple push_back. It really has two parts: the one that copies the object to the dynamic array, and the one that resizes the array. Most of the time, say for a vector of ints, you really want the copy to be inlined (it just copies an int after all). However you never want the resizing part to be inlined: it happens rarely, and it’s so slow anyway that inlining it is pretty useless. But how does the compiler know that one part should be “always” inlined, while the other should not? Exactly: it doesn’t. So what do you think happen? Could you swear that the compiler will not happily inline both parts for every push_back in your code? I saw it happen with VC6. Could you swear it doesn’t happen with, say, PS3 compilers?

• speaking of which, can you guess how much we saved on the exe size a few weeks ago on PS3, when we switched from the default STL implementation to uSTL ? Hint: give your answers in megabytes.

Please use and abuse the STL, it makes my life that much easier when it comes to beating the competition. Maybe exceptional products are not written with “standard” code, you know…

Don’t tell me it’s happening again. My website was down all day long. I just switched from one web hosting company to another, because the previous one had fucking lame miserable support and broken servers. I hope I didn’t go from Scylla to Charybdis here.

If you know a serious, rock-solid web hosting company, feel free to drop me a line about it.