Talk:Game development

Doom details

So... Someone apparently got Doom running on the XO. I recall also seeing a video of a console emulator on the XO, but it seems to have since been taken down. The framerates seem a little sluggish but still playable. The active screen area is inset quite a bit, presumably for performance reasons. Does anyone have details on the implementation of these things? Was it GTK running on Sugar/Matchbox, or was a custom solution used for performance? —Joe 16:22, 18 March 2007 (EDT)

SDL is OK

Tux Paint uses it.

The rpm files have problems. SDL_mixer drags in Qt via timidity and the KDE sound deamon. Don't bother with SVG, that drags in GNOME!!! I think OLPC is going to hack up some alternate RPMs, but really this is a Fedora problem.

The screen is using 5:6:5 color, which is bad in more ways than I can count. You can see green/magenta banding (posterization) easily on a smooth grey gradient, especially if that gradient is bright and radial like a highlight.

There is a way to do your own swizzle for better quality and bit depth. See this kernel patch for a way to sanely enable it. (without that patch, an ioctl on /dev/fb0 will do the job) Games could look very nice with smooth 18-bit color if this were used.

AlbertCahalan 23:44, 18 March 2007 (EDT)

Whoah, Whoah! what's all this talk of 3d?!?! 3d on the olpc is overkill. I'd stick with 2D only. I think for the games, the key is to code them very well - modularly and very well structured, with clear code and comments (localization might be a problem here). Code them in such a way that the game specific code is very slim, and hte core code extensible. My recommnedation on this is to mainly code just what you need for the game itself, for simplicity sake, and for the kids' sake - let them do more than just stick pieces together.

I'd also do an isometric engine, btw.

Michael Sloan, 22 March 2007