{Posting this from GMANE as it seems long emails from my mail account do not
make it through to this list}
I have checked into SVN an interim version of the new lispbuilder-sdl API's
that should work on CLISP and Lispworks at least - I have not verified
status with SBCL.
I was surprised at how little the top-level API actually changed as I
initially thought the modifications I made were a lot more dramatic.
One big change is that an SDL_Surface is now more like a sprite. Take a look
in lispbuilder-sdl/sdl/surfaces.lisp for the surface class definition.
The SURFACE class now holds the wrapper functions for the pixel readers
and writers that are created when the surface is first loaded. Accessing
these is now a case of:
(WITH-SURFACE (surf-1 (load-image "image1.bmp" ""))
(write-pixel 10 10 (color :r 0 :g 10 :b 100))
(read-pixel 10 10))
I'm not sure if building these pixel reader/writer wrappers into the SURFACE
at object creation is such a good idea as I am unsure how a surface might
be affected when moved between GFX card memory and system memory (HW vs SW
surface).
There are three different examples in sdl_random_rects.lisp and
sdl_pixels.lisp that show various ways of doing the same thing.
Please note that in WITH-EVENTS, the keywords have now changed from
:QUIT, :VIDEOEXPOSE to :QUIT-EVENT, :VIDEO-EXPOSE-EVENT etc. The
remaining keywords all follow the new format (Again for C-Tab expansion
in Emacs/Slime) (:IDLE remains :IDLE).
Also note that constants such as sdl-cffi::sdl-init-video can no longer be
passed as parameters to WITH-INIT. These must now be specified prior to
calling WITH-INIT using INITIALIZE-ON-STARTUP (explained in a previous
mail note).
I have not yet moved several useful sdl-base:: functions to sdl:: so if
you look at the examples you will see that functions from both
sdl-base:: and sdl:: are used, making things somewhat confusing. This
needs to be fixed. I have also not properly exports all necessary symbols
hence the 'sdl::'
CLISP does not support the CFFI finalization mechanism, so foreign
objects are not garbage collected as they are in Lispworks and SBCL. If
you want to use CLISP then you should use the WITH-RECTANGLE,
WITH-SURFACE, WITH-COLOR macros to garbage collect these foreign objects
automatically. (The examples do work in CLISP though -
but I haven't run these for an extended length of time to see if the
heap runs out of space). If you are using Lispworks and SBCL then these
macros provide several convenience functions. For example:
(WITH-SURFACES ((surf-1 (load-image "image1.bmp" "") nil)
(surf-2 (load-image "image2.bmp" "") nil))
(setf surf-1.x 100
surf-1.y 200
surf-2.x 400
surf-2.y 500)
(format t "surf-1 width := ~A, height := ~A~%"
surf-1.width surf-1.height))
NOTE: The 'nil' in (surf-1 (load-image "image1.bmp" "") nil) tells the
WITH-SURFACE macro not to free the surface. If this is 't' or not specified
(it is an &optional parameter), then the SURFACE is freed when
WITH-SURFACE ends.
What I am looking for is feedback on how we can make the API's do the
work while appearing as simple as Frank's PSP Lua examples. I think we
are getting there with the sdl_bmp_sample.lisp example. But there are
other API's that can be more intuitive.
I have not included the new CLOS event handling mechanism (described in a
previous post - this is done and works) as I do not really see much of a
gain over the existing WITH-EVENTS. It's no good having a single DEFMETHOD
for handling e.g. mouse movement, when at different times the mouse may
be controlling a ship, and at other times controlling the mouse cursor in
a preferences screen.
To this end I have implemented an 'actor' type mechanism whereby events can
be sent to specific 'actors'. However I think this crosses into game
engine territory. I'm not sure if this should be added as a part of
lispbuilder-sdl (It does make things a lot cleaner however. I have
re-implemented the fly 'squash' example on my local machine and the code
becomes a lot clearer and easier to understand.)
Anyway, let me know what you folks think.
- Luke
_______________________________________________
application-builder mailing list
[email protected]
http://www.lispniks.com/mailman/listinfo/application-builder
