Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

New SDL Parrot Bindings Underway

15 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.

0 new messages