Coder Corner

No time for long posts or long explanations but one year (!) after the previous version, I forced myself to release whatever was available. So, here:

http://www.codercorner.com/KonokoPayne_WIP_April_2009.rar

Well, apparently somebody posted a new run of Konoko Payne on YouTube… hmmm…

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…

I keep forgetting this one so let me post it once and for all. Adding a debug console to a Win32 app takes 4 lines of code.

if(AllocConsole())
{
freopen(”CONOUT$”, “wt”, stdout);

SetConsoleTitle(L”Debug Console”);

SetConsoleTextAttribute(GetStdHandle(STD_OUTPUT_HANDLE), FOREGROUND_GREEN | FOREGROUND_BLUE | FOREGROUND_RED);
}

You can then printf your way out of trouble.

Idea to try: one region = one mesh.

Current system:
- a level is made of different regions connected by portals
- a portal is a convex polygon
- a region is a collection of meshes
- a mesh is a collection of “subsets”. Each mesh has a single PRS transform and is a single object in 3DS MAX.
- a subset is a collection of triangles sharing the same render states (same material).

Currently, things are exported as-is from 3DS MAX, and each region contains several meshes, depending on whatever is in the MAX scene. Visible objects are batched, and sorted to minimize the number of render state changes. However this may not be necessary: we could use the “static batching” that happens for each individual mesh instead, the one creating subsets. We just have to merge all the meshes of a given region together, ending up with a single mesh per region.

If the regions are quite small, i.e. if it is possible to see “all” meshes of a region from a particular viewpoint, this looks like a good idea (following the “optimize your worst case” strategy). We save memory by reducing the number of “meshes” in the system, we save CPU time on culling, batching, etc.

If the engine creates one physics mesh for each render mesh, it might also have some benefits. It certainly saves memory, minimizing the cost associated with each “object” within the physics engine. It also reduces the stress on the broad phase. However it puts it on the midphase (basically OPCODE), since the whole region is now a huge AABB-tree. The old “RAPID vs OPCODE” tests showed that AABB-trees are not too great when a small object is fully contained within a big scene, but on the other hand temporal caches helped a lot for this case, so it might be ok in the end.

Now the only issue with this is probably when you have a room with several open doors, each of them being a portal connected to a different region. If you stand in the middle of the room looking at those doors, you end up rendering all the regions even though a small part of them is visible, whereas before only the first meshes of each region would have been rendered. So you made your worst case worse, in a way.

——–

Not merging meshes at all and keeping the same organization and the same number of objects as in MAX does work, but it puts the burden on the artists, and on the batcher. But even if the batcher does a perfect job, you still waste memory associated with individual meshes. In ICE, sizeof(Mesh) is something like 500 bytes or more, which I know is too much, but that’s how it is now, and a lot of professional engines have worse than this. With ~1000 meshes in a single region,that’s ~500 Kb lost per region: not good. Plus, the batcher is never “perfect” anyway, i.e. it has a runtime cost.

Merging meshes by material regardless of spatial considerations doesn’t work. It makes things easier for the batcher but it kills the physics.

A good alternative is just to cover the region with a fixed-size grid, assign triangles to grid cell (regardless of their original mesh), and create one mesh per cell. It keeps the number of meshes under control, it’s physics-friendly, and also culling-friendly. The main drawback is when the physics does a convex decomposition and relies on it to have good collision response. You can end up with a perfectly flat plane cut to N different, unconnected physics meshes - and bad collision response when an object slides from one part of the mesh to the other.

You can always completely decouple the physics & graphics representations, but it’s a pain to manage. Probably the best option though.

I continued creating a new level for KP in 3DS MAX. Nothing extraordinary so far but it’s refreshing to get away from programming, from time to time. If only MAX wasn’t crashing on me all the time, I would almost enjoy it.

Anyway, here’s a depot, where the player arrives after leaving the helipad scene:

Then the first pass for a shaft connected to the depot above:

So nothing special here, but not so bad for “programmer’s art”.

Better, later.

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:

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

Pic 1

Pic 2Â

EDIT: I just fixed a crash & some bugs and re-uploaded the file below. You may want to download it again if you grabbed the previous version.

—————————————-

Here’s a quick Konoko Payne update. This thing has no end and I may have bitten off more than I can chew. But I’m still chewing.

Notable fixes for this release, for what it’s worth:

• lasers can now break glass windows (previously they couldn’t)
• the character controller has been optimized (a lot)
• I switched to a new version of FMOD
• there was a very painful lag on some machines, that should have been removed. In any case the mouse motion should feel smoother now.
• a whole bunch of minor fixes…

Other than that, I worked a bit on a state machine editor. There’s a first version available, you can access it this way:

• enter the developer mode (type “developer” in the console)
• press one of the function keys (say F5) to free the mouse and access the menu
• select “Scene->Character Editor”

You can then select a character, edit its “motion cells”, and the “transitions” between them. There are a lot of parameters, and each character has hundreds of motions and thousands of transitions. I was previously editing this manually in the compiler’s IDE… It worked up to a point, but it became increasingly painful over the years. So I finally decided to bite the bullet, and then started a small editor for this. To be honest I’m not sure I will actually use it. So far it looks like directly editing a text file is just as fast. I’m not sure how people deal with that in “real” companies. I’ve seen some of them using text / XML files, either edited by animators or by gameplay programmers (I think it’s an animator’s job rather than a gameplay programmer’s job, but some animators are very reluctant when it comes to defining those transitions). I also saw a couple of other companies using home-made editors, visual or not. I’m not sure what the usual packages like Granny provide here. It seems a bit difficult to use a middleware to define those transitions and blending parameters, since a lot of things not directly related to character animation, like sound and visual effects, should also be linked to specific animation or transition frames - and hence, ideally edited in the same tool as the motion’s blends. A generic trigger mechanism (user callbacks) might help, but then the middleware’s editor can only edit those generic, blind triggers - without giving a proper pre-visualization of the result, since it doesn’t know anything about the engine’s special effects those triggers are linked to.

Anyway, my next immediate problem is the throw system, which uses the same animation & transitions as normal moves, but also requires extra parameters - currently not supported by the editor. So the state machine exported by the editor currently lacks this information.

Better, later…

After the last Konoko Payne update I got a complaint about the Furies’ voices in the game. Apparently Oni plays all those samples 1.14 times faster, and the coefficient is stored somewhere in the binary raw file, probably as meta-data for the particular wav files. Since I only replay the wavefiles as-is in KP, they appear to be slower than the original. And fans complain.

And so I started thinking: hmmm, I would have to assign some more parameters to each sound file, update the parsing code, and… and…

…and then I realized it was bullshit. Don’t touch the script files or the parsing code: just change the damn pitch in Audacity or something for whatever files are used by Furies. End of story.