This post originated from an RSS feed registered with Agile Buzz
by James Robertson.
Original Post: SDL in VisualWorks
Feed Title: Michael Lucas-Smith
Feed URL: http://www.michaellucassmith.com/site.atom
Feed Description: Smalltalk and my misinterpretations of life
Bob Westergaard wrote an SDL interface in VisualWorks for Smalltalk so that he could use SDL from Smalltalk. He did several of the tutorials in smalltalk too so that people would have a benchmark of how things should work to go by.
That's where we begin. Bob and I have begun the job of taking it 'further' than just that. Putting it to use in a practical application - how about a game?
So our fun begins with trying to use SDL for something more advanced than just wiggling some sprites or stars about on the screen. We want to achieve an interface to SDL that is easy for Smalltalkers to use and therefore, give them high productivity, and therefore reduce the cost of maintaining or writing code for SDL.
We also wanted to do this in such a way that wouldn't impact performance in any significant manner. The first step is to turn C structures, very prevalent in most C libraries, in to Smalltalk classes. Why? Well, then we can call methods on them and we can lose one argument off nearly every SDL call out there!
This turned out to be pretty easy to do. Instead of talking to the C Interface, we now talk through a dummy interface that 'wraps' structures up in to specialised Smalltalk classes, such as the SDL_Surface class. We can now do things such as screen flip instead of self interface SDL_Flip: screen.
Take that to the n-th degree and then through in ephemerons for finalization and auto-deallocation of C structures when Smalltalk no longer needs them and half your job is done for you.
Things get complicated though when you discover that most of the SDL interface is not in Smalltalk yet. Uh oh! Quick check with Bob, yes, he did them by hand as required. Why? Well - DLLCC's header file parser is broken.
How broken? Well, so-so broken. It'll parse most things, so long as you don't do it under Linux and so long as you don't want to pick up any #define's that are meaningful or any enum's that aren't part of a structure.
Work around for the Linux problem? You run it through the C pre-processor before handing it to DLLCC's parser. Then you have to filter out all the stdlib structures and procedures that get included by the cpp program. But we still haven't picked up every thing - oh well, that'll hav eto do for now.
Next problem you hit? Sometimes the whole thing locks up or crashes - why? Well, it turns out you need to lock surfaces, right? Sure, so we check if we must lock a surface then lock it if required, right? Sure, but what if the mustlock code was copied from C wrong? :) That was one evening down the drain.
But now we're on the other side of the light. We have a Sprite object that we can put on the screen, move about, rotate, give velocity to, accelerate/decelerate it as required. Things are looking up - we get to use the Smalltalk debugger, inspector.
Hey, we can even add new state to C structures by adding instance variables to our class! We can even add convenience methods to our classes to make things easier. How about this, I want a new surface in the screen's current format?: SDL_Surface newExtent: 300@300.
So lets not stop here, lets also include music and sound effects. We can now use SDL_mixer inside Smalltalk too. I haven't wrapped any of those structures and calls up in to objects yet, but when I have, you'll be writing code like this: 'music.ogg' play.
Where is all this code? It's in the same place it always was: In public store under SDL Core, SDL Demos and SDL Tests. The game we're making is in Space Objects.
Previous Topic
