Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Coro and SDL 2 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • That's interesting. Not long ago, someone showed [mongueurs.net] how, with a little help from SDL, Perl can be a suitable platform on which to develop a commercial-quality game [frozen-bubble.org]. I wonder whether the trouble with SDL's thread support [perl.org] means that this combination falls short of its promise; indeed, I can imagine games so demanding that this issue would be a show-stopper. But what kind of application are you writing that would cost you this kind of grief? And what did the SDL maintainers have to say about what you found?

    • Hey. Out of some mix of (false?) modesty and other factors, I don't like to talk about what I actually do. Usually I have more room to talk about stuff but in this case, it's kind of a three way and one of the parties is shy. But if you really care, telnet to weehours.net 2000 and ask for me. Obviously I'm not going to let anyone's cat out of the bag, but I can give some background. If you care, that is.

      SDL works okay as far as I know. For about anything, you can ignore the fact that SDL sucks in threads and just use POE, or Event, or write your own event loop, or use SDL's.

      SDL's event loop doesn't have file watchers, and one of the requirements for this project is async communication with a server over an SSL socket. So that ain't going to fly. I can fork off waiting for mouse events in another process and then select() or use Event to watch for activity from either the mouse or the SSL socket. But I'm a Coro junkie.

      It's really Coro that's touchy here, and that's to be expected as long as Coro is a module rather than a comprehensive core rework. And even then, the problem of XS is hard. Cory has to copy the C stack in and out. I have a reasonably good idea how C compilers, libc, dynamic linking, etc works, but not when it comes to threads, so I don't know why Coro and threads don't play nice together, but in this case, it looks like even loading libpthreads replaces malloc() with one that does things to the stack frame that aren't safe to do with Coro loaded. And it blows up.

      The real trouble with SDL that maintainers should be notified of is the build system problems, and I filed a report. However it looks like there have been no releases since 2003. Off the top of my head. Maybe I'm misremembering. But I already said all of that in the main article. There's nothing they can be expected to do about the libs they link to (the C SDL libs) sucking in libpthread, especially since this isn't generally a problem.

      The retarded thing that really makes this yak shaving is I'm supposed to be working on a bit of embedded-ish hardware (which I decided to use SDL and some XS libs I wrote to wrap the vendor's C++ libs) but I can't get their API to work right, so I'm just kind of prototyping on the x86 laptop. So, part of my motivation for making Coro work with SDL is that it frickin' works on the embedded board and I might have to/get to move development back there if the vendor get their act together.

      Way more than you wanted to now? Sorry.

      The board is from igamesplus.com by the way. That'll give you a clue what I'm working on here. Fun stuff.

      -scott

Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.