Re: [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 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. |