cl-sdl-help — Public support list for the CL-SDL project

[cl-sdl-help] CL-SDL + CMUCL on Mac OS X 10.4.10 Intel

[Kris De S. <kri...@gm...>]

Hi,

I'm new to CL-SDL, and I'm not sure whether this is the right place to 
post this, but it's the best place I can think of. So here goes:

I managed to get CL-SDL working with CMUCL on Mac OS X 10.4.10 Intel. 
This took some doing, so I thought I'd relate the how-to-do-it here so 
that others in a similar position as mine need not reinvent the wheel.

I'm using CMUCL distribution cmucl-2007-10-x86-darwin, and CL-SDL 
version 0.2.2. I installed ASDF (don't know the exact version number) 
and UFFI 1.6.0.

I used fink to install both SDL and Xorg. Fink installs SDL under 
"/sw/lib". This however is not part of the *library-paths* in 
ffi/uffi.lisp, so I added it there myself.

If you set up ASDF, UFFI and CL-SDL, and try to run the examples at this 
point you will see two problems popping up:

* Warning messages like the following:

	_NSAutoreleaseNoPool(): Object 0x349cc0 of class _NSThemeWidget 
autoreleased with no pool in place - just leaking

* An error message:

	Uncaught exception: <NSInternalInconsistencyException> Error (1002) 
creating CGSWindow

After the error the application will hang.

The reason for this problem lies with the implementation of SDL on the 
mac. SDL uses Cocoa, and Cocoa applications need to be initalised in a 
certain way. This happens in SDL when one uses the SDL_main approach. 
That is, SDL provides a main method which sets up the Cocoa context and 
which then calls your own main method. However, as we're starting things 
from within the Lisp interpreter this doesn't work; we are way past the 
main method here.

The solution is to redo the setup provided in SDL_main in the form of a 
separate function, and then call that. The implementation of that 
function can be found here:

	http://www.devolution.com/pipermail/sdl/2006-February/072880.html

This is code in an e-mail by Ulrich von Zadow on the SDL mailing list. 
Copy that code into a file. I named it cocoa-util.m. This file may then 
be compiled into a dylib as follows:

	gcc -I /sw/include/SDL/ -fPIC -fno-common -c cocoa-util.m -o cocoa-util.o
	gcc -dynamiclib -framework cocoa cocoa-util.o -o libcocoautil.dylib

Remember: /sw/include is where fink installs the header files. This may 
be a different location if you have installed SDL through some other method.

By placing the dylib in a location where UFFI may find it, we can then 
use UFFI to provide access to the cocoa initialisation function:

	(uffi:load-foreign-library #p"/path/to/libcocoautil.dylib" :module 
"cocoautil")
	(uffi:def-function "CustomSDLMain" nil :returning :void)

 From this point on the all examples in CL-SDL will work without 
modification. Simply you precede their activation with a call to 
customsdlmain. I.e.:

	(customsdlmain)(nehe:run-tutorial 2)
	
That's it.

I haven't delved into the internals of the examples yet so I can't say 
for sure that they all do what they're supposed to do, but they seem to 
be okay.

Anyway, cool project, and keep up the good work!

Cheers,

Kris

[cl-sdl-help] color struct not passed by value in cl-sdl-ttf

[Tril <tr...@tu...>]

#|

ttf:render-glyph-blended and other similar functions (at least
ttf:render-glyph-shaded is affected as well) expect a sdl:color
structure to be passed by value.  However, the struct is actually
passed by address even though the function correctly requires an
argument of type (:struct sdl:color) and won't accept a pointer to one
(try passing the color to ttf:render-glyph-blended without using
sgum:deref-pointer on it first and get a type error).  The below code
shows that the address of the struct gets interpreted as an RGB value
and embedded into every pixel of the returned bitmap.

Usage: load the below code, then evaluate:
(test *white*) 
(test *black*) 
 
The test function calls ttf:render-glyph-blended to create a bitmap of
the capital letter 'A', then outputs the array of pixels returned
followed by the address of the color struct you passed in, all in hex.
 
The low order 24 bits of the address of the color struct (instead of
the correct contents of the color struct) will become the RGB portion
of the returned colors (in reverse order).  So for instance if
(sgum:address-of *white*) is #x818F770, then all the pixels returned
from ttf:render-glyph-blended will contain #x70, #xF7, and #x18 as
color information.  The alpha component will be correct.
  
I simply don't know enough UFFI or Lisp to easily fix this myself, but
I guess the bug is in cl-sdl-0.2.2/ffi/uffi.lisp, macro
def-foreign-routine or something called from there, possibly UFFI
itself.

For the record I am using Debian unstable with packages:
sbcl 0.9.11.0-1
cl-sdl 0.2.2-3
cl-sdl-ttf 0.2.2-3
cl-uffi 1.5.13-1

-Tril

|#

(require :sdl-ttf) 
(ttf:init) 
(defparameter *font* (ttf:open-font "VeraMono.ttf" 16)) 
 
(defparameter *white* (sgum:allocate-foreign-object sdl:color 1))  
(setf (sdl:color-r *white*) 255)  
(setf (sdl:color-g *white*) 255)  
(setf (sdl:color-b *white*) 255)  
 
(defparameter *black* (sgum:allocate-foreign-object sdl:color 1)) 
(setf (sdl:color-r *black*) 0) 
(setf (sdl:color-g *black*) 0) 
(setf (sdl:color-b *black*) 0) 
 
(defun test (color) 
  (let* ((a (ttf:render-glyph-blended *font* (char-code #\A) (sgum:deref-pointer color sdl:color))) 
         (pixel-values (loop for row from 0 to (- (sdl:surface-h a) 1) 
                        collect (loop for col from 0 to (- (sdl:surface-w a) 1) 
                                  collect (format nil "~X" (sdl:get-pixel a col row)))))) 
    (format t "~A~%~X" pixel-values (sgum:address-of color)))) 
 

[cl-sdl-help] help optimizing alien structure ref in SBCL

[David M. <dc...@gm...>]

I allocate an event using uffi:with-foreign-object of type sdl:event.

Later that event is taken as a parameter to these two functions:

(uffi:def-type event-ptr '(* sdl:event))

(defun MME-X (mouse-motion-event)
  (declare (type event-ptr mouse-motion-event))
  (sdl:event-mouse-motion-x mouse-motion-event))

(defun MME-Y (mouse-motion-event)
  (declare (type event-ptr mouse-motion-event))
  (sdl:event-mouse-motion-y mouse-motion-event))

At compile time these functions get the sbcl complaint about
%sap-alien conversion.
At runtime they account for 90% of the consing of the entire program.
Can you see what I'm mis-declaring here that is causing this bad behavior?

[cl-sdl-help] another "%sap-alien warning" question

[David M. <dc...@gm...>]

Sorry to raise such a similar issue to one that keeps coming up.

In sbcl calls to 
(sdl:event-mouse-motion-x event)
generate a warning about inefficient runtime-compile-invoking
%sap-alien conversions.  I've tried to properly declare my event, ala:
  (declare (type event-ptr event))
where I've already evaluated the top level form 
  (uffi:def-type event-ptr '(* sdl:event))
But I still seem to get the warning.  Is this because a pointer to a
mouse-motion-event is an even narrower subtype of a pointer to an
event?  Is there some magic declaration I can use to make it shut up? 
I tried
    (uffi:def-type motion-event-ptr '(* sdl:mouse-motion-event))
and though it evaluated fine, I still get the pesky warning.

[cl-sdl-help] Re: sdl fullscreen and lisp

[Vladimir S. <vs...@sh...>]

>Suppose some programmer, lets call him "Ralph", was programming with
>cl-sdl, and created a sdl:+fullscreen+ window while typing to his sbcl
>through emacs.  Now suppose Ralph's program hits a bug and goes to the
>sbcl debugging prompt.  Any neat ideas on how to go see / talk-to that
>prompt while in fullscreen mode?
>
>Ralph's been hitting C-A-f1 and issuing a kill -HUP to sbcl, which
>frees his mouse and keyboard, but kills poor sbcl, and leaves
>my^H^HRalph's X session locked in a tiny, tiny 640x480 video mode.
>
>Any words of wisdom for Ralph?  :)
>
>  
>
Simplest thing is probably unwind-protect that closes the window when
the stack gets unwound (but I guess that doesn't do much good for
continuable errors). If Ralph doesn't mind only 80 columns, he could
try running the Lisp from the command line on a virtual terminal (with
the DISPLAY variable set to whatever is appropriate). Another thing
you (or I should say Ralph :) might try is some *debugger-hook* stuff
to close or hide (I don't think you can hide/minimize from SDL,
though) the window when the debugger is called. I've never used this
method, but now that I think about it it sounds like the best way to
go.

Vladimir

[cl-sdl-help] sdl fullscreen and lisp

[David M. <dc...@gm...>]

Suppose some programmer, lets call him "Ralph", was programming with
cl-sdl, and created a sdl:+fullscreen+ window while typing to his sbcl
through emacs.  Now suppose Ralph's program hits a bug and goes to the
sbcl debugging prompt.  Any neat ideas on how to go see / talk-to that
prompt while in fullscreen mode?

Ralph's been hitting C-A-f1 and issuing a kill -HUP to sbcl, which
frees his mouse and keyboard, but kills poor sbcl, and leaves
my^H^HRalph's X session locked in a tiny, tiny 640x480 video mode.

Any words of wisdom for Ralph?  :)

[cl-sdl-help] ttf:render-text-shaded bug?

[<dc...@gm...>]

Hi, 

When I call it ttf:render-text-shaded gives a runtime error
complaining it wants sdl color structures passed by *value*, and not
the more convential *pointers* to sdl color structures.  Is this the
bug it seems to be?


I'm using cl-sdl-ttf 0.2.2 in debian sarge.

-Dave Morse

[cl-sdl-help] sdl:update-rects

[David M. <dc...@gm...>]

Why is there no sdl:update-rects function?

[cl-sdl-help] sdl:update-rects

[David M. <dc...@gm...>]

Why is there no sdl:update-rects function?

Re: [cl-sdl-help] %SAP-ALIEN

[David M. <sv...@ya...>]

Lars Brinkhoff wrote:
> The efficiency of this particular example is irrelevant, I just
> included it to demonstrate one way to trigger the warning.  My
> actual worry is that cl-sdl:draw-pixel exhibit the same behaviour.

Whoa, I'd never even noticed the cl-sdl package before.  That could be 
handy!  Hey, is there any real cl-sdl specific doc?  The only thing I 
saw said, in effect "its the same as in C.  Use 'apropos'.  Good luck!"

Re: [cl-sdl-help] %SAP-ALIEN

[Lars B. <la...@no...>]

David Morse <sv...@ya...> writes:
> > This small program is sufficient to get the message:
> >   (progn
> >     (sdl:init sdl:+init-video+)
> >     (cl-sdl:clear-screen (sdl:set-video-mode 512 512 32 sdl:+hwsurface+))
> >     (sdl:quit))
> 
> Are you really worried about effeciency in this example, or just
> trying to get a clean compile?

The efficiency of this particular example is irrelevant, I just
included it to demonstrate one way to trigger the warning.  My
actual worry is that cl-sdl:draw-pixel exhibit the same behaviour.

-- 
Lars Brinkhoff,         Services for Unix, Linux, GCC, HTTP
Brinkhoff Consulting    http://www.brinkhoff.se/

Re: [cl-sdl-help] %SAP-ALIEN

[David M. <sv...@ya...>]

Lars Brinkhoff wrote:
> Using SBCL 0.8.16 on a PowerPC, I'm getting the classical error
> message below.  I understand there's a solution to this involving
> type declarations, but I don't know where to put them.  Should I
> hack the internals of CL-SDL?
> 
> This small program is sufficient to get the message:
>   (progn
>     (sdl:init sdl:+init-video+)
>     (cl-sdl:clear-screen (sdl:set-video-mode 512 512 32 sdl:+hwsurface+))
>     (sdl:quit))
> 
> ; in: LAMBDA NIL
> ;     (SB-ALIEN-INTERNALS:NATURALIZE
> ;    (SB-SYS:SAP+ SB-ALIEN::SAP (/ SB-ALIEN::OFFSET SB-VM:N-BYTE-BITS
> ;    '#<SB-ALIEN-INTERNALS:ALIEN-RECORD-TYPE (STRUCT SDL:SURFACE ...))))
> ; ==>
> ;   (SB-ALIEN-INTERNALS:%SAP-ALIEN
> ;    ALIEN '#<SB-ALIEN-INTERNALS:ALIEN-RECORD-TYPE (STRUCT SDL:SURFACE ...))
> ; note: unable to
> ;   optimize
> ; because:
> ;   could not optimize away %SAP-ALIEN: forced to do runtime
> ; allocation of alien-value structure

Are you really worried about effeciency in this example, or just trying 
to get a clean compile?  Because sdl:set-video-mode is going to take 
lots, lots more time than consing up a little ol' alien wrapper object 
on the heap.  (the latter is what the warning is complaining about).

On the sbcl-help list I'm trying to drum up popular support for getting 
this error message to be either shorter & less dire sounding, or 
possibly non-existant.  However, so far I'm yelling into the wind, so if 
you'd care to lend your voice, it'd be appreciated.  :)

Re: [cl-sdl-help] %SAP-ALIEN

[Lars B. <la...@no...>]

Matthew Danish <md...@an...> writes:
> On Mon, Nov 08, 2004 at 09:52:45PM +0100, Lars Brinkhoff wrote:
> > Using SBCL 0.8.16 on a PowerPC, I'm getting the classical error
> > message below.  I understand there's a solution to this involving
> > type declarations, but I don't know where to put them.
> > 
> > This small program is sufficient to get the message:
> >   (progn
> >     (sdl:init sdl:+init-video+)
> >     (cl-sdl:clear-screen (sdl:set-video-mode 512 512 32 sdl:+hwsurface+))
> >     (sdl:quit))
> 
> Maybe try declaring cl-sdl:clear-screen inline?

Doesn't seem to help.  I'm thinking something like what Kevin replied
below, applied to some proper location.  In this case, it seems like
adding some kind of declaration involving (struct sdl:surface) could
be helpful.

http://lists.b9.com/pipermail/uffi-users/2004-July/000382.html
http://lists.b9.com/pipermail/uffi-users/2004-July/000383.html

-- 
Lars Brinkhoff,         Services for Unix, Linux, GCC, HTTP
Brinkhoff Consulting    http://www.brinkhoff.se/

[cl-sdl-help] NULL returns

[David M. <sv...@ya...>]

When a SDL function would return NULL to C, should I look for the cl-sdl 
equivalents to return nil, or return something that I should test with 
uffi:null-pointer-p ?

[cl-sdl-help] how to allocate an SDL_Color struct?

[David M. <sv...@ya...>]

What's the most portable way to allocate one of these beggars when 
working with cl-sdl in lisp?

typedef struct{
   Uint8 r;
   Uint8 g;
   Uint8 b;
   Uint8 unused;
} SDL_Color;

Is the answer uffi:allocate-foreign-object ?

[cl-sdl-help] %SAP-ALIEN

[Lars B. <la...@no...>]

Using SBCL 0.8.16 on a PowerPC, I'm getting the classical error
message below.  I understand there's a solution to this involving
type declarations, but I don't know where to put them.  Should I
hack the internals of CL-SDL?

This small program is sufficient to get the message:
  (progn
    (sdl:init sdl:+init-video+)
    (cl-sdl:clear-screen (sdl:set-video-mode 512 512 32 sdl:+hwsurface+))
    (sdl:quit))

; in: LAMBDA NIL
;     (SB-ALIEN-INTERNALS:NATURALIZE
;    (SB-SYS:SAP+ SB-ALIEN::SAP (/ SB-ALIEN::OFFSET SB-VM:N-BYTE-BITS
;    '#<SB-ALIEN-INTERNALS:ALIEN-RECORD-TYPE (STRUCT SDL:SURFACE ...))))
; ==>
;   (SB-ALIEN-INTERNALS:%SAP-ALIEN
;    ALIEN '#<SB-ALIEN-INTERNALS:ALIEN-RECORD-TYPE (STRUCT SDL:SURFACE ...))
; note: unable to
;   optimize
; because:
;   could not optimize away %SAP-ALIEN: forced to do runtime
; allocation of alien-value structure

-- 
Lars Brinkhoff,         Services for Unix, Linux, GCC, HTTP
Brinkhoff Consulting    http://www.brinkhoff.se/

[cl-sdl-help] 0.2.2 released

[Matthew D. <md...@an...>]

0.2.2 is out, please report any bugs to the mailing lists.  The release
is mostly bugfixes and some minor enhancements.

-- 
; Matthew Danish <md...@an...>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."

Re: [cl-sdl-help] can't find glu

[David M. <sv...@ya...>]

Matthew Danish wrote:
> Do you have xlibmesa3-glu and xlibmesa-glu-dev installed?

I do now.  Thank you.  And thank you for maintaining these spiffy bindings!

Re: [cl-sdl-help] can't find glu

[Matthew D. <md...@an...>]

Do you have xlibmesa3-glu and xlibmesa-glu-dev installed?

P.S. Can you arrange for future e-mails to this list to be in ASCII
format?  Thanks.

-- 
; Matthew Danish <md...@an...>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."

[cl-sdl-help] can't find glu

[David M. <sv...@ya...>]

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
Hi,<br>
I'm on Debian, using their fancy clc system.&nbsp; When I (require :opengl),
I get compile errors.&nbsp; Digging a bit the underlying error seems to be:<br>
<blockquote><tt><br>
Error in function SDL-GL-UFFI-MACROS:FIND/LOAD-FOREIGN-LIBRARY:<br>
&nbsp;&nbsp; Cannot find one of ("libGLU" "glu32")<br>
  <br>
  </tt></blockquote>
of course there is a libGLU.so on my system in both /usr/lib and
/usr/X11R6/lib.&nbsp; So why can't it find it?<br>
<br>
<br>
[I'm not subscribed, so please reply-all]<br>
</body>
</html>

[cl-sdl-help] User Events

[Paulo J. de O. C. de M. <po...@me...>]

Hi all,

I'm having trouble using a user event. I've been able to create one
with:
(sgum:with-foreign-objects ((ue user-event))
...)

but how can I set data-1 and data-2?, what should I put in code and type
and how do I use that in the loop, an example would be great. It doesn't
need to be working code, just something simple.

My best regards,

-- 
Paulo J. Matos : po...@me...
Instituto Superior Tecnico - Lisbon
Computer and Software Eng. - A.I.
 - > http://mega.ist.utl.pt/~pocm
---
	-> God had a deadline...
		So, he wrote it all in Lisp!

Re: [cl-sdl-help] sdl:draw-pixel -- Why so slow?

[Matthew D. <md...@an...>]

On Sat, Apr 05, 2003 at 04:23:44PM -0800, Jason Dagit wrote:
> Has anyone else noticed draw-pixel being extremely slow?  I was
> working on a raytracer and using draw-pixel to update the screen but
> it takes WAY longer to do that than write to a file.  I even tried
> writing to an off screen surface then blit'ing that.  But it's still
> about 1000 or more times slower than anything else.  Even the CLX
> package is faster....

Last time I noticed that, I think it was due to a forgotten inline
declaration.  Try adding (declaim (inline draw-pixel)) to the beginning
of sdl/sdl-ext.lisp and recompiling/loading.

-- 
; Matthew Danish <md...@an...>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."

[cl-sdl-help] sdl:draw-pixel -- Why so slow?

[Jason D. <da...@en...>]

Has anyone else noticed draw-pixel being extremely slow?  I was
working on a raytracer and using draw-pixel to update the screen but
it takes WAY longer to do that than write to a file.  I even tried
writing to an off screen surface then blit'ing that.  But it's still
about 1000 or more times slower than anything else.  Even the CLX
package is faster....

Any suggestions?

Thanks,
Jason

Re: [cl-sdl-help] SDL segfault

[Matthew D. <md...@an...>]

On Sun, Mar 02, 2003 at 11:22:41AM -0500, Jonathan Simpson wrote:
> I'm trying to use cl-sdl 0.2.1 on linux with cmucl 18d, but every 
> example program I try with the exception of #'sdl-test:start segfaults. 
>   Some segfault immediately while others(such as example1.lisp) run for 
> a second or so before crashing.
> 
> The error message I get is the standard:
> 
> "Fatal signal: Segmentation Fault (SDL Parachute Deployed)"
> 
> I think the problem may be related to gc, because it crashes immediately 
> after/during garbage collection and #'sdl-test:start is the only one 
> which doesn't seem to cause gc.  I have seen it crash before gc'ing, but 
> I've never seen it complete a collection.
> 
> Has anyone seen this before?

I haven't seen it on CMUCL before.  Try adding the flag
sdl:+init-noparachute+ to the sdl:init arguments (with LOGIOR) and avoid
the usage of sdl:quit (there's a signal handling bug in SDL_Quit).

-- 
; Matthew Danish <md...@an...>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."

Re: [cl-sdl-help] SDL works but opengl not displaying

[Jason D. <da...@en...>]

You'll be happy to know that I recompiled the C code (I added a get_pixel
function) and now it displays correctly!

I'd be happy to submit my code change. It's incredibly simple though.  I
may do more work so I don't want to give it to you just yet.

Jason

On Wed, 26 Feb 2003, Matthew Danish wrote:

> On Tue, Feb 25, 2003 at 12:39:09PM -0800, Jason Dagit wrote:
> > I'm a debian (unstable) user and I apt'd your package (latest version)
> > with the sdl and opengl bindings.  My lisp is cmucl version 3.1.7 18d+.
> >
> > When I try
> >
> > (2dt:start)
> >
> > it works just fine and so does example1.  But if I run any of the nehe
> > tutorials or the sdl-test it starts up with no errors and reports the
> > correct display information and even creates the window with the
> > appropriate title bar. But the window remains black.  It's as if
> > everything but displaying via opengl works.
> >
> > Do you know of anyone that has gotten this to work in debian?  I checked
> > last night and I have the latest apt'able version of all the relevant
> > software.
>
> Hi, sorry about the delay, but I had to have SourceForge reset the list
> administrator password since it's been about a year since I last used
> it, and I did not remember it.
>
> I develop on Debian/x86 with CMUCL, so this problem mystifies me as
> well.  Note that I see very similar symptoms with LispWorks; try the
> :solar-system ``nehe'' demo--in LispWorks it displays /something/ if not
> the right thing.
>
> Right now my development Linux box is due for a case/PSU replacement,
> and I've a few RL issues to sort out, so I'll get back to you in a few
> days.
>
> --
> ; Matthew Danish <md...@an...>
> ; OpenPGP public key: C24B6010 on keyring.debian.org
> ; Signed or encrypted mail welcome.
> ; "There is no dark side of the moon really; matter of fact, it's all dark."
>
>