DarkBasic Pro -v- Blitz Basic 3D
Philip Young
This is somewhat off topic but can anyone who has used both of the above
packages give their views on which is the better?
To put this in context, I am not a professional programmer. Actually, I'm a
lawyer. (No doubt that confession will now cause some humourous responses).
I am very familiar with BASIC and also pretty familiar with C. I prefer C.
Before anyone asks, I've never even opened a book on C++. I've never had the
time.
I've had a look on the net. The only comparative review I could find was in
PC Plus edition 199. That said both packages were very good but that Blitz
Basic 3D just pipped DarkBasic Pro at the post. It also said that DarkBasic
Pro is based on a more pseudo-Basic style language and is slightly easier to
use with better tutorials. According to PC Plus BlitzBasic 3D has a language
more similar to C and has slightly more power than DarkBasic Pro at the end
of the day.
This would have meant that I would have opted for BlitzBasic 3D. However, I
saw on the DarkBasic Pro website that you can buy a texture generator
package with DarkBasic Pro, which is awfully tempting I've got to say. I'm
not sure if that package works with BlitzBasic 3D.
All views gratefully received!!!
And, before you ask, yep, I am intending to create an Elite-a-like with the
package I buy. I do have some experience of writing this sort of game. I
wrote two similar games back on my old Amiga workbench v1.2 with Amos.
Before you ask, the graphics were crap because I have the artistic skills
and abilities of giraffe. And a particularly artistically untalented giraffe
at that.
Cheers
Philip
Will Davis
"Philip Young" <phili...@netvigator.com> wrote in message
news:bbfmj0$qv...@imsp212.netvigator.com...
> Dear all
>
> This is somewhat off topic but can anyone who has used both of the above
> packages give their views on which is the better?
>
> To put this in context, I am not a professional programmer. Actually, I'm
a
> lawyer. (No doubt that confession will now cause some humourous
responses).
Ahah!! Now we can get some answers....wait till DB, IB and CP are around,
this could get interesting!
I've got DBPro, and I have to say it's very good, but suffering at the
moment from a large number of bugs which, although they keep getting fixed,
it is annoying to have to reinstall and repatch everything. I've never used
Blitz3d tho - I just liked what I saw with DBPro and went and got it.
EdzUp
the
> package I buy. I do have some experience of writing this sort of game. I
> wrote two similar games back on my old Amiga workbench v1.2 with Amos.
> Before you ask, the graphics were crap because I have the artistic skills
> and abilities of giraffe. And a particularly artistically untalented
giraffe
> at that.
My opinion is as follows:
DBPro:
Pros:
1) Nice editor its easy to use and laid out so everything is within reach
2) Can compile everything into one EXE
Cons:
1) Each patch DBLtd release seems to break something else
2) Isnt as fast as Blitz 3d
3) Direct X ONLY
4) Networking still needs LOTS of work
5) Needs CD EVERY 100 compiles, and as you will know every coder does small
changes and tests to have the CD EVERY 100 compiles is a pain in the arse.
Unless you want to pay EXTRA for the dongle :(
Blitz3d:
Pros:
1) Its bloody fast
2) A complete forum of people who are willing to help when required.
3) With TeraBits packing routines you can pack everything into data files or
into the exe.
4) With Blitz Max you will be able to code for Mac's, Linux, OpenGL as well
as DirectX :P (This should run standard Blitz3d code so no need to do a
complete recode like I did to go from DB1.13 to DBPro :( ).
5) Networking is fast too
6) Each new patch doesnt break previously working commands.
Cons:
1) Help files need some work
2) Command set can be a little trickier to learn but once mastered its
almost as fast as C++ and in some cases faster.
Hope it helps.
Regards
Ed
EdzUp
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.486 / Virus Database: 284 - Release Date: 29/05/03
Raptor
news:bbfmj0$qv...@imsp212.netvigator.com...
>
> This is somewhat off topic but can anyone who has used both of the above
> packages give their views on which is the better?
>
>
> All views gratefully received!!!
>
> And, before you ask, yep, I am intending to create an Elite-a-like with
the
> package I buy. I do have some experience of writing this sort of game. I
> wrote two similar games back on my old Amiga workbench v1.2 with Amos.
> Before you ask, the graphics were crap because I have the artistic skills
> and abilities of giraffe. And a particularly artistically untalented
giraffe
> at that.
>
> Cheers
>
> Philip
>
>
>
>
Greetings!
Wow, that's interesting. I'm actually a few steps ahead of you here (and a
few steps behind). I'm working in both DBPro and B3D at the moment (still
deciding which is best for my uses), and I'm also working on an Elite style
game. I actually started a thread previously asking about seamless space to
atmosphere transitions (one of things I'd like to emulate most from the
Frontier games). It's probably a complex task to handle with either
language, but I can always default back to C if I wish, heh.
As for a comparison, DarkBasicPro has a more Basic-like syntax and command
structure. If you've had experience with Q/QuickBasic, then DBPro is easier
to pick up and use. A QBasic veteran can ALMOST port a small to midsized
proggy into DBPro and require only minor tweaks. For example, you can do
the following in both (if my QBasic syntax isn't rusty):
INPUT "What's your name? ", name$
PRINT "Hello, ", name$
END
For Blitz, you'd have to use:
name$ = INPUT("What's your name? ")
PRINT "Hello, " + name$
END
I also like the IDE that comes with DBPro over the Blitz IDE. It has some
better features and, for me, is a little easier on the eyes.
However, I do NOT like DBPro's instability. I'm not saying that it crashes
(I haven't experienced many random crashes yet, *knocks on wood*), I'm
saying that many patches have a tendency to fix one thing while breaking
another. DBPro has more features and buzzwords for a programmer to play
with, and it works with some nifty DX8 features, but many of those don't
work correctly or are added/removed at the will of those doing the
bug-fixes. It's frustrating to realize that your game doesn't work on a
particular system, not because of something you did/didn't do, but because
of the language's bugs and stability issues.
For example, my pseudo 2D (3D in a 2D style) Elite style game I was doing in
DBPro ran excruciatingly slow on my P3 1.0AGhz, 640MB RAM, w/ATI AiW Radeon
7500. Then I installed Patch 4.1 and it worked a like it did on an
identical system with a GeForce4 Ti4600. I learned that Patch 4.1 fixed
some issues DBPro had with certain ATI cards. It just didn't sit right with
me that my code ran slow because of something completely out of my own
control.
I'm currently using Blitz3D right now until DBPro improves, as Blitz is a
more stable codebase. While DBPro does have more powerful features built in
that can take advantage of some of the newer hardware effects, that's all
useless if the game doesn't work. Out of the 6 computers that I have access
to, Blitz will run a 3D program on all of them, whereas DBPro will only run
on 4 (and only on 1 of those at full speed). A good chunk of this
compatibility comes because Blitz3D only requires DirectX 7, whereas DBPro
is DX 8 and above. The speed issue, I think, is due to the scarcity of DX8
compatible video cards in my house.
Blitz, I think, also has a better command structure and syntax. This is a
matter of opinion, but I prefer Blitz's style to DarkBasicPro's. Blitz, in
my opinion, handles loading of media a little better than DBPro. Whereas in
DBPro you have to assign each image, model, terrain, and sprite it's own
number within each category, Blitz lumps them all together as "entities" and
allows you to set a specific "handle". For example, in DBPro you'd use
(these are examples, and I cannot guarantee that this code is fully accurate
because I don't have either languages here at work):
LOAD IMAGE "SpaceBackground.bmp", 1
LOAD IMAGE "ShipSprite.bmp", 2
ROTATE IMAGE 1, 90, 0, 0
PASTE IMAGE 1, 0, 0
SPRITE 1, 100,100, 2
ROTATE SPRITE 1, 90, 0, 0
SPRITE 1, 100, 100, 2
And this semi-pseudo-code, in theory, would load two images (a space
background and a ship sprite), would rotate the background 90 degrees, would
show the background image, would create the ship sprite from Image 2 and
place it at 100, 100, would rotate that sprite, then place it again (the
SPRITE command in DB does double duty for creating a sprite from an existing
image and for placing the sprite on the screen). For Blitz3D, you'd have
something like:
BackgroundImage = LoadImage("SpaceBackground.bmp")
PlayerShip = LoadSprite("ShipSprite.bmp")
RotateEntity BackgroundImage, 90, 0, 0
DrawImage BackgroundImage, 0, 0
RotateEntity PlayerShip, 90, 0, 0
DrawSprite PlayerShip, 100, 100
While Blitz syntax is a little more abstract, it's setup in such a way that
makes it easier to use the file handles than it does arbitrary numbers.
Sooo, to sum up this rather lengthy reply, I prefer Blitz3D over
DarkBasicPro at the moment due to Blitz's stability and syntax style. But
both are good languages for relatively quick game creation. DarkBasicPro is
easier for a complete newbie to pick up, whereas Blitz may be preferable to
those with C experience. DarkBasicPro is an irritatingly unstable codebase,
but IS update many many more times than Blitz seems to be. Meaning
DarkBasic's problems are at least visibly being worked on.
As to TextureMaker, I'm ALMOST certain that it can generate textures that
can be exported to at least SOME standard format. So I don't think I'd
worry about compatibility on that end.
I hope my rather long winded repyl has helped out some, hehe.
--
-Richard Powell @Work
"Nice guys may finish last, but you know,
the company's much better back here."
Philip Young
news:bbg0r1$5ju$1...@pump1.york.ac.uk...
>
> "Philip Young" <phili...@netvigator.com> wrote in message
> news:bbfmj0$qv...@imsp212.netvigator.com...
> > Dear all
> >
> > This is somewhat off topic but can anyone who has used both of the above
> > packages give their views on which is the better?
> >
> > To put this in context, I am not a professional programmer. Actually,
I'm
> a
> > lawyer. (No doubt that confession will now cause some humourous
> responses).
>
> Ahah!! Now we can get some answers....wait till DB, IB and CP are around,
> this could get interesting!
>
I actually had a long and interesting email conversation with David just
over 3 years ago (my goodness, has it been that long?) regarding his views
of, and experiences with, the English civil justice system as regards his
action against Gametek.
Speaking professionally, I was pleased to hear that, on the whole, he was
satisfied with the efficiency of the system and of the service given by the
lawyers he instructed.
Who is "CP"?
Philip
Philip Young
I also posted my original email to the Retro Remakes website.
All the emails and posts I have read and/or received (of which there have
been over 60!) seem to come out about 50 / 50 in favour of both packages.
Given the bug problems with DarkBasic Pro I have, on reflection, decided to
opt for Blitz 3D.
Philip
"Raptor" <rpo...@raptorgames.com> wrote in message
news:3edb9664$1...@news.iglou.com...
Will Davis
> "Will Davis" <whd...@york.ac.uk> wrote in message
> news:bbg0r1$5ju$1...@pump1.york.ac.uk...
> >
> > "Philip Young" <phili...@netvigator.com> wrote in message
> > news:bbfmj0$qv...@imsp212.netvigator.com...
> > > Dear all
>
> Who is "CP"?
>
> Philip
Christian Pinder, who wrote a new version of Elite called The New Kind (TNK)
by reverse engineering the BBC version and re-writing it in C. It was
freeware for ages, but then DB got pissed off (quite rightly) by a PocketPC
port of it (or rather the EULA with it!) that somebody had done. Now you
can't officially get TNK (it is pretty hard to find).
Dylan Smith
<phili...@netvigator.com> wrote:
>Given the bug problems with DarkBasic Pro I have, on reflection, decided to
>opt for Blitz 3D.
Urgh. Don't do it - BASIC is not standardized in any way: each dialect is
subtly and irritatingly different, most are inconsistent, and most
lack things that are (ironically) basic features of other languages.
If you're going to write anything of any size, use a proper language :-)
BASIC is especially unsuitable for games, and it's never portable -
not even between different 'compilers' (most are interpreters).
If you can't/don't want to use C, consider using Python. Although you'll
have some of the speed issues of BASIC, Python is a much better language
and it's multiplatform.
--
Dylan Smith, Castletown, Isle of Man
Flying: http://www.dylansmith.net
Frontier Elite Universe: http://www.alioth.net
"Maintain thine airspeed, lest the ground come up and smite thee"
Philip Young
> >
> > Philip
>
> Christian Pinder, who wrote a new version of Elite called The New Kind
(TNK)
> by reverse engineering the BBC version and re-writing it in C. It was
> freeware for ages, but then DB got pissed off (quite rightly) by a
PocketPC
> port of it (or rather the EULA with it!) that somebody had done. Now you
> can't officially get TNK (it is pretty hard to find).
>
For everyone's future reference, it seems to me that the simple answer to
this type of problem is for such tribute software not to be provided
entirely "freeware". Instead, it could be provided free of charge but
subject to a condition and/or agreement which provides that the software is
not to be distributed, whether commercially or otherwise, by the downloader.
This should then provide a legal "bar" to the downloader incorporating the
software into a commercial product as it means the downloader will only be
able to legally use the game for his/her own entertainment.
To give a practical example, the same concept is found on DVDs, VHS
cassettes, etc. You have probably noticed that these are said to be provided
for home use only. The classic type of statement you find on them is
something along the lines of:
"WARNING: the copyright proprietor has licensed the film (including its
soundtrack) comprised in this video cassette for home use only. All other
rights are reserved. The definition of home use excludes the use of this
video cassettte at locations such as clubs, coaches, hospitals, hotels, oil
rigs, prisons and schools. Any unauthorised copyright, editing, exhibition,
renting, exchanging, hiring, public performance, diffusion and/or broadcast
of this video cassette or any part thereof is strictly prohibited and any
such action establishes liability for a civil action and may give rise to
criminal prosecution."
Obviously the validity and effect of such a statement can be debated, but at
the very least it serves in providing a useful deterrent effect.
I hope this is helpful.
Philip
Martin Christensen
Hash: SHA1
>>>>> "Dylan" == Dylan Smith <dy...@vexed2.alioth.net> writes:
Dylan> If you can't/don't want to use C, consider using
Dylan> Python. Although you'll have some of the speed issues of BASIC,
Dylan> Python is a much better language and it's multiplatform.
Even if you can and want to use C, start with Python anyway, and if
need be, replace the slowest pieces of code with optimised C modules.
Or if you have an aversion to Python, use some other well-structured
high-level language, but Python already has a lot of nice library
support that would come in handy to a game developer. The choice of
using a high-level language instead of something like C/C++ will save
you a lot of time and worries in the long run, and while some people
like to scream and hollar about performance, 1) that's what e.g. C
modules are for, and 2) usually bad programmers are the cause of
slowness, not interpreted languages.
Martin
- --
Homepage: http://www.cs.auc.dk/~factotum/
GPG public key: http://www.cs.auc.dk/~factotum/gpgkey.txt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Using Mailcrypt+GnuPG <http://www.gnupg.org>
iEYEARECAAYFAj7dyToACgkQYu1fMmOQldUdRACgodCBobb+UTDK5hkRMMDni2pK
0CQAnjO4dXl4iHhp5jgLR5kl0PoE2Iu+
=MAV1
-----END PGP SIGNATURE-----
John Jordan
<dy...@vexed2.alioth.net> writes
>
>If you can't/don't want to use C, consider using Python. Although you'll
>have some of the speed issues of BASIC, Python is a much better language
>and it's multiplatform.
Note that these "game BASICs" are normally compiled and so run at
similar speeds to other compiled languages. Python would be orders of
magnitude slower.
While I'd recommend C and either SDL or DirectX for a "serious" game
project, an all-in-one compiler/library setup is understandably
attractive to anyone who doesn't fancy hacking through obfuscated
installation procedures, bloated APIs and badly-written documentation
before they can get a triangle on the screen.
Alternatively turn up in #gamedev on irc.starchat.net and you should
find someone willing to talk you through the pitfalls.
--
John Jordan
Will Davis
"Dylan Smith" <dy...@vexed2.alioth.net> wrote in message
news:slrnbdr9s6...@vexed2.alioth.net...
> On Wed, 4 Jun 2003 01:11:47 +0800, Philip Young
> <phili...@netvigator.com> wrote:
> >Given the bug problems with DarkBasic Pro I have, on reflection, decided
to
> >opt for Blitz 3D.
>
> Urgh. Don't do it - BASIC is not standardized in any way: each dialect is
> subtly and irritatingly different, most are inconsistent, and most
> lack things that are (ironically) basic features of other languages.
>
> If you're going to write anything of any size, use a proper language :-)
> BASIC is especially unsuitable for games, and it's never portable -
> not even between different 'compilers' (most are interpreters).
>
> If you can't/don't want to use C, consider using Python. Although you'll
> have some of the speed issues of BASIC, Python is a much better language
> and it's multiplatform.
>
Dunno about Python, but I think you're mistaken about Blitz3D and
DarkBasic - they're specially designed FOR games programming, with high
level programming constructs especially for interfacing with DirectX and
other graphics utilities. It's basically really abstract so that you don't
have to get stuck in the niggly bits like you do in C, but it does have a
lot of expressive power as well (though no where near as much as C). It is
fully compiled (no byte code), but since it's so high level may still not be
as fast as C. Have a look at StarWraith for something that is pretty damn
good and was programmed in DB (not even DBPro!).
Martin Christensen
Hash: SHA1
>>>>> "John" == John Jordan <jo...@jaj22.demon.co.uk> writes:
John> Note that these "game BASICs" are normally compiled and so run
John> at similar speeds to other compiled languages. Python would be
John> orders of magnitude slower.
I doubt that. Slower, yes, but that's what we have C modules for. Most
of the heavy stuff would be done in graphics libraries and such. Much
of the remaining heavy stuff would be taken care of by Python's own
numeric libraries (i.e. not just regular numeric computations), which
are also quite fast. The remaining hot spots would gradually be
replaced by e.g. C modules. I doubt that the final result would be
noticeably slower than in any compiled language, and certainly not
orders of magnitude slower. If, of course, you wanted to keep
everything in pure Python, sure, that could be a significant slowdown.
Martin
- --
Homepage: http://www.cs.auc.dk/~factotum/
GPG public key: http://www.cs.auc.dk/~factotum/gpgkey.txt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Using Mailcrypt+GnuPG <http://www.gnupg.org>
iEYEARECAAYFAj7fOLgACgkQYu1fMmOQldVgWgCdE+/Liemcafve9ZPm/lLmKBEl
u9cAn1/CTkPhyUpPy6drPiKbtk/ievAL
=l6vy
-----END PGP SIGNATURE-----
Serguei Narojnyi
> of the heavy stuff would be done in graphics libraries and such. Much
> of the remaining heavy stuff would be taken care of by Python's own
> numeric libraries (i.e. not just regular numeric computations), which
> are also quite fast. The remaining hot spots would gradually be
> replaced by e.g. C modules. I doubt that the final result would be
> noticeably slower than in any compiled language, and certainly not
> orders of magnitude slower. If, of course, you wanted to keep
> everything in pure Python, sure, that could be a significant slowdown.
why not just fucking write it in C to begin with then. fucking CS
students...
John Jordan
<n...@snaar.net> writes
Hmm. This post is so wrong in so many ways that the possible replies
fight in my head. I think I'll just concur with Snaar.
--
John Jordan
Will Davis
"John Jordan" <jo...@jaj22.demon.co.uk> wrote in message
news:cJ63soDb...@jaj22.demon.co.uk...
As in concur that to write a program in even two different languages is a
bit pointless when you could just write it in the better one to start with?
Well yes then, so do I. The thing about DBPro and B3D is that you _can_
write it all in one language, and I don't think you can import foriegn
language files anyway. What is Python anyway? I've never heard of it.
Paul Roberts
to
> atmosphere transitions (one of things I'd like to emulate most from the
> Frontier games). It's probably a complex task to handle with either
> language, but I can always default back to C if I wish, heh.
It's not exactly a trivial task in C or C++ either :-)
(says someone who tried a few years ago, and all but gave up)
--
Paul Roberts
email/msn: paul [at] pwroberts [dot] com
http://www.m3fe.com/
Philip Young
> > fight in my head. I think I'll just concur with Snaar.
> >
>
> As in concur that to write a program in even two different languages is a
> bit pointless when you could just write it in the better one to start
with?
> Well yes then, so do I. The thing about DBPro and B3D is that you _can_
> write it all in one language, and I don't think you can import foriegn
> language files anyway. What is Python anyway? I've never heard of it.
>
>
Sorry. Crap humour, I know. I'm afraid I couldn't resist it.
Philip
Will Davis
Don't worry, I don't any of us can resist crap humour!
Kegs
> As in concur that to write a program in even two different languages is a
> bit pointless when you could just write it in the better one to start with?
Well because Python is easier to write than C or C++ it is quicker to get an
working prototype knocked together, without having to worry about the low
level memory management, as that is all handled internally.
As python is interpreted at runtime, rather than compiled, it isn't as fast
as either C or C++, it does however have libraries that allow python modules
to run as part of C/C++ programs and vice versa. Sp you can convert those
parts of the program where performance is an issue into C/C++ after you have
prototyped them in python, which is easier than prototyping and debugging in
C.
> Well yes then, so do I. The thing about DBPro and B3D is that you _can_
> write it all in one language, and I don't think you can import foriegn
> language files anyway. What is Python anyway? I've never heard of it.
Python is a true object-oriented interpretted language that is open-source and
freely distributed, and not horribly retarded, like some varieties of basic
are.
--
James
jamesk[at]beeb[dot]net
Backup not found. [A]bort, [R]etry, [P]anic...
Will Davis
"Kegs" <m...@privacy.net> wrote in message
news:m3wufz0...@localhost.localdomain...
> "Will Davis" <whd...@york.ac.uk> writes:
>
snip
> freely distributed, and not horribly retarded, like some varieties of
basic
> are.
>
Well in that case I must be a horrible retard lover :o)
...I'd just never heard of it, that's all. I might have a look one day.
Havok
hijacked the computer of John Jordan <jo...@jaj22.demon.co.uk> and
wrote:
I've been using Python for about six months now at home and at work,
at work I use it mostly for simulations which involve a lot of math
and complex objects. I've got years of C experience and sure I can
write code that is faster in C, but Python is so much faster to
develop in that I would never do anything in C that I didn't have to.
I doubt you will find things are an order of magnitude slower in
Python than C, unless you are trying to do it that way. Although I
admit sometimes I have to write some code in C for performance, I just
write a stub for the code and use it from Python anyway.
I have fuck all spare time now and if I decide to program something
then I'm definatly going to use Python, no doubt at all. At work
estimates are always done by others based on C or Java, I can almost
almost always complete the work before the deadline, often long before
it, with less bugs.
I really don't have a clue about interpreted vs compiled language
performance, I've done most of my work in C but I haven't noticed any
significant drop in performance moving to interpreted languages. I
know that C compilers have years of optimization work in them that
Python won't achive, but I doubt the game BASICs can achive them
either, unless they are compiled to C first.
--
Havok - Admiral of Defence
The Galactic Network of Explorers and Traders.
http://www.galnet.org
Martin Christensen
Hash: SHA1
>>>>> "Havok" == Havok <elite.n...@REMOVEpaulnilsson.com> writes:
Havok> I've been using Python for about six months now at home and at
Havok> work, at work I use it mostly for simulations which involve a
Havok> lot of math and complex objects. I've got years of C experience
Havok> and sure I can write code that is faster in C, but Python is so
Havok> much faster to develop in that I would never do anything in C
Havok> that I didn't have to.
Development time and flexibility in situations where you just want to
try some quick changes are the really big advantages of using
high-level languages like Python. For game development in particular,
the only reason I can think of that makes Python more appealing than
any other language is its support for external libraries. I'm sure
there are plenty of other high-level languages that would be good for
such tasks.
As for Python's speed in simulations, that's thanks to external C
libraries (numeric Python), I take it. Fast stuff. If you want it any
faster, Fortran is still, after all these years, the way to go.
Havok> I doubt you will find things are an order of magnitude slower
Havok> in Python than C, unless you are trying to do it that way.
Depends on what you're trying to accomplish. Sometimes cannot avoid
the slowness of an interpreted language. For instance, if you have a
couple of nested loops inside which you don't do all that much, the
overhead of performing the loop itself will be much more significant
than if you wrote it in C. On the other hand, I doubt that I could
write the program I've developed for my Master thesis much faster in
any other language than Python, since the majority of the processing
time is spent juggling references to objects and manipulating strings.
Havok> Although I admit sometimes I have to write some code in C for
Havok> performance, I just write a stub for the code and use it from
Havok> Python anyway.
That makes sense as a small part of a greater solution, but if Python
is only used to add the last few pieces of logic, I'm inclined to
agree with Serguei. There's no need to be religious about one's choice
in language, though he does indeed seem to be.
Havok> I have fuck all spare time now and if I decide to program
Havok> something then I'm definatly going to use Python, no doubt at
Havok> all.
Having just turned in my thesis, I now have some time again. Python is
my primary language, but I've decided to start developing my skills in
some other language, probably Scheme or ML in order to help me think
outside of the usual imperative box. Sure, you can whip up a solution
to a simple problem in Python in no time, but if you want to make it
maintainable, it's only about twice as fast to develop in as, say,
C++.
Havok> At work estimates are always done by others based on C or
Havok> Java, I can almost almost always complete the work before the
Havok> deadline, often long before it, with less bugs.
Bugs is where I really save time with Python. I find that I have much
fewer bugs overall than in most other languages, and more importantly,
they tend to be quite shallow. Only in ELisp do I make fewer bugs.
Havok> I really don't have a clue about interpreted vs compiled
Havok> language performance, I've done most of my work in C but I
Havok> haven't noticed any significant drop in performance moving to
Havok> interpreted languages.
Depends on what you're trying to accomplish. Very often, interpreted
languages are 'fast enough'.
Havok> I know that C compilers have years of optimization work in them
Havok> that Python won't achive, but I doubt the game BASICs can
Havok> achive them either, unless they are compiled to C first.
Well, BASIC can sometimes be compiled, and it doesn't have the
overhead of dynamic type checking. There's an optimising compiler for
Windows, I've been informed, that does a very good job, but there are
still some things for which a language like Python will never run as
quickly as some other languages. That rarely matters, though.
Martin
- --
Homepage: http://www.cs.auc.dk/~factotum/
GPG public key: http://www.cs.auc.dk/~factotum/gpgkey.txt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Using Mailcrypt+GnuPG <http://www.gnupg.org>
iEYEARECAAYFAj7jNq4ACgkQYu1fMmOQldXXkgCcDc8E8ubjq1Ynko77PoabyjGS
QPIAoOTmPFiZj6fJBNXn5bpVZ5VJfO4h
=1pXM
-----END PGP SIGNATURE-----
Dylan Smith
<knightsofspam...@gvdnet.dk> wrote:
>outside of the usual imperative box. Sure, you can whip up a solution
>to a simple problem in Python in no time, but if you want to make it
>maintainable, it's only about twice as fast to develop in as, say,
>C++.
Only twice as fast as C++ can be a lot more than 'only' depending on
the project. It can represent a highly significant saving of time
and aggravation.
Then there's the other thing: those people who think you can't write
maintainable/readable code in Perl simply don't know what they are
talking about.
Martin Christensen
Hash: SHA1
>>>>> "Dylan" == Dylan Smith <dy...@vexed2.alioth.net> writes:
Dylan> Then there's the other thing: those people who think you can't
Dylan> write maintainable/readable code in Perl simply don't know what
Dylan> they are talking about.
If you want to write maintainable, readable code, what's the point in
using Perl? :-)
Martin
- --
Homepage: http://www.cs.auc.dk/~factotum/
GPG public key: http://www.cs.auc.dk/~factotum/gpgkey.txt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Using Mailcrypt+GnuPG <http://www.gnupg.org>
iEYEARECAAYFAj7kdVAACgkQYu1fMmOQldXdbACffaIrEssgqtyPhp2GrW/cXyo+
huoAoJzvUG9ivHgSmkax/iiI1l/w37tk
=lnBm
-----END PGP SIGNATURE-----
Raptor
understand that. :)
--
-Richard Powell @Work
"Nice guys may finish last, but you know,
the company's much better back here."
"Paul Roberts" <usene...@pwroberts.com> wrote in message
news:bbpto4$pef$1...@wisteria.csv.warwick.ac.uk...
tom
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> >>>>> "Havok" == Havok <elite.n...@REMOVEpaulnilsson.com> writes:
> Havok> I've been using Python for about six months now at home and at
> Havok> work, at work I use it mostly for simulations which involve a
> Havok> lot of math and complex objects. I've got years of C experience
> Havok> and sure I can write code that is faster in C, but Python is so
> Havok> much faster to develop in that I would never do anything in C
> Havok> that I didn't have to.
>
> Development time and flexibility in situations where you just want to
> try some quick changes are the really big advantages of using
> high-level languages like Python.
This is misleading. I've written big-ish things in python and due to
the weak typing, big changes to your big chunk of code introduce bugs
which, had the thing been written in C, the compiler would have caught.
This is why i don't write large things in python anymore. it is a
pain in the arse to make changes. There is the grubby feeling that
there are basic type mismatches skulking around in the code. there
is a python checker somewhere online (also written in python) which
will spew you a few pages of spurious warnings, and i used to use
this to check releases of my dubious python emailer/newsreader wasn't
bepooed.
> For game development in particular,
> the only reason I can think of that makes Python more appealing than
> any other language is its support for external libraries. I'm sure
> there are plenty of other high-level languages that would be good for
> such tasks.
>
> As for Python's speed in simulations, that's thanks to external C
> libraries (numeric Python), I take it. Fast stuff. If you want it any
> faster, Fortran is still, after all these years, the way to go.
No way, man ;-)
Download the python sourcecode and run through what happens as things
are interpreted. math.sin(x) involves a dictionary lookup, for example.
External C functions must parse their arguments with the
PyArg_ParseTuple function, which takes string format and varargs.
Python is cute and quick for little things but no use for modern
3d games.
> Havok> I doubt you will find things are an order of magnitude slower
> Havok> in Python than C, unless you are trying to do it that way.
:-)
--
Tom Morton (http://www.moretom.net)
Scorpyo
Lift up your hearts..
As soon as DB Pro will be stable and bug free David Braben will start
coding Elite 4..
cheers all
Scorpyo
Martin Christensen
Hash: SHA1
>>>>> "tom" == tom <tom.m...@ntlworld.com> writes:
>> Development time and flexibility in situations where you just want
>> to try some quick changes are the really big advantages of using
>> high-level languages like Python.
tom> This is misleading. I've written big-ish things in python and due
tom> to the weak typing, big changes to your big chunk of code
tom> introduce bugs which, had the thing been written in C, the
tom> compiler would have caught. This is why i don't write large
tom> things in python anymore.
This is a mistake I've made myself. While it's a real danger and can
lead to non-shallow bugs at times, in my experience, it's invariably
due to bad data design. When this sort of error rears its ugly head,
it's usually a sign that you need to start over.
But this is indeed the major weakness of dynamically typed
languages. I just find that, as I mentioned above, it's a barrier that
I don't run into unless I need a rewrite anyway. If need be, you can
add manual type checking in critical places, but needless to say,
that's not a very practical solution, especially since it negates the
benefits of dynamic typing. If you're genuinely worried about not
being able to keep track of your data types, go for a statically typed
language (which certainly doesn't have to be low-level like
C/C++). Just don't expect any language, regardless of its feature set,
to be able to save you from yourself.
>> As for Python's speed in simulations, that's thanks to external C
>> libraries (numeric Python), I take it. Fast stuff. If you want it
>> any faster, Fortran is still, after all these years, the way to go.
tom> No way, man ;-) Download the python sourcecode and run through
tom> what happens as things are interpreted. math.sin(x) involves a
tom> dictionary lookup, for example.
I'm talking about numeric (or is that numerical?) Python, the set of
modules especially for number crunching, not just the standard
mathematical functions in the math module.
tom> External C functions must parse their arguments with the
tom> PyArg_ParseTuple function, which takes string format and varargs.
tom> Python is cute and quick for little things but no use for modern
tom> 3d games.
I've heard about one or two companies that have had tremendous success
with it, but they did gradually replace the Python code. Early in
development, speed and, to a lesser degree, size, the drawbacks of
Python and similar languages/environments are less important. Instead,
you get primarily RAD, which allows easier prototyping. Since you
should always plan on throwing one away anyway, might as well do it
with a cheap model.
Martin
- --
Homepage: http://www.cs.auc.dk/~factotum/
GPG public key: http://www.cs.auc.dk/~factotum/gpgkey.txt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Using Mailcrypt+GnuPG <http://www.gnupg.org>
iEYEARECAAYFAj7lEOYACgkQYu1fMmOQldW6HACfQj7w/klPBD/hfApCl0aklprE
YdgAnjvsG1SBg7/jvsd26jAJGsc8fSpj
=kue0
-----END PGP SIGNATURE-----
Will Davis
"Scorpyo" <tis...@libero.it> wrote in message
news:4e6130.030609...@posting.google.com...
Now is that pessimism or optimism?...
Will Davis
"tom" <tom.m...@ntlworld.com> wrote in message
news:%X5Fa.5659$0d7.1...@newsfep4-glfd.server.ntli.net...
> On 08 Jun 2003, 16:14:23, Martin Christensen wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > >>>>> "Havok" == Havok <elite.n...@REMOVEpaulnilsson.com> writes:
> > Havok> I've been using Python for about six months now at home and at
> > Havok> work, at work I use it mostly for simulations which involve a
> > Havok> lot of math and complex objects. I've got years of C experience
> > Havok> and sure I can write code that is faster in C, but Python is so
> > Havok> much faster to develop in that I would never do anything in C
> > Havok> that I didn't have to.
> >
> > Development time and flexibility in situations where you just want to
> > try some quick changes are the really big advantages of using
> > high-level languages like Python.
>
> This is misleading. I've written big-ish things in python and due to
> the weak typing, big changes to your big chunk of code introduce bugs
> which, had the thing been written in C, the compiler would have caught.
C is weak-typed as well, unless you've got a special compiler that does
type-checking as extra. Everything in C is represented as an integer, and
therefore all types are interchangeable - can't really get more weak typed.
Martin Christensen
Hash: SHA1
>>>>> "Will" == Will Davis <whd...@york.ac.uk> writes:
Will> C is weak-typed as well, unless you've got a special compiler
Will> that does type-checking as extra. Everything in C is represented
Will> as an integer, and therefore all types are interchangeable -
Will> can't really get more weak typed.
True, but it has static type checks, which is what he was after. If
you don't blow too hard at the house of cards that is C's type system,
it does provide some measure of safety. The people who scream about
type safety (as e.g. Snaar has been known to do) should perhaps not
shout too loudly about the virtues of C (which us heathens should, of
course, be brought to understand is the only language for doing
anything practical :-)), and perhaps instead lend their voices to
languages that actually provide it.
Martin
- --
Homepage: http://www.cs.auc.dk/~factotum/
GPG public key: http://www.cs.auc.dk/~factotum/gpgkey.txt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Using Mailcrypt+GnuPG <http://www.gnupg.org>
iEYEARECAAYFAj7lHZcACgkQYu1fMmOQldUExQCfamhe5X2OcwLJZ/Cy1VO1cRX8
7JcAniPMny8Hhq/U+3bpOfNJ2Wj0YB3j
=c9I/
-----END PGP SIGNATURE-----
John Jordan
<knightsofspam...@gvdnet.dk> writes
>
>I'm talking about numeric (or is that numerical?) Python, the set of
>modules especially for number crunching, not just the standard
>mathematical functions in the math module.
If you mean what I think you mean by numeric libraries, these are
normally useless for games programming because almost everything CPU-
heavy is handled with linearized approximations or heavily customised
special-case routines.
Despite this, it's still easy for a game to use up all the available CPU
of a modern PC even when coding in C. I could name commercial games
which do just that at remarkably low frame rates for little discernable
benefit, and you've probably seen all the terrain engines linked here
that scrape 25fps with an unimpressive quantity of triangles. If you try
to write any non-trivial part of a 3d game in Python or any other
interpreted language, you *will* run into problems.
On a side point, note that Fortran's prowess in numeric applications has
as much to do with the usage-optimising compilers as the libraries.
Python would be grossly slow for anything that didn't farm out 99% of
its processing to libraries.
--
John Jordan
Tom Morton
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> >>>>> "tom" == tom <tom.m...@ntlworld.com> writes:
> >> Development time and flexibility in situations where you just want
> >> to try some quick changes are the really big advantages of using
> >> high-level languages like Python.
> tom> This is misleading. I've written big-ish things in python and due
> tom> to the weak typing, big changes to your big chunk of code
> tom> introduce bugs which, had the thing been written in C, the
> tom> compiler would have caught. This is why i don't write large
> tom> things in python anymore.
>
> This is a mistake I've made myself. While it's a real danger and can
> lead to non-shallow bugs at times, in my experience, it's invariably
> due to bad data design. When this sort of error rears its ugly head,
> it's usually a sign that you need to start over.
No this is more trivial than crap design. if i add an argument to
a function i need to search for every call [in my huge codebase]
and fix it, or i find out later at runtime. rarely executed code
may not reveal its filthy new bugs for some time. this is the same
for renaming functions and class fields and so on. Of course in C
this stuff would all be caught at compile time.
Martin Christensen
Hash: SHA1
>>>>> "Tom" == Tom Morton <t...@moretom.net> writes:
Tom> No this is more trivial than crap design. if i add an argument to
Tom> a function i need to search for every call [in my huge codebase]
Tom> and fix it, or i find out later at runtime.
Ah, okay, that's different, then. I almost never run into that
situation, since I tend to make replacement functions whenever I need
to do something as drastic as changing the number of arguments.
Typically when I add an argument, it'll have a default value so that
it doesn't need to be specified, but if it's so major a change that
the number of required arguments changes, I typically make a new
function for it. As a helpful side effect, I don't get the same
problems as you.
Tom> rarely executed code may not reveal its filthy new bugs for some
Tom> time. this is the same for renaming functions and class fields
Tom> and so on. Of course in C this stuff would all be caught at
Tom> compile time.
With a proper test harness such as unit testing, this problem
automagically goes away as well has help you solve a lot of other
problems. When you run your test suite, every piece of code is run,
ideally, no matter if it's run rarely or often in normal operation. If
you're putting together a large piece of software without some form of
test suite to run on it, you have more serious issues than a
compile-time check can save you from. That being said, your argument
does have merit, even if ordinary good engineering practices would
make it a moot point. Of course, ordinary good engineering practices
aren't always very ordinary. (That'll be Snaar's que to rant about
'fucking computer scientists' again...)
Martin
- --
Homepage: http://www.cs.auc.dk/~factotum/
GPG public key: http://www.cs.auc.dk/~factotum/gpgkey.txt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Using Mailcrypt+GnuPG <http://www.gnupg.org>
iEYEARECAAYFAj7lzmAACgkQYu1fMmOQldX8EQCgmJkUNcqQMmecN1YFG/yoXmBX
6WAAoK3SOBCISKaCr5D5eGuLM4ph2wwj
=9zOf
-----END PGP SIGNATURE-----
Martin Christensen
Hash: SHA1
>>>>> "John" == John Jordan <jo...@jaj22.demon.co.uk> writes:
>> I'm talking about numeric (or is that numerical?) Python, the set
>> of modules especially for number crunching, not just the standard
>> mathematical functions in the math module.
John> If you mean what I think you mean by numeric libraries, these
John> are normally useless for games programming because almost
John> everything CPU- heavy is handled with linearized approximations
John> or heavily customised special-case routines.
Ah, I've only worked with simulations, never games directly, and
assumed that they would have a shared foundation what physics are
concerned. I assumed that it was mostly only necessary to cut corners
on graphics as such.
I am aware that a few gaming libraries have been developed for Python.
What exactly they do and how they do it, I haven't the faintest idea.
I've heard a lot of good about them, albeit from sources I don't trust
to be unbiased. I know that at least one of them is mostly just an
interface to SDL.
John> Despite this, it's still easy for a game to use up all the
John> available CPU of a modern PC even when coding in C. I could name
John> commercial games which do just that at remarkably low frame
John> rates for little discernable benefit, and you've probably seen
John> all the terrain engines linked here that scrape 25fps with an
John> unimpressive quantity of triangles. If you try to write any
John> non-trivial part of a 3d game in Python or any other interpreted
John> language, you *will* run into problems.
If by non-trivial parts you mean the stuff that juggles all the big
numbers, I'm sure you're right. However, I also consider mission
scripting, event handling etc. to be non-trivial, and these things
don't demand so much CPU power that it makes much of a difference if
they're very tightly optimised or not. Since they're also much more
likely to change significantly than, say, the 3D engine, there are
plenty of arguments in favour of simplicity at the expense of
(constant-time) efficiency.
John> On a side point, note that Fortran's prowess in numeric
John> applications has as much to do with the usage-optimising
John> compilers as the libraries.
I was thinking more of Fortran _for_ libraries rather than _because_
of its libraries, LAPACK being one example that immediately springs to
mind. I didn't so much consider the means by which it is fast as the
mere fact that it is fast itself.
John> Python would be grossly slow for anything that didn't farm out
John> 99% of its processing to libraries.
I'm sure you're right, and I would certainly not try to claim
differently. That is the exact reason why I've advocated gradually
replacing hot spots with more efficient code. Or one might even just
make a prototype in a HLL like Python first and then reimplement in a
more efficient language afterwards. The point is merely that mistakes
will be made, and, in my experience, more mistakes tend to be made if
you start out at a low level of abstraction. Moreover, since it takes
significantly longer to code stuff in a LLL than a HLL, prototyping in
a HLL and reimplementing in a LLL can save time in the long run. Of
course, the ideal solution would be a language with the abstraction
level of Python or similar and the efficiency of C, but I don't know
of any suitable language that offers that.
Martin
- --
Homepage: http://www.cs.auc.dk/~factotum/
GPG public key: http://www.cs.auc.dk/~factotum/gpgkey.txt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Using Mailcrypt+GnuPG <http://www.gnupg.org>
iEYEARECAAYFAj7l1DAACgkQYu1fMmOQldVCaQCfc7vQJq9Q+r0dPQPDygl3wsTe
yTgAnRMx4/mGFdeGyhVxYS7OKl3j0IlW
=Q5ZQ
-----END PGP SIGNATURE-----
Dylan Smith
<knightsofspam...@gvdnet.dk> wrote:
>If by non-trivial parts you mean the stuff that juggles all the big
>numbers, I'm sure you're right. However, I also consider mission
>scripting, event handling etc. to be non-trivial, and these things
>don't demand so much CPU power that it makes much of a difference if
>they're very tightly optimised or not.
I've written a scripting language (a terminal control language). The
terminal control program itself was written in C, and the scripting
language compiled to a bytecode executed by my terminal control program.
Flex and bison saved vast amounts of time and aggro when it came to
making the script language.
But if I had to do it all again, I'd have written it such that Perl or
Python would have been the scripting language - the terminal controller
would have been a perl module instead of a C program (I wrote it as
a C program because I could make it a small standalone exe, but given
the cheapness of CD-R disks, in hindsight Perl or Python would have
been a much better choice, and I'd have got a very powerful scripting
language to write the terminal control macros in for free)
Dylan Smith
>No this is more trivial than crap design. if i add an argument to
>a function i need to search for every call [in my huge codebase]
>and fix it, or i find out later at runtime.
Doesn't Python have the equivalent of Perl's "use strict" and -w
interpreter flags which throw compile errors for this sort of thing?
Dylan Smith
<knightsofspam...@gvdnet.dk> wrote:
>compile-time check can save you from. That being said, your argument
>does have merit, even if ordinary good engineering practices would
>make it a moot point. Of course, ordinary good engineering practices
>aren't always very ordinary. (That'll be Snaar's que to rant about
>'fucking computer scientists' again...)
But on this one, the 'fucking computer scientists' have it right.
I've worked on a _very_ large project where we did all of that stuff
(automated regression testing, proper design with peer reviews, following
a proper software development process). Following our process, not only
could we estimate coding effort with a degree of accuracy I didn't think
possible, we had a very low defect count. Software engineering processes
_work_, even if they are not particularly fun.
Martin Christensen
Hash: SHA1
>>>>> "Dylan" == Dylan Smith <dy...@vexed2.alioth.net> writes:
Dylan> But on this one, the 'fucking computer scientists' have it
Dylan> right. I've worked on a _very_ large project where we did all
Dylan> of that stuff (automated regression testing, proper design with
Dylan> peer reviews, following a proper software development
Dylan> process). Following our process, not only could we estimate
Dylan> coding effort with a degree of accuracy I didn't think
Dylan> possible, we had a very low defect count. Software engineering
Dylan> processes _work_, even if they are not particularly fun.
Oh, I quite agree. If you want some non-trivial task to be done fast,
use automated testing (I use unit testing because it's what I've had
exposure to; can't really say much about other methods). I feel much
the same about consistent use of unit testing as I do about exercising
(physically): it's not always a lot of fun, but it always pays off,
and whenever I neglect it, I always end up regretting it.
Martin
- --
Homepage: http://www.cs.auc.dk/~factotum/
GPG public key: http://www.cs.auc.dk/~factotum/gpgkey.txt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Using Mailcrypt+GnuPG <http://www.gnupg.org>
iEYEARECAAYFAj7mAQsACgkQYu1fMmOQldUKLQCghe77S95xlUBXl5py3JaLa+vv
AV8AoLlMDfJ8rDMzcVLHXs2Clb10p/XF
=jg/u
-----END PGP SIGNATURE-----
Havok
hijacked the computer of Martin Christensen
<knightsofspam...@gvdnet.dk> and wrote:
>Development time and flexibility in situations where you just want to
>try some quick changes are the really big advantages of using
>high-level languages like Python. For game development in particular,
>the only reason I can think of that makes Python more appealing than
>any other language is its support for external libraries. I'm sure
>there are plenty of other high-level languages that would be good for
>such tasks.
I'm not sure how good Python is for game development, I've been
following Pygame mailing list for quite some time now and there are a
lot of people using it for this. The thing that always put me off
using pygame was a lack of a GUI system.
>Depends on what you're trying to accomplish. Sometimes cannot avoid
>the slowness of an interpreted language. For instance, if you have a
>couple of nested loops inside which you don't do all that much, the
>overhead of performing the loop itself will be much more significant
>than if you wrote it in C. On the other hand, I doubt that I could
>write the program I've developed for my Master thesis much faster in
>any other language than Python, since the majority of the processing
>time is spent juggling references to objects and manipulating strings.
Well if you have a lot of nested loops in which you don't do a lot of
stuff mabye you should tethink your algorithm.
>Havok> Although I admit sometimes I have to write some code in C for
>Havok> performance, I just write a stub for the code and use it from
>Havok> Python anyway.
>
>That makes sense as a small part of a greater solution, but if Python
>is only used to add the last few pieces of logic, I'm inclined to
>agree with Serguei. There's no need to be religious about one's choice
>in language, though he does indeed seem to be.
Not sure if you need to be *religious* about a language but I don't
think it makes a lot of sense to use too many languages at the same
time. YMMV but when I was at uni and there were projects in Java, C,
Smalltalk, Prolog and Lisp around the same time it gives me problems
switching between them.
More importantly I tend to build up a code library for languages I
work with, the more I work with a language the better my library gets,
if I switch language often then I end up rewriting the same algorithms
in different languages which I think is a waste of time (mostly,
although there are some benifits).
Most of my library is in C which gives me problems when I'm using
languages such as Java. I used TCL for a while but it becomes too
cumbersome (sp?) when the code gets large, I don't find it very
maintanable either. The final straw was the "Everything is a string,
unless it may look like a decimal number, unless it looks like an
octal number, unless ..." situation with TCL. I decided to choose Perl
or Python instead, I had some Perl experience, no Python.
I chose Python because code written by almost anyone seemed to be
readable and understandable, not so with Perl. But perl has CPAN which
is a definate plus, I often consider going gung-ho on Perl for a few
months but don't want to turn my mind into the twisted wasteland of
the professional Perl programmer.
>Havok> I have fuck all spare time now and if I decide to program
>Havok> something then I'm definatly going to use Python, no doubt at
>Havok> all.
>
>Having just turned in my thesis, I now have some time again. Python is
>my primary language, but I've decided to start developing my skills in
>some other language, probably Scheme or ML in order to help me think
>outside of the usual imperative box. Sure, you can whip up a solution
>to a simple problem in Python in no time, but if you want to make it
>maintainable, it's only about twice as fast to develop in as, say,
>C++.
Good idea whilst you have the time, I like to program in HUGS now and
then but it often reminds me how much I like other languages :) I like
the functional model but I can't do without my side-effects now and
then, and the odd dirty global variable.
Depending on how large the project is 50% time saving can be quite a
bit. I tend to think I save more than 50% overall because I find it
easier to integrate the testing easily. I find Java quite easy to do
this with as well but I don't really like the language as much as
Python.
IMHO documentation is the real time killer anyway, there's no easy
solution to this either. Java goes some way to fix this with Javadoc
(which is a step good up from c2man) but often your company has some
legacy way of documenting that must be used. Don' get me started on
user manuals, oh Jesus noooo.
>Havok> At work estimates are always done by others based on C or
>Havok> Java, I can almost almost always complete the work before the
>Havok> deadline, often long before it, with less bugs.
>
>Bugs is where I really save time with Python. I find that I have much
>fewer bugs overall than in most other languages, and more importantly,
>they tend to be quite shallow. Only in ELisp do I make fewer bugs.
Hmmm, I like the way hashtables and lists are as easy to use as an
integer. I like that I don't need method / function calls to use them
because the syntax is in the language, I like that I can subclass them
and still use the native syntax, or that I can define my own class
which is not a subclass and still use the syntax. I also really like
that subclasses and subtypes are not the same thing, more Smalltalk
style than Java.
>Havok> I know that C compilers have years of optimization work in them
>Havok> that Python won't achive, but I doubt the game BASICs can
>Havok> achive them either, unless they are compiled to C first.
>
>Well, BASIC can sometimes be compiled, and it doesn't have the
>overhead of dynamic type checking. There's an optimising compiler for
>Windows, I've been informed, that does a very good job, but there are
>still some things for which a language like Python will never run as
>quickly as some other languages. That rarely matters, though.
Well thats what people said about Java and now it outperforms C in
some tasks. It's not just about execution speed, it's really easy to
say "A perfectly written C program that does X will work faster than a
perfectly written Python program that does X" but programs are never
"perfectly written" a better example is which will be faster when the
development hours are limited, e.g. if you have 300 development hours
to solve problem X it's very possible that the C program could end up
slower.
Another example is microthreads, it's easy for me to run several
hundred-thousand "threads" on my python machine, they run very fast
using generators and the paradigm is quite useable. I'm not sure how
well C would fare in that situation, without building your own
execution table which is not so elegant (but reasonably equal in
technique).
cheers
John Jordan
<knightsofspam...@gvdnet.dk> writes
>
>Ah, I've only worked with simulations, never games directly, and
>assumed that they would have a shared foundation what physics are
>concerned. I assumed that it was mostly only necessary to cut corners
>on graphics as such.
Nah. Collisions, sensor detection and AI interaction are all naturally
O(N^2) or worse. Graphics are at least O(N) most of the time, and you
can drop the detail if the frame rate gets too low. Terrain and other
detail-generation routines will happily consume as much CPU as you have
available, whatever they're written in.
>If by non-trivial parts you mean the stuff that juggles all the big
>numbers, I'm sure you're right. However, I also consider mission
>scripting, event handling etc. to be non-trivial, and these things
>don't demand so much CPU power that it makes much of a difference if
>they're very tightly optimised or not.
I despise mission-scripting, but that's another story. Note that the
condition-testing part can be pretty CPU-heavy depending on the quantity
and complexity of conditions in play - I'm not sure how that would be
dealt with in a combined Python/C project.
AI scripting in interpreted languages isn't really appropriate unless
it's limited to state-switching.
>Or one might even just
>make a prototype in a HLL like Python first and then reimplement in a
>more efficient language afterwards. The point is merely that mistakes
>will be made, and, in my experience, more mistakes tend to be made if
>you start out at a low level of abstraction. Moreover, since it takes
>significantly longer to code stuff in a LLL than a HLL, prototyping in
>a HLL and reimplementing in a LLL can save time in the long run.
Prototyping is the easy bit anyway as far as technical coding goes,
because you can get away with static allocation, massive usage of global
variables and half-baked setup code. Mind you, many games companies seem
to write their release code like that.
> Of
>course, the ideal solution would be a language with the abstraction
>level of Python or similar and the efficiency of C, but I don't know
>of any suitable language that offers that.
Python would get within the same order of magnitude with a JIT compiler,
but then anyone capable of writing a JIT compiler would probably shout
"Fool! Write it in fucking C!" if you asked :-)
--
John Jordan
apollyo...@yahoo.com
I am building a game creation tutorial database, and I need everyone
from artists and music creators to programmers to come to my site and
write tutorials. My website is jemmy.anyxhost.com
please, spread the word
Optimus Prime
You'll want SubNetZero then.
GW
Oh be nice., He did say 'please'!
Although sadly I think most people, when busy writing stuff for the
interwebnetwork, prefer to add it
as content to their own websites than someone elses!
--
Transmitted from a GalNET terminal
The Galactic Network of Explorers and Traders
