From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Sylvain Beucler Newsgroups: gmane.lisp.guile.user Subject: Re: Long-lived Guile scripts in a mono-threaded game engine Date: Tue, 27 May 2008 18:14:45 +0200 Message-ID: <20080527161445.GB18239@perso.beuc.net> References: <20080526211900.GB14261@perso.beuc.net> <87fxs4yy89.fsf@gnu.org> <20080527083324.GA16693@perso.beuc.net> <87hccjnars.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1211905123 10255 80.91.229.12 (27 May 2008 16:18:43 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 27 May 2008 16:18:43 +0000 (UTC) Cc: guile-user@gnu.org To: Ludovic =?iso-8859-1?Q?Court=E8s?= Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Tue May 27 18:19:14 2008 Return-path: Envelope-to: guile-user@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1K11tF-0006Pl-VK for guile-user@m.gmane.org; Tue, 27 May 2008 18:19:10 +0200 Original-Received: from localhost ([127.0.0.1]:44275 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K11sU-0001AV-Jo for guile-user@m.gmane.org; Tue, 27 May 2008 12:18:22 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1K11pA-00074l-Nz for guile-user@gnu.org; Tue, 27 May 2008 12:14:56 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1K11p9-00073Q-87 for guile-user@gnu.org; Tue, 27 May 2008 12:14:56 -0400 Original-Received: from [199.232.76.173] (port=57394 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K11p9-00073F-2U for guile-user@gnu.org; Tue, 27 May 2008 12:14:55 -0400 Original-Received: from smtp3-g19.free.fr ([212.27.42.29]:55729) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1K11p2-0000i7-LN; Tue, 27 May 2008 12:14:48 -0400 Original-Received: from smtp3-g19.free.fr (localhost.localdomain [127.0.0.1]) by smtp3-g19.free.fr (Postfix) with ESMTP id 15E1717B568; Tue, 27 May 2008 18:14:46 +0200 (CEST) Original-Received: from localhost.localdomain (unknown [82.238.35.175]) by smtp3-g19.free.fr (Postfix) with ESMTP id 8E03717B5DD; Tue, 27 May 2008 18:14:45 +0200 (CEST) Original-Received: from me by localhost.localdomain with local (Exim 4.69) (envelope-from ) id 1K11oz-0004q7-8M; Tue, 27 May 2008 18:14:45 +0200 Content-Disposition: inline In-Reply-To: <87hccjnars.fsf@gnu.org> X-Operating-System: GNU/Linux User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 3) X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.user:6580 Archived-At: Hi, On Tue, May 27, 2008 at 03:20:55PM +0200, Ludovic Court=E8s wrote: > Sylvain Beucler writes: >=20 > > Here's a sample script (very close to the C bindings, for a start): > > > > (define (hit) > > (if (> (sp_gethitpoints (current_sprite)) 10) > > (begin > > (sp_sethitpoints (current_sprite) (- (sp_hitpoints (current_spr= ite)) 10)) > > (dialog1)) > > (begin > > (say_stop "ARRRRrr.." (current_sprite)) > > (sp_kill (current_sprite) 0) > > (say_stop "Uh, I was supposed to protect him, not kill him!" 1)= )) > > (set_honour! (- (get_honour) 1))) > > > > (define (dialog1) > > (say_stop "Why are you hitting me, player?" (current_sprite)) > > (say_stop "Uh, sorry I won't do that again" 1)) > > > > > > Now every time we see a (say_stop), the script will pause for 2 > > seconds, so the player can read the text. > IOW, `say_stop' does a `(sleep 2)' (or `sleep (2)'), or waits for some > UI event, is that right? --- > what is the nature of the pause? (I think that that might be important.= ) > How do you interrupt the tight little say_stop sleep loop (if that's wh= at > it is) when you are using C bindings? Basically, a timestamp (for 'say_stop' and 'wait') or more generally a goal (coordinates for 'move_stop') is attached to the script. The game loop, before refreshing the screen, passes on each active script and see if it needs to be resumed. If at a point the engine needs 3s to load a bunch of graphics and sounds from the disk (e.g. during a screen change), the paused script won't wake up during that, but instead will be awaken by the engine when it's done with the loading. So the script does not (sleep). In this game, the engine is a mini-OS with a non-preemptive process model. This is often used in games for efficiency and ease of debugging (no concurrency). In my case this is because the code was like this before I put my hands on it :) Currently when the script engine interprets 'say_stop("Hello");', it will set the timestamp at now+2s, save the script resume point, and return to the main game loop. > > This would be pretty cumbersome. This is supposed to introduce > > people to the beautiful world of scheme, not scare them to death ;) >=20 > Well, it's not necessarily that scary, and it depends on how often you'= d > have to use it. Let's precise the audience: most often, 15-20 years-old with little programming skills. If we get them to try out Scheme despite Lots of Irritating Superfluous Parentheses, that will already be a success ;) Maybe Guile support could then be reserved for Real Programmers, but to answer your question scripting is used very often in this engine, so I doubt CPS will please them. > > call/cc has another issue: how do I return? Let's say I'm in the > > middle of (dialog1) and I need to stop the script. Maybe with a set o= f > > double continuations: one continuation at the top level to return to > > the point before I called the initial procedure (which would stops th= e > > script); and another one that is set at each (say_stop) to return to > > the following line (to resume the script). >=20 > Yes, something like that: a continuation to invoke the "scheduler" (the > engine), which would be passed the continuation within `dialog1' that > needs to be resumed eventually. Well, I don't think the engine should be called _by_ Guile. Rather the opposite: the engine calls Guile, and does it one time per active script or hook. > It may actually be simpler to run the Scheme code in a separate POSIX > thread, and have it woken up by the engine when it should start working= . Yeah, I was trying to avoid introducing threads in the engine :) But it sounds like the only usable solution as of now. Ideally Guile would offer a '(pause)' function that would return from 'scm_eval_string' or similar, with another 'scm_resume()' function that would unfreeze it :) --=20 Sylvain