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

Re: [pygame] Advice on Game Engine



Mike Wagman wrote:

The basic problem with using any toolkit is there is always something in
there using resources that you never use.


I've heard alot of good things about OpenGL and pygame but have never
tried it myself- it's on my list to learn. (along with C to integrate
the two)

On the user interface - you will probably need to code your own. There
are some out there but they have the reputation of being somewhat bulky.

The biggest advantage of sprites is grouping and collisions if you need
those use sprites.





OpenGL is pretty cool imho, and i really don't think that it's draining on resources.

Maybe it takes a bit longer to initialize, but after you're in, you have only benefits.

Almost every PC on today's Desktops has an OpenGL - compatible 3d card in them, let it be an old nvidia riva or 3dfx card or anything like that. Even if they don't rock with todays 3D - Games anymore, they're surely able to blit some lousy quads with your textures / images / sprites on them at BLAZING!!! speed. And smoooooooth... drool... I did an attempt at an OpenGl - Accelerated 2d thingie once.

The good thing is, once you loaded an image (or "Surface") into the Graphic Card as an OpenGL texture, it stays there until you delete it and can be blitted dozens of times each frame and you would still get fps in the hundreds.

So, for a Mario type game (example), you'll load one texture 'brick', one 'floor', one 'sky', one 'cloud', one 'mario', 'turtle', etc... each with alpha transparency... then you'll check your map, and put the quads on the screen where you want them, you'll have maybe 200 quads on the screen each time, render the frame, and it's REALLY quick (if i remember correctly). Or you just blit a tile more then needed around the borders of the screen and only have to move your camera, adding rows of tiles when you get to the border of the former offscreen tiles...

...

Ok, i'm babbling, but i just think that OpenGL is GREAT for 2d stuff, and you could always extend your 2d stuff with little 3d effects, think of stuff zooming into / out of the game, particle effects, lightning effects etc.

I think i'll have to get back to my tileengine project soon... can't... resist...

As for sprites, it should be easy to subclass / extend the pygame sprite classes to use openGL sprites instead of surfaces or just write your own one.

...

One problem i had when i tried to build my own 2d sprite engine was that it got too compley really fast... like, i tried to build an event - driven system as described in

http://sjbrown.ezide.com/games/writing-games.html

, but it got out of hand really quick. I guess i'll have to refactor a lot and get a 'big picture' over the whole complex.

I remember having thought 'there really should be an event mechanism implemented in python', either in the language or as an easy - to - use - extension. Has anyone advice on keeping python event driven programming simple and clear?