Coder Corner

I just uploaded a fixed version of my old radix sort code. A bug was introduced in january 2006 when I added some optimizations sent to me by a user. Apparently I didn’t check them out enough: they made the code crash when negative zeros (binary 0×80000000) are involved. So I reverted to the previous code. Grab the fixed version here.

Big thanks to Ignacio Castano for reporting this!

Note that this only affects the latest radix code. The original code didn’t have the bug.

Some of you might know “Roudoudou”, old coding wizard on CPC (yes, Amstrad CPC). I just discovered his website dedicated to urban exploration, and I find it amazing. Some pictures are puzzling. How the hell did they reach the top of the Grand Palais in Paris without triggering a zillion alarms?!

Other than that, this one reminds me of something….. 

I created a new battle arena for Konoko Payne. I did it in good old MAX 5, computed the lighting using good old Flexporter,and here it is! Turned out better than expected. I think I’ll continue and turn this into a full level.

Top view: the platform will eventually go down from the top to the bottom of the structure. Inspired from the “shaft” level in GITS-Standalone Complex on PS2.

As a level in KP: I like the dark blue ambient mixed with the orange-colored lights. The helicopter is from Oni, level 19. I might create a better one eventually.

Side view: simple but efficient.

Overview in ICE, with or without textures. It’s plain old vertex colors, just like Oni. Some people find them obsolete and lame. I find them convenient and fast. I saw some so-called “next gen” engines looking way worse.

Used as a battle arena for KP’s demo mode:

So they released a new PhysX version, and this time the character controller (CCT) source code is included. Partially. For various reasons they decided not to release the source code for the actual sweep tests (box-vs-box, capsule-vs-capsule, capsule-vs-mesh, etc). So the SDK exposes them as utility functions and the CCT code just accesses them through the NxUtility interface. However all the code for the CCT logic has been released.

I originally wrote the CCT as part of ICE, for Konoko Payne. It was many years ago, before I joined Novodex. Then I integrated it to the Novodex SDK, it got rewritten, refactored to use the NX math classes, etc. Then for some reasons it got moved outside of the SDK, in its own NxCharacter DLL. Then filtering callbacks were removed because of the Ageia hardware (the original plan was to move the CCT to HW, so callbacks were forbidden.) Then fixes sent to us by various customers got integrated. Then I rewrote it for “large worlds”, using doubles for positions. Then this feature was dropped, a decision I’m still bitter about. Then the code got modified by various people over the years. Then the code was rewritten again to remove the sweep tests, which got exposed as NxUtility functions instead. And then the final code was released, probably because they got tired of modifying the CCT for each individual customer (they always want something a little bit different).

Looking at it again today, I have mixed feelings. One one hand it still does its job more or less correctly. On the other hand, it’s a bit in a sad state by now:

• It’s a bit bloated, with some useless code that could be dropped.
• It has O(n^2) parts to deal with character-character interactions and it misses an incremental SAP to support “sleeping characters” (to avoid testing all of them each frame). This is because the SDK didn’t expose its SAP interface directly to users.
• It doesn’t support large worlds even though the code structure is ready for it (relocating everything around the player’s position instead of working in world-space, etc).
• It’s probably not as fast as it could be, since the CCT was never a big priority for Ageia (sometimes I had the feeling nobody cared about it. It wasn’t HW accelerated so it wasn’t important. Sigh.)

The current CCT used in KP is basically the same. But without the problems. That’s because a single person touched the code, and no political reason ever motivated a code change. It’s a bit sad that the code I produce alone in my free time (Opcode, Flexporter, etc) often ends up in a better shape and faster than the code produced within a company, where N people with different mindsets and sometimes conflicting views are allowed to change it. It worked great within Novodex because we were only 2 people, “owning” clearly defined parts of the code: Adam was in charge of the solver & joints, I was in charge of the collision detection. We never stepped on each-other’s steps, as far as I can remember. Within Ageia… let’s just say things were different.

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.

The brain works in mysterious ways…

Go to the following page and watch the video. There are two teams, with black or white t-shirts. They are throwing a basket-ball at each other. Can you count how many times the white team throws the ball? Count one each time the ball goes from somebody’s hands to somebody else’s hands.

http://viscog.beckman.uiuc.edu/grafs/demos/15.html

Got the right number? Check the answer here…

———————–

I have the feeling the same thing sometimes happens when we’re debugging. The bug is obvious, litteraly in front of our eyes, but we don’t see it because we’re focused on other parts of the code, which we think must be the problem. I guess it’s +1 for pair programming.

And yes, that video fooled me big time

Somebody on the Oni forums posted a new texture for Konoko’s face. I quickly tried it in KP:

Pic 1

Pic 2Â

I was looking at old backup CDs when I found this again. It’s old but it still make me laugh a lot

A cute trick from the Molly Rocket forums:

http://nothings.org/computer/edgeenum.html

Celui-ci est pour Lionel C: tu ne quitteras jamais Barcelone, ils ont des “miradors de luxe” pour t’empêcher de partir!

http://fr.wikipedia.org/wiki/Mirador