Re: [pygame] PyGame / PyOpenGL Example

[Ian Mallett]

That would explain weird problems people have had with my code...

Re: [pygame] PyGame / PyOpenGL Example

[Greg Ewing]

David wrote:


Do you have an algorithm as to how to automatically divide an
arbitrary rectangle into a near-optimal set of smaller power-of-two
rectangles?


For an exact subdivision, decompose each of the coordinates
into powers of 2 (which is easy, just look at the bits) and
take all the pairwise combinations of widths and heights.

You might want to impose some minimum size on the pieces,
though, to avoid creating ridiculously small fragments.

--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury,  | Carpe post meridiem! |
Christchurch, New Zealand  | (I'm not a morning person.)  |
[EMAIL PROTECTED]  +--+

Re: [pygame] PyGame / PyOpenGL Example

[Brian Fisher]

On Thu, Feb 14, 2008 at 5:42 AM, David <[EMAIL PROTECTED]> wrote:
>  Do you have an algorithm as to how to automatically divide an
>  arbitrary rectangle into a near-optimal set of smaller power-of-two
>  rectangles?
>
I've never written one myself - I've seen somebody else's code (I
think it might have been the popcap framework) that split stuff into
at most 4 textures only did a split only if the image was > .5 and >=
.75 of the next higher power-of-2 - so like 800 would stick with 1024
cause 512 + 256 < 800, but 600 would become 512 + 128 cause 512 + 256
> 600. In that case it would save like 30% of the memory usage of the
alternative (1024x1024 texture), and it also puts an upper bound on
the waste per image to be like 69%, as opposed to 400%.

I suppose it would be very simple to write a nice recursively defined
algo - basically where the function can be asked to decide how to
split some quad (either vertical horizontal or both) and when it does
split it would call itself on the leftovers as appropriate. I would
guess that you just put in some practical limit as the decision to
split in terms of pixel or percentage waste (to have 0 waste in the
crazy bad case of a 511x127 image you would have 9x7=63 textures for
that one image, while 1 texture would only be 1% waste - and you may
start getting occasional seams on some cards cause of floating point
issues on coords)


>  I am the author of Lamina, and just have never worried about
>  optimizing the texture usage.  Now that it has my attention, the
>  mapping of multiple subtextures into one continuous panel seems
>  straightforward, but choosing the subtexture sizes to start with is
>  not obvious.  I suppose I could just premap all the common full-screen
>  window sizes by hand, and then nearest-fit any other window sizes.
>
It's probably not important if you haven't found a case where it's
important. Compared to the weirdness that happens when you don't
address the power-of-2 problems at all (stuff like large white
textures or invisible content or slow performance on some machines,
like Richard mentioned)  it's small beans.

Re: [pygame] PyGame / PyOpenGL Example

[Brian Fisher]

On Wed, Feb 13, 2008 at 10:10 PM, Kris Schnee <[EMAIL PROTECTED]> wrote:
>  So, if I wanted to draw a GUI window across the screen, and I'd normally
>  want it to be, say, 800x200, I'd have to either split it and draw two
>  textures, or make the texture 1024x256, or just draw a polygon with
>  shading provided by OpenGL and use that as the window?
>
well I would think that in the general case redrawing the components
of the window would be the best solution - along the lines of the
third thing you mentioned - drawing a filled polygon (or maybe more
likely a quad). I don't think you'd want to use shading (i.e. lighting
off), and if you wanted to use power-of-2 textures as tiling for the
body of the window you could do that by setting the texture mode to
wrap. You could also draw window borders either by stretching or
tiling edge images.

If however you had a GUI that changed relatively little and already
performed well in Software rendering, doing the Lamina overlay
approach would probably be just as good. In fact it would be superior
if the gui overlay wasn't changing from frame to frame.

As far as whether to put your images in the next largest power-of-2
texture, or spread across multiple textures or packing multiple images
in a texture or whatever - I would say unless it sounds fun to write
the code to try one approach, the best thing is to make the problem
easy and just do the image in a larger texture thing. Then you can
optimize things later - if you need to. If you unload textures when
you don't need them (like after every level), or have fairly small art
requirements it will probably never be an issue.

Re: [pygame] PyGame / PyOpenGL Example

[Greg Ewing]

Ian Mallett wrote:
Strangely enough, I've never had problems using textures which are not a 
standard size.  Any idea why?


Some OpenGL implementations support non-power-of-2 sizes
(I believe it's one of the officially sanctioned extensions)
but not all. You're probably lucky enough to have one that
does -- but don't rely on your code working for other people.

--
Greg

Re: [pygame] PyGame / PyOpenGL Example

[Greg Ewing]

Brian Fisher wrote:

On Feb 13, 2008 3:43 PM, René Dudfield <[EMAIL PROTECTED]> wrote:


Have you seen the Lamina code?
http://pitchersduel.python-hosting.com/browser/branches/Lamina/


I would guess that it would perform poorly if you
wanted a lot of moving/animating pygame surfaces drawn all over.


You don't have to redraw the whole overlay -- you can just
update selected parts of the texture and redraw those, e.g.
the bounding rectangles of your sprites.


Also,
it appears to take the approach of putting the overlay into a subset
of a power of 2 texture.


I don't see much disadvantage in that, other than perhaps
wasting a bit of video memory. The unused parts of the
texture are never touched once the texture has been set
up.

And if you're clever, you may find something useful to
pack into the otherwise unused areas.

It's probably not the best in all cases, but the Lamina
approach has the advantage that it's very simple and
requires little modification of the techniques one
uses in normal 2D pygame apps. So it's often possible
to use one of the existing pygame gui libraries with
it almost unchanged.

--
Greg

Re: [pygame] PyGame / PyOpenGL Example

[David]

On 2/13/08, Brian Fisher <[EMAIL PROTECTED]> wrote:

> 2. spread images across multiple textures and draw all of them (so the
> 24x12 image would be spread across 4 textures, a 16x8, an 8x8, a 16x4
> and an 8x4) which lets you draw more polys in order to not waste so
> much video memory

Do you have an algorithm as to how to automatically divide an
arbitrary rectangle into a near-optimal set of smaller power-of-two
rectangles?

I am the author of Lamina, and just have never worried about
optimizing the texture usage.  Now that it has my attention, the
mapping of multiple subtextures into one continuous panel seems
straightforward, but choosing the subtexture sizes to start with is
not obvious.  I suppose I could just premap all the common full-screen
window sizes by hand, and then nearest-fit any other window sizes.

David

-- 
[EMAIL PROTECTED]
Pitcher's Duel -> pitchersduel.python-hosting.com

Re: [pygame] PyGame / PyOpenGL Example

[Richard Jones]

On Thu, 14 Feb 2008, Brian Fisher wrote:
> support for non-power of 2 texures is pretty much standard for recent
> graphics cards

Note that there can be a *significant* performance penalty when using some 
cards / drivers.


Richard

Re: [pygame] PyGame / PyOpenGL Example

[Brian Fisher]

On Wed, Feb 13, 2008 at 10:16 PM, Ian Mallett <[EMAIL PROTECTED]> wrote:
> Strangely enough, I've never had problems using textures which are not a
> standard size.  Any idea why?
>
I assume by "standard size" you mean non-power of 2... you probably
have no problem with it because all the machines you've worked with
have openGL 2.1 drivers and/or drivers with
ARB_texture_non_power_of_two enabled (glGetString(GL_EXTENSIONS) will
tell you what extensions you have - but as Rene found out for me,
don't call it before creating your window on Mac OSX)

support for non-power of 2 texures is pretty much standard for recent
graphics cards ...provided the user is running opengl drivers from the
card manufacturer (probably because it's part of the 2.1 standard) but
one notable place support is missing on windows is Vista's standard
OpenGL 1.4 implementation. It probably doesn't have that support
because it maps to Direct3D, where support for such textures is still
optional.

On Mac OSX, I *think* it's standard as of the machines that came out
about the 10.4/Intel change era

Re: [pygame] PyGame / PyOpenGL Example

[Ian Mallett]

Strangely enough, I've never had problems using textures which are not a
standard size.  Any idea why?

Re: [pygame] PyGame / PyOpenGL Example

[Kris Schnee]

Brian Fisher wrote:

... Also, I have to say that at first I thought it would be a "Royal
Pain" to have to deal with rendering 2d stuff in openGL - but it
actually turned out to be much easier than I thought and kind of a lot
of fun (although I may have more pain later I suppose). The only thing
that isn't trivially simple, in my opinion, is figuring out how you
want to deal with texture size limitations. In particular, on the
majority of systems out there, textures have to be a power-of-2 in
width and height - so you have to deal with that to upload say a 24x12
image for blitting. The 3 basic approaches are:
1. overallocate textures and render just the portion of the texture
that has an image (so that 24x12 image would be on a 32x16 texture and
would render just texcoords (.0,.0)-(.75,.75)), which will waste about
50% of your video memory and possibly cause extra texture thrashing,
but actually some commercial games ship this way cause it just never
ended up being a problem for their game.
2. spread images across multiple textures and draw all of them (so the
24x12 image would be spread across 4 textures, a 16x8, an 8x8, a 16x4
and an 8x4) which lets you draw more polys in order to not waste so
much video memory
3. pack multiple images into a single texture - the attached example
uses that approach. It can be pathologically bad in terms of memory
thrashing in some cases (like say if you wanted to draw one image each
from 100 large multi-image textures) but if images that are used
together are in a texture together, it is actually the optimal
approach in terms of performance (like it tends to be good to make
sure font characters are all packed in textures together)


Thanks for the code.

So, if I wanted to draw a GUI window across the screen, and I'd normally 
want it to be, say, 800x200, I'd have to either split it and draw two 
textures, or make the texture 1024x256, or just draw a polygon with 
shading provided by OpenGL and use that as the window?

Re: [pygame] PyGame / PyOpenGL Example

[Ian Mallett]

On Feb 13, 2008 4:02 PM, Greg Ewing <[EMAIL PROTECTED]> wrote:

> In my experience, doing anything in 3D is very hard work,
> and if you don't tackle the most important parts first,
> there's a danger of running out of steam before you
> get it finished.
>
  Greg is correct.  Do the most important stuff first, even though it is
often annoying to work on the basecode when you really want to write the fun
parts.  If you try to hang the game on a non-existent skeleton, you will
have problems.  And, continuing the metaphor, putting the skeleton in after
assembling the outside requires destroying parts of the skin and organs.  It
is also less efficient, reliable, and it takes longer.  Just do the basecode
first.

  Also, you must make sure you do it right.  Skeletal problems are hard to
fix later.  In particular, the draw function in which you implement the
camera is by far the most important.  Problems here can affect your code
horribly later.  Make sure it is right.  I recommend writing it by drawing a
simple object (say, a cube) and then build the code, constantly testing.  It
hurts in the short term, but it will pay off in the long run.

Ian

Re: [pygame] PyGame / PyOpenGL Example

[René Dudfield]

yeah, I think there are a couple of approaches.

Lamina takes the first approach... which is to make almost everything
work - just by updating dirty rects.  So you render to an offscreen
surface.  As long as you are careful with dirty rects - it should be
fairly fast, and not very complex.  Mainly to be able to use software
rendering in your opengl app.

However for lots of moving images, it's probably not the fastest way -
which is where your approach is better.


At one point a few years ago I tried to make a spritegl class - that
wasn't very sophisticated, but worked ok for basic games.  It's in
http://rene.f0o.com/rdpyg/ but it doesn't work on all games.  The idea
was to do it at the sprite level so you can optimize things like
drawing 20 sprites at once etc.  I found it ran mostly slower than SDL
- but it was really badly written, mostly as a prototype.  Both your
code, and Lamina are better.

It would be nice if pygame.sprite was more hardware friendly.  So
things like rotation, and scaling were abstracted.

Also note, that SDL 1.3 has pretty good opengl, and direct 3d
support... they basically use the idea of hardware surfaces for their
abstraction.  You can run some demos already, and it's interesting to
look at that API.


Also, here is some code to make opengl act like it's in 2D.  So you
can draw things using pixel coordinates, rather than 3d coordinates.

http://pygame.org/wiki/MakeOpenglDrawIn2D

def glEnable2D():
""" make opengl behave like you are drawing in 2d."""
vPort = glGetIntegerv(GL_VIEWPORT)
glMatrixMode(GL_PROJECTION)
glPushMatrix()
glLoadIdentity()
glOrtho(0, vPort[2], 0, vPort[3], -1, 1)
glMatrixMode(GL_MODELVIEW)
glPushMatrix()
glLoadIdentity()



def glDisable2D():
   """ Use when you've finished drawing in 2D.   """
   glMatrixMode(GL_PROJECTION)
   glPopMatrix()
   glMatrixMode(GL_MODELVIEW)
   glPopMatrix()





cu,


On Feb 14, 2008 12:22 PM, Brian Fisher <[EMAIL PROTECTED]> wrote:
> On Feb 13, 2008 3:43 PM, René Dudfield <[EMAIL PROTECTED]> wrote:
> > Have you seen the Lamina code?
> > http://pitchersduel.python-hosting.com/browser/branches/Lamina/
> >
> I hadn't seen it before - It appears to take the approach of
> maintaining a single full-screen overlay which is created from a
> pygame surface. I would guess that it would perform poorly if you
> wanted a lot of moving/animating pygame surfaces drawn all over. Also,
> it appears to take the approach of putting the overlay into a subset
> of a power of 2 texture.
>
>
> > It'd be nice to be able to get one of these into the pygame
> > examples... or onto the cookbook.  Especially if it can be used to run
> > existing games (with a little modification).
> >
> It sounds fun to write something like that up - should the goal be
> something that is close to a drop in replacement for pygame.display
> stuff? maybe with some additional interface for getting transformed
> and colored blits or something?
>

Re: [pygame] PyGame / PyOpenGL Example

[Brian Fisher]

On Feb 13, 2008 3:43 PM, René Dudfield <[EMAIL PROTECTED]> wrote:
> Have you seen the Lamina code?
> http://pitchersduel.python-hosting.com/browser/branches/Lamina/
>
I hadn't seen it before - It appears to take the approach of
maintaining a single full-screen overlay which is created from a
pygame surface. I would guess that it would perform poorly if you
wanted a lot of moving/animating pygame surfaces drawn all over. Also,
it appears to take the approach of putting the overlay into a subset
of a power of 2 texture.


> It'd be nice to be able to get one of these into the pygame
> examples... or onto the cookbook.  Especially if it can be used to run
> existing games (with a little modification).
>
It sounds fun to write something like that up - should the goal be
something that is close to a drop in replacement for pygame.display
stuff? maybe with some additional interface for getting transformed
and colored blits or something?

Re: [pygame] PyGame / PyOpenGL Example

[Brian Fisher]

On Feb 13, 2008 4:28 PM, Greg Ewing <[EMAIL PROTECTED]> wrote:
> There's also
>
> 4. Scale the texture image so that it has power-of-2 sizes
>
> which may work well enough for photographic images and such
> like where you're not too concerned about the appearance of
> fine details.
>
I've heard that approach suggested before, but In my opinion, that
approach is either inferior or equivalent in every respect to approach
1 that I mentioned (putting the image in a portion of a power of 2
texture, and draw from a subset of the texture)

The reasons why are:
1. They both take up exactly the same amount of video memory
2. Performance is worse for the scaled one because when drawing only
the original image pixels from a subset of the texture the video card
only has to lookup and filter those original pixels, but when the
image was scaled now the video card has to lookup and filter
additional pixels (it would tend to be around 2x the mem lookup)
3. Quality is worse for the scaled one, especially when rendering at
the original image size - even if you got a super awesome up scale
(like blackman or something) going into the texture, you are still
getting a bilinear filter on the rendering
4. Time to load images to the card is (ever so slightly) worse with
the scaled one, cause you have to do the scale
5. You have to write/utilize more code in the scaling case

For that reason, I would say there are only 3 sensible approaches to
the images to power-of-2 texture mapping problem, that I am aware of.

Re: [pygame] PyGame / PyOpenGL Example

[Greg Ewing]

Brian Fisher wrote:

textures have to be a power-of-2 in
width and height - so you have to deal with that to upload say a 24x12
image for blitting. The 3 basic approaches are:


There's also

4. Scale the texture image so that it has power-of-2 sizes

which may work well enough for photographic images and such
like where you're not too concerned about the appearance of
fine details.

--
Greg

Re: [pygame] PyGame / PyOpenGL Example

[Greg Ewing]

Kris Schnee wrote:

Maybe I'm answering my own question here. I'm basically looking for eye 
candy instead of focusing on the gameplay concepts I want to develop.


It's probably better to focus on getting the gameplay right
before going after eye candy. Maybe prototype the whole
thing in 2D first.

In my experience, doing anything in 3D is very hard work,
and if you don't tackle the most important parts first,
there's a danger of running out of steam before you
get it finished.

--
Greg

Re: [pygame] PyGame / PyOpenGL Example

[René Dudfield]

Very cool :)


Have you seen the Lamina code?
http://pitchersduel.python-hosting.com/browser/branches/Lamina/

btw, I had to comment out this line, which seems to be fcked on
pyopengl cvs.  Otherwise it segfaulted.
#print glGetString(GL_EXTENSIONS)

I also get this on exit:
Exception exceptions.TypeError: "'NoneType' object is not callable" in
> ignored


It'd be nice to be able to get one of these into the pygame
examples... or onto the cookbook.  Especially if it can be used to run
existing games (with a little modification).



cheers,




On Feb 14, 2008 10:14 AM, Brian Fisher <[EMAIL PROTECTED]> wrote:
> attached is an example of one way to draw pygame surfaces in OpenGL.
> It's originally a piece of a larger library, so I tried to rip out
> dependencies on that library. It exports a "Display" class which takes
> over creating the pygame display and can blit objects which have 4
> attributes on them - surface (pygame surface), width, height and
> hotspot (2 element sequence saying where the center of the image is).
> When things are blit, the Display class adds attributes to the object
> to track GL texture info. If you run it, it shows itself working (if
> __name__=="__main__": thing)
>
> It doesn't show how to print text (my class for that was too hairy to
> extract) but the approach I take is to have pygame.font render
> individual characters from strings to surfaces as needed and store
> them in dict (so they won't be regenerated all the the time), and then
> blit the cached surfaces for each letter in the string to the display
>
> There are 2 somewhat unusual things about this code - first is it
> uploads the textures as "premultiplied-alpha" or what it calls
> Light-Opacity model, where the blend mode is GL_ONE,
> GL_ONE_MINUS_SRC_ALPHA - the reason for that is that its the only way
> to get GL's bilinear filtering math to be accurate (so you don't
> introduce edge artifacts by blending color's that are supposed to be
> transparent - the yellow blocks in the exampleGL.py would have brown
> edges if it used Color-Opacity RGBA). The other weird thing is it has
> some 2d motion blur stuff.
>
> ... Also, I have to say that at first I thought it would be a "Royal
> Pain" to have to deal with rendering 2d stuff in openGL - but it
> actually turned out to be much easier than I thought and kind of a lot
> of fun (although I may have more pain later I suppose). The only thing
> that isn't trivially simple, in my opinion, is figuring out how you
> want to deal with texture size limitations. In particular, on the
> majority of systems out there, textures have to be a power-of-2 in
> width and height - so you have to deal with that to upload say a 24x12
> image for blitting. The 3 basic approaches are:
> 1. overallocate textures and render just the portion of the texture
> that has an image (so that 24x12 image would be on a 32x16 texture and
> would render just texcoords (.0,.0)-(.75,.75)), which will waste about
> 50% of your video memory and possibly cause extra texture thrashing,
> but actually some commercial games ship this way cause it just never
> ended up being a problem for their game.
> 2. spread images across multiple textures and draw all of them (so the
> 24x12 image would be spread across 4 textures, a 16x8, an 8x8, a 16x4
> and an 8x4) which lets you draw more polys in order to not waste so
> much video memory
> 3. pack multiple images into a single texture - the attached example
> uses that approach. It can be pathologically bad in terms of memory
> thrashing in some cases (like say if you wanted to draw one image each
> from 100 large multi-image textures) but if images that are used
> together are in a texture together, it is actually the optimal
> approach in terms of performance (like it tends to be good to make
> sure font characters are all packed in textures together)
>
> I hope the example helps - also I'm interested in ways people think
> this code could be improved.
>
>
>
> > On Tue, 12 Feb 2008 23:23:49 +1030, fragged <[EMAIL PROTECTED]>
> > wrote:
> > Hey guys,
> >
> > I've been searching for some decent examples of PyOpenGL to help me port
> > my current application to OpenGL to speed things up on my perty new
> > 1920x1200 LCD (Getting about 20fps, using no acceleration whatsoever),
> > however I've been unable to find any decent guides on the net that
> > simply show me how to do the equivalent of loading an image and some
> > text - the small fragments I have found have still been using PyGame to
> > render text and this seems to break on my gentoo system whilist working
> > on another and I'm not really sure if this is the /propper/ way to do it.
> >
> > would somebody have one of these laying about, know of one or be able to
> > hack one up for me? It'd be a great help and I'd also love to see it go
> > in the examples directory on PyGame.org as there seems to be very few
> > extreme beguinners guides.
> >
>

Re: [pygame] PyGame / PyOpenGL Example

[Brian Fisher]

attached is an example of one way to draw pygame surfaces in OpenGL.
It's originally a piece of a larger library, so I tried to rip out
dependencies on that library. It exports a "Display" class which takes
over creating the pygame display and can blit objects which have 4
attributes on them - surface (pygame surface), width, height and
hotspot (2 element sequence saying where the center of the image is).
When things are blit, the Display class adds attributes to the object
to track GL texture info. If you run it, it shows itself working (if
__name__=="__main__": thing)

It doesn't show how to print text (my class for that was too hairy to
extract) but the approach I take is to have pygame.font render
individual characters from strings to surfaces as needed and store
them in dict (so they won't be regenerated all the the time), and then
blit the cached surfaces for each letter in the string to the display

There are 2 somewhat unusual things about this code - first is it
uploads the textures as "premultiplied-alpha" or what it calls
Light-Opacity model, where the blend mode is GL_ONE,
GL_ONE_MINUS_SRC_ALPHA - the reason for that is that its the only way
to get GL's bilinear filtering math to be accurate (so you don't
introduce edge artifacts by blending color's that are supposed to be
transparent - the yellow blocks in the exampleGL.py would have brown
edges if it used Color-Opacity RGBA). The other weird thing is it has
some 2d motion blur stuff.

... Also, I have to say that at first I thought it would be a "Royal
Pain" to have to deal with rendering 2d stuff in openGL - but it
actually turned out to be much easier than I thought and kind of a lot
of fun (although I may have more pain later I suppose). The only thing
that isn't trivially simple, in my opinion, is figuring out how you
want to deal with texture size limitations. In particular, on the
majority of systems out there, textures have to be a power-of-2 in
width and height - so you have to deal with that to upload say a 24x12
image for blitting. The 3 basic approaches are:
1. overallocate textures and render just the portion of the texture
that has an image (so that 24x12 image would be on a 32x16 texture and
would render just texcoords (.0,.0)-(.75,.75)), which will waste about
50% of your video memory and possibly cause extra texture thrashing,
but actually some commercial games ship this way cause it just never
ended up being a problem for their game.
2. spread images across multiple textures and draw all of them (so the
24x12 image would be spread across 4 textures, a 16x8, an 8x8, a 16x4
and an 8x4) which lets you draw more polys in order to not waste so
much video memory
3. pack multiple images into a single texture - the attached example
uses that approach. It can be pathologically bad in terms of memory
thrashing in some cases (like say if you wanted to draw one image each
from 100 large multi-image textures) but if images that are used
together are in a texture together, it is actually the optimal
approach in terms of performance (like it tends to be good to make
sure font characters are all packed in textures together)

I hope the example helps - also I'm interested in ways people think
this code could be improved.


> On Tue, 12 Feb 2008 23:23:49 +1030, fragged <[EMAIL PROTECTED]>
> wrote:
> Hey guys,
>
> I've been searching for some decent examples of PyOpenGL to help me port
> my current application to OpenGL to speed things up on my perty new
> 1920x1200 LCD (Getting about 20fps, using no acceleration whatsoever),
> however I've been unable to find any decent guides on the net that
> simply show me how to do the equivalent of loading an image and some
> text - the small fragments I have found have still been using PyGame to
> render text and this seems to break on my gentoo system whilist working
> on another and I'm not really sure if this is the /propper/ way to do it.
>
> would somebody have one of these laying about, know of one or be able to
> hack one up for me? It'd be a great help and I'd also love to see it go
> in the examples directory on PyGame.org as there seems to be very few
> extreme beguinners guides.
>
"""
Implementation of how to render to the display for gl stuff

(C) Copyright 2005 Hamster Republic Productions - but you are free to do whatever you want with this
"""



import pygame
import math
import OpenGL
from OpenGL.GL import *
import weakref
import types
#from motherhamster.imageassets import ImageAsset
#from motherhamster import editorinfo
import array


def GetHigherPowerOf2(value):
return 2**int(math.ceil(math.log(value, 2)))

def UnpackImage(image):
#CHECK: really need to queue up the item for later...
# in a multithreaded envron. this might happen at a bad time
if hasattr(image, "GLtexture"):
texture_pack = image.GLtexture
textur

Re: [pygame] PyGame / PyOpenGL Example

[René Dudfield]

Also note most of the nehe tutorials have been translated to python in
the pyopengl Demo directory.

chairs,

On Feb 14, 2008 7:49 AM, Ian Mallett <[EMAIL PROTECTED]> wrote:
> If you really want to make something nice, even if it is a 2D
> background, your best option is to render a 3D image.
>
> The image you're looking at doesn't look like it was created with a
> heightmap, the simplest way of making 3D terrain, because the texture
> does not appear to stretch.
>
> You can something almost as good by using a heightmap (a heightmap
> codes elevations into pixels.  You can use a tool to make them, like
> "Earth Sculpter", because doing so by hand is inaccurate and slow).
>
> You then convert the image into a mesh of polygons by iterating
> through each pixel.  There some nice tutorials out there for this,
> too.  The mesh is then compiled into a display list for speed.  The
> map is then drawn at the correct location.  The houses, trees, and the
> like in the image you pointed out are made separately, then
> superimposed into the final scene before it is drawn.
>
> All in all, it is a pretty complicated mess.  If you're just beginning
> OpenGL, I recommend the Python NeHe tutorials:
> http://www.pygame.org/gamelets/ as a good introduction.  gamedev.net
> can help you with the finer details.
>
> Ian
>

Re: [pygame] PyGame / PyOpenGL Example

[Ian Mallett]

If you really want to make something nice, even if it is a 2D
background, your best option is to render a 3D image.

The image you're looking at doesn't look like it was created with a
heightmap, the simplest way of making 3D terrain, because the texture
does not appear to stretch.

You can something almost as good by using a heightmap (a heightmap
codes elevations into pixels.  You can use a tool to make them, like
"Earth Sculpter", because doing so by hand is inaccurate and slow).

You then convert the image into a mesh of polygons by iterating
through each pixel.  There some nice tutorials out there for this,
too.  The mesh is then compiled into a display list for speed.  The
map is then drawn at the correct location.  The houses, trees, and the
like in the image you pointed out are made separately, then
superimposed into the final scene before it is drawn.

All in all, it is a pretty complicated mess.  If you're just beginning
OpenGL, I recommend the Python NeHe tutorials:
http://www.pygame.org/gamelets/ as a good introduction.  gamedev.net
can help you with the finer details.

Ian

Re: [pygame] PyGame / PyOpenGL Example

[Kris Schnee]

Richard Jones wrote:

On Wed, 13 Feb 2008, René Dudfield wrote:

Apart from Richards shameless self promotion of pyglet, here's some
other things to look at...


It was more an attempt to dispel the "even in Python" statement :)


Heh. Thanks, both of you.

It looks like with Pyglet I'd need to learn its equivalents to Pygame's 
event handling, although that doesn't look too complex, and in exchange 
I'd get the ability to load textures and draw images and text easily 
while still being able to use standard OpenGL drawing functions. Maybe 
that's worth trying.


I'm having a hard time figuring out which of these many systems is best 
for my purposes, if I'm to do 3D. Am I making a mistake by looking at 3D 
at all? Since I'm working alone I have no ambitions to do full 3D 
animation; basically it'd be a way to represent a landscape with height. 
The terrain I'd like is a simple island landscape with rocks, trees and 
buildings, like this: 
 
Does it make sense to go to the trouble of a 3D engine to get the 
flexibility of being able to look at the terrain from any angle?


Maybe I'm answering my own question here. I'm basically looking for eye 
candy instead of focusing on the gameplay concepts I want to develop.

Re: [pygame] PyGame / PyOpenGL Example

[Brian Fisher]

On Feb 12, 2008 1:51 PM, Richard Jones <[EMAIL PROTECTED]> wrote:
> On Wed, 13 Feb 2008, René Dudfield wrote:
> > Apart from Richards shameless self promotion of pyglet, here's some
> > other things to look at...
>
> It was more an attempt to dispel the "even in Python" statement :)
>
Can't it be both? :)

Re: [pygame] PyGame / PyOpenGL Example

[Richard Jones]

On Wed, 13 Feb 2008, René Dudfield wrote:
> Apart from Richards shameless self promotion of pyglet, here's some
> other things to look at...

It was more an attempt to dispel the "even in Python" statement :)


Richard

Re: [pygame] PyGame / PyOpenGL Example

[René Dudfield]

Apart from Richards shameless self promotion of pyglet, here's some
other things to look at...


Have a look in the Demo directory of pyopengl for many goodies.  It's
an often overlooked place of python opengl code.

If you want to render text in 3d: http://ttfquery.sourceforge.net/

soya, openglcontext, python-ogre, blender, vision egg, visual
python... the all have text stuff.  Have a look here for more goodies:
http://www.vrplumber.com/py3d.py

And here's how to use pygame gui libraries(pgu, ocemp etc) with opengl:
http://pitchersduel.python-hosting.com/browser/branches/Lamina/

There's some easy to use demos included with Lamina using pygame to
render in 2D and only updating the screen as needed.

Also have a look at http://pygame.org/wiki/CookBook  There appears to
be some text things in there too.


Good idea about adding to pygame examples of such a common thing.
Mostly people go to the pyopengl Demo directory for opengl stuff - but
we should put something like this into pygame too.  Maybe Lamina
itself should be included with pygame.

For now the cookbook would be a great place to put examples for this.



cu,




On Feb 13, 2008 7:56 AM, Richard Jones <[EMAIL PROTECTED]> wrote:
> On Wed, 13 Feb 2008, kschnee wrote:
> > Loading images and
> > displaying those and text is a royal pain in OpenGL, even in Python.
>
> The "even in Python" is a little out of date now :)
>
> from pyglet import image, font
>
> # display an image
> im = image.load('image.png')
> im.blit()
>
> # display some text
> t = font.Text(font.load('', 24), 'Hello, world!')
> t.draw()
>
>
>  Richard
>

Re: [pygame] PyGame / PyOpenGL Example

[Richard Jones]

On Wed, 13 Feb 2008, kschnee wrote:
> Loading images and
> displaying those and text is a royal pain in OpenGL, even in Python.

The "even in Python" is a little out of date now :)

from pyglet import image, font

# display an image
im = image.load('image.png')
im.blit()

# display some text
t = font.Text(font.load('', 24), 'Hello, world!')
t.draw()


 Richard

Re: [pygame] PyGame / PyOpenGL Example

[Ian Mallett]

I don't exactly recommend the NeHe tutorials for their nice code, but
there are some nice clear enough python examples.

http://www.pygame.org/gamelets/
Has nehe tutorials 1-10.

I'll write some OpenGL basecode sometime too.

Re: [pygame] PyGame / PyOpenGL Example

[kschnee]

On Tue, 12 Feb 2008 23:23:49 +1030, fragged <[EMAIL PROTECTED]>
wrote:
> Hey guys,
> 
> I've been searching for some decent examples of PyOpenGL to help me port
> my current application to OpenGL to speed things up on my perty new
> 1920x1200 LCD (Getting about 20fps, using no acceleration whatsoever),
> however I've been unable to find any decent guides on the net that
> simply show me how to do the equivalent of loading an image and some
> text - the small fragments I have found have still been using PyGame to
> render text and this seems to break on my gentoo system whilist working
> on another and I'm not really sure if this is the /propper/ way to do it.
> 
> would somebody have one of these laying about, know of one or be able to
> hack one up for me? It'd be a great help and I'd also love to see it go
> in the examples directory on PyGame.org as there seems to be very few
> extreme beguinners guides.


Hey.

I'll look again at my old code later, but for now: Loading images and
displaying those and text is a royal pain in OpenGL, even in Python. For
images you basically need to load a texture and convert it, and I think
there's a restriction on the size or proportion of textures. Drawing stuff
in 2D, as for a GUI, involves switching to an "ortho" mode and either
manually drawing shaded rectangles, or drawing rectangles textured with a
pre-loaded texture. Drawing the text can be done in several ways:
finding/creating a bitmap of a font, or making a bunch of textures out of
an image, or using a stand-alone module like PyGlyph (with which I've had
some success). It's easier to draw a spinning translucent textured cube in
OpenGL than to write "Hello World!" The "ortho" switch is not that hard, at
least; I've got code for that. After much fiddling every so often, I've
been reverting to 2D. Still, I'd like to get a simple 3D landscape with a
sky and "billboarded" sprites, plus the ability to use my GUI with it.

For the moment, try looking up the "NeHe OpenGL" tutorials, the first few
of which are available in Python. (The key parts are pretty much the same
in any language too.) Also look up the "OpenGL RedBook," a version of which
is available free online. I think I put the crude OpenGL code I was using
into the ZIP at , so you
might look at that for ideas.

A(nother) good basic demo of images and text would be great, yeah.

Kris

[pygame] PyGame / PyOpenGL Example

[fragged]

Hey guys,

I've been searching for some decent examples of PyOpenGL to help me port 
my current application to OpenGL to speed things up on my perty new 
1920x1200 LCD (Getting about 20fps, using no acceleration whatsoever), 
however I've been unable to find any decent guides on the net that 
simply show me how to do the equivalent of loading an image and some 
text - the small fragments I have found have still been using PyGame to 
render text and this seems to break on my gentoo system whilist working 
on another and I'm not really sure if this is the /propper/ way to do it.


would somebody have one of these laying about, know of one or be able to 
hack one up for me? It'd be a great help and I'd also love to see it go 
in the examples directory on PyGame.org as there seems to be very few 
extreme beguinners guides.


Oh, and if your looking at 20fps on that resolution thinking that it is 
something else your probbably right. Although there is 
pygame.update.rect() or whatever I'd much prefer something that is 
accelerated both for my understanding of computers and that smooth 60fps 
that I'd be getting :D


Cheers
Fragged aka Colin