Scripting (2)

I’ve forgotten to ask an important question:

I’d like the game logic to reside in the script and the GFX/SOUND/EFFECTS code reside in the C code. However, the two must communicate, for instance the game state change at each frame so the script and the C code must communicate at each frame. This could down the performance … here is my idea in pseudo code:

(in the script)
LOOP
? Treat all SDL events in the Queue? (call to the C code)
? Undertake some actions
? Update graphics (call to the C code)
ENDLOOP

I wonder if there is a more intelligent way to do that separation between the game logic and the pure low level logic (gfx, events).
Using SDL_Perl would be even worse because if I perform each graphical or event action in the script, it adds more calls to the C code from the script…

Thanks to all !
Julien

What kind of game is it? 2D action? Turn based?

Do you intend to make heavy use of rotation or alpha blending?

You could invest some time stress testing php and SDL in a simple
fashion to see if it meets the requirements you think you will have.

But I imagine you should be fine, after all there are lots of games
made with Python and SDL.On Thu, Nov 20, 2008 at 10:59 AM, julien CLEMENT wrote:

I’ve forgotten to ask an important question:

I’d like the game logic to reside in the script and the GFX/SOUND/EFFECTS
code reside in the C code. However, the two must communicate, for instance
the game state change at each frame so the script and the C code must
communicate at each frame. This could down the performance …

[…]

It depends on the scripting engine implementation, what kind of
hardware you’re targetting and how frequently you’ll run scripts or
make script->native calls.

In most cases, calling native code (ie C, C++ etc) from scripts is
pretty efficient (after all, that’s how most scripting languages get
actual work done), while entering/leaving the scripting engine/VM can
be pretty expensive. This differs a great deal between scripting
engines, though.

You might want to do some benchmarking to get a rough idea of where
the bottlenecks are, and how significant they actually are.

Just keep in mind that benchmarking results tend to differ a lot
between architectures and CPU generations, so unless you’re
targetting some specific hardware, benchmarking is only good for
an “order of magnitude” orientation.

//David Olofson - Programmer, Composer, Open Source Advocate

.------- http://olofson.net - Games, SDL examples -------.
| http://zeespace.net - 2.5D rendering engine |
| http://audiality.org - Music/audio engine |
| http://eel.olofson.net - Real time scripting |
’-- http://www.reologica.se - Rheology instrumentation --'On Thursday 20 November 2008, julien CLEMENT wrote:

I’ve forgotten to ask an important question:

I’d like the game logic to reside in the script and the
GFX/SOUND/EFFECTS code reside in the C code. However, the two must
communicate, for instance the game state change at each frame so the
script and the C code must communicate at each frame. This could
down the performance … here is my idea in pseudo code:

(in the script)
LOOP
? Treat all SDL events in the Queue? (call to the C code)
? Undertake some actions
? Update graphics (call to the C code)
ENDLOOP

I wonder if there is a more intelligent way to do that separation
between the game logic and the pure low level logic (gfx, events).
Using SDL_Perl would be even worse because if I perform each
graphical or event action in the script, it adds more calls to the C
code from the script…

Well,

I’ve successfully created a tiny example application in Perl, using SWIG to interface with SDL. I have 3 functions:

sdl_init
sdl_quit
poll_events

In poll_events, I don’t go in an infinite loop since I want the script to handle the main loop.
I simply do a “while( SDL_PollEvent(&evt) > 0 )” loop.
I was surprised to see that no event were lost. Can someone clarify how SDL can handle events whilst the execution continuously switches between the Perl script and the SDL code ?

(Again, I’m using SWIG)

Thanks

Julien

SDL uses a dedicated thread for collecting events from various
sources, at least on some platforms - but even without that, there
wouldn’t be a problem. Events are queued up in the order they occur,
so the application can read them whenever it gets around to it. No
sensible API will drop events just because you don’t read
them “instantly”. That just wouldn’t work in a non real time OS.

//David Olofson - Programmer, Composer, Open Source Advocate

.------- http://olofson.net - Games, SDL examples -------.
| http://zeespace.net - 2.5D rendering engine |
| http://audiality.org - Music/audio engine |
| http://eel.olofson.net - Real time scripting |
’-- http://www.reologica.se - Rheology instrumentation --'On Thursday 20 November 2008, julien CLEMENT wrote:

Well,

I’ve successfully created a tiny example application in Perl, using
SWIG to interface with SDL. I have 3 functions:

sdl_init
sdl_quit
poll_events

In poll_events, I don’t go in an infinite loop since I want the
script to handle the main loop.
I simply do a “while( SDL_PollEvent(&evt) > 0 )” loop.
I was surprised to see that no event were lost. Can someone clarify
how SDL can handle events whilst the execution continuously switches
between the Perl script and the SDL code ?

With Lua, I expose “high level” functions to the scripts (such as
init_screen(width, height, depth, fullscreen)) and use them to program what
I want. init_screen would init SDL with video and audio, init the mixer,
SDL_ttf and anything else that is needed for the game to run. You got the
idea, right?

The event queue is processed and cleared when flip is called, which happens
in each game loop iteration.

If you study hard the Lua API, it’s even possible to write callbacks in Lua
for SDL assynchronous events, such as when a music ends playing. And with
it’s garbage collector and using metamethods, you can make resources such as
images and sounds to be automatically freed when no longer needed.

Lua is known for having a small footprint, being easily embeded and
performing very fast. It has been used in a number of commercial games.
Check www.lua.org for more info.

Cheers,

Andre> ------------------------------

Date: Thu, 20 Nov 2008 17:42:27 +0100
From: David Olofson
Subject: Re: [SDL] Scripting (2)
To: sdl at lists.libsdl.org
Message-ID: <200811201742.27253.david at olofson.net>
Content-Type: text/plain; charset=“iso-8859-6”

On Thursday 20 November 2008, julien CLEMENT wrote:

Well,

I’ve successfully created a tiny example application in Perl, using
SWIG to interface with SDL. I have 3 functions:

sdl_init
sdl_quit
poll_events

In poll_events, I don’t go in an infinite loop since I want the
script to handle the main loop.
I simply do a “while( SDL_PollEvent(&evt) > 0 )” loop.
I was surprised to see that no event were lost. Can someone clarify
how SDL can handle events whilst the execution continuously switches
between the Perl script and the SDL code ?

SDL uses a dedicated thread for collecting events from various
sources, at least on some platforms - but even without that, there
wouldn’t be a problem. Events are queued up in the order they occur,
so the application can read them whenever it gets around to it. No
sensible API will drop events just because you don’t read
them “instantly”. That just wouldn’t work in a non real time OS.

//David Olofson - Programmer, Composer, Open Source Advocate

…------- http://olofson.net - Games, SDL examples -------.
| http://zeespace.net - 2.5D rendering engine |
| http://audiality.org - Music/audio engine |
| http://eel.olofson.net - Real time scripting |
’-- http://www.reologica.se - Rheology instrumentation --’


Mensagem enviada pelo Microlink Webmail 12.7.8p3

Hello !

Lua is known for having a small footprint, being easily embeded and
performing very fast. It has been used in a number of commercial games.
Check www.lua.org for more info.

I am interested in Lua, too. Is there any short
example online that uses SDL, for example
opens a window, fills a rect, updates the screen ?

CU

Torsten Giebl wrote:

Hello !

Lua is known for having a small footprint, being easily embeded and
performing very fast. It has been used in a number of commercial games.
Check www.lua.org for more info.

I am interested in Lua, too. Is there any short
example online that uses SDL, for example
opens a window, fills a rect, updates the screen ?

This has come up recently on the Lua list. There is no definitive
Lua binding for SDL, but there are two active projects that were
mentioned and look very promising:

http://scrupp.sourceforge.net/
(active, MIT license, game engine w/extra libs,
win32/linux/macosx, binaries available)

http://love2d.org/
(active, zlib license, game engine w/extra libs,
win32/linux, macosx coming, binaries available)

I believe there are many others, at least one commercial casual
game framework, or ready-to-use 3D engines like Apocalyx. The one
to use might depend on whether what the game needs. Might be worth
setting up a page at the Lua wiki.

There’s also LuaSDL at
http://luaforge.net/projects/luasdl/
but I have done little portability work and it’s strictly
tolua-style C call equivalents–
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia

Hi,

http://www.pygame.org is the python binding for SDL and related
libraries (and some other niceties).

There’s been a few thousand games made with it… so that should show
you that it’s possible to do games with a scripting language and SDL.

cu!On Thu, Nov 20, 2008 at 9:59 PM, julien CLEMENT wrote:

I’ve forgotten to ask an important question:

I’d like the game logic to reside in the script and the GFX/SOUND/EFFECTS
code reside in the C code. However, the two must communicate, for instance
the game state change at each frame so the script and the C code must
communicate at each frame. This could down the performance … here is my
idea in pseudo code:

(in the script)
LOOP
Treat all SDL events in the Queue (call to the C code)
Undertake some actions
Update graphics (call to the C code)
ENDLOOP

I wonder if there is a more intelligent way to do that separation between
the game logic and the pure low level logic (gfx, events).
Using SDL_Perl would be even worse because if I perform each graphical or
event action in the script, it adds more calls to the C code from the
script.

Thanks to all !
Julien


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org