On Tuesday, Mar 18, 2003, at 11:40 America/New_York, Gerrit Holl wrote:
I said you gain very little from the pure C approach.. with the hybrid approach that I'm recommending, you write as much as possible in pygame, then profile your code to see what's slow, and write that in C (try psyco first, and see if that does enough).Bob Ippolito schreef op dinsdag 18 maart om 16:22:25 +0000:How about speed?Has anyone on this list used Pygame to learn and then moved to C and sdl, and if so what was it like? is it worth it.You gain very little from this approach.
http://pygame.org/docs/tut/newbieguide.html states:
There are two cases where this technique just won't work. The first is where the whole window or screen really is being updated every frame - think of a smooth-scrolling engine like an overhead real-time strategy game or a side-scroller. So what do you do in this case? Well, the short answer is - don't write this kind of game in pygame. The long answer is to scroll in steps of several pixels at a time; don't try to make scrolling perfectly smooth. Your player will appreciate a game that scrolls quickly, and won't notice the background jumping along too much.
I have totally ignored the short answer because I found it very unconvincing.
I am currently scrolling at 10 pixels per time, but that still is 10 pixels
per frame. This puts a large pressure on game speed. Is it then purely because
of my lack of programming expierence that my game runs slow on P3 while
Commander Keen runs fast on a 286, or are there more issues?
Is DOS faster because of direct hardware? Games run smooth for Linux, too.
Or is Pygame not suitable?