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:
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.