Alternatives to SDL

shotgunefx has asked for the wisdom of the Perl Monks concerning the following question:

Replies are listed 'Best First'.
Re: Alternatives to SDL by zentara (Cardinal) on Feb 06, 2007 at 21:06 UTC
I think you asked this before, and I mentioned Tk or Tk::Zinc will do the job. Another possibilty now is the Gtk2::DrawingArea, which is more similar to SDL than a canvas. The Gtk2::DrawingArea can use Pango and Cairo to make exotic looking drawings. You need to use a little hack with a DrawingArea however, to maintain persistence of image, but you can glean that technique from the various demos. See Drawing with Perl/Gtk2 If you go with Gtk2, you can then incorporate Gtk2::Streamer (which is the general purpose high-quality actively developed multi-purpose player for Gtk2). However, I found that SDL::Audio was easier to understand than Gtk2::Streamer. P.S. The newest promise on the horizon is Papyrus but there is no Perl port yet. I'm not really a human, but I play one on earth. Cogito ergo sum a bum	[reply]
Re^2: Alternatives to SDL by shotgunefx (Parson) on Feb 06, 2007 at 21:19 UTC
Thanks for the pointer. I don't think I asked quite the same question (maybe wrong though), but I don't recall feeling that the situation was completely hopeless until the last few days. I considered TK briefly (I haven't played with it in some time), but I didn't think I could get the control I want, but maybe I didn't look hard enough. I'll check out Gtk2, hopefully I'll have better luck. Otherwise, think I'll have to brush up on my C and give QT a try. -Lee "To be civilized is to deny one's nature."	[reply]
Re: Alternatives to SDL by Joost (Canon) on Feb 06, 2007 at 21:07 UTC
If you just want to play songs one after the other, you might be better off using a stand alone command line player like mplayer it plays very nearly everything if you've got the right codecs. Another option is gstreamer, which is the gnome media playing framework. It has a perl API and should also play a lot of different formats, but you might have to work your way through a lot of non-perl documentation to get it to work. update: as for imaging, if you're going with GStreamer, GTK2 will probably integrate nicely and it has the nice ~~TK2::Canvas~~ Gnome::Canvas interface that will let you do nice looking structured drawing. "What should it profit a man, if he should win a flame war, yet lose his cool?"	[reply]
Re^2: Alternatives to SDL by zentara (Cardinal) on Feb 06, 2007 at 21:15 UTC
I would probably go with Tk::Zinc myself, for the simple reason that it has scalable text, i.e. you can make the text objects zoom to size with the other items. The Tk canvas and Gnome2::Canvas can't do that, you need to switch fonts. Zinc also supports alpha layers so you can make cool buttons and effects. I'm not really a human, but I play one on earth. Cogito ergo sum a bum	[reply]
Re^3: Alternatives to SDL by shotgunefx (Parson) on Feb 06, 2007 at 21:31 UTC
Scaling text isn't that big of a deal as I wasn't doing it anyway, but alpha layers, I was playing with a bit, though that in itself can be quirky in SDL. All things being equal, I'd rather have more options rather than less. But either way, it's not a deal breaker/maker as I'm trying not to make it too busy and KISS as it's for the car. The big thing is if I can get enough control over the events for handling the touch inputs the way I want. Thanks for the suggestion, I'll look into them both. -Lee "To be civilized is to deny one's nature."	[reply]
Re^3: Alternatives to SDL by shotgunefx (Parson) on Feb 07, 2007 at 22:02 UTC
Looked into Zinc a bit, while I think especially with the animation issues, it might not be ideal, it's pretty damn sweet. Considering the UI is pretty close to vector to begin with, it's tempting. -Lee "To be civilized is to deny one's nature."	[reply]
Re^2: Alternatives to SDL by shotgunefx (Parson) on Feb 06, 2007 at 21:25 UTC
CMD is out. It's a touchscreen interface for my car (eventually a digital dash as well, but these issues have been holding that at a standstill). Non-perl docs is not a big issue, much of SDL isn't documentated and had to spend a good deal of time in the C docs for it anwyay. Most of what I'm doing on screen is just blitting sprites (and managing the animation frames), and some TTF text. I had some OpenGL aspirations, but at this point, that's on the far horizon. -Lee "To be civilized is to deny one's nature."	[reply]
Re^3: Alternatives to SDL by Joost (Canon) on Feb 06, 2007 at 21:40 UTC
CMD is out. It's a touchscreen interface for my car What I meant was, you could fairly easily control a command line player from perl using whatever GUI you want. Unless you need very tight control, you don't have to run the audio stream through the perl process. for example, mplayer has single-key commands for almost every action. it's probably not very hard to wire that to a perl program. "What should it profit a man, if he should win a flame war, yet lose his cool?"	[reply]
Re^4: Alternatives to SDL by shotgunefx (Parson) on Feb 06, 2007 at 21:48 UTC
Re^5: Alternatives to SDL by Joost (Canon) on Feb 06, 2007 at 21:53 UTC
Re: Alternatives to SDL by Corion (Patriarch) on Feb 06, 2007 at 22:09 UTC
Depending on whether you want an integrated toolkit or are prepared to fudge your UI together from single parts, maybe going back to OpenGL for the drawing (via the MESA software renderer or some supported hardware renderer) and using the fmod library for the mixing and playback of whatever sound you have could be a solution. OpenGL has the advantage of having Perl bindings available and it has Glut, a somewhat basic user interface library. It completely lacks widgets and doesn't have much in the way of event handling though. Fmod is a commercial library which is gratis for open source projects and I had great success in playing back mp3 files with it. I didn't bother to fudge around with other solutions but if fmod is ruled out, maybe the Ffmpeg modules (both, the command line or the XS variant) might provide adequate playback functionality.	[reply]
Re^2: Alternatives to SDL by shotgunefx (Parson) on Feb 07, 2007 at 00:06 UTC
That might not be a bad idea, but I haven't looked at OpenGL from a programming perspective in ages. Suppose there was a little hesitation there. SDL doesn't have any widgets either, so I wouldn't be losing anything, I guess I'll have to take a look at it from a distance and see how easy it's going to be to grok. One of the things that I wanted for the dashboard part was to use a 3D model of my car that I have in conjucture with the diagnostics, but since it's mostly dressing, I was saving that for last. I've recently used ffmpeg, but only for converting stuff. Never thought of using it for playback. I guess I'll have to poke around and whatever has the best docs/most active will get the nod. That or maybe I'll take my own shot at an Wx+SDL library. Just hate wasting so much time. -Lee "To be civilized is to deny one's nature."	[reply]
Re: Alternatives to SDL by Anonymous Monk on Feb 06, 2007 at 23:23 UTC
Prima?	[reply]
Re: Alternatives to SDL by shotgunefx (Parson) on Feb 14, 2007 at 12:51 UTC
An update, after looking at some of the alternatives (and how much work I'd have to do to refactor), I decided to give it one last final shot. I hunted down everything SDL related and manually deleted it. (Ubuntu doesn't want to let SDL-Mixer go without uninstalling ubuntu-desktop). One problem I've had repeatedly is smpeg. It doesn't seem to be actively developed and half of the mirrors listed aren't up. Not a good sign. I've always had problems getting it to compile (complaints of syntax errors, usually something to do with friend functions). So I decided to use smpeg and smpeg-dev and hope I could just build everything else from source. Now I just get pure static. So I decided to try building smpeg again from src (smpeg-0.4.5+cvs20030824). After much head bashing, I determine I need autotools-1.4 installed (I've got 1.9), so I install that, and now I'm getting token errors about AM_PATH_GTK, after much more googling, I find that this should be defined in some GTK m4 file. So I download every gtk dev package I can find, and now the definition is there, but it still doesn't work. I try running .configure again (after make realclean) and still no dice. I'm about to give up, and find another post on an unrelated autotools problem mentioning something about running autogen.sh So I run autogen.sh, run ./configure again, and what do you know. It works. Not only does it work, everything works pretty much flawlessly, even when suspending and restoring. Unless something happens, pretty sure I'll be looking at these alternatives for future projects, too much frustration with SDL. Figured I'd just pass along my resolution in case this helps anybody with similar problems. Here's the packages I used. The last source of SDL_Perl-2.1.3 I could get to build, with all my patches to fix the memory leaks, and the addition of panning to SDL::Mixer along with some related constants (the pod has been updated as well), it's available here. mySDL-Perl-2.1.3.tar.gz The following sources. freetype-2.1.10.tar.gz jpegsrc.v6b.tar.gz SDL-1.2.11.tar.gz SDL_gfx-2.0.13.tar.gz SDL_image-1.2.5.tar.gz SDL_mixer-1.2.7.tar.gz SDL_net-1.2.6.tar.gz SDL_ttf- 2.0.8.tar.gz smpeg-0.4.5+cvs20030824 For the GL stuff, I just used the ubuntu packages. Again, thanks for all the input. -Lee "To be civilized is to deny one's nature."	[reply]