What's the least insane choice for implementing 2d game graphics? I'm toying around with DirectX9 right now, but it seems like overkill and I'm thinking it's not exactly very portable.
I'm aiming for something like Cave Story or maybe Touhou-style graphics.
In my opinion, it's Allegro. It's mature, cross-platform, can take advantage of acceleration provided by the host, and is easy to program for.
Some people recommend SDL. Similar to above, but it provides less additional tools for a game writer. Use it if you're hardcore OSS, otherwise Allegro's probably a better choice for games IMHO.
I've also been playing around with ClanLib. A bit like Allegro, but higher level and requires C++. I find it quite nice so far. Can be bitch to compile if you're not using Visual C (I wanted to use it with Dev-C++).
Allegro is a very old-school functional API with quite a bit of global state and such that makes CS majors grind their teeth. However, it is easy and straightforward to use, with a minimal number of hoops to jump through to get code up and running. It also has a vast library of functions that are useful for game code.
SDL is a slightly more modern functional API. It is also provides only the absolute basics to get a 2D or 3D canvas up and running. From there on, you need to either code absolutely everything yourself, or download any number of external add-on libraries. Personally, I can't stand having to do that, and if you're going to distribute source, it means people will have the worst time getting your code compiled, but maybe you still prefer that.
SDL feels more solid for OpenGL code, though, so personally I've used Allegro for 2D and SDL for 3D.
I prefer SDL.. It doesn't matter if you have to "code everything yourself" because you only need to do it once, put it in a function, you know.. Make the tools yourself.
>>4
That is sort of what I am trying to do, I'm building a shmup development toolkit. I suppose SDL/Allegro will end up handling graphics (and input?) but I will also be poking around with efficient collision detection algorithms and scripting (maybe bulletML).
Thanks for the info guys, I'm checking out Allegro and SDL now.
While we're on the subject of game development, has anybody ever done it with Eclipse/CDT/MinGW? I know I was having troubles getting directX to work with it ...
>>4
I used to have that attitude, then I noticed I rarely finished anything because I was always busy writing routines that were already implemented elsewhere. Wow, look at my awesome custom libraries, now where's the game?
There is no reason to do so, unless you're trying to learn. Chances are the game libraries have a better implementation than what you wrote anyway.
This is what I've learned the hard way (spare yourself the pain):
For efficient 2D collision detection, I recommend run-length encoded sprites. That is to say, sprites stored runs of solid pixels or empty pixels. Allegro can use those for drawing speed improvement already (fast to draw since you can just skip the empty pixels), but it's fairly easy to extend the idea into fast and pixel-perfect collision detection.
Although you say DirectX seems like overkill, you might want to look at 3D accelerated 2D anyway (not necessarily Direct3D, you could always use OpenGL is you want it to be portable). Modern graphics accelerators perform rather crummily when it comes to 2D acceleration, yet a bunch of textured quads rendered in orthographic mode is a cakewalk for them. Things like rotation, scaling and alpha blending is lot less costly as well.
Making a shooter, which have a lot of moving objects on the screen at the same time, using just 2D acceleration might make it difficult to get decent framerates, unless you keep the resolution low.
ClanLib does this.
The thing with 3D accelerated sprites is that means you're stuck with it, since most libraries I've looked at don't let you mix framebuffer access and 3D acceleration. So you can't code your own drawing any longer, but have to do everything through 3D.
This may not pose a problem, though, depending on what you want to do.
In Touhou games, it seems that the player, enemies, and bullets are quads while the background/level is a 3d flyby-ish kind of thing. I suppose that means it's all done in 3d anyway?
ZUN uses DirectX for his games, doesn't he?
DirectX != Direct3D
i know i know, it includes DirectInput and DirectSound and DirectShow, etc etc