Parrot Games

A while back there was an April Fools joke that involved the announcement of a Perl/Python combined language. Today there's a website that mentions a VM that will run multiple languages. And on top of that is a project to make SDL (a games library) bindings for the VM.

Is it all an elaborate hoax? No matter: we get to talk about Indy Games along the way so it can't be all bad. We also get to look at aspects of languages that maybe we don't think about much.

M station: I guess we should say first of all that it's not April 1 and that if people scan the web for Parrot, then the python-perl item is not the one they want!

chromatic: Good point. Maybe it's interesting to include the story of me trying to convince you it was a real project.

heh, heh -- to be honest I did think that there must be something to it, just based on your continual mention of it. But after reading what you've said below and having a close look at the parrotcode website ... I don't believe it at all!!

Well, I don't usually visit that website, so I don't remember all of the details of the name and I was too lazy to check when I sent you the link. That's the dark side of being a lazy Perl programmer.

One of the aims, I think, is to be able to easily write bindings to include other languages in your code. Intuitively, I'd expect that the VM would have to take an extra performance hit to be able to do it. Is that true?

Yes and no.

Yes, in the sense that Parrot has to support enough of the required underlying features of several languages in a mostly-generic way. That is, being able to run a statically-typed language such as C and a dynamically-typed language such as Perl on the same VM means that you can't do as much optimization for the C side of things as you could with a native compiler. You can't take shortcuts based on the variable x always holding an 8-bit unsigned integer, because Perl doesn't give you those guarantees.

Of course, you *can* make a smarter compiler and you can cheat in other ways. For example, Parrot *can* generate native code (and, in some cases, executables) on multiple platforms, which is something that Perl 5, PHP, and Ruby don't do now. Python has some capabilities to do this, but I'm not sure of the details.

On the other hand, changing some of the fundamental design assumptions of the Perl 5 engine has lead to dramatic speedups. We've had a working object system for three months or so now, and some of the sample benchmarks show that Parrot trounces Perl 5, Python, and Ruby running the same program written in Parrot-ish, Perl5ish, Pythonish, and Rubyish ways, respectively.

Whether that means Parrot is especially fast or Perl 5, Python, and Ruby are slower than you might think, I won't say -- though people do use the three other languages for productive, important work today.

You're working on something in relation to Parrot that is game-related. What is your project about?

My project, Parrot SDL, is creating the bindings from Parrot to SDL, the cross-platform multimedia library. If you're familiar with the defunct Loki Games (who ported several commercial games to Linux) or the homebrew game scene, you probably already know that SDL provides fast and easy to use APIs for graphics, fonts, sounds, and input programming. (If not, you do now.)

Writing these as Parrot libraries means that any language that can run on Parrot can use SDL. If I were to add a new feature to Parrot SDL today, the dozen or so languages that run on Parrot now could use it. (There's a bit of handwaving there; I'm not sure all of the targeted languages are far enough along to make method calls.)

I very much think that Parrot is well-suited to game programming -- maybe not pixel-slinging first person shooters -- but definitely games that one or two people and an artist could create in somewhere between a week and three months. There's a real sweet spot there.

I also think that Parrot's suitable for the bigger games too, but that's a different approach altogether.

I'll pick up on the "sweet spot". I think it's important that gaming isn't just left to big corporations because the barriers to entry are so formidable. There is a place for clever, relatively simple games that can be made by small teams -- people still play Tetris and all sorts of non-blockbuster games just for fun. Another aspect of this is that off-the-wall ideas would be very, very lucky to get past the selection committees of the major publishers. A thriving small games community would get all sorts of interesting things going.

That's very true. It takes man-years to create an AAA blockbuster title that has a 1-in-10 chance (or less) of breaking even. With good tools, modest goals, and a couple of man-months, a good programmer or two could create a fun, polished game. It won't be A-list and probably won't make a million dollars, but it's less risky, it's potentially more creative, and it's within the grasp of a decent coder.

As far as something like the idea of the Parrott SDL is concerned, a simplified API still has to be learnt like any other. It just takes less time. Given that the tool set will become limited, do you really think this is a way forward?

It depends on how and where the simplification happens. If it's simple in the sense that it only supports a subset of SDL, then programmers should hope it supports the right subset of SDL. If it's simple in the sense that Parrot's not C and it translates to hosted languages in a Perlish, Pythonish, or Rubyish way, then it may be the right approach.

For example, it would be a mistake to hide the fact that you need source and destination rects when you're blitting or updating a surface -- that's SDLish and vital to its model. Hiding the fact that they're stored as a C-struct of two signed 16-bit integers and two unsigned 16-bit integers is a plus, though. As well, does the average game need to know that you need to poll for events before performing a blocking event check for Parrot to update its timers correctly? (I certainly didn't, until Jens Rieks explained it to me this weekend)

There'll still be things to learn, including an API. My goal is to make an API that's as easy to use as it can be without being too simple to be useful. Even if I don't succeed in all cases, it's still possible to use the raw NCI calls directly from Parrot -- without writing C or even requiring a C compiler. (You'll have to have Parrot and SDL installed, of course.)

Similarly, the idea of Parrott as a VM for multiple languages makes one think of the next logical leap ... to plain English! Phuwf!

That's a big leap.

Going in the opposite direction though, how about a game-specific language with a super-hot compiler?

Absolutely. There's no technical reason you couldn't host LOGO on Parrot now with this. (Randal Schwartz suggested Squeak, but I'm not the guy for that.)

I've actually been thinking about how that could work. If you know the language will target Parrot and Parrot SDL directly, you can really cheat. Maybe something like this:

	new app:
		width  => 640
		height => 480
		bpp    =>  16

	new image:
		file   => 'smiley_face.png'
		x      => 0
		y      => 240

		start  => 0
		end    => 640
				screen => app.surface

There are things I like about that and things I don't. It's still an interesting idea, though, moving objects defined in Parrot to top-level operations in this new language.

One happy design artifact of Parrot is that the interface between Parrot code and C libraries is very, very thin. On JITted platforms, it's almost non-existant.

(JIT, or just-in-time compiling, is where the VM can translate opcodes into processor-specific assembly code. Where most Parrot ops are a few lines of C code, the JIT can reduce them even further.)

Because Perl 5 uses a stack to pass arguments back and forth, the interface layer can spend a lot of time manipulating the stack to set things up for calling C functions. If the C function is pretty small and fast, the argument handling can be pretty expensive.

Parrot's a register machine, so while you can't avoid shuffling data around now and then (at least, on real hardware that doesn't have 128 registers), you don't have to play the pop-pop-pop-push-push-push games. The translation layer just grabs this register and that register, calls the function, and sets this register and that register.

It's the difference between having one big mailbox for everyone in an apartment complex versus one mailbox for each apartment. If you keep things organized well, you can cheat a little bit -- I know my mail's always in box 324, so I don't have to dig through a pile of mail until I reach the point in the pile where I stopped looking last time.

That's not a perfect analogy, but I hope it makes sense.

Back to top


post to Delicious Digg Reddit Facebook StumbleUpon

Recent on Mstation: music: Vivian Girls, America's Cup, music: Too Young to Fall..., music: Pains of Being Pure At Heart, Berlin Lakes, music: Atarah Valentine, Travel - Copenhagen, House in the Desert

front page / music / software / games / hardware /wetware / guides / books / art / search / travel /rss / podcasts / contact us