Performance in embeded / extended python

[Michael Robin]

In my current Python game "project" (can't really call it that
yet...), I can get about 18fps if I choose 200 sprites, or about 60fps
for 40 sprites, on a PIII850. (Cut this in half if a "radar" or other
window is also active.)
This is doing real-time 2d rotation of mult-segmented objects,
position updating, and viewport mapping all in Python w/o any
extensions. I'm probably going to move to an extension when I get to
fancier objects, collision detection and some physics similation code
that's probably o(n^2 or ^3), but for now things seem pretty good.

m
-----------

emmanuel.astier at winwise.fr (Emmanuel Astier) wrote in message news:<3b443731.3777511 at news.iway.fr>...
> On Wed, 4 Jul 2001 13:08:19 -0700, "John Roth"
> <johnroth at ameritech.net> wrote:
> 
> >
> >"Emmanuel Astier" <emmanuel.astier at winwise.fr> wrote in message
> >news:3b431024.15341289 at news.iway.fr...
> >> Hi,
> >>
> >>
> >> I embedded and extended python for a game, and I was REALLY
> >> disappointed by the performances I get...
> >>
> >> Every frame of my game ( should be 60 time by second ) I call my
> >> Python logical part from my C game with :
> >
> >There's one thing that needs to be said right off - while there are
> >many successful commercial games that use a scripting language to
> >control the actual flow of the game, they don't, and I must repeat,
> >they don't call the script every frame. As you've noticed, it's just
> >too slow. It's the responsibility of the game engine (written in C
> >or C++, with Assembler assists as needed for performance) to
> >handle everything until, and only until, the engine needs a decision.
> 
> I don't agree : I worked on a successful commercial game, and I writed
> the script for this game, and it was REALLLY light, and I run it every
> frame.
> The language was far more simple and stupid that Python, but it was
> aimed for a PSone ( 33Mhz ! ).
> I was hoping that aiming a real PC, I could use a language like
> Python.
> But I agree my older script didn't had to handle 200 objects per
> seconds.
> 
> BTW, a game like Unreal has a script that's called every frame (all
> the logical part is scripted), and it runs quite well :)
> 
> >
> >With 200 sprites, I presume you're doing some kind of arcade type
> >game - lots of stuff flashing around the screen, and the gameplayer is
> >pushing his hand-eye coordination to the limit. People don't use scripting
> >languages for that, except possibly for transitions.
> 
> The 200 sprites were just a test.
> I intend to use the script for our engine, and having to specialize it
> yet.
> 
> >
> >Scripting languages are used where there is an extended storyline
> >embedded in the game, such as Adventure or RPG type games. The
> >script handles the storyline and transition, and the game engine handles
> >everything else.
> >
> >For example, in Zork: Grand Inquisitor, there's a point early in the
> >game where the adventurer comes across a glass box on the wall, with the
> >sign "in case of adventure, break glass." The mechanism to solve this puzzle
> >requires a state machine with around five states and five or six inputs,
> >each
> >state transition requires that the scene is updated. There are literally
> >hundreds
> >of such situations in the game.
> >
> >If you tried to do this in C or C++, with the inevitable rewrites as the
> >game
> >designers tried to tweak it this way and that to make the game a compelling,
> >memorable experiance, you'd run through your budget in no time flat.
> 
> I totally agree... 
> 
> >
> >>
> >> PyObject_CallFunction( LogicalEntryPoint, NULL );
> >>
> >> Logical Entry Point being a PyObject* pointing on the name of the
> >> function.
> >
> >I presume that you've made sure that the function is preloaded in
> >memory at all times - it does not have to be reloaded from disk
> >or recompiled from a string.
> 
> 
> Gulp.............
> 
> Euh... I don't know how to be sure my function is preloaded, and not
> on the disk... How can I do that ?
> 
> 
> >
> >> My function do only :
> >>
> >>     for i in range ( 0, NbTestSprites - 1 ):
> >>         ListOfSprites[i].setPos( 100, 100 )
> >>
> >> ie it sets the pos of 200 sprites.
> >> ListOfSprites is a tuple of 200 sprites, sprites is a extension class,
> >> and setPos one of its method.
> >
> >"for i in range(...)" creates 101 objects each time it's executed: it
> >has to build a tuple, and objects for all numbers from 101 to 200.
> >(numbers from -1 to 100 are preallocated in the interpreter). It's
> >faster if this is done once, and then passed to the for loop:
> >
> >foobar = range(0, NbTestSprites - 1)
> >
> >for i in foobar:
> >
> >This only works if foobar is stored somewhere where it doesn't have
> >to be recreated on each call.
> >
> 
> Designers will handle the scripts and I'm not sure they will use this
> kind of optimisation ( using map seems a good win here too ).
> 
> >>
> >> I'm using Swig to extend Python with my C functions ( I Tried Boost
> >> too, but there is even more overhead... )
> >
> >Swig is intended to make extension more convenient. Convenience is
> >usually exactly opposite to performance. Do it by hand.
> 
> Swig is not really something appearing in the profile.
> but the PyArg_ParseTuple function could appear...
> 
> Thansk for your reponse, 
> 
> Emmanuel