From kamils80 at gmail.com Mon Jul 2 12:14:09 2007 From: kamils80 at gmail.com (Kamil Shakirov) Date: Mon, 02 Jul 2007 19:14:09 +0700 Subject: [Pal-devel] plans for SDL_ttf and SDL_net Message-ID: <4688EC11.1060804@gmail.com> Hi. First, thanks a lot for such a nifty 'PAL' library. :) I have started my first game in CL and decided to use it. Are there any plans to support SDL_ttf and SDL_net? Thanks. From tomi.neste at netikka.fi Mon Jul 2 16:11:18 2007 From: tomi.neste at netikka.fi (Tomi Neste) Date: Mon, 02 Jul 2007 19:11:18 +0300 Subject: [Pal-devel] Re: plans for SDL_ttf and SDL_net Message-ID: Kamil Shakirov wrote: > Hi. > > First, thanks a lot for such a nifty 'PAL' library. :) I have started my > first game in CL and decided to use it. Are there any plans to support > SDL_ttf and SDL_net? > > Thanks Welcome to pal-devel! I have thought about SDL_ttf support before but wasn't sure if it would be really necessary. OTOH it shouldn't be too hard to implement and it would be real handy in some situations, so yes, I guess I'll cook something up soon :) Also beware that the current text rendering seems to be quite slow, I'll need to fix that too while I'm at it. As of SDL_net; I have no plans about it, at least until the main functionality of PAL is finished. Meanwhile you might want to take a look at alternative libraries, maybe http://common-lisp.net/project/usocket/ or something similar would do? If you bump into any problems or have any other ideas for improvement let me know! From tomi.neste at netikka.fi Tue Jul 3 20:01:17 2007 From: tomi.neste at netikka.fi (Tomi Neste) Date: Tue, 03 Jul 2007 23:01:17 +0300 Subject: [Pal-devel] Release 3 Message-ID: Release 3 of PAL is now available at http://common-lisp.net/project/pal - some minor & major bugfixes. Most importantly it _should_ now work on SBCL, CLisp, Allegro CL and Lispworks :) - bitmap loading should be a lot faster - few changes in the API, check changes.txt - some draft documentation is available on the website, not much yet though Tomi Neste From matthieu.villeneuve at free.fr Mon Jul 9 12:40:29 2007 From: matthieu.villeneuve at free.fr (matthieu.villeneuve at free.fr) Date: Mon, 09 Jul 2007 14:40:29 +0200 Subject: [Pal-devel] Installation problem Message-ID: <1183984829.46922cbd67c8d@imp.free.fr> Hello, I'm trying to install PAL (SBCL / Linux Ubuntu) and running into an "Attempt to call an undefined alien function" error message at startup, or when calling: (pal-ffi:init (logior pal-ffi:+init-video+ pal-ffi:+init-audio+)) I installed the SDL library, I think I correctly have header files in /usr/include/SDL/ and libs in /usr/lib (including libSDL.so). There probably is something obvious I missed, but I don't see what... do you have any idea about this? Thanks a lot, -- Matthieu Villeneuve From flatlander at yellow-hut.com Mon Jul 9 18:36:31 2007 From: flatlander at yellow-hut.com (Tomi Neste) Date: Mon, 09 Jul 2007 21:36:31 +0300 Subject: [Pal-devel] Installation problem In-Reply-To: <1183984829.46922cbd67c8d@imp.free.fr> References: <1183984829.46922cbd67c8d@imp.free.fr> Message-ID: kirjoitti Mon, 09 Jul 2007 15:40:29 +0300: > Hello, > > I'm trying to install PAL (SBCL / Linux Ubuntu) and running into an > "Attempt to call an undefined alien function" error message at startup, > or when calling: > (pal-ffi:init (logior pal-ffi:+init-video+ pal-ffi:+init-audio+)) > > I installed the SDL library, I think I correctly have header files in > /usr/include/SDL/ and libs in /usr/lib (including libSDL.so). > There probably is something obvious I missed, but I don't see what... > do you have any idea about this? > Thanks a lot, > > > -- > Matthieu Villeneuve > _______________________________________________ > Pal-devel mailing list > Pal-devel at common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/pal-devel Thanks for reporting this, there was quite a stupid mistake in the ffi.lisp that prevented PAL from loading the foreign dynamic libraries. Should be fixed in the CVS by now, alternatively you could change the library definitions in the beginning of pal/ffi.lisp to be as follows: (cffi:define-foreign-library sdl (:windows "SDL") (:unix (:or "libSDL-1.2.so.0" "libSDL-1.2.so"))) (cffi:define-foreign-library sdl-mixer (:windows "SDL_mixer") (:unix (:or "libSDL_mixer-1.2.so.0" "libSDL_mixer-1.2.so"))) (cffi:define-foreign-library sdl-image (:windows "SDL_image") (:unix (:or "libSDL_image-1.2.so.0" "libSDL_image-1.2.so"))) (cffi:define-foreign-library opengl (:windows "opengl32.dll") (:unix (:or "libGL.so"))) It is possible that you still need to change the lib*.so.n.n versions to those matching your installation. From flatlander at yellow-hut.com Wed Jul 11 21:55:28 2007 From: flatlander at yellow-hut.com (Tomi Neste) Date: Thu, 12 Jul 2007 00:55:28 +0300 Subject: [Pal-devel] Re: pal question (problem ?) In-Reply-To: <871wfevs8r.fsf@no-log.org> References: <871wfevs8r.fsf@no-log.org> Message-ID: Nicolas Lamirault kirjoitti Wed, 11 Jul 2007 19:07:32 +0300: > > hi, > i try your PAL library. It seems very useful. So i try to start use it > with a Simon like game. > first tests are concluants. > But i've got a problem to load several image in a loop : > > (defun play-sequence () > "Draw the current color, and play the associated sound." > (loop for color in *random* > do > (when *debug* > (format t "~&Play ~A~%" color)) > (set-simon color) > (draw *simon*) > (play-music (load-music *sound*) nil 255) > (sleep (/ 1 2)) > (set-simon :base) > (draw *simon*))) > > > this function read *random* list and for each color draw the available > image : > > (defmethod draw ((s simon)) > (when *debug* > (format t "~&Draw ~A : ~A" *simon* (simon-image s))) > (draw-image (simon-image s) (v 0 0))) > > > set-simon update some internal variables. > > i've a test : > > (defun climon-test () > (with-pal (:width +width+ :height +height+ :fullscreenp nil > :paths (concatenate 'string *climon-directory* > "font/")) > (initialize-simon) > (draw *simon*) > (setf *random* '(:blue :yellow :red :blue :green :blue :green > :red :red :blue :red)) > (event-loop () > (test-keys > (:key-space (play-sequence)) > (:key-q (return-from event-loop)))))) > > each object (simon-{color}) contains the same image but with the > specified color with a nice light. > > when we do the test, it seems that all the images are drawing. But in > real, i don't see images with specified colors. Sounds are ok > > any idea of my problems . > > i send you with this mail my code. Graphics and sound are stolen from > memotux (Simon in OCaml). > > thanks for any help > > Nice little game you got there! I'm surprised you got that far with the current PAL documentation being what it is... ;) It looks like your problem is in the play-sequence function, the following should work: (defun play-sequence () "Draw the current color, and play the associated sound." (loop for color in *random* do (when *debug* (format t "~&Play ~A~%" color)) (set-simon color) (draw *simon*) (pal::update-screen) ;; update the screen! (play-music (load-music *sound*) nil 255) (sleep (/ 1 2)) (set-simon :base) (draw *simon*))) By default PAL updates the screen only once for each iteration of EVENT-LOOP so you need to do it manually. Since PAL::UPDATE-SCREEN is useful in these kinds of situations I'll change it into an exported symbol in the PAL package. Hope this helps, if you still have problems/questions feel free to ask. From matthieu.villeneuve at free.fr Thu Jul 12 06:19:31 2007 From: matthieu.villeneuve at free.fr (matthieu.villeneuve at free.fr) Date: Thu, 12 Jul 2007 08:19:31 +0200 Subject: [Pal-devel] API suggestion [was Re: Installation problem] In-Reply-To: References: <1183984829.46922cbd67c8d@imp.free.fr> Message-ID: <1184221171.4695c7f34ae7e@imp.free.fr> Hello, Selon Tomi Neste : > kirjoitti Mon, 09 Jul 2007 15:40:29 +0300: > > I'm trying to install PAL (SBCL / Linux Ubuntu) and running into an > > "Attempt to call an undefined alien function" error message at startup, > > or when calling: > > (pal-ffi:init (logior pal-ffi:+init-video+ pal-ffi:+init-audio+)) > > > > [...] > > Thanks for reporting this, there was quite a stupid mistake in the > ffi.lisp that prevented PAL from loading the foreign dynamic libraries. > Should be fixed in the CVS by now, alternatively you could change the > library definitions in the beginning of pal/ffi.lisp to be as follows: > > [...] Thanks, it works perfectly. I'm now in the process of writing a little "Mario Kart"-like game, and I'd like to suggest what I think could be a little API improvement regarding the DRAW-IMAGE function. As of now, the function takes 2 mandatory arguments and 2 optional ones: (draw-image image position &optional angle scale) As I understand it, specifying a non-null angle causes the image to be centered around POSITION instead of being aligned on its top-left corner, and it would seem more consistent to me if alignment was specified by other parameters. Moreover, I tend to prefer keyword parameters, as they allow more flexible and readable calls. What would you think of the following interface? (draw-image image position &key (angle 0.0) (scale 1.0) (halign :left) (valign :top)) I'm afraid I know close to nothing about OpenGL so I can't offer a patch, but if you see another way for me to contribute to PAL, please juste let me know. Thanks a lot, -- Matthieu Villeneuve From flatlander at yellow-hut.com Thu Jul 12 13:34:19 2007 From: flatlander at yellow-hut.com (Tomi Neste) Date: Thu, 12 Jul 2007 16:34:19 +0300 Subject: [Pal-devel] API suggestion [was Re: Installation problem] In-Reply-To: <1184221171.4695c7f34ae7e@imp.free.fr> References: <1183984829.46922cbd67c8d@imp.free.fr> <1184221171.4695c7f34ae7e@imp.free.fr> Message-ID: kirjoitti Thu, 12 Jul 2007 09:19:31 +0300: > As I understand it, specifying a non-null angle causes the image > to be centered around POSITION instead of being aligned on its top-left > corner, and it would seem more consistent to me if alignment was > specified by other parameters. Moreover, I tend to prefer keyword > parameters, as they allow more flexible and readable calls. > What would you think of the following interface? > > (draw-image image position > &key (angle 0.0) (scale 1.0) > (halign :left) (valign :top)) > That is a good idea and I think I'll implement it right away :) Going through the api of draw-* functions has been on the top of my todo list for a while, I hate some of the inconsistencies in there and you are right about the &optional parameters also. They kinda creeped in when I kept adding functionality. > I'm afraid I know close to nothing about OpenGL so I can't offer a patch, > but if you see another way for me to contribute to PAL, please juste let > me know. > I consider most of the OpenGL part to be finished by now, it is mostly debugging, fixing the api and writing tutorials that is needed, so help and opinions in those areas is always welcome. Of course writing tutorials at this point can be a bit hard... From flatlander at yellow-hut.com Thu Jul 12 13:45:49 2007 From: flatlander at yellow-hut.com (Tomi Neste) Date: Thu, 12 Jul 2007 16:45:49 +0300 Subject: [Pal-devel] Re: pal question (problem ?) In-Reply-To: <87ejje6ofk.fsf@no-log.org> References: <871wfevs8r.fsf@no-log.org> <87ejje6ofk.fsf@no-log.org> Message-ID: Nicolas Lamirault kirjoitti Thu, 12 Jul 2007 11:01:19 +0300: > > oh thanks ! i will try this > > Pal is a very good soft. > there is nice example. > one remarks concerning them. If we start theme using SLIME (i means > start lisp REPL not in the current directory), there is some problem > of font (default font isn't founded). > For my game, i try what to generate dynamic path using > asdf:component-relative-pathname. It works welL > i continue on my game ... It should work but of course I might have slipped somewhere, I'll see if I can fix this. > > i've got another question. In the last Ubuntu, i can't start the game, > pal exemple or anyelse twice. > i explain : > > i start the game > i play > q, for stop > i start the game > i've got : > > memory fault > [Condition of type SB-KERNEL::MEMORY-FAULT-ERROR] > > Restarts: > 0: [ABORT] Return to SLIME's top level. > 1: [ABORT] Exit debugger, returning to top level. > > Backtrace: > 0: (SB-KERNEL::MEMORY-FAULT-ERROR) > 1: ("foreign function: #x8063F11") > 2: ("foreign function: #x8064164") > 3: ("foreign function: #xB65713BC") > 4: ("foreign function: #xB70DFA71") > 5: ("foreign function: #xB70E1541") > 6: ("foreign function: #xB73F99BF") > 7: ("foreign function: #xB73FF1E6") > 8: ("foreign function: #xB73ED863") > 9: (PAL-FFI:SET-VIDEO-MODE > # > # > # > #) > 10: ((SB-PCL::FAST-METHOD PAL:OPEN-PAL NIL) > # > # > :WIDTH > # > :HEIGHT > # > :FPS > # > :TITLE ..) > 11: (CLIMON::CLIMON-TEST) > 12: (SB-INT:SIMPLE-EVAL-IN-LEXENV (CLIMON::CLIMON-TEST) > #) > --more-- > > > on some other computer (ubuntu, debian) i haven't got this problem. > > any idea ? > Hmm, that looks suspiciosly same as the problem that exists with latest SDL_mixer on Windows. I'll have to look at this closer... Could you check and see if the machines have same versions of the SDL packages installed? From lam at tuxfamily.org Thu Jul 12 08:01:19 2007 From: lam at tuxfamily.org (Nicolas Lamirault) Date: Thu, 12 Jul 2007 10:01:19 +0200 Subject: [Pal-devel] Re: pal question (problem ?) In-Reply-To: (Tomi Neste's message of "Thu\, 12 Jul 2007 00\:55\:28 +0300") References: <871wfevs8r.fsf@no-log.org> Message-ID: <87ejje6ofk.fsf@no-log.org> oh thanks ! i will try this Pal is a very good soft. there is nice example. one remarks concerning them. If we start theme using SLIME (i means start lisp REPL not in the current directory), there is some problem of font (default font isn't founded). For my game, i try what to generate dynamic path using asdf:component-relative-pathname. It works welL i continue on my game ... i've got another question. In the last Ubuntu, i can't start the game, pal exemple or anyelse twice. i explain : i start the game i play q, for stop i start the game i've got : memory fault [Condition of type SB-KERNEL::MEMORY-FAULT-ERROR] Restarts: 0: [ABORT] Return to SLIME's top level. 1: [ABORT] Exit debugger, returning to top level. Backtrace: 0: (SB-KERNEL::MEMORY-FAULT-ERROR) 1: ("foreign function: #x8063F11") 2: ("foreign function: #x8064164") 3: ("foreign function: #xB65713BC") 4: ("foreign function: #xB70DFA71") 5: ("foreign function: #xB70E1541") 6: ("foreign function: #xB73F99BF") 7: ("foreign function: #xB73FF1E6") 8: ("foreign function: #xB73ED863") 9: (PAL-FFI:SET-VIDEO-MODE # # # #) 10: ((SB-PCL::FAST-METHOD PAL:OPEN-PAL NIL) # # :WIDTH # :HEIGHT # :FPS # :TITLE ..) 11: (CLIMON::CLIMON-TEST) 12: (SB-INT:SIMPLE-EVAL-IN-LEXENV (CLIMON::CLIMON-TEST) #) --more-- on some other computer (ubuntu, debian) i haven't got this problem. any idea ? thanks for your help "Tomi Neste" writes: > Nicolas Lamirault kirjoitti Wed, 11 Jul 2007 19:07:32 > +0300: > >> >> hi, >> i try your PAL library. It seems very useful. So i try to start use it >> with a Simon like game. >> first tests are concluants. >> But i've got a problem to load several image in a loop : >> >> (defun play-sequence () >> "Draw the current color, and play the associated sound." >> (loop for color in *random* >> do >> (when *debug* >> (format t "~&Play ~A~%" color)) >> (set-simon color) >> (draw *simon*) >> (play-music (load-music *sound*) nil 255) >> (sleep (/ 1 2)) >> (set-simon :base) >> (draw *simon*))) >> >> >> this function read *random* list and for each color draw the available >> image : >> >> (defmethod draw ((s simon)) >> (when *debug* >> (format t "~&Draw ~A : ~A" *simon* (simon-image s))) >> (draw-image (simon-image s) (v 0 0))) >> >> >> set-simon update some internal variables. >> >> i've a test : >> >> (defun climon-test () >> (with-pal (:width +width+ :height +height+ :fullscreenp nil >> :paths (concatenate 'string *climon-directory* >> "font/")) >> (initialize-simon) >> (draw *simon*) >> (setf *random* '(:blue :yellow :red :blue :green :blue :green >> :red :red :blue :red)) >> (event-loop () >> (test-keys >> (:key-space (play-sequence)) >> (:key-q (return-from event-loop)))))) >> >> each object (simon-{color}) contains the same image but with the >> specified color with a nice light. >> >> when we do the test, it seems that all the images are drawing. But in >> real, i don't see images with specified colors. Sounds are ok >> >> any idea of my problems . >> >> i send you with this mail my code. Graphics and sound are stolen from >> memotux (Simon in OCaml). >> >> thanks for any help >> >> > > Nice little game you got there! I'm surprised you got that far with > the current PAL documentation being what it is... ;) > It looks like your problem is in the play-sequence function, the > following should work: > > (defun play-sequence () > "Draw the current color, and play the associated sound." > (loop for color in *random* > do > (when *debug* > (format t "~&Play ~A~%" color)) > (set-simon color) > (draw *simon*) > (pal::update-screen) ;; update the screen! > (play-music (load-music *sound*) nil 255) > (sleep (/ 1 2)) > (set-simon :base) > (draw *simon*))) > > By default PAL updates the screen only once for each iteration of > EVENT-LOOP so you need to do it manually. Since PAL::UPDATE-SCREEN is > useful in these kinds of situations I'll change it into an exported > symbol in the PAL package. > > Hope this helps, if you still have problems/questions feel free to ask. > > -- Nicolas Lamirault From tomi.neste at netikka.fi Thu Jul 12 19:13:36 2007 From: tomi.neste at netikka.fi (tomi.neste at netikka.fi) Date: Thu, 12 Jul 2007 22:13:36 +0300 Subject: [Pal-devel] Summary: Problems with running applications under Linux Message-ID: <1184267616.46967d604920b@imp.netikka.net> It seems that some people (yours truly included, running Ubuntu 7.04 with ATI X550 and the OSS drivers) are having problems under Linux when trying to run PAL applications several times in the same Lisp session. I did some testing and it _looks_ like the problem is in some graphics cards drivers. Of course it is possible that there is a bug in PAL, but so far I haven't find it. Running the following function twice after PAL is loaded should trigger the bug, if present on your system: ----------- (defun test-open-close () (pal-ffi::init (logior pal-ffi::+init-video+)) (pal-ffi::gl-set-attribute pal-ffi::+gl-depth-size+ 0) (pal-ffi::gl-set-attribute pal-ffi::+gl-doublebuffer+ 1) (when (cffi:null-pointer-p (pal-ffi::set-video-mode 800 600 0 (logior pal-ffi::+gl-doublebuffer+ pal-ffi::+opengl+))) (error "PAL failed to obtain SDL surface")) (pal-ffi::quit)) ----------- This happens on my computer with both SBCL and CLisp, but not with an equivalent C program or any of the Windows CLs that I have tried. So far I have no idea what is causing this but if anyone has any clues or more info I'd appreciate sharing it. Since this kind of bug causes problems when developing in an incremental, "live" environment like CL here are some suboptimal workarounds: - The bug doesn't seem to appear with all drivers/gfx cards. Especially running X11 without HW acceleration should be safe. - Never call CLOSE-PAL. I haven't tested it much, but it should be possible to just call OPEN-PAL when starting your lisp session and never use CLOSE-PAL or WITH-PAL (which eventually calls CLOSE-PAL). Of course this means that some parameters like window size can't be changed after initialisation. - Never return from WITH-PAL. Run your main loop in a separate thread and install condition handlers that just restart your main loop without closing down PAL. That way you can incrementally change your functions/classes etc. while your app is running. I might actually add this as an option to WITH-PAL. All in all this bug mostly has effect only while developing, applications that don't need to open/close PAL several times should work fine. -- tomppa From flatlander at yellow-hut.com Fri Jul 13 22:02:36 2007 From: flatlander at yellow-hut.com (Tomi Neste) Date: Sat, 14 Jul 2007 01:02:36 +0300 Subject: [Pal-devel] Recent changes and future plans Message-ID: I just committed some changes to CVS head that might(will) break your existing stuff, so here is little summary: - I implemented Matthieu Villeneuve's suggestions about :halign etc. on draw-image. - Cleaned up some inconsistencies in several functions, things should work a bit more sensibly now - Renamed draw-image-part to draw-image*. For consistencys sake I'll probably add them same :angle etc. options to it as is in draw-image. - Removed draw-quad. Hope no one was using that... I'll replace it with something more general. - Added/fixed/clarified the examples. - Sprinkled some random bugs around the code for everyones pleasure, please report if you find them :) In addition to polishing the base Pixel Art Library I'm planning a few projects that build on top it, namely: - Simple GUI for things like game editors. If I manage to make it skinnable and general enough it could be also used in games. - TTF support - Native CL bitmapfont builder, or if anyone knows a reasonable crossplatform app that already does a good job at this let me know. - Maybe some kind of general purpose sprite library. As usual, if anyone has any feature(s) they would like to see implemented let me know. From flatlander at yellow-hut.com Sun Jul 15 11:24:04 2007 From: flatlander at yellow-hut.com (Tomi Neste) Date: Sun, 15 Jul 2007 14:24:04 +0300 Subject: [Pal-devel] Recent changes and future plans In-Reply-To: <46985C22.1010401@gmail.com> References: <46985C22.1010401@gmail.com> Message-ID: Kamil Shakirov kirjoitti Sat, 14 Jul 2007 08:16:18 +0300: > Hi Tomi, > > When I am trying to checkout (using cvs client from MinGW) the latest > snapshot from CVS I get the following error: > > D:\Development\updates>cvs -d > :pserver:anonymous:anonymous at common-lisp.net:/project/pal/cvsroot login > (Logging in to anonymous:anonymous at common-lisp.net) > CVS password: > /project/pal/cvsroot: no such repository > cvs login: authorization failed: server common-lisp.net rejected access > to /project/pal/cvsroot for user anonymous:anonymous > > But when I checkout slime from the same cvs server it works. > > Thanks. > > Tomi Neste wrote: >> I just committed some changes to CVS head that might(will) break your >> existing stuff, so here is little summary: >> >> - I implemented Matthieu Villeneuve's suggestions about :halign etc. on >> draw-image. >> - Cleaned up some inconsistencies in several functions, things should >> work a bit more sensibly now >> - Renamed draw-image-part to draw-image*. For consistencys sake I'll >> probably add them same :angle etc. options to it as is in draw-image. >> - Removed draw-quad. Hope no one was using that... I'll replace it with >> something more general. >> - Added/fixed/clarified the examples. >> - Sprinkled some random bugs around the code for everyones pleasure, >> please report if you find them :) >> >> In addition to polishing the base Pixel Art Library I'm planning a few >> projects that build on top it, namely: >> >> - Simple GUI for things like game editors. If I manage to make it >> skinnable and general enough it could be also used in games. >> - TTF support >> - Native CL bitmapfont builder, or if anyone knows a reasonable >> crossplatform app that already does a good job at this let me know. >> - Maybe some kind of general purpose sprite library. >> >> As usual, if anyone has any feature(s) they would like to see >> implemented let me know. >> _______________________________________________ >> Pal-devel mailing list >> Pal-devel at common-lisp.net >> http://common-lisp.net/cgi-bin/mailman/listinfo/pal-devel >> > Should be fixed now. -- tomppa From flatlander at yellow-hut.com Fri Jul 20 13:12:56 2007 From: flatlander at yellow-hut.com (Tomi Neste) Date: Fri, 20 Jul 2007 16:12:56 +0300 Subject: [Pal-devel] Re: pal question (problem ?) In-Reply-To: <87abtrnu27.fsf@no-log.org> References: <871wfevs8r.fsf@no-log.org> <87abtrnu27.fsf@no-log.org> Message-ID: Nicolas Lamirault kirjoitti Fri, 20 Jul 2007 15:22:40 +0300: > > thanks for your help. > i make another game : http://www.cliki.net/Cletris > using PAL > > thans for your very nice software. > > > "Tomi Neste" writes: > >> Nicolas Lamirault kirjoitti Wed, 11 Jul 2007 19:07:32 >> +0300: >> >>> >>> hi, >>> i try your PAL library. It seems very useful. So i try to start use it >>> with a Simon like game. >>> first tests are concluants. >>> But i've got a problem to load several image in a loop : >>> >>> (defun play-sequence () >>> "Draw the current color, and play the associated sound." >>> (loop for color in *random* >>> do >>> (when *debug* >>> (format t "~&Play ~A~%" color)) >>> (set-simon color) >>> (draw *simon*) >>> (play-music (load-music *sound*) nil 255) >>> (sleep (/ 1 2)) >>> (set-simon :base) >>> (draw *simon*))) >>> >>> >>> this function read *random* list and for each color draw the available >>> image : >>> >>> (defmethod draw ((s simon)) >>> (when *debug* >>> (format t "~&Draw ~A : ~A" *simon* (simon-image s))) >>> (draw-image (simon-image s) (v 0 0))) >>> >>> >>> set-simon update some internal variables. >>> >>> i've a test : >>> >>> (defun climon-test () >>> (with-pal (:width +width+ :height +height+ :fullscreenp nil >>> :paths (concatenate 'string *climon-directory* >>> "font/")) >>> (initialize-simon) >>> (draw *simon*) >>> (setf *random* '(:blue :yellow :red :blue :green :blue :green >>> :red :red :blue :red)) >>> (event-loop () >>> (test-keys >>> (:key-space (play-sequence)) >>> (:key-q (return-from event-loop)))))) >>> >>> each object (simon-{color}) contains the same image but with the >>> specified color with a nice light. >>> >>> when we do the test, it seems that all the images are drawing. But in >>> real, i don't see images with specified colors. Sounds are ok >>> >>> any idea of my problems . >>> >>> i send you with this mail my code. Graphics and sound are stolen from >>> memotux (Simon in OCaml). >>> >>> thanks for any help >>> >>> >> >> Nice little game you got there! I'm surprised you got that far with >> the current PAL documentation being what it is... ;) >> It looks like your problem is in the play-sequence function, the >> following should work: >> >> (defun play-sequence () >> "Draw the current color, and play the associated sound." >> (loop for color in *random* >> do >> (when *debug* >> (format t "~&Play ~A~%" color)) >> (set-simon color) >> (draw *simon*) >> (pal::update-screen) ;; update the screen! >> (play-music (load-music *sound*) nil 255) >> (sleep (/ 1 2)) >> (set-simon :base) >> (draw *simon*))) >> >> By default PAL updates the screen only once for each iteration of >> EVENT-LOOP so you need to do it manually. Since PAL::UPDATE-SCREEN is >> useful in these kinds of situations I'll change it into an exported >> symbol in the PAL package. >> >> Hope this helps, if you still have problems/questions feel free to ask. >> >> > Great, nice that you like it :) -- tomppa From flatlander at yellow-hut.com Sat Jul 21 17:23:11 2007 From: flatlander at yellow-hut.com (Tomi Neste) Date: Sat, 21 Jul 2007 20:23:11 +0300 Subject: [Pal-devel] Next release Message-ID: First, I just applied a pile of changes that changed all(?) relevant PAL functions to automatically coerce their numerical arguments, so there is no need to guess anymore whether a function wants floats, integers or what. Internally all PAL:VECtors still use single-floats. This makes the interface more lispy but is also likely to cause some bugs, so please report if you found any. Since there have been some major changes since the last release and I'm fairly happy with the current api the next release is going to be tagged as version 1.0 and I'll try to keep full backwards compatibility after that. (I have considered the previous releases "stable" for my purposes, but maybe they were more like "stable beta" releases ;) ) What that means is that if any of you have any ideas for major changes I'd like to hear those now, since after 1.0 all changes will be purely incremental in nature. -- tomppa From matthieu.villeneuve at free.fr Mon Jul 23 06:33:18 2007 From: matthieu.villeneuve at free.fr (matthieu.villeneuve at free.fr) Date: Mon, 23 Jul 2007 08:33:18 +0200 Subject: [Pal-devel] Next release In-Reply-To: References: Message-ID: <1185172398.46a44bae4c285@imp.free.fr> Hello Tomi, Quoting Tomi Neste : > What that means is that if any of you have any ideas for major changes I'd > like to hear those now, since after 1.0 all changes will be purely > incremental in nature. I would like to suggest a few name changes: - reset-tags-holding-this-resource -> reset-tags-holding-resource (maybe merge this one with reset-tags: (reset-tags &key resource) ). - coerce-form-for -> (make-coerce-form value destination-type) - defunct -> define-coercing-function (?) - with-blend -> with-blend-mode - relt -> random-elt - :middle -> :center (argument to draw-image) Those correspond to my personal taste, but they don't come with any guarantee of quality... Thanks again for your work on Pal! Cheers, -- Matthieu Villeneuve From flatlander at yellow-hut.com Mon Jul 23 07:34:53 2007 From: flatlander at yellow-hut.com (Tomi Neste) Date: Mon, 23 Jul 2007 10:34:53 +0300 Subject: [Pal-devel] Next release In-Reply-To: <1185172398.46a44bae4c285@imp.free.fr> References: <1185172398.46a44bae4c285@imp.free.fr> Message-ID: kirjoitti Mon, 23 Jul 2007 09:33:18 +0300: > Hello Tomi, > > Quoting Tomi Neste : >> What that means is that if any of you have any ideas for major changes >> I'd >> like to hear those now, since after 1.0 all changes will be purely >> incremental in nature. Since most of your renaming suggestions are about internal PAL functions there is no problem changing them (i.e if you use them be prepared for random changes in their interface and behaviour ;) ). Related to that, is there any unexported functionality that people frequently use? So far I have kept everything not immediately useful unexported but if there is something you would like to see officially exported let me know. > > I would like to suggest a few name changes: > - reset-tags-holding-this-resource -> reset-tags-holding-resource > (maybe merge this one with reset-tags: (reset-tags &key resource) ). > - coerce-form-for -> (make-coerce-form value destination-type) Reasonable suggestions, consider it done. (btw. reset-tags-holding-this-resorce was originally reset-tags-holding-this-resource-that-i-m-giving-you-as-an-argument. Maybe you can guess that I'm not yet quite satisfied wit the way resources are handled...) > - defunct -> define-coercing-function (?) I'd like to keep this reasonably short since it is used quite often in pal.lisp and is not intended for external use anyway. The current name stands for defun-and-coerce-types. Notes: a) There are currently lots of unnecessary declarations in the pal sources, try not to let them distract you. Mostly they are there just because when I was bored I used to play "get this function compile without efficiency warnings" games with SBCL ;) And of course they help SBCL to catch type errors, so I think there is no harm done. b) I have been thinking about adding automatic coercion of symbols (TAGs) to resource types. So in addition to (play-sample (tag 'sfx)) you could use (play-sample 'sfx). This could be achieved by simply adding a rule to make-coerce-form. c) I think I'll need to start adding some comments in the source... > - with-blend -> with-blend-mode This is a bit problematic since with-blend accepts also the blend color, not just mode. So I think with-blend-mode would be misleading. > - relt -> random-elt Hmm, ok. > - :middle -> :center (argument to draw-image) I'm fine with both, so in the sake of compatibility I'm going to keep the current name :) > > Those correspond to my personal taste, but they don't come with any > guarantee of quality... > > Thanks again for your work on Pal! > Cheers, > > > -- > Matthieu Villeneuve > _______________________________________________ > Pal-devel mailing list > Pal-devel at common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/pal-devel -- tomppa From flatlander at yellow-hut.com Sat Jul 28 13:42:37 2007 From: flatlander at yellow-hut.com (Tomi Neste) Date: Sat, 28 Jul 2007 16:42:37 +0300 Subject: [Pal-devel] Version 1.0 Message-ID: Pixel Art Library v1.0 is now released. If you were using the CVS head there shouldn't be much suprises, for those still using Release 3 see the changes.txt. Enjoy, and let me know when you find the bugs. This time I was more careful in hiding them... -- tomppa From flatlander at yellow-hut.com Mon Jul 30 11:32:14 2007 From: flatlander at yellow-hut.com (Tomi Neste) Date: Mon, 30 Jul 2007 14:32:14 +0300 Subject: [Pal-devel] Performance notes Message-ID: Few notes about how to get the maximum graphics performance from (current cvs) PAL: First, if you don't notice any problems there is no need to worry about performance. Using OpenGL for 2d graphics is likely to be very fast, even when naively implemented and running on low-end hardware. Functions like draw-circle, -line and -polygon are quite slow. Normally it shouldn't be problem but if you want to do complex vector graphics it could. This is mostly a design issuea since PAL is more oriented towards bitmap graphics, if you need faster polygon primitives let me know the details and I'll see what I can do. DRAW-IMAGE and DRAW-IMAGE* should be _much_ faster in the cvs head version than in the recent 1.0 release, given that a few conditions are met: Internally draw-image/draw-image* works by "chaining" the draw operations and as long as the chain is not cut performance is very good. If the chain is repeatedly cut you will get lousy performance. The chain is cut when: - You call any graphics function except draw-image or draw-image*. - You use any graphics state altering functions or macros (rotate, scale, set-blend-mode, with-transformation etc.) except set-blend-color. - You draw a different image than with the previous draw-image calls. Internally PAL keeps count of the "current" image and whenever it changes the chain gets cut. - You use the :angle or :scale keywords in draw-image. That maybe fixed in the future. (Also the alignment keywords cut the chain, due to my laziness. I'll fix that soon.) It's okay to have rotations and image changes but to get maximum performance you need to make sure they don't regularly cut the chain. So if you are only allowed to draw the same image again and again how you get anything interesting on the screen? By tiling your graphics in one big image and using the draw-image* you can avoid the need to change image and in some cases you can use set-blend-color to change the color of image. At some point I'm going to add a mechanism for cutting images to tiles which then can be used interchangebly with regular images, that should make avoiding image changes much easier. About the examples/ - teddy.lisp is an especially bad example of chaining. Since the teddies all have the same image drawing them would be very fast if not a) when drawing the shadows with-transformation gets repeatedly called. It would be better to translate the shadow position manually b) the teddies need to be rotated. - hares.lisp works suprisingly well altough it uses rotations and scaling. It should be very fast if these wouldn't cut the chain :( Again, if you don't have any perfomance problems just ignore what I just wrote :) -- tomppa