[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [pygame] image.load() -->> array?



I've known people who could detect the difference between 100 and 80
fps, so it's possible.  12 fps may be where we decide that we are
seeing movement rather than a cycle of still images, but that doesn't
mean there is no difference beyond that.  If you draw enough stuff,
your framerate will drop like a rock with sdl, no matter how optomized
your algorithm.  You still have to take into consideration other
programming routines that occur besides just drawing.  I am looking
forward to the gl backend for sdl, that should help level the playing
field.  Although opengl isn't really that difficult to learn.

The main problem is that modern video cards aren't designed for 2d
rendering, so the increase in capability doesn't fit that domain.
Standard resolutions have grown well beyond 320x240, but 2d drawing
routines haven't increased nearly as fast.  And every time the
resolution doubles, the amount of the screen being drawn quadruples.

You could always write a game for gameboy, where the tile engine is
built right in to the hardware :)  Although even then I think you have
to fight the framerate eventually.

On 10/25/07, Ian Mallett <geometrian@xxxxxxxxx> wrote:
>     Of course it's pointless to draw nothing.  The framerates are still
> respectable when drawing stuff.  SDL drops to about 40 or 50, OpenGL to
> 60-120 depending on the render method.
>
>     One's eyes "refresh" at about 12 fps, so anything faster than that looks
> fluid.  The amount of smoothness, of course, is dependent on the framerate
> of the screen.  12fps vs. 40fps is a big difference.  After about 60, most
> people can't tell any increase.  I don't care if I can't see it.  It is
> still cool to know that your computer is doing that.
>
> Ian
>