[rtf]

First of, I second the others. By the time I got around to seriously learning programming and specifically game programming I was using Python/Pygame on a 1 gigahertz machine and it gave me about as much power as a 486 would running optimized C code. (more in some instances, less in others) If you're after concepts and not retro-technical details this is a good route to go.

But as for the questions:

1. Threading is not the answer; it was a missing concept on DOS machines. Interrupt polling is what you want to look at. 2. I recall reading about this but never did it myself. These days you're lucky if both the monitor and graphics card support mode 13h. 3. The term you want is "fast rectangle blit". This is still relevant if you use software rendering.

[VinzO]

What are the advantages of an interpreted language for game programming? My idea is that it is probably much slower. I can't see the advantage. Is it that there are a lot of usefull libraries or else? ( I almost don't know python/pygame ).

[nostrademons]

Most games nowadays use a two-tiered architecture: they write the graphics, rendering, collision-detection, and other processor-intensive parts as C libraries, and then do the game mechanics, AI, physics, and other highly-changeable parts in an interpreted scripting language. That way, they get the maintenance advantages of a high-level language without paying the speed penalty.

Also, many people don't realize just how much faster computers are now than they were 10 years ago. As part of the prototyping for my startup, I wrote a couple games in JavaScript, which is roughly 1000 times slower than C. They were generally quite playable, except on Firefox/X-windows where an odd Canvas bug seems to be adding a lot of latency without pegging the CPU. I'd still use Flash if I were doing a production game (JavaScript's timing is inconsistent, with occasional long pauses presumably for garbage collection), but as long as you stick to 2D it's quite feasible to do games entirely in interpreted languages.

[marvin]

The distinction interpreted/compiled is largely moot these days, since most popular interpreted languages are actually compiled (or at least bytecode-compiled) before they are run.

The real question is whether you would want to use a modern, abstract, weakly typed language like Python instead of a strongly typed and machine-code compiled language like C++. The latter is, usually, considerably slower. The decision all depends on how serious you want to get. For small-scale experiments, Python is just fine because it takes half the time and half the effort to write and test a piece of code. Unless you are pushing the limits on how fast you want something to run, Moore's law works in your favor and you can very quickly create something which does what you want and is fast enough. If you need the speed, you will know, but at least then you will have a simple prototype which will keep you from falling in any stupid traps on the way.

So to answer your question, development speed is the factor that makes people want to use these languages. You don't have to jump through hoops unless you need run-time execution speed.

And yes, Python has excellent library support for doing just about anything that doesn't have to be blazingly fast. This, along with better language constructs (more dynamic classes and methods, weak typing, versatile and easy-to-use lists and mappings, list mapping functions etc), is what makes development much faster. Oh, and it doesn't hurt that you can dynamically test the things you've written, if you want to.

[VinzO]

Thanks for your reply. One more question, I am maybe old fashionned, but weak typing kind of scared me. I am more used to strong typing and I find it weird when I look at python variable declaration. In my point of view, strong typing helps avoid bugs and write cleaner programs. What advantages do you see in weak typing?

[jcl]

Some arguments I have seen for dynamic typing:

- Code is shorter and potentially easier to read.

- While static typing can identify some bugs at compile time, these are usually the easiest bugs to find regardless of the language you use. The hard bugs -- the ones not caught by the compiler -- only become obvious through testing. So if you have a good suite of tests, you will find both classes of bugs, whether or not you use a statically typed language.

- In a dynamically typed language, you spend less time wrestling with the typing system -- instead of casting in C or Java, doing long template-related declarations in C++, or convincing ML or Haskell that your program should be allowed to run.

- And, more theoretically, a statically typed language limits the space of programs that you can write. While most of the programs disallowed by static typing are buggy, some are useful, and a statically typed program with the identical useful functionality is longer.

Of course, static typing has its benefits as well. It's the reason our fastest languages are as fast as they are, and it's a comforting safety net, especially in large projects.

[procrastitron]

You have it backwards, actually. Python is strongly typed and C++ is weakly typed. You probably meant dynamically/statically typed.