Thread: [Guile-sdl-devel] Merging guile-SDL-s [Was - Announcing Projector - Guile bindings for SDL]
Status: Beta
Brought to you by:
joels
From: Vikram S. <vi...@ww...> - 2001-06-20 18:21:04
|
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. |
From: Vikram S. <vi...@ww...> - 2001-06-20 21:06:26
|
> Mentioned in my previous email... being able to choose which > subsystem[s] you want with (use-modules (sdl subsystem)). This also > has the advantage that we could theoretically handle SDL > initialization transparently according to what modules they use, so > there would be no need to call (sdl-init subsystems). The only trick > to this is handling the init flags, noparachute, threads, and opengl. > These could possibly perform a re-initialization. OOps, Got my mail filters wrong and this went into the SDL folder and I didn't see the previous mail. I also thought of init-ing as the module is loaded , but how do we handle errors in initiliazation. > This was just an idea... I feel weird using uppercase in scheme code, > but then people have to learn the translation mechanism. Does guileGL > provide both? We could certainly do that. Taken as Accepted. > You'll see both in Scheme code. I kind of like the : notation because > it's shorter and makes the function stand out as an accessor. Shorter notation is fine with me. > Vikram> 3) I have some xtra bindings for Joystick, Mouse, Cdroms, > Vikram> SDL_gfxPromitives and rotozoom which can be put in > > Nice. Especially rotozoom, I hadn't seen this before and was looking > for a good scaling/rotation lib. > It's not meant for realtime rot and zooming though, but may work for some > cases.It is aimed more at pre-rendering - Like creating rotated versions > of a sprite at the start of the game. > In these cases I was using simple lists. The above example would > return (2 20 10), which is a little faster. I suppose the question is > are we more concerned with speed or having the results make sense in > other contexts? I thought writing docs and explaining it to someone else would be a much easier job with alists. > Yes, I was already making SDL_ttf optional. I don't think anyone uses > SDL without SDL_image, we don't need to special case for that. > > If "around the corner" means available and soon to be dubbed stable, > then yes :) The source is currently at http://www.libsdl.org/cvs/SDL_ttf-2.0.3.tar.gz > Ah, and you come up with the opposite decision on the direction of the > merge :) But after starting the other way last night, you may be > right. I'm just not very good with autoconf, so I wanted to use your > layout, but if you can make SDL_mixer and SDL_ttf optional in my > source tree, that's great. Then I'll start the work??.Tomorrow (21st) I'll take your sources put them in a layout similar to mine (change filenames if needed) and then add my extra functions and stuff and maybe have one source file using snarfing. Then we better put it up in the CVS(or I'll tarball it) and continue with conversion to a snarfable version by dividing the work. I'll wait for one more mail from you, and tell me if you have started on something. |
From: Alex S. <fo...@de...> - 2001-06-20 21:33:10
|
>>>>> "Vikram" == Vikram Subramanian <vi...@ww...> writes: Vikram> OOps, Got my mail filters wrong and this went into the SDL Vikram> folder and I didn't see the previous mail. I also thought Vikram> of init-ing as the module is loaded , but how do we handle Vikram> errors in initiliazation. Good point... we could let them use wasInit() to be sure everything went OK. If they're being careful they have to check the status of the init anyway. >> In these cases I was using simple lists. The above example >> would return (2 20 10), which is a little faster. I suppose >> the question is are we more concerned with speed or having the >> results make sense in other contexts? Vikram> I thought writing docs and explaining it to someone else Vikram> would be a much easier job with alists. Since these are basically convenience functions, and a normal tight event loop would use the accessors for the event smob, we don't need to be especially efficient here so the alists sound better. Vikram> Then I'll start the work??.Tomorrow (21st) I'll take your Vikram> sources put them in a layout similar to mine (change Vikram> filenames if needed) and then add my extra functions and Vikram> stuff and maybe have one source file using snarfing. Then Vikram> we better put it up in the CVS(or I'll tarball it) and Vikram> continue with conversion to a snarfable version by Vikram> dividing the work. OK, as I said I had already started working on this. The code is at http://eyeofdog.org/foof/code/guile-sdl/guile-sdl-merged.tar.bz2. I'm using your layout and file names, but most of my code, with almost all gh_ functions renamed, and SCM_INUMP replaced with scm_exact_p. I started converting SCM_INUM and gh_scm2long with scm_num2long, but was careless reading the prototype... where I have scm_num2long (s_num) I should have used scm_num2long (s_num, (char*) SCM_ARGN, "function-name") I won't have time to help tonight, but will have time tomorrow. -- Alex Shinn <fo...@de...> Lisper, Smalltalker, and all around poor speaker |
From: Vikram S. <vi...@ww...> - 2001-06-21 20:01:34
|
> OK, as I said I had already started working on this. The code is at > http://eyeofdog.org/foof/code/guile-sdl/guile-sdl-merged.tar.bz2. I'm Got it. I couldn't get to do anything today and he only thing I did was to get the CVS vesrion of Guile up, which took some time since Guile had problems with the broken gcc that comes with Redhat. Tomorrow I'll be removing gh_ stuff from Joystick, CDROM and Mouse codes and maybe even from the sdl-mixer. I'm not touching the video part since it's mostly Alex's code. BTW the stable vesrion SDL_ttf-2 that works with Freetype2 is out and at http://www.libsdl.org/projects/SDL_ttf/ |
From: Alex S. <fo...@de...> - 2001-06-20 19:15:00
|
>>>>> "Vikram" == Vikram Subramanian <vi...@ww...> writes: >> 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. Vikram> I don't get you. What do you mean by seperate Guile Vikram> modules?? Mentioned in my previous email... being able to choose which subsystem[s] you want with (use-modules (sdl subsystem)). This also has the advantage that we could theoretically handle SDL initialization transparently according to what modules they use, so there would be no need to call (sdl-init subsystems). The only trick to this is handling the init flags, noparachute, threads, and opengl. These could possibly perform a re-initialization. Vikram> To start off, these are the issues that struck me first as Vikram> I went thro' Alex's source. Vikram> 0) All gh_ stuff(from anything that's taken from mine) to Vikram> be replaced by SCM_. Very easy, mostly query-replace. Vikram> 1) How should the enums/constants be named - Mine is like Vikram> SDL_INIT_VIDEO while Alex's is like sdl-init/video. Could Vikram> we provide both?? (As in guileGL) This was just an idea... I feel weird using uppercase in scheme code, but then people have to learn the translation mechanism. Does guileGL provide both? We could certainly do that. Vikram> Setters and getters for SMOBS - Mine is like Vikram> "sdl-color-get-r" "sdl-color-set-r!"(BTW I don't have a Vikram> SMOB for SDL_Color) .Alex's is like "sdl-color:r" Vikram> "sdl-color:set-r!". I think we will stick with Alex's Vikram> convention for this (I just checked out the doc for host Vikram> database in Guile networking) You'll see both in Scheme code. I kind of like the : notation because it's shorter and makes the function stand out as an accessor. Vikram> Related stuff - I had problems using SCM_INUMP with Uint32 Vikram> numbers.gh_exact_p seemed to work with it.Similarly I had Vikram> to use gh_scm2ulong since gh_scm2long simply choked and Vikram> said it was beyond the range. Alex is using only SCM_INUMP Vikram> for everything while Joel seems to be using SCM_NUMBERP Vikram> for Uint32 things.I think INUMP doesn't work with Uint32-s Vikram> and should be converted with SCM_NUM2ULONG. Right, SCM_INUMP is definitely wrong :) It should probably be the equivalent to the gh_ functions you're using, scm_exact_p and scm_num2long. Vikram> 2) Handling the SDL_Event structure. I return a simple Vikram> alist.This was used simply because it was easier to write Vikram> that way.Alex is using a SMOB. The only argument I have is Vikram> that it might reduce programmer error. He can't request a Vikram> field that does not mean anything for that event Vikram> type. Obviously SMOB-s are faster. If we're worried about programmer error we can do type checking in the smob functions... probably a good idea. Vikram> 3) I have some xtra bindings for Joystick, Mouse, Cdroms, Vikram> SDL_gfxPromitives and rotozoom which can be put in Nice. Especially rotozoom, I hadn't seen this before and was looking for a good scaling/rotation lib. Vikram> 4) I have used alists generously.For example for getting Vikram> the current mouse state - It returns the state of the Vikram> mosue like ((state . 2) (x . 20) (y. 10)). Basically I Vikram> have used it in places where things are read only and Vikram> retuned back by functions or in places where more than one Vikram> value is returned by a function thro' pointers. I don't Vikram> think it's much of a performance hit and avoids Vikram> unneccessary SMOBs. In these cases I was using simple lists. The above example would return (2 20 10), which is a little faster. I suppose the question is are we more concerned with speed or having the results make sense in other contexts? Vikram> 5) As for package requirements - I feel SDL and SDL_image Vikram> can be made compulsory while SDL_mixer, SDL_ttf can be Vikram> made optional. Or do we make SDL_image as also optional?? Yes, I was already making SDL_ttf optional. I don't think anyone uses SDL without SDL_image, we don't need to special case for that. Vikram> There is a relase of SDL_ttf2 around the corner that uses Vikram> Freetype2. Should we use that instead of the current Vikram> SDL_ttf?? If "around the corner" means available and soon to be dubbed stable, then yes :) Vikram> So I think, it would be easier to merge mine into Alex's Vikram> and maybe introduce snarfing on the way and reorganise Ah, and you come up with the opposite decision on the direction of the merge :) But after starting the other way last night, you may be right. I'm just not very good with autoconf, so I wanted to use your layout, but if you can make SDL_mixer and SDL_ttf optional in my source tree, that's great. Vikram> source files, Makefiles etc. I haven't used snarfing Vikram> before. Finally, what's the form of the documentation. I started some texinfo documentation. This would ideally make use of the snarfer, which I haven't played with yet. I wrote several test scripts, but we should have some more complicated examples. -- Alex Shinn <fo...@de...> Lisper, Smalltalker, and all around poor speaker |