Redirecting StdOut

[Ugo García]

> You'll doubtless get other replies on this, including pointers to PyGame.
> What makes you think a game implemented in Python will not have
> enough speed?  You certainly would not be writing the low level
> graphics routines in Python, but then you aren't about to do that
> in C, either (I sincerely hope).  Python can call on libraries
> which have already been written *in C* (usually) to do the grunt
> work, so it is quite fast enough.
    I've seen PyGame but It still doesn't like. The idea of making a game in
a interpreted language doesn't like very much. (Is like making a game in
Visual Basic). Perhaps I'm used to make games with C (and of course, asm)
or, perhaps this is the right way to do it. Do u know many games that are
made with an interpreted languaged? I don't. (I'm talking about GAMES, not
little demos). Well, I known one: BLADE. It use Python to define the world,
the behavour of the characters, and other things like the save games... If u
have test it u could agree that it's extremely sloowly when loading (don't
know if it's because it use Python or because the coders as Spanish, like
me.... :-) ).

> As for reliable, I have to most vigorously object to anyone
> characterizing C as "reliable".  C code is notoriously difficult
> to make reliable, generally being strewn with pointer bugs,
> memory allocation problems, and so forth.  C was really written
> only as a somewhat more human-readable Assembly language substitute
> and has been supplanted by many more suitable alternatives for
> something as sophisticated as the engine of a game.
(ufff. very difficult to understand by my poor English... Let see...) I
agree that C is more complicated than other languages; more complicated to
code and more complicated to debug. But... What engines do u know are
written in another language instead of C? (Perhaps we're are naming 'engine'
to different thing)

> Or to put it another way: don't knock it till you've tried it!
> Python is quite possibly a far more suitable solution for
> the entire application, not just for the scripting language.
I agree again. I've to try other alternatives before deciding.... but I have
already try another.... and I'm still see Python as a script language for a
engine, not for the whole engine (it depend, of course, in the kind of the
engine).

Don't know, perhaps most people who write engines are wrong (i think they're
written in C), or perhaps I'm wrong. This is the goal of the forums... to
get the right way!!! :-)

Thanks,
--ugo