Advertisement

Linux graphic API?

Started by January 15, 2005 11:06 PM
18 comments, last by shemsuheru2064 19 years, 10 months ago
Except for special purposes, ignore stuff like svgalib and framebuffer - they're really more suited to embedded systems and aren't generally available and/or usable on desktops.

You really want something which works in X - this means that you have either

- Use Xlib directly (not pretty) - with or without OpenGL
- SDL - lets you do limited software rendering into a window or fullscreen in X
- SDL+ OpenGL - hardware rendering, SDL hides the Xlib mess for you (and identical code should work on Win32)
- Use some other library for instance Allegro or GGI

You will be able to launch the app from the command line, if you do so within an X environment already.

As a Linux user myself, I wouldn't generally consider making a game which is not portable to Windows, at least ultimately, as it vastly decreases the number of people who can play it. If you use a library which works on Win32 as well, you can probably port it later with a minimum of fuss (assuming you don't use any other (non-gfx related) Linux-specific stuff).

Mark
Quote: So now, I would have to decide to use SDL with X or the framebuffer?
What are the major differences between the two? Any pro/con for each choice?


Use SDL. It's available on most every platform and it has a small and well-documented API. Compare that to direct framebuffer manipulation which results in lots of platform dependent code.
Free Mac Mini (I know, I'm a tool)
Advertisement
Thanks a lot guys, SDL looks like the way to go!
At least on my installation of SDL, it will use X automatically if X is started, and the framebuffer if I run the SDL app in text mode.
I can MAYBE understand why framebuffer would be considered an option in a thread like this, but @#$#!$!@ING SVGALIB!???

ARE YOU FREAKING INSANE?

This is a library that's designed to let you (OMG!) use the incredible resolution of 640x480x256 colors!!! (and up, but this is what it's designed for) Let's not also mention that your silly little game must run as root (BAM your system is hacked for the 12971287 things that you don't know about that you must never do with code running as root). Oh and 3d? You're silly! Computers aren't fast enough to render 3d! LOL Alpha blending LOL!
Quote: Original post by C-Junkie
ARE YOU FREAKING INSANE?

We are all programmers here, but you really need to learn to lay off the sugar, you sound like you are going to kill something :-P
Turring Machines are better than C++ any day ^_~
Advertisement
It gets more attention than "svgalib is obsolete."

Therefore, more people remember, and they never commit this sin ever again.

svgalib... sheesh
No one mentions clanlib, or allegro? Shame on you people for not letting him know about more possibilities. :p
I'm using SDL. I've programmed C++ for at least 8 years and I can say it's a good way to go. Even if you just want a windows and a framebuffer, or in our case, open gl, it's pretty good and works everywhere.

Not to mention platform independence which is quite nice :)

I just wanna put SDL in the spotlight it deserves...

Albert
-------------------------------------------http://www.thec.org
X and the framebuffer are good. Keep in mind that you can also use the DGA 2.0 driver, which uses hardware for graphics acceleration.

http://www.linuxdevcenter.com/pub/a/linux/2003/08/07/sdl_anim.html?page=1

Using the DGA might not be the best idea if you plan on using pixel-perfect collision detection though, as individual pixel access is still relatively slow. Or, perhaps, you can wait until the glSDL backend is integrated within SDL.

This topic is closed to new replies.

Advertisement