> I took a copy of the lispbuilder-sdl-gfx tree and changes > all references to gfx with ttf (perhaps I forgot some?). Then I > removed the code, and wrote the bare minimum of cffi wrappers > to load a font and use that to get a surface with a text written > with that font on it.
Excellent, thanks. And thanks to Jeremy Smith too. > Now 255 255 255 is, of course, the rgb of the foreground color, > but for some reason it seems to get randomly different colors > each time I run it. I eventually came to the conclusion that > happens by magic ;-) Sounds weird. > utils-sdl.lisp needs the function get-sdlcolor to allocate > a SDL_Color struct. It's attached as a patch. I've thought about this and I'm a little concerned that a lot of the functions in util.lisp return references to foreign memory that then becomes the responsibility of the caller to free. I know we need to keep the lispbuilder-sdl wrapper light and fast, but I'm concerned about memory leaks if the Lisp function that allocates the foreign memory is not also the function that frees the memory. If you look at the lispbuilder-openrm code in SVN, when returning e.g. a r-g-b, or r-g-b-a color, the util functions will convert this foreign memory array into to Lisp vector. Similarly, util functions that accept color values will convert the incoming Lisp vector into a foreign color struct or array or whatever the C API expects. This means that creating a new color is as simple as #(255 255 255), or (vector 255 255 255). In cases where I want to create e.g. a vertex and pass this into a function I use a 'with-vertex' (or 'with-color') macro to handle the free automatically. Obviously this does not work for large structures, e.g. SDL_Surface or SDL_Event, and these should continue to be passed around as an opaque memory block. But I think that simple structs like SDL_Rect or SDL_Color are definitely candidates for conversion into Lisp equivalents (i.e. vectors). The reason that I am concerned about foreign memory leaks is because there are garbage collectors (OK, Corman Lisp for sure) that are only kicked off due to the Lisp side and not the C side. When run, the GC will clean up the Lisp and the C side, but the C side never initiates a GC run. So we may encounter a situation where we run out of memory due to C leaks. Those are my thoughts. Anyway this is a part of the API redesign process. -Luke _______________________________________________ application-builder mailing list application-builder@lispniks.com http://www.lispniks.com/mailman/listinfo/application-builder
