Re: [Guile-sdl-devel] Merging guile-SDL-s [Was - Announcing Projector - Guile bindings for SDL]
Status: Beta
Brought to you by:
joels
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 |