New SDL Parrot Bindings Underway

0 views
Skip to first unread message

Chromatic

unread,
Mar 30, 2004, 2:33:26 AM3/30/04
to perl6-i...@perl.org
Hi all,

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

unread,
Mar 30, 2004, 4:05:27 AM3/30/04
to chromatic, perl6-i...@perl.org
Hi,

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

unread,
Apr 1, 2004, 12:51:26 AM4/1/04
to Jens Rieks, perl6-i...@perl.org
On Tue, 2004-03-30 at 01:05, Jens Rieks wrote:

> 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

unread,
Apr 6, 2004, 12:33:15 AM4/6/04
to perl6-i...@perl.org
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.

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

move_parrot_logo.imc

Tim Bunce

unread,
Apr 6, 2004, 5:57:47 AM4/6/04
to chromatic, perl6-i...@perl.org
On Mon, Apr 05, 2004 at 09:33:15PM -0700, chromatic wrote:
> 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

unread,
Apr 6, 2004, 7:14:23 AM4/6/04
to Tim Bunce, perl6-i...@perl.org
Tim Bunce <Tim....@pobox.com> wrote:

> 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

unread,
Apr 6, 2004, 1:42:51 PM4/6/04
to perl6-i...@perl.org
Hi!

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

unread,
Apr 6, 2004, 1:46:32 PM4/6/04
to Jens Rieks, perl6-i...@perl.org
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...
--
Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk

Jens Rieks

unread,
Apr 6, 2004, 2:04:06 PM4/6/04
to Dan Sugalski, perl6-i...@perl.org
Hi,

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

unread,
Apr 6, 2004, 1:59:38 PM4/6/04
to Dan Sugalski, Jens Rieks, perl6-i...@perl.org
On Tue, 2004-04-06 at 10: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...

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

unread,
Apr 6, 2004, 2:11:48 PM4/6/04
to Jens Rieks, perl6-i...@perl.org

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.

Reply all
Reply to author
Forward
0 new messages