Slashdot Mirror
Linux Game SDK, Fully Playable Game
Denis Oliver Kropp writes "Yesterday was the release of the new ClanLib and of ClanBomber. ClanLib is a game SDK by ClanSoft (www.clanlib.org). ClanBomber is the first fully playable game that uses this API. It compiles under Linux and Win32, uses X11 or DirectX. ClanLib (and the game) even support joystick under both environments. ClanLib will support svgalib and GGI in the near future. Check out the screenshots at www.fischlustig.de/clanbomber "
Oh, good point.
You say it sucks, and we all know you're a famous 3D programmer, so we'll believe you immediately.
Now I actually have used OpenGL and I didn't see anything objectionable about it. It does everything one would expect, and in a way which maps fairly nicely onto real 3D hardware.
John Carmack (who *is* a famous 3D programmer) likes OpenGL a lot.
So remind me again, why should we listen to you on this?
Does this thing target Sony Playstation(tm) Nintendo 64(tm) or even Sega Saturn? No?!
Well it won't be used by ANY sane game company since the above platforms are real cash cows for game developers.
I perceive MESA as being much more likely to be a booster for Linux gaming as porting existing OpenGL stuff should be relatively straightforward.
I DO NOT belive in viability of open source games. Period.
If you do then please point me at some playable ones that match the commercial stuff in quality.
Not just yet another "space invaders"!
It's all a waste of developers' time and energy.
Commercial vendors won't use it and open source geeks won't have time/patience/resources/motivation to develop killer games with it.
Absolute No-hoper. Sorry.
Do you really trust an application enough to let it do anything other than read the current resolution and colour depth? Would you really consider it a good thing that an app could switch the colour depth or resolution of the Xserver.
I wouldn't.
I agree with you otherwise. Linux game SDKs have a long way to go. But I'm glad somebody is pushing forward.
There are sprite libraries with xgalaga and with
xjetset. Doing sprites in X11 nicely isnt that
hard because you have server side pixmaps.
That game looks rather nice.
i.e. the Advanced Linux sound architecture.
GGI is then -like X- the basis for other higher level libs like CrystalSpace, PenguinPlay or the API presented here.
The main ploblem: ALSA seems to be GPL. Unless they change it to LGPL or better X license, it's dead.
Hardware companies simply won't release specs for their bleeding edges cards (like the Soundblaster Live).
And so the word "multiplatform" means only Windows+Linux to you?
Ok mister expert, why don't you optimize the assembler functions in clanlib
and show us just how much framerate you gain? - Because you can't.
Any sane person wouldn't try to figure the pipelines in modern CPU's and
speculate in which instruction is faster than another, if that particular
code has no effect on the overall performance. Why do you think we didn't
write this library in pure assembler?
Facts: the two instructions you complain about gets executed once per
scanline. The gain by optimizing those can't be measured in percent, not
even in theory.
At this point we do not care about a 10% increase, when we can get 100% or
200% by implementing all the extensions a particular X server supports.
You failed to learn the simplest rule about optimizations. Always find the
better algorithm before you even consider assembler code. Looking at your
homepage and your comments here, reveals you as no more than a simple
amateur that thinks you can beat every other game developer in the world.
Let me ruin your world, you are not the genius you think you are.
...since it has pictures of naked women in it.
Obviously, someone knows what sells. Image the increase in popularity of linux if it had a nice splash screen...
"Hardware companies simply won't release specs for their bleeding edges cards (like the Soundblaster Live)."
Hmm who should bend for whom? They're being stubborn. We are potential customers.
Is the tail wagging the dog or is the dog wagging the tail?
The number of game engine APIs poping up are
in my opinion due to the limitations of X11.
Here is the list of things I want to see in
the X12 standard:
1. Cross platform network audio streaming. I brought this up before and was told that eSound, is the answer. IT IS NOT.
I want to be able to play xgal REMOTELY on my Linux box over a network, via a PC X-server, something like eXceed, or XWin-32, and let the X-Server take care of audio. eSound does not do this, it only runs on Linux. I want to be able to open xawtv, and watch it over a lan (this part I can already do), with audio (this is the part that is missing).
2. Just as the previous poster has noted, it is important to support on-the-fly resolution/colordepth switching. It's pointless trying to make a 3D game run full screen at 1920x1440 resolution (god I love my Princeton E2100, hope next Christmas is going to be just as good).
3. Since X is used across networks, I feel it is very important to add some kind of compression methods to its protocols (both graphics and audio)
Anyway, the point is, that as long as the X11 is not answering to the above consumer demands, the APIs are going to keep multiplying, which does not help to the porting in the least bit, and hurts every UNIX flavor in the long run. I say it's time for X12.
Paul Koshevoy.
Yeah, have a look on his website. Its quite funny - maybe we should post it on segfault.org?
Very impressive that he has been a five interviews with game companies without getting a job (NOT)...
But then again, he thinks his code is much cooler than westwood...
Based on all the negative comments I have readed here, I think all of you should download and try SDL from http://www.devolution.com/~slouken/SDL/ While I'm not related in any way to the developers of this SDK, the only thing I can say about it is that I'm very impressed. It doesn't have any of the mistakes of ClanLib: it is C (not C++), it is way fast, it doesn't pack tons of unnecesary bloatware into the SDK, it has been tested with REAL games such as Doom and Descent, it is stable, and it is way easy to use. It even interacts with Mesa/OpenGL and is more portable, with Solaris, Win32 and BeOS versions ready and many others going on. Take a glimpse at it, it really looks like an absolutly portable game SDK and gives you anything you need to jump into game programming with no hassle and .
First off, its C++...icky....but thats not a real issue because you can create wrappers, its just fugly.
Real problem is I can't get ANYTHING to compile without modifying the makefile in question. Second, the only thing I got to compile was pacman, the rest get this error:
/usr/local/lib/libclanlayer1.so: undefined reference to `gzread'
/usr/local/lib/libclanlayer1.so: undefined reference to `gzdopen'
/usr/local/lib/libclanlayer1.so: undefined reference to `gzclose'
I looked at the library requires and all I needed was Hermes, which I got and compiled and installed. I have libz and have to modify the Makefiles to add it, yet I still get this error.
I got Pacman to compile, but it sucks the big one. Slow, doesn't reqister events well, I try to turn away from the ghost comming at me and the guy runs straight at it instead of turning down the tunnel I tried to turn into.....I have to keep hitting the button LONG before I get to the turn and MAYBE it will turn when he gets there. The events are deffinately fucked up...the drawing is fast enough to get by, but events should be registering faster then that. Hell, sometimes when the guy is just standing there the event doesn't register at all....that is BAD.
So, looks like crapware to me. I sure hope that linux game APIs are going to be better then this. I figure, if it can't run quick enough to play on a P200 then who gives a shit if it even exists.
I didn't see anything about scrolling support, does it support this? I was writing my own SDK a while back and I managed to get 800x640 50 fps on a Dx4 100 with xshm but it was a bitch to maintain, I wouldn't mind porting.
Privet Alexey,
Amazing site you have there.
You're probably the most self-centered, bragging fool ever, to publish such dravel on the 'net.
If you ever hope to find a job _anywere_, you better learn to be a little more humble.
How did you get such a high score on the TOEFL tests, when you have so many mistakes in your post and on your site ? Better work a little on that, if you are wishing for Harward, I'd guess.
Well, don't worry too much, you're still young and foolish, have the future to look forward to - and you were _almost_ right about mov ecx,0.
Paka dorachok.
Is the tail wagging the dog? If you think that the 5% (if that) of the hardware market who want to run a GPL'ed ALSA should convince manufacturers to commit to a full disclosure policy, yes.
I joined the mailing list for this reason and got a fast response:
remove all assembler files from the Makefiles:
OutputFiles/asm_rle.s
OutputFiles/blit_transparent_clip_asm.s
OutputFiels/blit_transparent_noclip_asm.s
Then remark the inside the #ifndef WIN32 defines in:
Layer1/Display/Generic/blit_transparent.cpp
I just compiled and ran ClanLib and Clanbomber from CVS.
I was wondering if there would be any benefit to moving the sound card drivers out of the kernel, and doing something similar to the situation with video drivers and X.
Would that make the development of a sound API easier? Could someone with knowledge/experience in these matters please comment on this?
Yours,
--
They aren't sprites. 'Sprites' under the garbage PC hardware do not exist (except for the mouse pointer), you're thinking of Commodore which actually did support sprites.
The goal of ClanLib isn't to replace Mesa or GGI. It is _NOT_ trying to be a lowlevel graphics API that solves all problems for Linux.
The goal of ClanLib is to provide a clean and easy interface for game developers. Of course you can do everything ClanLib does with Mesa or GGI - but in most cases _you cannot do it as easy_. And more importantly, ClanLib sets a standard for how surfaces/sprites should be loaded. Thus if I write a loader for the XXX graphics format, other developers would just "plug it in" into their game.
All game companies out there produce their own "ClanLib" on top of Mesa and DirectX - believe me. This is because lowlevel libs are too generic - often trying to solve the need for a large array of applications. This goes for Mesa too - it is not a game library, and should not be treated as that.
If you want hardware acceleration for Linux - fine, go help XFree86. If you want cool 3D graphics for Linux, help Mesa. If you want an easy gaming API, go help ClanLib. If you want linux game developers to share more code between each other - go help ClanLib.
It seems at a first glance very good to have a game-oriented library in Linux capable
of imitate the behavior of DirectX. But it is not
when a 1985-dated game named Pacman is not capable of running faster than 15 fps in a
state-of-the-art Pentium II machine with a buzzword-enabled ultimate graphics card.
Sorry, guys, but I cannot consider this library anything more than a sad joke.
Linux will be considered a serious gaming platform when it manages to
provide a real game-oriented API that provides direct (or, at least, fast enough) access to ALL the hardware.
I would like to encourage all the ClanLib and others I-wanna-do-anything-too libraries to stop
all this nonsense and misoriented work and joining a real promising development, such as hardware-accelerated OpenGL,
the fb device or GGI.
OpenGL is a God-afwul steaming pile of crud.
Nobody sane who has programmed in OpenGL can honestly
say that it is a good library. It's not by any
stretch of the imagination.
What is not open? ClanLib is LGPL, and so is GGI, unless I am mistaken. They are certainly free and open, both of them.
Try programming with DDK you'll find out what "steaming crud" really smells like.
Isn't this just absolutely incredible ! The thousands of Linux-fans of the Linux community have accomplished a brand new portable (relatively, it doesn't do Mac's ?) graphics library. (What was wrong with OpenGL ?). It can even do sprites ! WOW !!
I can vaguely recall a similar game on my old DOS machine, back in 1985 or so. It did not run at 55 fps admittedly, but what the h!, it was a 286 and no graphics accelerator !
I'm amazed.
Before we know it, we'll see games like Wolfenstoned 3D. Darn, I hardly can't wait !
Re: sound API
What's wrong with 'echo ^G'?
Muhahaha, now that I've introduced by new toolkit there'll NEVER be any games for linux!!!
make a free library and a free engine that is as advance to do say, Half Life is when I will be impressed...
I ate my tag line.
-=Ellis (D)25=-
By the way, do a search for cross-elf on the net.
It let's you run one binary on dos, linux, and 95, with no problems whatsoever.
Come on do a little research.
Or look like a fool.
The ship sank. Get over it. (This sig was cut out from another's shirt and painstakingly hand-posted)
*I* aren't sure why you aren't getting this kind of attention. I'm just kidding. Am I not a picky punk? Aren't I a picky punk? Ain't I a picky punk? English is weird.
Posted by Scott Francis[Mechaman]:
Take a look at the anime section of wm.themes.org. Note that the second Dirty Pair Flash theme(with a background of the Pair in compromising positions) is beating out almost every other theme by 2/3rds..
Confirms some speculations I have about certain users..
I was hoping to see more of those screenshots, but the site started dying... The ones I saw looked good, though!
As if i didn't have enough timewastes already...
retrorocket.o not found, launch anyway?
Clanlib is platform independent,right? Even if it's not, it supports Linux, and that should be *all* Linuxs... i think the clanlib-0.1.14 has some intel-specific asm code there...
mustapha.
Clanlib is not multi-platform! Do NOT tie things to Linux only! All *IX should benefit... GGI works perfectly so far on both my Sun and Linux systems.
I appreciate that they got so far but it is not open software!
...Steve
The ClanLib folks may be open to contributions from other unix platforms. Why don't you ask them if they'll accept you're code?
Me thinks someone needs a lesson in sarcasm.
It doesn't work on my Alpha either. Looks Intel-specific, though I'm certainly no guru on the subject. I might even be missing something as simple as a configure flag ... :)
-- Rick
Close. It's because there are too few users, which in turn is probably due to price.
SGI has had hardware accelerated OpenGL for ages. Why aren't there any games for Irix?
Still waiting for GGI and reasonable support for switching resolutions and colour depths...
Considering the present state-of-the-art in Linux game SDK's, they did well though (then again, there were good cross-platform action games years ago)
"I love my job, but I hate talking to people like you" (Freddie Mercury)
So you think that the only software that should be released should support every hardware platform out there? There are some applications where the benefit of making software easily portable just isn't worth it and games is one of those applications.
Since this post contained direct insult I could not resist answering it.
0. I guess there are more bragging fools than me, in particular those who prefer to critique hiding under AC status, my work is not the best in the world but to certain point it was as good as some commercial samples. Until I see _anything_ from you I would
1. I have had a job, I do have a job and will have job. I could have a job in recognized computer company but I felt that I can do more than that. As you could mention I have other qualifications beyond programming.
2. TOEFL. My score is not as high as it will be this summer. True that I do have way too much spell and grammar errors, primarily because I have little time devoted to my site. This is fair point to notice and I do not ask for an excuse here. And I am working on it.
3. I take your advice, mister AC and working on my English, that work includes posts on this site where I have pleasure to talk with people like you. Don't get me wrong, I am actually grateful to you as you make some fair comments.
4. About Harvard/Stanford/Wharton. Pity you don't have Email, I would notify you when I get in. This will be sooner than you think.
5. As for mov ecx,0
6. If you pretend to know Russian learn how to spell.
AtW,
http://www.investigatio.com
alexc
Join Majestic-12 Distributed Search Engine
Go to my site, download my dune32 source code, have a look at my assembler code (it's in C++ file) designeg for Watcom.
;P
;)
The reason this lib is not in Asm is most likely because you wanted to make it portable, besides in game 10% of code runs 90% of time, and I DO know optimization rules, that's why I was not suggesting insane idea to write it all in asm. Only few functions must be in Asm.
About instructions I do complain: this was OBVIOUS optimization, and if you could not do that, than you probably can't do other, inside loops.
Pipelines are easy to figure out as long as you don't be lazy to look at timings for mainstream processors, I would optimize for Pentium+.
;)
You don't need to ruin my world, it's already ruined. And yes I am amateur, as you could see from my page my main profession is business, BUSINESS, programming is my hobby, see the difference? Interesting, did you look at MY asm, while I have looked at yours? I think you didn't.
Look, I am not saying you bad programmer, you probably even better than me, this is not my point.
To the AC below me: I've had job interview I did HAVE work offers, since my study will end in June this year I postponed my final decisions
Now, if you want to see some real guy who kicked some major ID ass look here:
http://www.ii.uib.no/~alexey/
Look for PolyEngine, he is my old friend from high school.
The main reason he and me quit games programming is because we are way out of colledges now and need to make some money for life, dammit! If you still studying than you won't understand that at all.
He is now doing Java browsers: http://www.icesoft.no
Peace, and good luck, don't be mad at me
AtW,
http://www.investigatio.com
alexc
Join Majestic-12 Distributed Search Engine
Well, probably I am way too strict to a 0.00x release (if we can call it release) but anyway, being a former game developer for PC I have noted the following.
How many of YOU here (yes personally you reading my words) have actually downloaded stuff and LOOKED AT THE SOURCE?? Personally I was most interested in their ASM routines, as a game programmer I had some hard times back in 1993 beating out of a CPU extra tick or two in every routine.
So, if you look at their file asm_rle.nasm (the first I have spotted), you can see something like that:
move ecx,0
You know, those who familiar with assembler not in theory but in practice, those who programmed games, demos etc WILL NEVER EVER USE THIS CODE!
For Christ sake, in games SPEED is the most important thing (memory comes second), it ought to be: xor ecx,ecx It's faster.
Same thing all over other assembler routies, they are WAY not optimized!!! Such a thing like movsb in a supposedly 32bit code is _the_ shame!
I ask myself, how it could happen that the guys did such an obvious mistake? The answer is simple: in their demos they can't check the real usefullness of their SDK, these simple demos could run fine even under EGAVGA.BGI (those who knew Borland would get what I mean) or even old WinG!
The guys should have made real demo, which stresses the hell out of their "SDK" to show it's useful for anything. Those who will try to develop real fun game (not stupid demo no one is gonna place more than 5 mins) will face big problems.
This actually brings to second point, did you ask yourself why there were so many SDKs and no one was successful? Even DirectX is mostly used in modern games only to obtain a valid pointer at video memory, all the other stuff is done by internals of the game itself.
These days such SDKs are only useful for educational type games, forget about serious game development if you can't make up your own engine, and this engine should be fast (unless you do Solitaire).
Honestly I wish guys who make this SDK good luck, but really all they get from it is good experience for themself, rather than some killer SDK.
Portability issue is not that important, with proper programming it's easy to port ANYTHING provided you didn't use external libs (without source code), to port all my games I only need to port Asm, which is easy too if target platform is x86.
You can check my games code and sources (including asm) at my website.
AtW,
http://www.investigatio.com
alexc
Join Majestic-12 Distributed Search Engine
i was worried for a minute there...i was looking at the Clansoft site, marveling at what they'd managed to do in linux, but worrying about the lack of a reference to the LGPL on the front page...luckily, however, Clanlib is actually under the LGPL...which is why i have no issues with declaring:
VIVA CLANSOFT!
when games become as natural a part of linux as ls and grep, i will be quite the happy camper...
-josh
Aren't you dead?
Could be the price of the hardware and software.
Well, at least you had like the first version of GLQuake if I remember.
I know I will be moderated down for this, but . . . Vincent
Wahhhh! Have you opened a Game Developer lately? Every other page has some 3D super-accelerated kick-ass modeling API. I can't find a 'standard' among them. Read the postmortem articles and you can see that there aren't two games out there that use the same tools, much less ActiveX. Just because Mesa is the best right now doesn't mean everyone should abandon development. It's competition and the challenges of beating out the other guy that make things better. Believe me, there are better browsers out there than Lynx, but twenty years ago everyone thought it was the browser to end all browsers. Was it?
The only reason ActiveX has any semblance of being a 'standard' is because Microsoft says so, per usual. If it's all you have available, then you use it, right? Windows in general makes it difficult to 'think outside the box', if you pardon the cliche, so the less innovative and groundbreaking game makers throw in the towel and use ActiveX.
These new entries into the Linux game world need our suppert, not our 'you're not as good as xxxx' sentiments. How is that 'tude going to encourage people to make things better? Don't we want something better than ActiveX for Linux? We gotta start somewhere, and unfortunately for the impatient, that somewhere is here and now.
By the way, as long as I'm on the soapbox, the grim reality is that development of games and software in general takes money. I praise the open software movement, but look at your history. The first open source software was written by government employees and contractors that were being paid to do so! It was their job! I don't know where GPL'd software authors find the time to write free software. I'd personally like to thank every one of them, but this 'gimme gimme' attitude isn't going to last much longer, and there's a plateau of quality out there that most people won't want to pass without compensation.
So there.
Mailbox open for flaming...
-mattyj
Also check out Crystal Space (at http://crystal.linuxgames.com). This is an Open Source 3D Game Kit. It contains a 3D engine, portable 3D sound drivers, low-level networking drivers, ... We are also working on Physics, AI, and scripting. The 3D engine can work with OpenGL, Direct3D, Glide, and software rendering. Crystal Space compiles and runs on Linux, Solaris, FreeBSD, SGI, Windows, DOS, OS/2, BeOS, Macintosh, Amiga, OpenStep, Rhapsody and NextStep.
One warning though. Crystal Space is not finished. It is work in progress. There are currently about 400 people subscribed to the developers mailing list. Not all of them are active developing but some are. Work is going very well. We're now busy defining the API and a first tutorial has just been released.
Greetings,
Project Manager of Crystal Space (http://www.crystalspace3d.org). Support CS at http://tinyurl.com/cb3x4
So with GGI they'd support 3D graphics under Linux as well? Anyone have any idea when that would be? (The web page doesn't say, AFAIK.)
Herbert von Kammerstein
Herbert von Kammerstein
Nosferatu Hacker extraordinaire! Well, I wish, anyways...
I can't believe they got SPRITES to work under X11. This is some incredible technology.
Clanlib is multi-platform in that it is open-source, and thus portable. They decided to spend their effort getting the library to work on one platform, likely in the hope that enthusiasts on other platforms will download, compile, and port. This is part of the power of Open Source: you don't have to do it all yourself.
If you want it on JRandomIx, just port the sucker! It's probably easier to port the library than to use it. If you don't have the hardware to do the port, what could you use the port for anyhow?
When you do port it, send Clanlib your diffs and your binary. They're likely to be more than happy to integrate your code and give you credit.
This is a true case of lighting a torch rather than cursing the darkness. Especially when you have the torch in one hand and a Zippo in the other.
--The basis of all love is respect
Yes, movsb is horribly slow (compared to equivalent instructions on pentium+). xor is slightly smaller than mov, and it did used to be faster, but on k6, pII, etc., the mov is no slower and is actually faster in some cases.
The big thing I disliked about these games is that they sit busylooping while not doing anything, so sitting at a menu while nothing is happening eats 100% cpu. Using blocking calls is pretty simple and makes other things happier. Some of us are actually doing stuff in the background while we play games...
No matter how bad this is, it's still not as bad as EGAVGA.BGI; I mean Borland actually had to try hard to come up with something that awkward.
Sorry but the just do it instruction was never included on a chip so getting even sprites to work is a huge deal. Get a clue.
The ship sank. Get over it. (This sig was cut out from another's shirt and painstakingly hand-posted)
Actually, props should go out to the ClanLib folks. The developers of GAMES (that's me), ClanLib and PenguinPlay all belong to the same online game-development consortium and we've done a lot of helping each other out.
Games are a big weak spot for Linux, so naturally it seems that making Linux an attractive game platform is an important long term goal for the community. Sure, some people don't like games, but no one can argue that games haven't partially driven CPU technology in the past and have almost totally driven low-end 3d technology.
So how do we push Linux (and unix in general) as a usefull game platform? Obviously we need to present game programmers with a programming interface that they can use to port games to (or ideally write original games for). Like GTK+ is for GUI applications (or Qt, depending on your religion), we need the "GTK+" of the game world. Some kind of library that:
1. Is portable
2. Is extendable
3. Can make use of hardware acceleration
4. Can grow with future graphics/sound technology
5. Is based on _some_ kind of industry standard
Number five is VERY important. A standard has to be agreed upon or developers are just going to shrug Linux off as a bunch of non-standard API's each evangalized by their own creator but no one else.
What we have been seeing lately, is too many chefs spoiling the soup. Everyone and his uncle has their own API they are trying to push, and no one is working together to agree on a standard.
You aren't going to like this but I'll say it anyway. The reason Windows has caught on as a game playform is because of DirectDraw and DirectSound (and to a lesser extent hardware-accellerated OpenGL). Simply, developers don't have to worry about writing their own routines to allocate video memory, access the sound card's dma buffers, etc. etc., because Microsoft for once provided a pretty decent standard API to write to, that everyone could pretty much agree on.
Everytime someone announces his own "KICKASS GAME API" we (the Linux/unix community) actually suffer a set-back. We slip farther from the goal of having a single, open, standard API for mainstream developers to rely on.
Fortunately we have things like Mesa, which seems to "Get It". I'm not going to advertise Mesa more than I have to, suffice to say it meets all of the five criteria I mentioned above. Personally I believe time spent on writing APIs that essentially do what Mesa already does is time wasted. LOOK INTO MESA before you decide to write "Yet Another Graphics API".
On the other hand, we have sound support on Linux. Currently it's a mess. Basically application writers need to directly access the sound driver in order to get any kind of noise working. We currently have no standard _OPEN_ API to work with, and for the most part sound capabilities under linux are limited to a single process using a sound card. This will not fly with game developers.
Like the graphics world, we need an sound API that:
1. Is portable
2. Is extendable
3. Is hardware-independant
4. Allows more than one process/thread access to sound hardware simultaniously (a mixer)
One thing I have seen that looks promising is eSound. Do your own research on it but it looks pretty nice, and it will get the job done if its developers continue to do "The Right Thing".
It is important for us small-time game developers to look for APIs like Mesa and eSound, which are implemented properly and have potential to become some kind of standard, rather than latching on to one that has cool screenshots but only had a single game written to them--or worse, just writing our own game API.
You should alllook at http://privat.schlund.de/g/grumbel/pingus/index.ht ml . It's a GPL'd Lemmings clone, but with Penguins! It also runs on ClanLib, though it's not finished yet.
Not the word multiplatform means supporting more than one platform. I didn't say it was omniplatform.
It's multiplatform in a way that GGI isn't, though. It runs on DirectX too! Thus, you just have to recompile a game written for ClanLib and it works in Windows or Linux