[NEW] library/sdl.imc
Chromatic
Overall this looks good. I am not sure if it is better to define flags
as constants or to do something like this:
.sym pmc flags
new flags, .PerlHash
set flags['double_buffered'], 1
set flags['full_screen'], 1
.sym pmc screen
screen = _SDL_SetVideoMode( 320, 200, 0, flags )
Then only _SDL_SetVideoMode has to care about the flags.
It is an idea anyway. Another idea is to pass similar arguments into
_SDL_init_flags() and receive back an integer. I prefer to hide that in
_SDL_SetVideoMode() though.
-- c
Jerome Quelin
> On Fri, 2004-02-13 at 09:57, Jens Rieks wrote:
> > here is an easy to use (with PIR code) wrapper of the SDL library.
> > It tries to hide all internals of the wrapper and makes the most
> > important SDL functions directly available in PIR code.
> Overall this looks good.
Then, will it be checked in?
I really dislike having to .include sdl.imc in a sub to .include the
other outside...
Jérôme
--
jqu...@mongueurs.net
Chromatic
> I really dislike having to .include sdl.imc in a sub to .include the
> other outside...
Me too. There's supposed to be a magic initialization sub of some kind
called on library load. I'm inclined to stick it in there, but it's not
there yet.
One downside of making sdl.imc smarter (changing it from sdl.pasm) is
that we can no longer use build_tools/build_nativecall.pl as is. That
may be an argument for making the tool smarter.
Dan, Leo?
-- c
Leopold Toetsch
> Me too. There's supposed to be a magic initialization sub of some kind
> called on library load. I'm inclined to stick it in there, but it's not
> there yet.
I'll have a look at that _init call tomorrow - albeit _init (it was that
name IIRC) could be a too commonly used label. _library_init or such
could be better.
> One downside of making sdl.imc smarter (changing it from sdl.pasm) is
> that we can no longer use build_tools/build_nativecall.pl as is. That
> may be an argument for making the tool smarter.
Why?
> -- c
leo
Jens Rieks
Am Donnerstag, 19. Februar 2004 05:54 schrieb chromatic:
> On Fri, 2004-02-13 at 09:57, Jens Rieks wrote:
> > here is an easy to use (with PIR code) wrapper of the SDL library.
> > It tries to hide all internals of the wrapper and makes the most
> > important SDL functions directly available in PIR code.
>
> Overall this looks good. I am not sure if it is better to define flags
> as constants or to do something like this:
I tried to make a 1:1 mapping of the SDL C functions to PIR subs, the
arguments are by intention the same as in there C counterparts.
> .sym pmc flags
>
> new flags, .PerlHash
> set flags['double_buffered'], 1
> set flags['full_screen'], 1
>
> .sym pmc screen
> screen = _SDL_SetVideoMode( 320, 200, 0, flags )
>
> Then only _SDL_SetVideoMode has to care about the flags.
>
> It is an idea anyway. Another idea is to pass similar arguments into
> _SDL_init_flags() and receive back an integer. I prefer to hide that in
> _SDL_SetVideoMode() though.
A high(er) level API should IMHO use other names, just SetVideoMode for
example. It would be confusing is someone knows the C functions and then has
to figure out the the function names are equal, but that the parameters are
different.
> -- c
jens
Jens Rieks
Am Donnerstag, 19. Februar 2004 23:39 schrieb Leopold Toetsch:
> Chromatic <chro...@wgz.org> wrote:
> > Me too. There's supposed to be a magic initialization sub of some kind
> > called on library load. I'm inclined to stick it in there, but it's not
> > there yet.
>
> I'll have a look at that _init call tomorrow - albeit _init (it was that
> name IIRC) could be a too commonly used label. _library_init or such
> could be better.
That sounds reasonable. _library_unload might also be practical.
> > One downside of making sdl.imc smarter (changing it from sdl.pasm) is
> > that we can no longer use build_tools/build_nativecall.pl as is. That
> > may be an argument for making the tool smarter.
>
> Why?
Sorry if its a stupid question, but what has build_tools/build_nativecall.pl
todo with sdl.pasm? I have to admin that I only have touched the NCI stuff
cursorily.
Has anyone tested parrot/sdl on Windows? As far as I kown, SDL needs some
DirectX init calls on Windows, which is normally done in SDL's own main
function; SDL_main.h contains some information about that.
> > -- c
>
> leo
jens
Chromatic
> > > One downside of making sdl.imc smarter (changing it from sdl.pasm) is
> > > that we can no longer use build_tools/build_nativecall.pl as is. That
> > > may be an argument for making the tool smarter.
> >
> > Why?
> Sorry if its a stupid question, but what has build_tools/build_nativecall.pl
> todo with sdl.pasm? I have to admin that I only have touched the NCI stuff
> cursorily.
Oops, I meant util/ncidef2pasm.pl.
The easiest way to build up a set of NCI calls is to write a
declarations file and process it with util/ncidef2pasm.pl. The original
SDL declarations file was:
[package]
SDL
[lib]
libSDL.so
[defs]
# from SDL.h
i SDL_Init i
p SDL_SetVideoMode iiil
v SDL_Quit
i SDL_FillRect ppl
v SDL_UpdateRect piiii
Run that through the tool and it spits out several lines of pasm. It's
not hard to write that code by hand, but it's a little tedious. Of
course, with various patches and plans, I've been updating it by hand.
Maybe it's worth updating to spit out PIR. Maybe not. I've attached a
patch that makes it a little bit smarter about register saving though.
-- c
Leopold Toetsch
> Hi,
> Am Donnerstag, 19. Februar 2004 23:39 schrieb Leopold Toetsch:
>>
>> I'll have a look at that _init call tomorrow - albeit _init (it was that
>> name IIRC) could be a too commonly used label. _library_init or such
>> could be better.
> That sounds reasonable. _library_unload might also be practical.
Actually it isn't any fixed-named label - its the LOAD pragma attached
to an arbitrary label. So no problem with naming.
leo
Leopold Toetsch
> Oops, I meant util/ncidef2pasm.pl.
This util just spits out PASM that generate NCI stubs and stores them as
globals. Not much change necessary: just put 2 statements around
.pcc_sub _sdl_init_nci_globals LOAD
[ code ]
invoke P1
This makes a subroutine out of the code (PASM is fine). Then instead of
C<.include> that file you do C<load_bytecode> it in e.g. C<_init>.
I'll try to get the LOAD pragma running RSN.
leo