Beefy Boxes and Bandwidth Generously Provided by pair Networks
more useful options
 
PerlMonks  

2D realtime pixel graphics options in Perl

by flyingmoose (Priest)
on Feb 28, 2004 at 21:32 UTC ( [id://332533]=perlquestion: print w/replies, xml ) Need Help??

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

Ok folks, here's a hard one...
I've kind of ditched by 3D game development plans for a while to go back to 2D, mainly because, well, it's more fun and it allows me to concentrate more on game-play and old-school quarter-eating fun like I remember from the days of Aladdin's Castle and Putt-Putt. 3D worlds just aren't as much fun and they don't allow one to express imagination quite the same way. It's like watching a movie instead of reading a book.

Suppose I want to want to do some 2D graphics in Perl that is the equivalent of an old-school X11 screensaver. Nothing fancy, just some on screen moving pixels and we can be done with it.

Unfortunately I have a laundry list of things I have explored, and I see major limitations in all of them. The "killer" library does not yet exist!

  • OpenGL is not a good option since OpenGL.pm is poorly maintained and does not compile on my system, etc. PDL's OpenGL module does compile, that's nice, but doing 2D through OpenGL is a bit of overkill.
  • Something like Linux::SVGAlib is not good because not many folks will have svgalib and it's not available through apt. Meaning I'd be the only one who ever used by program.
  • Tk::Canvas allows vector based operations, but there is no good way to do pixel based drawing. I suppose some of the photo classes might work, but I don't think they were designed for "flashy demo" purposes so this seems to be a bad idea. I can animate shapes, but for pixel-based fun there aren't many good options. The "Mastering Algorithms in Perl" book (which I don't own) evidentally printed periods to the screen. Ouch! If there was a "Tk::PixelFriendlyCanvas" we'd have gold right here.
  • SDL is nice, but it does not support any primitatives in the standard distribution, which is why cool apps like Frozen Bubble have to pretty much develop their own API's and can get very messy. Also it has a very good tendancy to lock up my machine in a non-killable sort of way, which is annoying -- that's what a low-level API does to you though :)
  • X11::Protocol is a pain in the butt for this sort of thing, but it would work. It's just painful to get off of the ground.
  • X::Osd works really well for what it does, but it does not allow pixel-oriented drawing.

Anybody have any ideas as to how I should get out of this rut? Or where I should just bite the bullet and deal with things?

Honestly, game development was so much easier (it seemed like) back in the day with QBASIC. I know I could do everything in C, or I could buckle down and learn XS (and then use something like clanlib from there), but I'm really just trying to get to that "programming is supposed to be fun" level. In other words, can I get where I want to be without a tremendous amount of pain :) Game-development should be fun and accessible in all languages, and right now it appears Python is slightly kicking our butts with PyGame support being fairly common place.

Maybe I'm wrong for trying to have this much fun in Perl, but hey, I like to choose the languages with the most advanced constructs available...C doesn't do that for me and then you get bogged down with data structures and memory management.

Replies are listed 'Best First'.
•Re: 2D realtime pixel graphics options in Perl
by merlyn (Sage) on Feb 28, 2004 at 23:00 UTC
      Appears to still be for relatively static purposes though. Tk::Animation is a chain of Tk::Photos, hence again not anything close to the old pseudo-MODE13H-esque hacking Zen I'm trying to achieve. Maybe that *does* lead me back down the evil X11 path.
Re: 2D realtime pixel graphics options in Perl
by chromatic (Archbishop) on Feb 29, 2004 at 00:04 UTC

    Have you tried SDL::OpenGL? I've had some success with it.

    Alternately, SDL Parrot's coming along. It's pretty simple at the moment, but you'd have the chance to blaze a trail.

      Hmm, I think you may have pointed me there before (I was asking about RedHat OpenGL.pm compilation at the time)...I think I could find any examples on how to initialize the OpenGL context (no Hello OpenGL demos in the POD) and must have stopped.

      Re: Parrot, etc, I doubt that's what I want for my "quick playing with graphics fun stuff", though I'd definitely like to see it. Where would I go about finding the SDL parrot code? I really need to check out Parrot source at some point or another, might as well be now.

        Parrot SDL lives in the main Parrot distribution for now. See examples/sdl/*imc and library/sdl*.

        The rest of the SDL Perl folks also want to see better graphics primitives. A sprite library would be nice -- there are some ideas toward that end in the tutorials.

Re: 2D realtime pixel graphics options in Perl
by Vautrin (Hermit) on Feb 29, 2004 at 02:09 UTC
    Most games / graphical things are programmed in C / C++ for speed. This makes me think you might want to try rolling your own perl wrapper using Inline::C (or Inline::CPP) to create an API for whatever you need.

    Want to support the EFF and FSF by buying cool stuff? Click here.
      Well, I've been here -- and this is exactly what the Perl bindings to Svgalib and a few other libraries above do. The idea is to avoid reinventing those wheels, as those wheels should already exist. Technically I could just use GTK2 or Qt or something equally complex, but then one spends a ton of time learning the in's and out's of Qt. Really, I'd just like to scrible on the screen as quickly as possible with a minimum of overhead. Over the years this has been QBasic and Pascal graphics modes, Mode13h from C, DOS Allegro, and of course OpenGL, etc.

      If I have to write yet-another-game-programming-library in Perl, I may do that...but I don't want to compete with SDL, per se, since that seems to be the way a lot of languages are going (not just Perl). Still, I'd like to see some higher level 2D drawing constructs built on top of SDL... available in some modules that are a little better organized than what we have today. Something that could effectively provide drawing primatives versus the blit-oriented stuff we have today.

      Dunno. Wheel reinvention is in my future. I feel it. That's not good.

        As I understand your problem, you can't find a graphics library that meets your needs. And the reasons for this are that either they aren't cross platform compatible, or don't have the features you need, right? Well, in that case you're either going to need to a) create your own graphics library for the functions you need or b) modify a freely available one.

        Want to support the EFF and FSF by buying cool stuff? Click here.
      It depends on the game. Some games, like solataire do not require 30+fps on a full screen. If done with double buffering, it could rock with no ill effects.


      I used to be a funny character, now I'm just 4 bits.
        Exactly. Rocking a la Atari 2600 (or say, 8-bit Megaman II) is all that is needed to have fun in my book. Kids these days want too much flashy stuff. Graphics sells, gameplay doesn't...or so it seems...
Re: 2D realtime pixel graphics options in Perl
by smackdab (Pilgrim) on Feb 29, 2004 at 09:26 UTC
    How about Tk::Zinc ? (TkZinc is another Canvas which proposes many new functions, some based on openGL) I haven't used it because it is not supported on Win32 (last I checked). It has great looking demos and I do hope it gets there sometime... Here is a link with docs and screenshots: http://www.openatc.org/zinc/
      I think they are aware that it is hard to compile. From their FAQ:


      3. Installing TkZinc

      Q: How do I install TkZinc?

      A: TkZinc can be installed either by compiling the sources please, read the README file), or by using a binary distribution (the last is often much simpler). For Perl users, TkZinc is also available on the CPAN

      Q: Which binaries package do you offers?

      A: Currently we propose binary package for Debian and Mandrake linux distribution for Intel based hosts. A perl-zinc debian package is also available for StrongArm-based host. However, Pat Thoyts has gently contributed in building a Windows starkit package for Tcl. Any such packaging will be highly appreciated.

      Q: Which are the current plateform known to work with TkZinc?

      A: TkZinc with Perl is working on Linux (and certainly on Unix). TkZinc with Tcl is working on Linux (Unixes), Windows and MacOSX (under X11 with fink).


      Let me guess: you didn't read the README file before you tried compiling?
        Let me guess: you didn't read the README file before you tried compiling?
        Let me guess...you just made an invalid assumption about a certain monk's familarity with the Linux/UNIX compile process and this ability to RTFM?

        To be completely fair, that was one of the less useful README's I've read, as it addressed all the contact information and nothing on the "how to resolve compilation and dependancy problems" side -- all of which I pretty much nailed on my own. Every kid knows "perl Makefile.PL, make, make test, make install". Obvious. That's all it said.

        The code is broken -- it should work from source *without* the need for binary patches. Needing binary patches for a module is like saying "Well, I really don't know how the heck all of this is supposed to go together...I give up...". Really, if the Perl module isn't compiling off CPAN, there is a problem -- and this will keep most users away from it.

      I'm definitely going to look at this. Those screenshots are excellent. I guess I passed over it due to not knowing what "Zinc" was. It doesn't compile straight out of CPAN (doh!) but maybe I'll figure out why...

      Update: guess what, it's not compile friendly in the least. latest tk-devel, tcl-devel, and it's still getting errors in the base file.

      beware: our previous site (www.openatc.org) has been stolen. Tk::Zinc web site is now www.tkzinc.org
Re: 2D realtime pixel graphics options in Perl
by flyingmoose (Priest) on Feb 29, 2004 at 02:54 UTC
    Off-topic, but this was on games.slashdot.org today (urg, yes, I'm linking slashdot), and pretty much describes why I don't finish half of what I start:

    Game Development Complexity

    This quote from some dude on slashdot pretty much sums up what I think about today:

    I remember when I was 13 writing ASM code code aspiring to write something like Monkey Island -- that was a very attainable goal. I had a friend who was a very good artist, he would whip up a some cells in autodesk animator, I had written a little converter, and we could walk our little guy around the screen against a background. Now truth be told I had NO idea how a game engine worked at 13 years old, but we did end up writing a few neat demos and bbs loaders (I was a weird kid).

    Now the level of art work and technical knowledge required to make something that looks half professional is off the scale. I have a great game idea that I don't think I'll ever be able to realize. Thats the loss I mourn... kids wont ever have the fun I had trying to make a game, and we might never be exposed to some new ideas these kids might have.

    --some dude on slashdot

    Gotta keep the fun alive. The fun little tools I used to play with as a kid (14, 15, etc) don't exist in similar forms now, and they *should* be.

Re: 2D realtime pixel graphics options in Perl
by samtregar (Abbot) on Feb 29, 2004 at 03:25 UTC
    Maybe I'm wrong for trying to have this much fun in Perl, but hey, I like to choose the languages with the most advanced constructs available...C doesn't do that for me and then you get bogged down with data structures and memory management.

    Yes, you're wrong to try to do game development in Perl. Why? Because nobody else does it, that's why! Programming these days takes more than a lone avenger with a compiler. It takes a community of active developers and users. And since there's no active Perl game programming community, Perl isn't much of an option.

    I've seen games written in Python using SDL pop up on Freshmeat. Maybe that's something to look into if you really can't deal with C. But whatever you choose, don't go it alone!

    And just to prove I know what I'm talking about: check this. It was a miserable failure and I believe the lack of a Perl game programming community was the #1 reason.

    -sam

      Yes, you're wrong to try to do game development in Perl. Why? Because nobody else does it, that's why! Programming these days takes more than a lone avenger with a compiler. It takes a community of active developers and users. And since there's no active Perl game programming community, Perl isn't much of an option.
      I'm not sure if that is flamebait or if you are attempting to goad me into the creating the world's best game library. Either way, you're clearly wrong about Perl not being up to the task. The only reason Python is anywhere is because the PyGame folks put in the time. Perl is a much better language for glueing things together, has a ton of modules in existance, and is better suited for AI. It's a natural fit.

      Did I say I couldn't deal with C? No. Not at all. I own C. It's just a chore to do anything beyond simple constructs. You have to watch yourself closer in graph theory, for instance. You can't make use of OO. (Ok, there is C++, but we shall not mention that abomination). Perl is just more "fun", and that is what matters. It lends itself towards cleaner, shorter, code that can do more in less time. We all know this.

      Should I (or anyone else) start a full-fledged library, Perl will take off just the same. SDL is a great start. Frozen-Bubble (YES! It's in Perl! You non-believers!) shows it's possible, it's just a little ugly inside. The primitives aren't there, and it's a chore to use. Something like a SDL::Simple and an SDL::PixelTools (line drawing, etc) on top of SDL would go a long way. Something that would allow something like frozen-bubble to read more elegantly.

      I don't know why you posted a Quake3 link. I'm not speaking that magnitude. The guy working on Bloodgate certainly is, though. Maybe he'll make it.

      Anyhow, thanks for that comment. It will serve as impotus for having to prove you wrong.

        The only reason Python is anywhere is because the PyGame folks but in the time.

        I think we, uh, agree? This is exactly my point. Technology is not the question. Community is the question. The PyGames folks are putting out games because they work as a community tp produce high quality Python game libraries. There is no "PerlGames" community, therefore you shouldn't use Perl to program games.

        Of course this could change, and maybe you can help change it. But you can't do it alone, and right now my guess is you are pretty much alone in wanting to program 2D games with Perl.

        Should I (or anyone else) start a full-fledged library, Perl will take off just the same.

        I doubt it. You need more than a library, you need users to use it and help you improve it.

        Anyhow, good luck. I'll be the first to congratulate you if you succeed. Just don't be too shocked if I'm the only one! My own foray into the world of Perl game SDK development was less than encouraging...

        -sam

        I don't know why you posted a Quake3 link.

        Because that was his attempt at using Perl for a game related project.

      Hey,

      the most addictive game ever is written in perl.

      ---------------------------
      Dr. Mark Ceulemans
      Senior Consultant
      BMC, Belgium
Re: 2D realtime pixel graphics options in Perl
by bakunin (Scribe) on Feb 29, 2004 at 17:02 UTC
    Hmmmm... What about SWF? You know, the Macromedia Flash generated animations. It is possible with Perl. To create GUIs, simple games, cartoons, and of course very appealing web interfaces, I recommend Ming-C library, along with the perl wrapper Ming-Perl. I'm also working on several Perl modules that drastically improve Ming's capabilities. Hopefully it will be ready in a month. If anyone is interested in creating SWF with Perl, I'd be very happy to give more information about Ming and my modules.

    If one is proficient with actionscript, the possibilities are only bounded by your imagination. For example, there are folks dynamically applying non-linear transformations to sprites, hence obtaining really cool wave effects. You may take a look at these sites:

    1. actionscript-toolbox.com
    2. peterjoel.com
    3. robertpenner.com
(OT) Re: 2D realtime pixel graphics options in Perl
by sfink (Deacon) on Mar 05, 2004 at 04:45 UTC
    I marked this response as off-topic because it won't help answer the original question. (But a co-worker has modified OpenGL.pm enough to get it to compile with more recent opengl headers -- go to the link below for info on that.)

    But I just wanted to throw in a "me, too!" for the people wondering if anyone is writing games in perl. My company does a real-time interactive display (LCD projector + camera + code), and I have integrated Perl into our "effects engine" as a scripting language. Recently, we've been using it to write simple games to add to our usual reactive effects. The system is proprietary and not what you're looking for anyway, since the scripting really just manipulates scenegraph-ish nodes and doesn't do any drawing or direct image manipulation itself, but it is certainly an example of using Perl to implement games. The graphics code is all C++ OpenGL code (we use a bare minimum of SDL, but mostly straight OpenGL calls). Mostly 2D so far, but with bits of 3D in already.

    And please forgive the commercial note, but we're looking for a Perl programmer right now. So if you want a job, or the previously-mentioned OpenGL.pm modifications, go to that link. (Actually, given the OSS stuff I work on, come join us and help me convince people that we should be using Parrot as the underlying VM for the scripting extension. Though you'll have to convince me first; Parrot isn't quite ready just yet!)

Re: 2D realtime pixel graphics options in Perl
by Anonymous Monk on Mar 02, 2004 at 09:11 UTC

    I looked at similar options recently while prototyping a custom embedded GUI we're working on. So this isn't strictly games related, but there's some overlap in the 2D drawing and handling input aspects. This started out in C, but that quickly became frustrating :).

    I ended up using the Allegro library (a games programming library somewhat similar to SDL). There's a Perl module with bindings and an OO wrapper to the API that I found here. It doesn't appear to be on CPAN, but the tarball installed fine with "perl Makefile.PL; make; make install". It does require the Allegro library (which is a one command install in Debian).

    This filled my needs very well for just doing mostly loading images and drawing various rectangles and text about the screen. I didn't even try most of the API, so I'm not sure about how well it covers those parts. It certainly doesn't cover the full Allegro API, but that wasn't a problem for me in this case. There don't seem to be many people using this, so that may be a factor. The docs were kind of geared towards someone who's used Allegro before, but most things are simple enough that it shouldn't really matter.

    -- Rob

Re: 2D realtime pixel graphics options in Perl
by PodMaster (Abbot) on Mar 02, 2004 at 09:26 UTC
    I'm a wee bit suprised none had mentioned Prima: "PRIMA is a general purpose extensible graphical user interface toolkit with a rich set of standard widgets and an emphasis on 2D image processing tasks."

    MJD says "you can't just make shit up and expect the computer to know what you mean, retardo!"
    I run a Win32 PPM repository for perl 5.6.x and 5.8.x -- I take requests (README).
    ** The third rule of perl club is a statement of fact: pod is sexy.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://332533]
Approved by Limbic~Region
Front-paged by Plankton
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others taking refuge in the Monastery: (6)
As of 2024-03-28 13:45 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found