New SDL Parrot Bindings Underway
Chromatic
With the improved object system in place, I've been porting the existing
SDL Parrot bindings. Here's a sample program that draws the friendly
blue rectangle again:
.pcc_sub _main non_prototyped, @MAIN
load_bytecode "library/sdl_app.imc"
load_bytecode "library/sdl_rect.imc"
load_bytecode "library/sdl_color.imc"
.sym pmc app
.sym int app_type
find_type app_type, 'SDL::App'
new app, app_type
.sym pmc args
new args, .PerlHash
set args['height'], 480
set args['width'], 640
set args['bpp'], 0
set args['flags'], 1
app.'_new'( args )
.sym pmc rect
.sym int rect_type
find_type rect_type, 'SDL::Rect'
new rect, rect_type
new args, .PerlHash
set args['height'], 100
set args['width'], 100
set args['x'], 270
set args['y'], 190
rect.'_new'( args )
.sym pmc color
.sym int color_type
find_type color_type, 'SDL::Color'
new color, color_type
new args, .PerlHash
set args['r'], 0
set args['g'], 0
set args['b'], 255
color.'_new'( args )
app.'_fill_rect'( rect, color )
app.'_update_rect'( rect )
sleep 2
app.'_quit'()
end
.end
As you can see, this is a lot simpler and quite a bit cleaner. I'll add
some documentation, port the existing examples to the new code, and
check it in.
Any preferences whether these files are 'library/sdl_rect.imc' or
'library/sdl/rect.imc', by the way?
-- c
Jens Rieks
Why are you using an underscore in front of all method and label names? They
are indicating global labels; it is not necessary to use them for method
names.
> Any preferences whether these files are 'library/sdl_rect.imc' or
> 'library/sdl/rect.imc', by the way?
I vote for library/SDL/*.imc, because this is consistent with the original
C API file naming scheme.
> -- c
jens
Chromatic
> Why are you using an underscore in front of all method and label names? They
> are indicating global labels; it is not necessary to use them for method
> names.
Habit. It's necessary for 'new', but none of the others. I'll change
it.
Allison also pointed out that .sym is going away in favor of .local --
it's two characters shorter, though.
> > Any preferences whether these files are 'library/sdl_rect.imc' or
> > 'library/sdl/rect.imc', by the way?
> I vote for library/SDL/*.imc, because this is consistent with the original
> C API file naming scheme.
It may be worth hiding the C API structure at some point, but I like
this for now.
Thanks,
-- c
Chromatic
> With the improved object system in place, I've been porting the existing
> SDL Parrot bindings.
Here's a quick status update. With helpful suggestions from Jens and
Allison, I've just finished porting the existing files in examples/sdl
to the new libraries. They're a lot nicer.
I've still some documentation to write (as well as a long list of rough
edges to smooth), but I'll fix that up shortly and check in some new
code. To whet your appetites, here's the new version of
examples/sdl/move_parrot_logo.imc.
Suggestions always welcome.
-- c
Tim Bunce
> On Mon, 2004-03-29 at 23:33, chromatic wrote:
>
> > With the improved object system in place, I've been porting the existing
> > SDL Parrot bindings.
>
> Here's a quick status update. With helpful suggestions from Jens and
> Allison, I've just finished porting the existing files in examples/sdl
> to the new libraries. They're a lot nicer.
This is probably a (dumb) parrot question rather than SDL, but I'd have
expected these:
> find_type app_type, 'SDL::App'
> .namespace [ 'MoveLogo::EventHandler' ]
to be more like
find_type app_type, 'SDL', 'App'
or: find_type app_type, [ 'SDL', 'App' ]
.namespace [ 'MoveLogo', 'EventHandler' ]
Would either/both of those work and you're just opting to have
double colons 'inside' a non-nested namespace name,
or am I misunderstanding how nested namespaces do/should/will work?
Tim.
Leopold Toetsch
> find_type app_type, 'SDL', 'App'
> or: find_type app_type, [ 'SDL', 'App' ]
No. C<find_type> finds a class enum. These types are kept in an
array - no hierarchy.
> .namespace [ 'MoveLogo', 'EventHandler' ]
That *would* be:
.namespace [ 'MoveLogo'; 'EventHandler' ]
*if* nested namespaces were implemented.
> Tim.
leo
Jens Rieks
Sorry for delay, I had less time than I expected.
On Sunday 04 April 2004 19:45, chromatic wrote:
> On Sun, 2004-04-04 at 10:04, Jens Rieks wrote:
> > > I think I prefer letting SDL::App be the main entry point for SDL
> > > applications, because *something* has to initialize SDL.
> >
> > So that anyone who wants to use SDL has to subclass from SDL::App?
>
> No, they just have to use SDL::App or write their own code to call the
> NCI subs themselves.
Sounds okay.
> > Isn't it possible to do it when loading the SDL bytecode?
>
> Yes, but it's not as easy.
Why not? Maybe create a pseudo class SDL::NCI when it does not exists,
and attach the NCI PMCs to it as properties?
Then it is possible to use
get_class nci, "SDL::NCI"
getprop nci, "SetVideoMode", nci
nci( ... )
> I now think we should put all of the struct layouts in SDL.imc, so
> people who want to write their own interface can do so against that, not
> SDL::App.
The structs can also go into a special class, or maybe everything into a
single "SDL::_intern" class.
> > I'm not sure if it is a bug, but @LOAD sections are called everytime
> > load_bytecode is called. If you load the SDL bytecode twice, all classes
> > are registered a second time, which will raise an exception. I'm not sure
> > if it is a bug or a future, though.
> > There are some other next to "@LOAD" and "@MAIN", but I can not find the
> > list at the moment.
>
> I think that may be a bug, but we could protect against it.
Yes. I am using 'find_method I0, "myclass"; if I0 > 1 goto END' in my new
files.
> > Indeed. But the main surface has to be usable with the same interface
> > like every other surface.
>
> That's true. You're right; let's just return an SDL::Surface from
> SDL::App::init() or BUILD() or whatever it is and tell people that this
> is the main surface.
Okay.
> > > We should raise an exception if it does not work, but I have no idea
> > > how to do that.
> >
> > I know how to raise an exception, what I don't know is how to check if a
> > NCI function returned NULL.
>
> I will work on this.
I'll prepare an example how to use exceptions.
> > > One other design problem I am considering right now is how to hide the
> > > difference between a double-buffered and a single-buffered surface.
> > > With a single-buffered surface you have to call UpdateRect() on the
> > > main surface explicitly. With a double-buffered surface, you only call
> > > flip().
> >
> > From a game-developer point of view, this should not be hidden. Both are
> > different techniques requiring different redraw strategies.
>
> Different method names for different techniques then? Different
> SDL::Surface subclasses for double-buffered and single-buffered?
Good idea.
What do you think about a hash interface for event handling?
newsub key, .Sub, _key_x
app["SDLK_x"] = key
> -- c
jens
Dan Sugalski
>What do you think about a hash interface for event handling?
>
> newsub key, .Sub, _key_x
> app["SDLK_x"] = key
I think... I think I need to get cracking on the event handling spec.
I'd prefer SDL to use parrot's built-in event handling system, but
for that to happen we first have to *have* a built-in event handling
system...
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Jens Rieks
sorry, this message was meant to go to chromatic only.
I modified my mail client setting to automatically add the mailinglist address
some weeks ago, I should revert to the old settings :-)
On Tuesday 06 April 2004 19:46, Dan Sugalski wrote:
> At 7:42 PM +0200 4/6/04, Jens Rieks wrote:
> >What do you think about a hash interface for event handling?
> >
> > newsub key, .Sub, _key_x
> > app["SDLK_x"] = key
>
> I think... I think I need to get cracking on the event handling spec.
> I'd prefer SDL to use parrot's built-in event handling system, but
> for that to happen we first have to *have* a built-in event handling
> system...
SDL events are meant, I proposed the hash-like access to avoid problems with
constants.
Will parrot's event handling mechanism also apply to "foreign" event sources
(also QT, GKT and others)?
jens
Chromatic
> At 7:42 PM +0200 4/6/04, Jens Rieks wrote:
> >What do you think about a hash interface for event handling?
> >
> > newsub key, .Sub, _key_x
> > app["SDLK_x"] = key
>
> I think... I think I need to get cracking on the event handling spec.
> I'd prefer SDL to use parrot's built-in event handling system, but
> for that to happen we first have to *have* a built-in event handling
> system...
That sounds good to me. I've not tried to integrate polling or
timer-based events yet.
I used the hash interface in the first version. It seems simple to
start, but it exposes a lot of complexity to the user unnecessarily.
SDL Parrot users shouldn't have to know that key up and key down events
have subtypes, for example.
Registering event handlers by subclassing a null object seems a lot
cleaner. There could be better names for the handler methods though.
-- c
Dan Sugalski
Yes. What I ultimately want is a single unified system that handles
all asynchronous things, including timers, signals, and IO. (And
events from a windowing system count as IO, at least to me)
I think I have a scheme or, rather, I have a scheme that I think will
work, but needs a little fleshing out. Got a few other things to take
care of first, then I'll get a discussion of this going and we can
see where we go from here.