Linux Game SDK, Fully Playable Game 58
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 "
*I* aren't sure. (Score:1)
Funny you should mention that... (Score:1)
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..
Slashdot effect already... :( (Score:1)
As if i didn't have enough timewastes already...
Clanlib doesn't work on ppc (linuxppc, glibc2.1) (Score:1)
mustapha.
NOT GOOD!!! (Score:1)
I appreciate that they got so far but it is not open software!
NOT GOOD? Then fix it. (Score:1)
X11 Sprite Libraries (Score:1)
Clanlib doesn't work on ppc ... or alpha (Score:1)
Too many chefs in the kitchen... (Score:1)
Too many chefs in the kitchen... (Score:1)
Don't misunderstand me, but... (Score:1)
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)
NOT GOOD!!! (Score:1)
This SDK has long way to go (Score:1)
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 [investigatio.com]
This SDK has long way to go (Score:1)
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/ [ii.uib.no]
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 [icesoft.no]
Peace, and good luck, don't be mad at me
AtW,
http://www.investigatio.com [investigatio.com]
This SDK has long way to go (Score:1)
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 [investigatio.com]
LGPL (Score:1)
VIVA CLANSOFT!
when games become as natural a part of linux as ls and grep, i will be quite the happy camper...
-josh
Too many chefs in the kitchen... (Score:1)
Too many chefs in the kitchen... (Score:1)
Too many chefs in the kitchen... (Score:1)
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
Crystal Space: An Open Source 3D Game Kit (Score:1)
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,
3D version? (Score:1)
Herbert von Kammerstein
Wow (Score:1)
I can't believe they got SPRITES to work under X11. This is some incredible technology.
NOT GOOD!!! (Score:1)
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.
x86 assembly (Score:1)
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.
Technology Breakthrough ! DamnStraight (Score:1)
Now, wait just a darned minute! (Score:1)
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.
Too many chefs in the kitchen... (Score:2)
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.
Check this out too (Score:2)
NOT GOOD!!! (Score:2)
NOT GOOD!!! (Score:2)