Python vs. C++ Builder - speed of development

[Bengt Richter]

On Sun, 02 Feb 2003 07:29:05 GMT, "Brandon Van Every" <vanevery at 3DProgrammer.com> wrote:

>Laura Creighton wrote:
>>
>> I don't know about that.  I am getting the sense that he has a problem
>> domain which he can define and manipulate in a nice orderly subset of
>> C++ and thus doesn't fall into holes.
>
>Yep.  I don't need more than simple inheritance right now.
>
>> But what puzzles me is why, if
>> this is the case, he insists on painting his room with a toothbrush
>> :-).
>
>Because in 3D mathematics you have to be very careful that it all works.
>You build lotsa little proven toothbrushes, later they will add up to a
>giant toothbrush.  Really, how do you think you're going to do game AI on an
>icosahedral sphere without a strong mathematical foundation?
>
PMJI, but the phrase "game AI on an icosahedral sphere" suggests that your
game design has coupled "game," "AI," and graphics infrastructure problems
involving "an icosahedral sphere" a bit closely.

You may find that if you separate them, Python may be best for one part and
C++ for another. And Python will let you integrate the parts easily.

It sounds like you may be grappling with some problems that are principally
about math and/or algorithms of graphics. I would be surprised if there aren't
newsgroups that specialize in that area. Also, if you don't have it, I'd recommend
a look at "Computer Graphics, Principles and Practice" by Foley, van Dam, Feiner
and Hughes, published by Addison Wesley, ISBN 0-201-84840-6. A couple of other AW
books are the OpenGL RM & PG blue and red books.

You can get reasonably fluent in Python pretty fast (basics are a snap to learn,
familiarity with _everything_ probably has to be forced by writing a book about
everything ;-)
<reply space reserved for product placement/> ;-)

Once there, I think you can't beat the ease with which you will be able to do
experimental prototyping of algorithms etc. To see if things look right
in terms of whether many 3D graphical elements have been munged together properly
to make the screen image you see, you don't need high frame rates. You need to
be able to experiment quickly to fix what you see (or what you see in a zoom utility
if you are not leaving nitty-gritty pixels to the graphics libraries).

If you _are_ going to get into the nitty-gritty of putting pixels on the screen,
spend time getting various notions of pixels and coordinates straight.
Some representations are innately scaleable and some aren't. E.g., screen pixel
coordinates are really indices, and only relate to coordinates. Maybe well, maybe not.

>> C++ is the tool to get out when you need to get real close to the
>> machine, and you need classes.
>
>Hey, bingo!  You've understood my 3D graphics case use.
>
>--
>Cheers,                         www.3DProgrammer.com
>Brandon Van Every               Seattle, WA
>
>20% of the world is real.
>80% is gobbledygook we make up inside our own heads.
100% of the above is gobbledygook inside your head. You were born with
a VR helmet jammed on tight, and the tiniest intuition of true reality
before you die will be a religious experience ;-)

Regards,
Bengt Richter