Linux libs on intro/demo compos
category: code [glöplog]
Hello, I would like to list (with your help) what libraries are usually available on a compo machine with Linux:
Not so sure about this ones:
thx
- OpenGL
- SDL
- GLUT
- Freetype
Not so sure about this ones:
- GLEW
- Cairo
- Pango
thx
The only libraries I would count on usually are: OpenGL, SDL, Qt, GTK, X
Others should be bundled together with the demo. :)
But really a good rule-of-thumb could be that only assume libraries that are for example available in fresh Ubuntu distribution installation(+SDL).
Others should be bundled together with the demo. :)
But really a good rule-of-thumb could be that only assume libraries that are for example available in fresh Ubuntu distribution installation(+SDL).
I don't have SDL on my Linux.
Pulseaudio should usually be available.
Waffle: do you know if this libs come on Ubuntu?
Xernobyl: what distro do you have?
Jaw: SDL have SDL_Audio, but Pulseaudio is nice also.
btw Cairo and Pango are required by GTK.
Xernobyl: what distro do you have?
Jaw: SDL have SDL_Audio, but Pulseaudio is nice also.
btw Cairo and Pango are required by GTK.
Bundling libs is good, because otherwise people might run into version incompatibilities (the only alternate solution to that is including the source, which you often might not want to do).
I think we should come up with somethink like LScB (Linux Scene Base) where we list all the libraries and their versions that are expected to be installed on a scener's/compo machine.
My proposal:
libSDL-1.2
/end of proposal
Very brief explanation follows
Advantages of libSDL:
- Have both video and audio init routines
- Doesn't do anything fancy except initialization
- OpenGL context initialization takes only 2 calls (1 call if SDL_Init() is already called). Comparison: GLUT needs about 5 calls, bare Xlib+GLX -- 11 very dirty-looking calls.
- Very simple callback-based audio in a separate thread, independent of actual system output (alsa, jack, oss, pulseaudio, whatever). Comparison: if you have a success story for getting your program to work with bare ALSA API, please tell! OSS is not available on Ubuntu. Pulseaudio is an api-layer over api-layer over api-layer over api-layer for those, who hate low-latency and love their audio not working at all. JACK is great but gets installed on musicians machines only.
- (games) contains mouse/kb events support.
- (1k/4k) Possible to get OpenGL and audio in about 500 gz-compressed bytes
- Extremely portable -- very easy to port a linux prod to anywhere else
- Quasi-ubiquitous -- so many things depend on it that you should already have it installed as a dependency for something if you are an active linux user
Disadvantages of libSDL:
- Not installed by default by some distributions
- (mostly related to games, not demos) Some users report that it doesn't give enough low-level control over events/eventloop
- Not hardcore enough for viznut
My proposal:
libSDL-1.2
/end of proposal
Very brief explanation follows
Advantages of libSDL:
- Have both video and audio init routines
- Doesn't do anything fancy except initialization
- OpenGL context initialization takes only 2 calls (1 call if SDL_Init() is already called). Comparison: GLUT needs about 5 calls, bare Xlib+GLX -- 11 very dirty-looking calls.
- Very simple callback-based audio in a separate thread, independent of actual system output (alsa, jack, oss, pulseaudio, whatever). Comparison: if you have a success story for getting your program to work with bare ALSA API, please tell! OSS is not available on Ubuntu. Pulseaudio is an api-layer over api-layer over api-layer over api-layer for those, who hate low-latency and love their audio not working at all. JACK is great but gets installed on musicians machines only.
- (games) contains mouse/kb events support.
- (1k/4k) Possible to get OpenGL and audio in about 500 gz-compressed bytes
- Extremely portable -- very easy to port a linux prod to anywhere else
- Quasi-ubiquitous -- so many things depend on it that you should already have it installed as a dependency for something if you are an active linux user
Disadvantages of libSDL:
- Not installed by default by some distributions
- (mostly related to games, not demos) Some users report that it doesn't give enough low-level control over events/eventloop
- Not hardcore enough for viznut
s/somethink/something/
@pera:
I don't know.
I'd assume that X, OpenGL, GTK, Cairo and Pango are available in Ubuntu since it's based in Gnome.
On the otherhand Kubuntu then probably has X, OpenGL and Qt since it's based in KDE. Isn't it lovely that there are so many windowing solutions to cause dependency hells! :-)
@w32:
Other good reason for SDL is that it's already in use with many Linux productions and for instance Assembly demoparty explicitly allows its use.
Disadvantage is that SDL has had its share of bugs in windowing code (f.e. with multiscreen monitors).
I don't know.
I'd assume that X, OpenGL, GTK, Cairo and Pango are available in Ubuntu since it's based in Gnome.
On the otherhand Kubuntu then probably has X, OpenGL and Qt since it's based in KDE. Isn't it lovely that there are so many windowing solutions to cause dependency hells! :-)
@w32:
Other good reason for SDL is that it's already in use with many Linux productions and for instance Assembly demoparty explicitly allows its use.
Disadvantage is that SDL has had its share of bugs in windowing code (f.e. with multiscreen monitors).
@waffle
Multiscreen on linux (and not only linux, to be honest) is a major disappointment itself, so i wouldn't expect _anything_ to work seamlessly and correctly with it. Do you have any experience with bare glx and multiscreen?
Multiscreen on linux (and not only linux, to be honest) is a major disappointment itself, so i wouldn't expect _anything_ to work seamlessly and correctly with it. Do you have any experience with bare glx and multiscreen?
I'd suggest installing command-line Ubuntu and then installing bare X and ALSA. Just assume nothing else there and run the demo with xinit <name>.
@Subi
Let it be gentoo then.
Oh, wait.
We're talking about Linux, not GNU/Linux, right? Then, there's just bare kernel and no userspace and no libraries at all. We still have framebuffer and oss emulation in alsa (good luck with using vanilla alsa), though. That should be enough for everyone.
Let it be gentoo then.
Oh, wait.
We're talking about Linux, not GNU/Linux, right? Then, there's just bare kernel and no userspace and no libraries at all. We still have framebuffer and oss emulation in alsa (good luck with using vanilla alsa), though. That should be enough for everyone.
alsa is not exactly complicated to use, mind you. snd_pcm_open, snd_pcm_set_params, and you're good to go :)
Having nothing more than X + alsa is a bit harsh, isn't it ? At least expecting SDL should be ok when the whole direct3D libs are allowed on windows.
And then, for demos, one could distribute .so file along the executable. :)
Having nothing more than X + alsa is a bit harsh, isn't it ? At least expecting SDL should be ok when the whole direct3D libs are allowed on windows.
And then, for demos, one could distribute .so file along the executable. :)
@xtrium
I've had very little experience from using ALSA, mainly because I couldn't ever set it up right. That maybe because I was at the time (or still am) a not very clever human being, or it's just my linux setup having three physical sound cards (internal, usb, videocard-hdmi), several virtual ones (dmix, 2ch-to-6ch, 6ch-to-2ch, some ladspa tweakery) and some very broken interconnections of all that. ALSA threw a lot of inapprehensible error messages at me, while libSDL (and JACK) just worked.
Anyway, thanks for defending SDL :D.
I've had very little experience from using ALSA, mainly because I couldn't ever set it up right. That maybe because I was at the time (or still am) a not very clever human being, or it's just my linux setup having three physical sound cards (internal, usb, videocard-hdmi), several virtual ones (dmix, 2ch-to-6ch, 6ch-to-2ch, some ladspa tweakery) and some very broken interconnections of all that. ALSA threw a lot of inapprehensible error messages at me, while libSDL (and JACK) just worked.
Anyway, thanks for defending SDL :D.
xtrium: Oh god, the old "SDL IS LIAK DIRECTX FOR LINUX"-argument again...
kusma: I'm not saying "oh gawd those 4k use Megabyte-big libs this is outrage" - I'm more than happy to use this just like everyone else in my own win32 code.
No, what I mean is that linux distros are so different between one another, the common base libs available falls down to pretty much nothing and thus, as of now, a linux coder can't expect the same facilities one would have using windows without, for example, SDL available on the compo machine.
No, what I mean is that linux distros are so different between one another, the common base libs available falls down to pretty much nothing and thus, as of now, a linux coder can't expect the same facilities one would have using windows without, for example, SDL available on the compo machine.
Quote:
the common base libs available falls down to pretty much nothing
Good point. That warrants some basic SDL use.
Not sure I see the need for SDL. If you're using GL then the difference between Windows and Linux is you only need to call XCreateWindow instead of CreateWindow, glXCreateContext instead of wglCreateContext and glXGetProcAddress instead of wglGetProcAddress.
@Subi
As to my knowledge, this is incorrect. You need absolute minimum of 11 rather obscure x11/glx calls to setup opengl context, not just XCreateWindow and glXCreateContext. If you know a better method, please share.
As to my knowledge, this is incorrect. You need absolute minimum of 11 rather obscure x11/glx calls to setup opengl context, not just XCreateWindow and glXCreateContext. If you know a better method, please share.
@w23: Fair point, okay here's my init code (probably won't compile, as I've quickly chopped out all error checking and logging, but it's an accurate representation of my Linux GL init code):
(pats copy of Xlib Programming Manual vol 1 ;) )
Beyond that, the GL code is the same for Windows and Linux (apart from glXGetProcAddress).
Code:
Display* m_p_Display = XOpenDisplay(NULL);
unsigned int m_uiScreen = DefaultScreen(m_p_Display);
int p_iAttributeListDoubleBuffered[] = { GLX_RGBA, GLX_DOUBLEBUFFER, GLX_RED_SIZE, 8, GLX_GREEN_SIZE, 8, GLX_BLUE_SIZE, 8, GLX_ALPHA_SIZE, 0, GLX_DEPTH_SIZE, 16 : 8, None };
XVIsualInfo* m_VisualInfo = glXChooseVisual(m_p_Display, m_uiScreen, p_iAttributeListDoubleBuffered);
Window WindowRoot = RootWindow(m_p_Display, m_VisualInfo->screen);
XSetWindowAttributes m_XSetWindowAttributes;
m_XSetWindowAttributes.colormap = XCreateColormap(m_p_Display, WindowRoot, m_VisualInfo->visual, AllocNone);
m_XSetWindowAttributes.border_pixel = 0;
m_XSetWindowAttributes.event_mask = ExposureMask | KeyPressMask | KeyReleaseMask | ButtonPressMask | StructureNotifyMask;
Window m_Window = XCreateWindow(m_p_Display, WindowRoot, 0, 0, uiWidth, uiHeight, 0, m_VisualInfo->depth, InputOutput, m_VisualInfo->visual, CWBorderPixel | CWColormap | CWEventMask, &m_XSetWindowAttributes);
Atom wmDelete = XInternAtom(m_p_Display, "WM_DELETE_WINDOW", true); // This isn't strictly necessary.
XSetWMProtocols(m_p_Display, m_Window, &wmDelete, 1);
GLXContext m_GLXContext = glXCreateContext(m_p_Display, m_VisualInfo, 0, GL_TRUE);
glXMakeCurrent(m_p_Display, m_Window, m_GLXContext);
(pats copy of Xlib Programming Manual vol 1 ;) )
Beyond that, the GL code is the same for Windows and Linux (apart from glXGetProcAddress).
The original post refers to what's available on a compo machine. I'd say it's not primarily important what any (beginner) desktop user Linux distros provide out of the box, but what would be a good, common foundation demos can be built upon. If that's not part of any default install, then just install it on the compo machine and be done with it.
Further, I find it pretty clear that there won't be a consensus on what to choose from the desktop environment layer (KDE/Qt, Gnome/GTK etc.), so that should be left out anyway.
Further, I find it pretty clear that there won't be a consensus on what to choose from the desktop environment layer (KDE/Qt, Gnome/GTK etc.), so that should be left out anyway.
My linux "demo" framework currently only depends on Xlib and GL. For graphics that is.
I mean -lX11 and -lGL