2D graphics engine/sprite library

Anonymous needs to make a 2D renderer in C that will display sprites taken from a cell-based 3D space in 2D in the style of traditional 2D RPGs (for example: http://www.jinseirpg.com/~screenshots/tests/Tales%20of%20Phantasia/top09.jpg ).

Can you suggest a sprite library to abstract from calling the low-level graphics library functions (like SDL, which is what I would use if I can't find anything neat, etc.), that runs under Linux, that would do at least truecolor sprites with color-key transparency?

Full graphics engines doing these kind of graphics I could adapt are welcome too.

Thanks!

My suggestion as usual is to roll your own based on SDL+OpenGL or something similar. Color keying can be offloaded to an alpha channel at texture load time (0 vs 255 or you could have transparent sprites with real alpha), and you get other effects like stretching/rotation and transparency/color blending for "free". It shouldn't take more than a day to whip up a Sprite class and/or a Texture class or something. Of course this won't abstract away anything at first but you can have your api the way you like it.

>>2 is a kid. Only teenagers come up with these gems.

Don't reinvent the wheel; others have done it before you, just better. There are some extension projects using Allegro that do this. If you're willing to live with C++ you could also use ClanLib or Kyra.

http://abattoir.wolfpaw.net/personal/gamelibs.php

Irrlicht is nice, dunno if it does what you want though.

SDL's Sprites support alpha and transparency.

You could always try rolleyes allegro. BTW Game programmers are usually very stupid people so you shouldn't trust the many of the recommendations in this thread.

>>3
comedy "why write a game when others have already done it for you, use RPGMaker" option

Game programmers

Good going at bringing up this topic again. Most "game programmers" I know graduated from good CS programs, and could run loops around most other grads. A decent game engine requires knowledge from many different domains. So, when dealing with code issues I'm more inclined to listen to a game programmer than, say, a programmer working on business code.

Your problem is that you believe people when they claim they're "game programmers" (when they're probably kids). Just because I claim I'm a special agent doesn't make it true.

>>6
More like pragmatism born of experience. I can almost guarantee >>2 is a kid, because I was also like that once. Most of us were. I'm sure there are quite a few readers who will be nodding their heads as they read my tale of woe:

See, I used to develop all the libraries I used, other than the standard C library. I'd spend hours on a routine, counting cycles and making it perfect. They were blisteringly fast. They were elegant. They were small. Simply put, they were great.

You know what? It sucked. When I was done, I had some really nice libraries, but I still had no game. I wanted a game, not a set of fucking libraries. The first real game I ever finished was when I mentally "grew up", became an early adopter of Internet in my area, and started using Allegro instead.

Use existing tools to get the job done. If you write your own when others already exist, you're a fucking retard. Just like I used to be. You'll learn some things that will make you less of a retard, but you'll still have nothing to show for it.

Ignore this advice at your peril. Your mileage will not vary.

>>6
Using existing libraries != RPGMaker.

If you want the API just the way you want it, just write an abstraction on top of an existing library.

I've seen the shit produced by the faggots who go off to work at EA.



LOL

Championship Manager 12, now even more like Championship Manager 11!

I think I'll try Allegro. After looking at 6-7 projects, what they do, how their APIs seem to be, and how nice and abundant are the docs for each, I reduced the list to 3:

- SDL alone (fastest, cleanest, but absolutely low level)
- SDL + Kyra (very high level, but more complex, and lacking docs)
- Allegro (older, I'm betting noticeably slower)

I saw SDL alone was too much work. I need to get this done. Thus I decided between Kyra and Allegro. Kyra does animations which I want to do, and looks awesome. However, documentation seems to be lacking (there are some docs built from comments in the class definitions, but that's not too nice, and no real tutorials). Combined with the fact it's OO and not simple, I don't want to dig it out. Thus I'll go for Allegro.

Allegro is probably faster than SDL, at least for most targets.

I don't know why so many people think SDL is the epitome of quality (it isn't) and Allegro isn't.

O rly? That's good to hear. Thanks for the info!

Tried Allegro, got it to compile (although it won't work with the debug options for some reason; I wonder why this kind of shit always happens in Linux; it _almost_ works); but I can't get it to work 10% decently. Even the basic examples will end up crashing Linux. Yeah, the whole thing. I would think I have a bugged Xfree86/DGA version and/or display drivers, but SDL games seem to work perfectly in all kinds of modes. If I try with different settings for Allegro, it'll just exit with an elegant "Impossible to start Allegro" (or something similar) error.

Thus I'm afraid I'll go back on my decision. I'll try SDL.

What distro are you using? I need to know which one to avoid if it's behaving like that :P

SuSE 9; tried both SuSE's packages (not in the distro, but I got them with RPMFind.net) and manually compiling it. I searched for issues but didn't seem to find anything special outside bugged Xfree86 which doesn't seem to be the case.

I also Googled for Allegro projects and found surprisingly, most of them are only compiled/supported for Windows. Perhaps Allegro is not as tested/nice under Linux?

Yeah I was about to ask which examples you were using because I wanted to try it out under Gentoo but most of the examples are for Windows.

Is the allegro library even being updated (with support for new cards, etc) this decade?

>>19
Allegro is more alive than SDL is. Yeah, seriously.

>>19 that still doesn't answer my question, though. Does allegro support video cards which have been made since 2000?

Uh... if your operating system supports the card, Allegro does. Isn't this obvious?

Do you really think any modern graphics kit still makes calls directly to the card? No, they use what X, framebuffer, DirectX, or whatever other abstraction is available on the OS.

This isn't the DOS era any more. We have these things called "drivers" we install in the OS for a reason.

>>22
>This isn't the DOS era any more.

I didn't know people still used used allegro since DJGPP had given way to Cygwin.

Of course they do. Since DJGPP's days they've ported it to *nix, Windows, QNX, BeOS and MacOS X. While the DJGPP port still exists, I doubt anyone uses it.

Plenty of people use Allegro, simply because it provides more tools for game development than SDL.

SFML is good.

What's wrong with Allegro? I use it.

>>26
fuck you

>>28
Why the hate?

>>29
>5 years

>>29
fuck you too. stop with the bumping old threads

>>31
... or you will do what? Exactly?

>>32
I shall call the bumper a son of a silly person and blow my nose at him.