Archive for February, 2008

MCoder sources

Friday, February 15th, 2008

Woah! Jean-Charles Meyrignac (a.k.a. MCoder) recently released most of his old Atari ST sources:

http://euler.free.fr/AtariST/

Years ago I would have killed for that :) When I was programming demos on Atari he used to be one of my coding heroes - along with Niclas Thisell (”Nick of TCB”), God of War’s Tim Moss (”Manikin of TLB”), Steve Bak, and a few others.

Why?

Thursday, February 14th, 2008

When I change a comment in a header file, why does the compiler rebuild everything ?

It’s smart enough to know it’s a comment, right? (Comments have a different color after all). So I would like to have a cool option not to mark a file as “modified” when I just change a comment. Granted, it probably would fail in some cases where macros are over-used or something, but it would work pretty well otherwise, wouldn’t it?

TODO: stack-allocated container?

Thursday, February 14th, 2008

I was browsing a codebase when I noticed this usage pattern, several times:

void SomeFunction()
{

vector<some class> localVector;

localVector.push_back(some data);

}

In considered cases, the push_back doesn’t always happen and the number of pushed elements is not known ahead of time (i.e. there’s a good reason why a dynamic array is used). However what happens is that only a few elements are usually written to the array, and overall a small amount of memory is actually needed. So, it’s a bit painful to do an allocation/deallocation for this.

So it might be useful to allocate the initial memory on the stack (i.e. with alloca) and only switch to “real” memory allocations the first time the array is resized. If we stack-allocate say 16K initially, it could significantly reduce the number of small allocations performed by that kind of code. Something to try at some point.

EDIT: done! Works nicely.

Customer is king

Wednesday, February 13th, 2008

Code is art. Art is subjective. Different programmers have different styles. If somebody uses a lot of templated C++ and STL, I will not say his code is bad. I will say I don’t like his style. To tell whether a code is “good” or “bad”, I need a metric. Something I can quantify. Something objective. So, to me, a “better” code is one that uses less memory, or less CPU time. It’s that simple.

More and more I see software engineers who forget a simple rule: we are not working to please ourselves. We are working to please the customers. Customers do not see the source code. They do not care whether it uses STL or not, is ANSI compliant or not, is “beautiful” or “ugly”, is portable or not, uses tabs or spaces, uses Hungarian notation or french comments. They do not see the source code. They don’t care.

They care about concrete things. It must be fun. It must be smooth. It must fly. It must load as quickly as possible.

Everything else is irrelevant. We are not here to please ourselves. We are not here to create over-engineered architectures that never pass the test of time anyway. Professional programmers do not code to please their egos. Do that at home, in your personal projects. Or start a blog.

Too much LUA smells bad

Wednesday, February 13th, 2008

Garbage collection is good. Not creating garbage in the first place is better.

Ghost shells

Wednesday, February 13th, 2008

There’s a certain hypocrisy in next-gen games. On one hand, some people tell me that next-gen games are all about polishing the details - and then they go work on their parallax mapping. On the other hand, when I point out some of the details they blatantly ignore, I’m told that “nobody cares” about them. Jeez, get your story straight!

Fact: seven-years old PC games (and a number of PS2 games) handle a few things better than current “next-gen” games.

Proof: check out the shells coming out of the gun in Oni. And then in Gears of War.

In Oni, the shells collide with the environment, slide down the slopes, you can hear their sound when they touch the ground, and they fade out smoothly after a while.

In Gears of War, they don’t collide with anything, they don’t make any sound, and I can’t tell if they fade out since they just royally go through the ground.

I guess that’s one of those “next-gen” details that nobody cares about. Still, it’s slightly disappointing.

Now, is there any reason why Oni (or Ghost In The Shell - Standalone Complex on PS2, etc) would handle this better than top of the line Xbox360 games?

Technically the answer is easy: Oni (and, I suspect, quite a few PS2 games) solves this with particles. Each shell is a single particle with a rotating texture - or better, rotating UVs. Collisions with the environment only involve simple raycasts, a collision callback is used to play the sound of shells touching the ground, and fading the shells out is easy since alpha-blending is a built-in feature of any particle system. A single particle is enough to fool the eyes since those shells are usually quite small on the screen. To be honest I never realized that the shells in Oni were simple particles, until I tried to re-program them in Konoko Payne.

Now, the problem with Gears of War is that they probably tried to make it “next-gen”. That is, I suspect they tried to handle shells as “real” meshes, controlled by a full-featured physics engine. Unfortunately this is an extraordinarily bad idea.

On the rendering side it’s not too bad. A real mesh obviously consumes more resources than a single particle, and it would be very slow to render a hundred bullets one at a time (set-world-matrix, render mesh, do that again), but nowadays there are instancing facilities in your favorite rendering API to make this possible. It’s still a lot more expensive than rendering a few hundred particles, and fading the shells out is more difficult (opaque meshes and transparent meshes are usually not even rendered by the same pipeline), but overall it’s not too painful.

On the physics side however, things are not so great. By nature the shells are very small, so if your physics engine doesn’t support continuous collision detection (CCD), it’s likely they’ll go straight through the ground. And if it does support CCD, well, you just added a hundred CCD-enabled rigid bodies to your simulation: not a good move. Your bullets may kill your enemies, but they just killed your framerate as well.

So, how do “next gen” games solve this problem? Well. Apparently they just ignore it, and are happy to live with ghost shells going through the ground. Somehow, I preferred the old-gen solution.

Hello world!

Tuesday, February 12th, 2008

Hola! Or should I say grüetzi ? Or simply bonjour? Those days I’m not sure anymore. I’m french, just moved from Zürich to Barcelona, and you may wonder why the hell I then write in english. Well, that’s because my main fellow co-worker was hungarian, and I now work for a swedish company. That being said, I’m still an Icelander inside. What a mess.

Anyway, new year, new web hosting, new job, new country, and then why not starting a blog, it’s 2008 after all.

This is the blog side of CoderCorner. I you liked the original, you’ll love this blog. If you hated the original, well, goodbye.

Goodbye and hello, as usual.

shopfr.org cialis