Python suitable for a game engine?

[Alan Daniels]

From: daniels at mindspring.com (Alan Daniels)

On Thu, 01 Jul 1999 15:41:27 +0100, the infinitely wise Alex Maranda
(amaranda at nospam.com) spoke forth to us, saying...

[snip...]
>you use confusing terms; I understand what you're saying, but you
>shouldn't use the word 'thread' for anything else than its OS meaning.
>You could say the 'the bulk of processing'. You might very well end up
>using real Python threads; don't forget in this case to release/reaquire
>the global interpreter lock in your C++ callbacks, if you make blocking
>syscalls (unlikely in a game).

It was pretty late when I was writing the first post. :=)
You are correct, "the bulk of processing" is what I meant. NO threads
will be involved. The only justification I can see is better CPU
utilization on an SMP machine, and I don't happen to have one of those
lying around. Hence the engine will run in a single thread.

To keep things moving along, I'm considering dealing with the Python
scripts in a round-robin approach. Every frame, I allow X number of
scripts to handle an event, bumping that number upwards or downwards
to keep a consistent framerate.

>Unlikely. You won't know until you try. To my knowledge UnrealScript is
>eventually translated to C++.

I definitely do NOT want to turn this into a systems level project.
I'm a language junkie, but the internals of compilers don't interest
me much. I understand the reasons that Tim Sweeney made UnrealScript,
but to me it seemed kind of overkill. The world doesn't need another
scripting language.

I have the (VERY!) preliminary code at:
    http://www.mindspring.com/~daniels/engine/index.html
if you're interested, although there isn't much to look at.

-- 
=======================
Alan Daniels
daniels at mindspring.com
daniels at cc.gatech.edu