Re: [pygame] Dirty Rect Animation

[DR0ID]

Hello

Yes I do dirty rect animation. If you read the code of the RenderUpdate 
(in pygame.sprite.Sprite.RenderUpdates) then you will see that this 
group does something like this:


dirty = [ ]
if old rect and new rect overlap:
 dirty_rect = old_rect.union(new_rect)
dirty.append(dirty_rect)
else
dirty.append(old_rect)
dirty.append(new_rect

This is done fore each sprite and give an performance boost. But if you 
have many sprite that overlap then the code above lead still to many 
overlapping areas. Therefore I use little different approach:


# 1. I have to find out the dirty areas on screen  because you have to 
know the old_rect and the new_rect
rect_list = [old_rect, new_rect,  ]  # all rect that affect the 
screen, afterward it will contain the dirty rects

for rect in rect_list:
   _unionR = pygame.Rect(rect)   # make a copy because 
_uionR will be modified
   i = _unionR.collidelist(rect_list)  # find first other 
rect that collides
   while -1< i:# repeat it as long there is 
an colliding rect
  _unionR.union_ip(rect_list[i]) # union the 
overlapping rects in place
   del rect_list[i]  #remove 
the on from the list
   i = _unionR_collidelist(rect_list)   # check if there 
are still overlapping rects in the list
   rect_list.append(_unionR.clip(_clip))  # at the end append the 
new rect to the rect_list (dirty rects now)


This code will handle any overlapping rects on screen. There is one draw 
back though. If you have a high and small rect and a another with a 
small hight and a big width then nearly the entire screen will be 
updated. Parts of the screen will be updated too, which did not change, 
so you will have to redraw them again (that is a strong reason against 
that update() should optimize the rects in that way, if it should do it 
then it should split the overlapping rects into two or three different 
rects such that only areas in the rects will be updated on screen, see 
below).


Especially in combination of a dirty flag the second code snippet is 
useful. I have used it in the FastRenderGroup I have written, here it 
goes (if you subscribe to the RSS feed then you will stay informed about 
updates):


http://www.mypage.bluewin.ch/DR0ID/pygame_projects.html#fast_dirty1

In the new release (soon today) I have written a separated 
LayeredRenderGroup (which is somewhat untested! sorry, had no time to 
test it) and the FastRenderGroup. The FastRenderGroup can handle about 
130 sprites doing dirty rects animation (on a PentiumM 1.5GHz), but with 
more sprites a full screen update will be faster, so it switches 
automatically to that mode.


Another approach would be to split the overlapping rects into single, 
non-overlapping rects. To know how to split rects see (some time ago I 
have found the following link, but have not tested it and I do not know 
how fast it really is):


http://barbieri-playground.googlecode.com/svn/pygame/smart_render/smart_render.py


I hope I could help.

~DR0ID





Peter Shinners schrieb:

John Cabral wrote:

I was working on some code for my game and read about the optimization
of feeding a list of rects to the update function.  I was curious if
it would be worthwhile to try to optimize the list that is fed to the
function.  Specifically, I would try to shorten the list by merging
rects that had significant areas of overlap.  However, I can't tell if
the function itself might perform this work itself.   Does anyone
know?


I've found that generally many small rectangles aren't slower than 
fewer big ones. The most important thing is the area effected.


And yes, overlapping rectangles are processed multiple times, so that 
can cost big on performance. A little effort to keep big areas from 
overlapping will pay off.

Re: [pygame] Dirty Rect Animation

[John Cabral]

Ahh, thank you both very much.  You even answered my follow up question.

Best,
JC


On 6/9/07, Peter Shinners <[EMAIL PROTECTED]> wrote:

John Cabral wrote:
> I was working on some code for my game and read about the optimization
> of feeding a list of rects to the update function.  I was curious if
> it would be worthwhile to try to optimize the list that is fed to the
> function.  Specifically, I would try to shorten the list by merging
> rects that had significant areas of overlap.  However, I can't tell if
> the function itself might perform this work itself.   Does anyone
> know?

I've found that generally many small rectangles aren't slower than fewer
big ones. The most important thing is the area effected.

And yes, overlapping rectangles are processed multiple times, so that can
cost big on performance. A little effort to keep big areas from
overlapping will pay off.

Re: [pygame] Dirty Rect Animation

[Peter Shinners]

John Cabral wrote:

I was working on some code for my game and read about the optimization
of feeding a list of rects to the update function.  I was curious if
it would be worthwhile to try to optimize the list that is fed to the
function.  Specifically, I would try to shorten the list by merging
rects that had significant areas of overlap.  However, I can't tell if
the function itself might perform this work itself.   Does anyone
know?


I've found that generally many small rectangles aren't slower than fewer 
big ones. The most important thing is the area effected.


And yes, overlapping rectangles are processed multiple times, so that can 
cost big on performance. A little effort to keep big areas from 
overlapping will pay off.

Re: [pygame] 3D sample code

[kschnee]

On Fri, June 8, 2007 11:29 pm, Richard Jones wrote:
> On Sat, 9 Jun 2007, Kamilche wrote:
>
>> Is there a way to render 3d objects out to disk only, and use the
>> renders in a normal Pygame program? Is there any advantage to doing so,
>> in speed, or memory, or anything?
>
> Sure, POV-Ray http://www.povray.org/ :)
>
>
> There's even pypov  http://arrowtheory.com/software/python/pypov/

There's also "Art of Illusion": http://artofillusion.org/ . It's very
different in interface from POV-Ray. Or for people more interested in
quick results than precision, Google Sketchup.

Re: [pygame] Dirty Rect Animation

[Patrick Mullen]

I'm fairly certain that update does NOT merge incoming rects or do any other
optomization  on input.  It iterates through all of the rects in the list
and updates that portion of the screen.  So you can optimize it
considerably by merging rects where it makes sense, rather than sending a
rect for each of your 1000 sprites you want to draw :)

You could also check out DR0ID's optimized drawing routine and see what he
does.  If I recall, it handles dirty rects.

Re: [pygame] 3D sample code

[Richard Jones]

On Sat, 9 Jun 2007, Will McGugan wrote:
> Kamilche wrote:
> > Is there a way to render 3d objects out to disk only, and use the
> > renders in a normal Pygame program? Is there any advantage to doing
> > so, in speed, or memory, or anything?
>
> It is possible to render to a texture and grab that back, but I don't
> think you could do that in PyGame without creating an OpenGL display
> first.

I believe - though I've not tried this - it is possible at least under X11 
(ie. GLX) to attach a GLX context directly to an X11 pixmap, rather than to a 
window, thus allowing you to render "off-screen".

I don't know whether this is possible under WGL or AGL (Windows and OS X 
respectively).


 Richard

Re: [pygame] 3D sample code

[Richard Jones]

On Sat, 9 Jun 2007, Kamilche wrote:
> Is there a way to render 3d objects out to disk only, and use the
> renders in a normal Pygame program? Is there any advantage to doing so,
> in speed, or memory, or anything?

Sure, POV-Ray http://www.povray.org/ :)

There's even pypov  http://arrowtheory.com/software/python/pypov/


Richard

Re: [pygame] 3D sample code

[kschnee]

On Fri, June 8, 2007 1:09 pm, David wrote:
>> You're right that you cant use any of the regular SDL drawing functions
>>  with OpenGL - or any other accelarated 3D API. You can work with 2D
>> graphics in OpenGL though, by drawing texture quads. If you wrap that in
>> a simplified interface, then the code doesn't look much different from
>> what you are used to in 2D PyGame.
>>
>
>
> For such a simplified interface, you might find Lamina useful.
>
>
> http://cheeseshop.python.org/pypi/Lamina/0.1.2

It does sound useful. When I tried the demos, though, they said "no module
named la." I figured this might mean "lamina," but changing it to that
didn't help. Then I thought it might be something from OcempGUI (which I
don't have installed), so I tried running a very basic demo:


## Hacked-together Lamina test

import lamina
from pygame import display, key, init, event
from pygame import time as pytime
from pygame.locals import *
import OpenGL.GL as ogl
import OpenGL.GLU as oglu

# create gui with appropriate constructor
gui = GUI_Constructor()

# create LaminaPanelSurface
gui_screen = lamina.LaminaPanelSurface( (640,480), (-1,1,2,2) )

# draw widgets on surface
gui.draw( gui_screen.surf )


Result:
Traceback (most recent call last):
  File "C:/Documents and Settings/Owner/Desktop/lamina/lamina_test_k.py",
line 12, in ?
gui = GUI_Constructor()
NameError: name 'GUI_Constructor' is not defined

That happens even with spyre and lamina in the same directory.

Re: [pygame] 3D sample code

[kschnee]

On Fri, June 8, 2007 2:30 pm, Kamilche wrote:
> Is there a way to render 3d objects out to disk only, and use the
> renders in a normal Pygame program? Is there any advantage to doing so, in
> speed, or memory, or anything?

Take a look at the program at , Peter
Rogers' "pygame-blender converter." It uses Blender (freeware) to render a
3D object to a set of animation frames.

[pygame] Dirty Rect Animation

[John Cabral]

Hello, all;
I was working on some code for my game and read about the optimization
of feeding a list of rects to the update function.  I was curious if
it would be worthwhile to try to optimize the list that is fed to the
function.  Specifically, I would try to shorten the list by merging
rects that had significant areas of overlap.  However, I can't tell if
the function itself might perform this work itself.   Does anyone
know?

Thank you,
JC

Re: [pygame] Numeric/NumPy/Numarray Clarification

[Lenard Lindstrom]

Chris Ashurst wrote:

I've been messing around with PyGame and the OpenGL bindings for a while
now, and I've recently begun to start seeing the light of using the array
classes from numpy for various math operation.

The thing is... Does anyone have any sort of clear idea about which package
I should have installed out of Numeric, NumPy and Numarray? They all seem to
be by the same bunch of people, but the fact that they all seem to do the
same thing, but are named differently and have no clues about them to let
you know which one does/has what bundled in with it.

For instance, in the pygame repository there's a little plasma demo that
uses RandomArray which is suppsedly in the Numeric package. I have the
Numeric package installed, but after searching through the
/usr/lib/python2.4/site-packages directory, I did not find RandomArray in
the Numeric package, but I *did* find a RandomArray2 module inside the
Numarray package. So in the code, I had to replace "from RandomArray import
*" to "from numarray.random_array.RandomArray2 import *".

Ultimately, that did the trick of solving the "missing" RandomArray import
problem, but seriously, I just want a nice, clean site-packages directory,
and just need some pointers on which bloody package I *should* have
installed, or at the very least, someone explain to me the differences
between the three apparently different packages.

Sorry for the long-windedness, but it's just kinda frustrating not knowing
if I have the "right" package installed.

Thanks :)

  

I can try, but will probably get it wrong.

First came Numeric. But as computers developed some found it didn't 
handle really large arrays well. So along came numarray, and Numeric was 
retired. numarray was a total rewrite of Numeric that also took 
advantage of the class/type merger of Python 2.2. But some found Numeric 
faster at handling small arrays and were reluctant to switch. So a third 
attempt was made to update Numeric to fixed some known issues. But this 
changed Numeric enough that it was introduced as a new package, numpy. 
numpy also includes features of numarray. numpy is advertised as the 
successor of both Numeric and numarray. But numpy is almost, though not 
entirely, backward compatible to Numeric. Things break. Also the 
official numpy documentation is not free. So the move to numpy has been 
slow.


The only solid suggestion I can make is don't bother with numarray. 
Pygame doesn't support it and never will. Pygame 1.8 will support both 
Numeric and numpy. But current pygame programs expect Numeric and may 
need updating to use numpy. So you will probably want both Numeric and 
numpy for now. Is it clear now? :-)


--
Lenard Lindstrom
<[EMAIL PROTECTED]>

Re: [pygame] 3D sample code

[Nick Moffitt]

Will McGugan:
> I think Kamilche was suggesting doing it on the fly. If you were just
> going to generate images offline, then you probably wouldnt use
> OpenGL.

Yes, hence my comment about caching transforms in 2D and how the process
might help certain odd cases in 3D.

-- 
"N'aimez pas votre voiture? Nick Moffitt
Alor, l'heure est arrive pour la brulé!"  [EMAIL PROTECTED]
-- Mark Jaroski

[pygame] mac app stuck on minimized

[sean]

Hi

Been pulling my hair out over this.

On Mac OS X while running my app from the command line the window minimize
and click to maximize worked fine. When I packaged it up using py2applet
it stopped maximizing when the icon was clicked.

Solution:
In the setup.py generated by py2app change the
  argv_emulation = true
to false

run the setup as normal and the window will behave normally


thanks to;
http://mail.python.org/pipermail/pythonmac-sig/2007-May/018917.html

Regards
Sean

Re: [pygame] 3D sample code

[Will McGugan]

Nick Moffitt wrote:


Will McGugan:
 


I don't think it would be pracitcal to render 3D models and blit them
in 2D. Happy to be proven wrong though.
   



Well, consider games like powermanga.  They generated their sprites
using 3-D tools and saved them to disk.
 

I think Kamilche was suggesting doing it on the fly. If you were just 
going to generate images offline, then you probably wouldnt use OpenGL.

[pygame] Numeric/NumPy/Numarray Clarification

[Chris Ashurst]

I've been messing around with PyGame and the OpenGL bindings for a while
now, and I've recently begun to start seeing the light of using the array
classes from numpy for various math operation.

The thing is... Does anyone have any sort of clear idea about which package
I should have installed out of Numeric, NumPy and Numarray? They all seem to
be by the same bunch of people, but the fact that they all seem to do the
same thing, but are named differently and have no clues about them to let
you know which one does/has what bundled in with it.

For instance, in the pygame repository there's a little plasma demo that
uses RandomArray which is suppsedly in the Numeric package. I have the
Numeric package installed, but after searching through the
/usr/lib/python2.4/site-packages directory, I did not find RandomArray in
the Numeric package, but I *did* find a RandomArray2 module inside the
Numarray package. So in the code, I had to replace "from RandomArray import
*" to "from numarray.random_array.RandomArray2 import *".

Ultimately, that did the trick of solving the "missing" RandomArray import
problem, but seriously, I just want a nice, clean site-packages directory,
and just need some pointers on which bloody package I *should* have
installed, or at the very least, someone explain to me the differences
between the three apparently different packages.

Sorry for the long-windedness, but it's just kinda frustrating not knowing
if I have the "right" package installed.

Thanks :)




~Chris




CONFIDENTIAL NOTICE: This email including any attachments, contains 
confidential information belonging to the sender. It may also be 
privileged or otherwise protected by work product immunity or other 
legal rules. This information is intended only for the use of the 
individual or entity named above.  If you are not the intended 
recipient, you are hereby notified that any disclosure, copying, 
distribution or the taking of any action in reliance on the contents 
of this emailed information is strictly prohibited.  If you have 
received this email in error, please immediately notify us by 
reply email of the error and then delete this email immediately.

Re: [pygame] 3D sample code

[Nick Moffitt]

Will McGugan:
> I don't think it would be pracitcal to render 3D models and blit them
> in 2D. Happy to be proven wrong though.

Well, consider games like powermanga.  They generated their sprites
using 3-D tools and saved them to disk.

When I was working on an SDL game in C, I noted that since I rotated
only in integer degrees, I could set up 360-long cache arrays for sprite
rotations.  This sped up rendering immensely, so long as nothing ever
zoomed in or out.

So if your 3-D game tends to repeat a few basic perspectives on an
object, you may actually consider memoizing renderings to a weakref
LRU/MRU structure of some sort.

-- 
"Here is the memo if you didn't receive it: GNOME and   Nick Moffitt
Free Software is all about *SAVING THE WORLD* not  [EMAIL PROTECTED]
drawing pissy little buttons on the screen."
-- Jeff Waugh

[pygame] pygame network redux, with code!

[Simon Wittber]

Based on some discussion re: simple pygame networking, I've whacked
together some code. Basically, it allows the server and clients to
send marshalable python objects (lists, dicts, numbers, strings etc)
between each other. Only documentation is  the tests at the moment.

The code assumes a dedicated piece of (headless) server code is used
as the game server, not a game instance itself. This is why the server
does not do anything to integrate with pygame, it all just twisted
code.

http://pygnet.googlecode.com/svn/trunk/

It's intentionally minimal, so that the programmer can hook it up to
their own event systems or whatever.

I'm a bit worried the client api feels bit clunky... happy for
comments on that :-)

http://pygnet.googlecode.com/svn/trunk/tests/client.py

So... could this thing become suitable for building multiplayer pygames?


--
   :: Simon Wittber
   :: http://www.linkedin.com/in/simonwittber
   :: phone: +61.4.0135.0685
   :: jabber/msn: [EMAIL PROTECTED]

Re: [pygame] 3D sample code

[Will McGugan]

Kamilche wrote:



Is there a way to render 3d objects out to disk only, and use the 
renders in a normal Pygame program? Is there any advantage to doing 
so, in speed, or memory, or anything?


It is possible to render to a texture and grab that back, but I don't 
think you could do that in PyGame without creating an OpenGL display 
first. I don't think it would be pracitcal to render 3D models and blit 
them in 2D. Happy to be proven wrong though.


Although maybe it could be done with a software based OpenGL 
implementation, like Mesa3D. :-/


Will

Re: [pygame] 3D sample code

[Kamilche]

Will McGugan wrote:

  [EMAIL PROTECTED]  wrote:

On Thu, June 7, 2007 2:45 pm, Horst JENS wrote:
  

On Mon, 2007-06-04 at 21:19 +0100, Will McGugan wrote:

  

I've just posted some sample code for using OpenGL with PyGame. Hope
you find it interesting.

http://www.willmcgugan.com/2007/06/04/opengl-sample-code-for-pygame/

  

that's exactly what i was looking for... thanks!


It is interesting. Am I right in understanding that you basically have to
choose between Pygame's normal (SDL) drawing functions, like surface.blit,
and OpenGL's? You can't just draw a 3D scene like that of the code above,
and then blit an interface or text atop it. Instead you have to switch to
a 2D mode, turn your Pygame drawing into an OpenGL texture, and draw a
rectangle textured with the new drawing -- and delete/replace the texture
every time you want to change something. That's so cumbersome that I've
barely ever gotten it to work; is there a better way to integrate OpenGL
and Pygame graphics?
  
You're right that you cant use any of the regular SDL drawing functions 
with OpenGL - or any other accelarated 3D API. You can work with 2D 
graphics in OpenGL though, by drawing texture quads. If you wrap that in 
a simplified interface, then the code doesn't look much different from 
what you are used to in 2D PyGame.


Will


Is there a way to render 3d objects out to disk only, and use the 
renders in a normal Pygame program? Is there any advantage to doing so, 
in speed, or memory, or anything?

Re: [pygame] 3D sample code

[David]

You're right that you cant use any of the regular SDL drawing functions
with OpenGL - or any other accelarated 3D API. You can work with 2D graphics
in OpenGL though, by drawing texture quads. If you wrap that in a simplified
interface, then the code doesn't look much different from what you are used
to in 2D PyGame.




For such a simplified interface, you might find Lamina useful.

http://cheeseshop.python.org/pypi/Lamina/0.1.2

David

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