[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Scripting
Jan Ekholm wrote:
>
> On Thu, 18 Apr 2002, Steve Baker wrote:
>
> >Jan Ekholm wrote:
> >
> >> Oh, you do really mean that doing stuff in C++ is so much easier than
> >> doing it in, say, Python (popular in this thread)? Good for you then. :)
> >
> >Not necessarily easier - just no harder. And if it's no harder to
> >write in C++ than in a scripting language, you should use C++ because:
>
> Oh, please. You can't possibly say that C++ is easier to use than a
> script language? Sure, for you it is, you have invested a decent maount of
> years doing fulltime C/C++, but for us normal hobbyhackers C++ is much
> harder.
OK - if you havn't learned C++ then C++ is harder than something you HAVE
learned. But I maintain that comparing two languages I know well, there
is no extra difficulty in developing programs just because one is compiled
and the other interpreted.
> Just think about stuff like memory management, references, pointers,
> operaor overloading, cumbersome containers (STL is powerful, but
> cumbersome), header files, memory corruption (what use is a stack trace
> when the memory was corrupted a minute ago?) and so on.
But used properly, those things (not memory corruption!) make it easier
to write clean, understandable code - that more than makes up for any
extra complexity they introduce when debugging said feature.
> >That can happen in any language that's sufficiently powerful to do the
> >things most games need to do. Unless you are prepared to go without
> >pointers, you are going to see these kinds of issues.
>
> You have a hard time doing anything i C/C++ without pointers. Especially
> if you plan to do a game and use some external library.
And what if your language of choice doesn't have pointers and the external
library relies on them? That's more than 'hard' - that's impossible!
> >In tests we did at work, Python ran between 40 and 200 times slower
> >than C++ for a 'typical' set of operations (which is something you
> >could argue about *forever* - but we thought it was typical code).
>
> Yes, I don't disagree here. Python is slower, someone could even say it's
> dog slow.
My dog could outrun a python! :-)
> Not necessarily. It all depends on how much extra stuff your game needs to
> do. Most Linux games don't really need to do that much extra beside
> drawing the scene, accept user input, update some objects, check for some
> special condition.
Really? Damn - I wonder what's wrong with my games?
The one I'm writing now (which is not OpenSource) spends 37% of it's time
in non-rendering activity (I know - I'm staring at the profiler right now) - and
that's *despite* the fact that all of the transform and lighting code
is done in software.
So, what would happen if I rewrote my present program (which is getting
30Hz frame rate and consuming 100% of the CPU) in Python - leaving the
rendering code in some hypothetical external library which is still written
in C or C++ or something.
Well, 63% of the 33ms frame time would still be in C/C++ inside that
rendering library - and would consume the same amount of time, which
is roughly 20.8ms.
The remaining 12.2ms of the current execution time would take (say) 50
times longer to execute...610.5ms. Plus the 20.8 spent rendering makes
for a total frame duration of 631.3ms - somewhat less than 2Hz.
Well, that's going to be a *GREAT* game isn't it! Flying around on the
back of a giant eagle through craggy mountains with the graphics zooming past
at TWO HERTZ!!! That would be *completely* unplayable.
Even if we get *wildly* optimistic and say that our interpreter is
only 10x slower (and my testing suggests that 200x slower is actually
nearer the mark) - then you STILL only get about 7Hz.
The human visual system needs at least 10 to 15Hz to see actual motion.
At 7Hz, you'll see just a sequence of static frames. I'm getting 30Hz
- but I'm not happy with that (you see double-imaging which is very
disturbing in a flying game) - I need 60Hz, so I'm now optimising the
bejeezus out of all of the code in the hope that I can double it's
speed.
Hence the reason I'm looking at the profiler right now and wondering
whether there's a better C++ compiler out there! :-(
Now tell me again why I should be using an interpreter?
It only gets worse from here.
When you go to modern hardware where *all* of the rendering calculations
are moved out into the graphics card, then you can start doing things
like realistic physics. This is definitely the trend for the upcoming
generation of games...the gdeveloper mailing list talks of little else
these days.
Realistic Physics will *easily* consume 100% of a CPU at 60Hz - and ALL
of that code ends up in your application - there is no hardware accelleration
for physics.
Now, with an interpreted language, you'll be lucky to get one frame
a second...with a compiled language, it'll look *AMAZING* with realistic
interactions between arbitary objects at 60Hz!
> >In action games, you tend to want to use all of the resources you
> >possibly can to get better graphics. Graphics are never "good enough".
>
> True. But more and more of the actual gfx is just a call to OpenGL/DX to
> draw some pre-setup vertex array or display list. Which can be done as
> fast in any language. So for static data the difference isn't huge.
Well, listen to the numbers.
Clearly what you say is not true for *actual* games like the
one I'm writing right now.
----------------------------- Steve Baker -------------------------------
Mail : <sjbaker1@airmail.net> WorkMail: <sjbaker@link.com>
URLs : http://www.sjbaker.org
http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net
http://prettypoly.sf.net http://freeglut.sf.net
http://toobular.sf.net http://lodestone.sf.net