[Guile-sdl-devel] Merging guile-SDL-s [Was - Announcing Projector - Guile bindings for SDL]

[Vikram S. <vi...@ww...>]

Hi,

Alex Shinn wrote:

> Things that should be obvious:
>
> 1) by a vote of 2-1, the name of the project should be guile-sdl.

I support that too. Actuall I wanted Projector to be a higher level game
library, but ended out to be a wrapper for SDL.

> 2) we have a lot of interest already, and a lot of discussion to do.
>    Since there's already a sourceforge project set up, we should take
>    advantage of that and use the web/cvs and mailing lists provided
>    there.

I see all 3 of us on the list.

<Snip>

> None of the projects are using separate Guile modules, (which I think
> we should be), so there's some discussion to be done on that front.

I don't get you. What do you mean by seperate Guile modules??

> I'd be curious as to each of your experience in C, Scheme and game
> programming.  I feel most comfortable in Scheme, but am a strong C
> programmer and already have experience creating Python bindings for
> the PowerPak library (built on top of SDL).  I've been playing with
> game programming for years now, but am not up on low-level graphics
> algorithms (I'm learning though).

I am more of a C programmer.I am newbie as far as Lisp, Scheme or Guile is
concerned.

To start off, these are the issues that struck me first as I went thro'
Alex's source.

0) All gh_ stuff(from anything that's taken from mine) to be replaced by
SCM_.

1) How should the enums/constants be named - Mine is like SDL_INIT_VIDEO
while Alex's is like sdl-init/video. Could we provide both?? (As in guileGL)

Setters and getters for SMOBS - Mine is like  "sdl-color-get-r"
"sdl-color-set-r!"(BTW I don't have a SMOB for SDL_Color) .Alex's is like
"sdl-color:r" "sdl-color:set-r!".
I think we will stick with Alex's convention for this (I just checked out
the doc for host database in Guile networking)

Related stuff - I had problems using SCM_INUMP with Uint32
numbers.gh_exact_p seemed to work with it.Similarly I had to use
gh_scm2ulong since gh_scm2long simply choked and said it was beyond the
range. Alex is using only SCM_INUMP for everything while Joel seems to be
using SCM_NUMBERP for Uint32 things.I think INUMP doesn't work with Uint32-s
and should be converted with SCM_NUM2ULONG.

2)  Handling the SDL_Event structure. I return a simple alist.This was used
simply because it was easier to write that way.Alex is using a SMOB. The
only argument I have is that it might reduce programmer error. He can't
request a field that does not mean anything for that event type. Obviously
SMOB-s are faster.

3) I have some xtra bindings for Joystick, Mouse, Cdroms, SDL_gfxPromitives
and rotozoom which can be put in

4) I have used alists generously.For example for getting the current mouse
state - It returns the state of the mosue like ((state . 2) (x . 20) (y.
10)). Basically I have used it in places where things are read only and
retuned back by functions or in places where more than one value is returned
by a function thro' pointers. I don't think it's much of a performance hit
and avoids unneccessary SMOBs.

5)  As for package requirements - I feel SDL and SDL_image can be made
compulsory while SDL_mixer, SDL_ttf can be made optional. Or do we make
SDL_image as also optional??
There is a relase of SDL_ttf2 around the corner that uses Freetype2. Should
we use that instead of the current SDL_ttf??

So I think, it would be easier to merge mine into Alex's and maybe introduce
snarfing on the way and reorganise source files, Makefiles etc. I haven't
used snarfing before. Finally, what's the form of the  documentation.

Introducing docs within the code is going to take some work and patience.
As Alex said I woul like to get over with this as soon as possible and do
some programming with it.