Skip to main content

Gloss - 0.6

Gloss is a high-performance graphics wrapper around Pygame that lets you take advantage of OpenGL without having to delve into the murky depths of 3D programming. Gloss lets you build 2D games where you can rotate, scale and recolor sprites on the fly, and also includes a selection of helpful mathematics functions to make the life of games coders easier.


Paul Hudson
(hudzilla)

The functionality most people will want to use in Gloss includes:

  • Loading textures, then drawing them to the screen scaled, rotated, translucent and recolored in real time
  • Drawing text to the screen (yes, still with scaling, rotation, etc)
  • Particle systems for common special effects such as fire and smoke
  • Rendering scenes to a texture ("render targets") for complex effects
  • Built-in support for lerping, normalization and scene tinting
  • Easy API calls for anti-aliasing, screenshots, picking and more

Gloss is licensed under LGPLv3, and comes with full documentation, a tutorial and several code examples to help get you started, so if you're looking to make a game quickly and easily give it a try!

Changes

This fixes problems people were having with non-power-of-2 textures, and adds support for joystick control.
pygame 844 2d 783 libraries 151 pyopengl 74 engine 59

Links

Home Page
http://www.tuxradar.com/gloss
Source
http://www.tuxradar.com/files/gloss/gloss0.6.tar.gz

Releases

Gloss 0.5 — 8 Jun, 2009

Gloss 0.6 — 23 Jun, 2009

Gloss 0.7 — 30 Sep, 2009

Gloss 0.8 — 21 Oct, 2009

Gloss 0.81 — 22 Oct, 2009

Gloss 0.85 — 23 Jan, 2010

Gloss 0.9 — 28 Mar, 2010

Pygame.org account Comments

  • Mad Cloud Games 2011-07-16 19:19

    First of all, Really cool and i started out interested in this. But after some profiling on a phenom II dual core and a radeon 5770, it looks like pygame.surface.blit is running at 26315 calls per second and gloss.Texture.draw is running at 20833 calls per second. Making (in my tests) gloss slower at drawing than pygame. I also am guessing that gloss's texture drawing does not appear to be hardware accelerated. ( thats just a guess, judging by the large spike in my cpu performance meter [about 60% usage] compared to hardly any on my graphics card [about 2 - 3% usage]). But the point is, this library looks like it has a lot of potential and the demos had amazing looking rotation which i find very cool, but i am hesitant to use it when there are other opengl pygame libraries out there that can get better performance. Dont get me wrong though, its really neat and useful. I would also suggest making some demos more centered around the programmer having control over the main game loop also instead of handing it off to gloss. I did not look through them all but the ones i did were very restricting unless you want to dive in and edit the gloss.py script.

  • David Griffin 2012-06-13 14:06

    Right, I'm not meaning to be disrespectful to Gloss (especially as I'm on the list of contributors!), but I figure I'll do a little post on some the caveats of using Gloss and why you should use an alternative.

    1) As Josh Cockrell pointed out, Gloss is slow. For certain workloads (well, actually anything with more than about 50 sprites...) it can be much slower than CPU rendering through Pygame. This is because Gloss uses the old, deprecated, style of glBegin...glEnd and per sprite drawing rather than vertex arrays/VBOs. To be fair, when Gloss was originally made it was using PyOpenGL 2.x, which was reasonably fast with this type of drawing. However, in the world of PyOpenGL 3.x, it struggles immensely.

    2) It appears to be abandoned and not actively developed (please correct me if I'm wrong!).

    Personally, I 'd recommend people interested in Gloss to use PyGL3Display, but that is almost certainly my own bias as I'm its developer - though I suppose I'm also designing PyGL3Display around similar principals to Gloss, albeit with some compromises to get much higher speeds. Pyglet is also another viable alternative, but isn't at all compatible with Pygame (and technically loses against PyGL3Display for speed, due to it using per sprite draws). And for those who want ultimate flexibility, use PyOpenGL directly. It isn't that hard...