Re: [pygame] FastRenderGroup revised (update4)

[Brian Fisher]

On 6/29/07, DR0ID <[EMAIL PROTECTED]> wrote:

I think this is only a O(n^2) in worst case otherwise it is less (but I
cant tell you what it is). The drawback of that method is, that in the
worst case it ends up with a big rect covering the entire screen.
Perhaps using Gustavos rect splitting thing would be better (? faster?).


At work we use tiled rects for our dirty rect system for software
rendering. It's a C++ engine, but the 2 really big wins for a tiling
system is that you never need to merge rects (merging is in general
O(n^2) unless you maintain some kind of partitioning system, then it
can by n log n) and you don't need to manage a pool for
allocating/deleting (a fixed size linked list pool can be constant
allocation and deletion time, but naive object allocation and deletion
from a variable sized heap/pool can be very very slow)

We tested a lot of different approaches and tiling was by far the
fastest we tried (in C++ anyways). In particular the fastest
implementation for us was where each tile has it's own rect, and it
does min/max ops on the cells rect to grow it to cover the overlap
being the dirty rect and the cell area. So in cases with a fairly
small number of objects, you oftenget a perfectly tight fit even
though the cells are like 16x8, but it's still all O(n) where n is the
number of objects.

Re: [pygame] Starting a game

[Charles Joseph Christie II]

On Friday 29 June 2007 06:15:39 pm Casey Duncan wrote:
> On Jun 29, 2007, at 3:06 PM, Charles Joseph Christie II wrote:
> [..]
>
> > You say to look at other people's games for an example of
> > abstraction. Do you
> > have a particular one in mind?
>
> Totally depends on the kind of game you are going to implement and
> whether it is sprite-based or OpenGL. Have you decided which of the
> options you mentioned you are going to do?
>
> -Casey

Whatever I make, I definitely want to use OpenGL for rendering. I know it's 
harder, but  no pain no gain amirite? ;D

Plus I'm learning how to make (really crappy) 3D models in Blender (awesome 
program, by the way). I don't intend to make a 3D game any time soon, but I'd 
still like to know how to use OpenGL.

Re: [pygame] Starting a game

[Casey Duncan]

On Jun 29, 2007, at 3:06 PM, Charles Joseph Christie II wrote:
[..]


You say to look at other people's games for an example of  
abstraction. Do you

have a particular one in mind?


Totally depends on the kind of game you are going to implement and  
whether it is sprite-based or OpenGL. Have you decided which of the  
options you mentioned you are going to do?


-Casey

Re: [pygame] Starting a game

[Charles Joseph Christie II]

On Friday 29 June 2007 05:55:26 pm Casey Duncan wrote:
> On Jun 29, 2007, at 2:34 PM, Charles Joseph Christie II wrote:
> > Alright. I don't know if I'm going to be using that MVC stuff...
> > although I
> > might reprogram the game to use it later, if I decide it'll be
> > better... but
> > I want to start a game now! I'm so bored just sitting here that I
> > may as well
> > start something.
> >
> > So now, I'm going to get started. But the problem is that the last
> > time I
> > tried it, I over-complicated it by using advanced sprite functions
> > that I
> > didn't understand at all. I'm still trying to figure out an eaiser
> > way to
> > draw stuff than making everything a class and making it extend from
> > pygame.sprite.Sprite (painful >.<)
>
> My advice, come up with a game concept, then come up with one aspect
> of it that you can implement easily and do that first. For example,
> if you were making a tiled rouge-like game, you could come up with
> some simple art for a player character (like a knight or mage) then
> make it so you move the character in a grid on the screen. If you are
> making an asteroids type game, make it so you can turn your ship,
> then implement thrust, etc.
>
> Try to bite off little chunks you can do in a few hours time and
> don't try and invent the whole thing at once, learn as you go.
>
> Some kinds of games (such as the rouge-like one I mentioned) already
> have lots of pygame implementations, and there are frameworks that
> can help with things like tiling, level design, etc. Sometimes though
> it may be as hard to learn to use the framework as it is to learn
> pygame itself, so beware of biting off more than you can chew.
>
> > Also, some concepts of object orientation seem to have bit me. How
> > should I
> > have classes interact with each other? I know I was doing it
> > completely wrong
> > last time, and one of my friends called me on it. But I forgot how
> > he said I
> > should do it...
>
> Look at other people's code. Games and OO programming go hand-and-
> hand IMO and it really helps you if you have the right level of
> abstraction. The sprite class is supposed to help you in this regard,
> giving you a small organizational unit for the components of your
> game. OTOH, using Sprite may make it more difficult to implement
> certain patterns (i.e., MVC). But to risk overusing a cliche: "Don't
> let the perfect be the enemy of the good", figure out how to make
> something work first then learn how to make it better. Don't try to
> learn everything at once.
>
> Maybe you said this before, but what kind of game are you making? Is
> there another pygame that has similar ideas and elements you can
> borrow from?
>
> -Casey

I'm trying to decide between a Tetris Attack clone (my friends were all 
interested in this idea), an RPG (some of my other friends recommended I 
start with this, but if I did I wouldn't allow myself to do something like 
Final Fantasy, it'd have to be something really weird like Tendrills) or an 
arcade shoot-em-up game like the one I tried to make for my senior project, 
which would be a series of boss-battles in which you have to type a set of 
words to damage the boss. My teacher really wanted to see what it looked like 
when it was done but my first try ened up... well, crappy to say the very 
least. (it couldn't shoot bullets T_T)

I had other people on the ML say that I should start backwards from what I did 
last time: try to get an enemy firing bullets before I get the player on the 
screen. Which I probably will do, just to make sure I do it right this time.

You say to look at other people's games for an example of abstraction. Do you 
have a particular one in mind?

Re: [pygame] Starting a game

[Casey Duncan]

On Jun 29, 2007, at 2:34 PM, Charles Joseph Christie II wrote:

Alright. I don't know if I'm going to be using that MVC stuff...  
although I
might reprogram the game to use it later, if I decide it'll be  
better... but
I want to start a game now! I'm so bored just sitting here that I  
may as well

start something.

So now, I'm going to get started. But the problem is that the last  
time I
tried it, I over-complicated it by using advanced sprite functions  
that I
didn't understand at all. I'm still trying to figure out an eaiser  
way to

draw stuff than making everything a class and making it extend from
pygame.sprite.Sprite (painful >.<)


My advice, come up with a game concept, then come up with one aspect  
of it that you can implement easily and do that first. For example,  
if you were making a tiled rouge-like game, you could come up with  
some simple art for a player character (like a knight or mage) then  
make it so you move the character in a grid on the screen. If you are  
making an asteroids type game, make it so you can turn your ship,  
then implement thrust, etc.


Try to bite off little chunks you can do in a few hours time and  
don't try and invent the whole thing at once, learn as you go.


Some kinds of games (such as the rouge-like one I mentioned) already  
have lots of pygame implementations, and there are frameworks that  
can help with things like tiling, level design, etc. Sometimes though  
it may be as hard to learn to use the framework as it is to learn  
pygame itself, so beware of biting off more than you can chew.


Also, some concepts of object orientation seem to have bit me. How  
should I
have classes interact with each other? I know I was doing it  
completely wrong
last time, and one of my friends called me on it. But I forgot how  
he said I

should do it...


Look at other people's code. Games and OO programming go hand-and- 
hand IMO and it really helps you if you have the right level of  
abstraction. The sprite class is supposed to help you in this regard,  
giving you a small organizational unit for the components of your  
game. OTOH, using Sprite may make it more difficult to implement  
certain patterns (i.e., MVC). But to risk overusing a cliche: "Don't  
let the perfect be the enemy of the good", figure out how to make  
something work first then learn how to make it better. Don't try to  
learn everything at once.


Maybe you said this before, but what kind of game are you making? Is  
there another pygame that has similar ideas and elements you can  
borrow from?


-Casey

Re: [pygame] undeliverable messages

[Charles Joseph Christie II]

On Friday 29 June 2007 02:23:13 pm Luke Paireepinart wrote:
> Can an admin remove
>
> <[EMAIL PROTECTED]>
>
> from the mailing list?
> I just keep getting bounces from his address every time I post.
> Thanks,
> -Luke

I just had the same problem a second ago...

Re: [pygame] undeliverable messages

[René Dudfield]

I think we should wait a few days first, since it seems to be a temporary error.

On 6/30/07, Luke Paireepinart <[EMAIL PROTECTED]> wrote:

Can an admin remove

<[EMAIL PROTECTED]>

from the mailing list?
I just keep getting bounces from his address every time I post.
Thanks,
-Luke

[pygame] Starting a game

[Charles Joseph Christie II]

Alright. I don't know if I'm going to be using that MVC stuff... although I 
might reprogram the game to use it later, if I decide it'll be better... but 
I want to start a game now! I'm so bored just sitting here that I may as well 
start something.

So now, I'm going to get started. But the problem is that the last time I 
tried it, I over-complicated it by using advanced sprite functions that I 
didn't understand at all. I'm still trying to figure out an eaiser way to 
draw stuff than making everything a class and making it extend from 
pygame.sprite.Sprite (painful >.<)

Also, some concepts of object orientation seem to have bit me. How should I 
have classes interact with each other? I know I was doing it completely wrong 
last time, and one of my friends called me on it. But I forgot how he said I 
should do it...

Well, I'm going to see if I can drum up something usable...

Re: [pygame] FastRenderGroup revised (update4)

[DR0ID]

Hello again


René Dudfield schrieb:

Hello,

very nice work!

I'm a bit busy myself for the next week.  So in two weeks would be a 
good time to meet up and finish off the last things before we put it 
into pygame.


1.) Change the name: yes, but to what?

Not sure.  I'm afraid of using 'Fast' because too many times I have 
seen projects where there is a new FastSomething only for it to 
eventually not be fast anymore a year later.


Your right, we should not use "fast" in the name. Perhaps 
OrderedDirtyGroup or DirtyOrderedGroup? Or DirtyLayeredGroup?




What are the main features of FastRenderGroup? 
Well it has the layering system from the LayeredRenderGroup (ist that 
name ok?). Then it uses the dirty flag technique, so only things marked 
dirty will be redrawn. And the automatic switch between the two 
rendering modes is another feature (the idea of all that is that you 
stuff your sprites in there and forget about all the complicated 
rendering stuff, it will be just done for you). I think there are the 3 
main features. Well clipping, you can set a clip, and it will only 
render in that area of the surface.




We should definitely let people know in the docs that FastRenderGroup 
is the preferred group to use.
Well not sure about that, I would say yes, but its a bit more 
complicated to use actually. You will be responsible to set the dirty 
flag whenever the sprite has to be redrawn (actually dirty=2 is a 
shortcut for sprites that are always dirty, so they do not need to set 
the dirty flag all the time, but this should be used with care, because 
if you set dirty=2 on every sprite then you can just use the 
LayeredRenderGroup).





2.) you really want to be able to pass in different get_ticks()
functions? I can do it, but I do not see the benefit, because I'm still
unhappy with the solution how to decide which method to use. Perhaps I
could use a Exponential back off strategy (do not know how to implement
it), but I'm not sure if that would be good. Any better ideas?

So people can use their own game timers.  Say the rest of the game 
uses either time.time, or even something from blender, crystalspace, a 
real time clock etc etc.  Should definitely use a default timer though.

That sounds like a good reason. I have just read Nick Moffitt mail:

"

Consider that when you sample, you have a timing value for the fastest
and the slowest method given a particular data set.  Use this to
calculate a threshold, and compare it against the current rendering
time.  Keep the rendering time for the previous frame as well, and do
comparisons between successive frames and comparisons relative to the
tests done earlier.  


You should also consider attack/sustain values for when to switch, so
that you don't end up with bang-bang switching in cases where the two
methods have similar speeds.

"

Perhaps we should try one of these. I like the idea to store the values 
of preceding frames, but on the other hand I do not want to take a 
measure at every frame. Instead of counting the frame we could use a 
timevalue like Rene proposed, but perhaps not every 10 seconds (too long 
in my opinion, see some line below). Perhaps I should implement the 
possibility to make it stick with one rendering mode.




The jerking stops for me when I make it not oscillate between update, 
and flip modes.  I think maybe an Exponential back off strategy might 
work... not too sure.  I think we should try a few different things 
when we meet up in two weeks.
Strange that the jerking stops when you disable the decisioning. Perhaps 
another strategy helps here.




Some possible different strategies:
- figure out the best rendering method in the first 1-3 seconds, then 
stick with that.
- keep checking to see which is the fastest way.  Only change modes at 
most once every 10 seconds.



3.) naming of the attributes of the DirtySprite: we can change them, but
to what? Are the current names already used?

Haven't had a chance to research this.  Let's look at it in two weeks.

Let's talk about them next time we meet at the minisprint.



4.) I don't think we can make it backwards compatible, so it will not
replace RenderUpdates (unless the pygame.sprite.Sprite becomes the
DirtySprite with dirty=2 as default, but that would be stupid).

Cool, that's fine if we can't.

btw, Gustavo posted about some code he's done for fast sprite usage:
http://renesd.blogspot.com/2007/06/pygame-weekly-mini-sprint-20070620.html#comments 



I think his approach is to break the screen up into tiles of 8x8.  
Then in the sprite code mark each tile as dirty, if the sprite needs 
to be updated in those positions.  This way there is a constant number 
of rectangles passed through to the update function every frame - and 
no over draw.
Yes, I stumbled on that some weeks ago and I have already taken a look. 
I think we could just extend the rect class in pygame. Perhaps we shoul

Re: [pygame] FastRenderGroup revised (update4)

[Nick Moffitt]

René Dudfield:
> What are the main features of FastRenderGroup?

Since I have read earlier versions of this code, and chatted with DR0ID
in the #pygame channel about the architecture (I suggested exponential
back-off as worth exploring) I'd like to have a go at this.

The core of it seems to be the chunk of code that tries two rendering
methods every 75th frame and chooses the faster of the two as the method
to use for the next 74 frames.  It's a benchmark-based system, and could
probably be called the BenchmarkingRenderGroup.

> The jerking stops for me when I make it not oscillate between update,
> and flip modes.  I think maybe an Exponential back off strategy might
> work...  not too sure.  I think we should try a few different things
> when we meet up in two weeks.
> 
> Some possible different strategies:
> - figure out the best rendering method in the first 1-3 seconds, then
> stick with that.
> - keep checking to see which is the fastest way.  Only change modes at
> most once every 10 seconds.

While writing the above, I thought that the name "StochasticRenderGroup"
might be good.  Then I stopped to look up the literal definition of a
stochastic process, and realized that it did not apply.  However, such a
process might actually be the solution to removing the sampling jitter.  

gcide says:

 3. (Statistics) of or pertaining to a process in which a series of
 calculations, selections, or observations are made, each one being
 randomly determined as a sample from a probability distribution.

Consider that when you sample, you have a timing value for the fastest
and the slowest method given a particular data set.  Use this to
calculate a threshold, and compare it against the current rendering
time.  Keep the rendering time for the previous frame as well, and do
comparisons between successive frames and comparisons relative to the
tests done earlier.  

You should also consider attack/sustain values for when to switch, so
that you don't end up with bang-bang switching in cases where the two
methods have similar speeds.

-- 
How do you get mailings?... from the lists Nick Moffitt
1. suspects   [EMAIL PROTECTED]
2. elbows
-- Don Saklad

Re: [pygame] Starting Window Position

[Ian Mallett]

Thanks for your help in all these matters.
Bye
Ian

On 6/29/07, Luke Paireepinart <[EMAIL PROTECTED]> wrote:


Ian Mallett wrote:
> I suppose I was just curious.  You could make really interesting
> programs- like pong on your desktop with windows!  :)  Whatever.  If
> it can't be done easily, then it is pointless.
It can be done easily using a GUI toolkit.  Pygame is not a GUI toolkit.
Look into TKinter or WxPython.
-Luke

Re: [pygame] Starting Window Position

[Luke Paireepinart]

Ian Mallett wrote:
I suppose I was just curious.  You could make really interesting 
programs- like pong on your desktop with windows!  :)  Whatever.  If 
it can't be done easily, then it is pointless. 

It can be done easily using a GUI toolkit.  Pygame is not a GUI toolkit.
Look into TKinter or WxPython.
-Luke

Re: [pygame] Starting Window Position

[Ian Mallett]

I suppose I was just curious.  You could make really interesting programs-
like pong on your desktop with windows!  :)  Whatever.  If it can't be done
easily, then it is pointless.

On 6/29/07, Luke Paireepinart <[EMAIL PROTECTED]> wrote:


Ian Mallett wrote:
> I gathered that, right after I sent it.
> Here's a new version:
>
> import pygame
> from pygame.locals import *
> import os, sys
>
> pygame.init()
> if sys.platform == 'win32':
> os.environ['SDL_VIDEO_WINDOW_POS'] = '300,230'
> pygame.display.set_mode((200,200), 16)
> pygame.time.wait(2000)
> pygame.quit()
>
> pygame.init()
> if sys.platform == 'win32':
> os.environ['SDL_VIDEO_WINDOW_POS'] = '400,430'
> pygame.display.set_mode ((200,200), 16)
> pygame.time.wait(2000)
> sys.exit()
>
> ...but it doesn't work.
why do you need to dynamically change the display position anyway?
SDL isn't designed for this.
I see no reason why you would need to change the display position.

If it were really necessary, why not just embed an SDL surface in a
WxPython window?
You should be able to set the position of that.
But that's unnecessarily complicated unless you have a real good use for
this.
-Luke

Re: [pygame] Starting Window Position

[Luke Paireepinart]

Ian Mallett wrote:
I gathered that, right after I sent it. 
Here's a new version:


import pygame
from pygame.locals import *
import os, sys

pygame.init()
if sys.platform == 'win32':
os.environ['SDL_VIDEO_WINDOW_POS'] = '300,230'
pygame.display.set_mode((200,200), 16)
pygame.time.wait(2000)
pygame.quit()

pygame.init()
if sys.platform == 'win32':
os.environ['SDL_VIDEO_WINDOW_POS'] = '400,430'
pygame.display.set_mode ((200,200), 16)
pygame.time.wait(2000)
sys.exit()

...but it doesn't work. 

why do you need to dynamically change the display position anyway?
SDL isn't designed for this.
I see no reason why you would need to change the display position.

If it were really necessary, why not just embed an SDL surface in a 
WxPython window?

You should be able to set the position of that.
But that's unnecessarily complicated unless you have a real good use for 
this.

-Luke

Re: [pygame] Starting Window Position

[Ian Mallett]

I gathered that, right after I sent it.
Here's a new version:

import pygame
from pygame.locals import *
import os, sys

pygame.init()
if sys.platform == 'win32':
   os.environ['SDL_VIDEO_WINDOW_POS'] = '300,230'
pygame.display.set_mode((200,200), 16)
pygame.time.wait(2000)
pygame.quit()

pygame.init()
if sys.platform == 'win32':
   os.environ['SDL_VIDEO_WINDOW_POS'] = '400,430'
pygame.display.set_mode((200,200), 16)
pygame.time.wait(2000)
sys.exit()

...but it doesn't work.

On 6/29/07, Luke Paireepinart <[EMAIL PROTECTED]> wrote:


Ian Mallett wrote:
> That still doesn't work either...
Lenard's code was showing how he tested that the environment variable
was ignored except by set_mode.
He did this by setting the variable to various different values, but not
calling set_mode,
and the changing value didn't change the window position.
I.E. he sent the code _because_ it didn't work.

-Luke

Re: [pygame] Starting Window Position

[Luke Paireepinart]

Ian Mallett wrote:

That still doesn't work either...

Lenard's code was showing how he tested that the environment variable
was ignored except by set_mode.
He did this by setting the variable to various different values, but not 
calling set_mode,

and the changing value didn't change the window position.
I.E. he sent the code _because_ it didn't work.

-Luke

[pygame] undeliverable messages

[Luke Paireepinart]

Can an admin remove

<[EMAIL PROTECTED]>

from the mailing list?
I just keep getting bounces from his address every time I post.
Thanks,
-Luke

Re: [pygame] Starting Window Position

[Ian Mallett]

Opps.  Heh.  Heh.  You're right, but changing it doesn't fix my problem.

On 6/29/07, Luke Paireepinart <[EMAIL PROTECTED]> wrote:


Ian Mallett wrote:
> How about a simple python shell code?
>
> import pygame
> import sys, os
> if sys.platform == 'win32':
> os.environ['SDL_VIDEO_WINDOW_POS'] = '3,23'
This sets the window's position
> pygame.display.set_mode((400,50), 16)
This sets the display resolution
>
> now, at this point, if I go:
>
> if sys.platform == 'win32':
> os.environ['SDL_VIDEO_WINDOW_POS'] = '3,23'
This sets the position to the same value it already is
> pygame.display.set_mode((200,200), 16)
This attempts to change the resolution.

Or am I misreading something?
>
> ...the window's position remains at (400,50).
It doesn't appear that you even attempted to change the window's
position, to me.
-Luke

Re: [pygame] Starting Window Position

[Ian Mallett]

That still doesn't work either...

On 6/29/07, Lenard Lindstrom <[EMAIL PROTECTED]> wrote:


Testing shows that on Windows the window position environment variable
is read with the call to pygame.display.set_mode() and ignored otherwise.

"""Try to move the pygame window"""

import pygame
from pygame.locals import *
import os

pygame.init()
font = pygame.font.Font(None, 48)
os.environ['SDL_VIDEO_WINDOW_POS'] = '20,100'
screen = pygame.display.set_mode((200, 100))

screen.fill(Color('white'))
screen.blit(font.render(os.environ['SDL_VIDEO_WINDOW_POS'],
True,
Color('black')),
(10, 10))
pygame.display.flip()
os.environ['SDL_VIDEO_WINDOW_POS'] = '20,100'
pygame.time.wait(3000)

os.environ['SDL_VIDEO_WINDOW_POS'] = '%d,%d' % (120, 200)
screen.fill(Color('white'))
screen.blit(font.render(os.environ['SDL_VIDEO_WINDOW_POS'],
True,
Color('black')),
(10, 10))
pygame.display.flip()
pygame.time.wait(3000)


Ian Mallett wrote:
> It still doesn't work though- it works the first time, and subsequent
> changes to the placement fail.
>
> On 6/28/07, *Lenard Lindstrom* < [EMAIL PROTECTED]
> > wrote:
>
> I admit it was a silly question. The positioning code works on my
> Windows system. I noticed the position is that of the client area.
>
>
> Ian Mallett wrote:
> > Yes...
> >
> > On 6/28/07, *Lenard Lindstrom* <[EMAIL PROTECTED]
> 
> > >> wrote:
> >
> > Ian Mallett wrote:
> > > So I would have the original program start a new one that
> codes the
> > > alternate window?
> > >
> > > The centering code, which is what I tested, works, but
> this doesn't:
> > > os.environ ['SDL_VIDEO_WINDOW_POS'] = 'value,value'
> > >
> > > On 6/28/07, *Brian Fisher* < [EMAIL PROTECTED]
> 
> >  >
> > >  
> >   > >
> > > You can only do that with multiple processes. It's one
> > window per
> > > process for SDL.
> > >
> > > On 6/28/07, Ian Mallett < [EMAIL PROTECTED]
> 
> > mailto:[EMAIL PROTECTED]>>
> > >     > wrote:
> > > > Awesome!  That works!  Thanks!  Just one more question
> > > though...  I want to
> > > > have two or more pygame windows running at the same
> time.  Can
> > > you do that?
> > > > Ian
> > > >
> > >
> > >
> >
> > Do you make the os.environ call before calling pygame.init   ?
> >
>


--
Lenard Lindstrom
<[EMAIL PROTECTED]>

Re: [pygame] Starting Window Position

[Luke Paireepinart]

Ian Mallett wrote:

How about a simple python shell code?

import pygame
import sys, os
if sys.platform == 'win32':
os.environ['SDL_VIDEO_WINDOW_POS'] = '3,23'

This sets the window's position

pygame.display.set_mode((400,50), 16)

This sets the display resolution


now, at this point, if I go:

if sys.platform == 'win32':
os.environ['SDL_VIDEO_WINDOW_POS'] = '3,23'

This sets the position to the same value it already is

pygame.display.set_mode((200,200), 16)

This attempts to change the resolution.

Or am I misreading something?


...the window's position remains at (400,50).
It doesn't appear that you even attempted to change the window's 
position, to me.

-Luke

Re: [pygame] Starting Window Position

[Lenard Lindstrom]

Testing shows that on Windows the window position environment variable 
is read with the call to pygame.display.set_mode() and ignored otherwise.


"""Try to move the pygame window"""

import pygame
from pygame.locals import *
import os

pygame.init()
font = pygame.font.Font(None, 48)
os.environ['SDL_VIDEO_WINDOW_POS'] = '20,100'
screen = pygame.display.set_mode((200, 100))

screen.fill(Color('white'))
screen.blit(font.render(os.environ['SDL_VIDEO_WINDOW_POS'],
   True,
   Color('black')),
   (10, 10))
pygame.display.flip()
os.environ['SDL_VIDEO_WINDOW_POS'] = '20,100'
pygame.time.wait(3000)

os.environ['SDL_VIDEO_WINDOW_POS'] = '%d,%d' % (120, 200)
screen.fill(Color('white'))
screen.blit(font.render(os.environ['SDL_VIDEO_WINDOW_POS'],
   True,
   Color('black')),
   (10, 10))
pygame.display.flip()
pygame.time.wait(3000)


Ian Mallett wrote:
It still doesn't work though- it works the first time, and subsequent 
changes to the placement fail.


On 6/28/07, *Lenard Lindstrom* < [EMAIL PROTECTED] 
> wrote:


I admit it was a silly question. The positioning code works on my
Windows system. I noticed the position is that of the client area.


Ian Mallett wrote:
> Yes...
>
> On 6/28/07, *Lenard Lindstrom* <[EMAIL PROTECTED]

> >> wrote:
>
> Ian Mallett wrote:
> > So I would have the original program start a new one that
codes the
> > alternate window?
> >
> > The centering code, which is what I tested, works, but
this doesn't:
> > os.environ ['SDL_VIDEO_WINDOW_POS'] = 'value,value'
> >
> > On 6/28/07, *Brian Fisher* < [EMAIL PROTECTED]

> >
> > mailto:[EMAIL PROTECTED]>
>  >
> > You can only do that with multiple processes. It's one
> window per
> > process for SDL.
> >
> > On 6/28/07, Ian Mallett < [EMAIL PROTECTED]

> mailto:[EMAIL PROTECTED]>>
> >   wrote:
> > > Awesome!  That works!  Thanks!  Just one more question
> > though...  I want to
> > > have two or more pygame windows running at the same
time.  Can
> > you do that?
> > > Ian
> > >
> >
> >
>
> Do you make the os.environ call before calling pygame.init   ?
>




--
Lenard Lindstrom
<[EMAIL PROTECTED]>

Re: [pygame] FastRenderGroup revised (update4)

[René Dudfield]

Hello,

very nice work!

I'm a bit busy myself for the next week.  So in two weeks would be a good
time to meet up and finish off the last things before we put it into pygame.

1.) Change the name: yes, but to what?

Not sure.  I'm afraid of using 'Fast' because too many times I have seen
projects where there is a new FastSomething only for it to eventually not be
fast anymore a year later.

What are the main features of FastRenderGroup?

We should definitely let people know in the docs that FastRenderGroup is the
preferred group to use.


2.) you really want to be able to pass in different get_ticks()
functions? I can do it, but I do not see the benefit, because I'm still
unhappy with the solution how to decide which method to use. Perhaps I
could use a Exponential back off strategy (do not know how to implement
it), but I'm not sure if that would be good. Any better ideas?

So people can use their own game timers.  Say the rest of the game uses
either time.time, or even something from blender, crystalspace, a real time
clock etc etc.  Should definitely use a default timer though.

The jerking stops for me when I make it not oscillate between update, and
flip modes.  I think maybe an Exponential back off strategy might work...
not too sure.  I think we should try a few different things when we meet up
in two weeks.

Some possible different strategies:
- figure out the best rendering method in the first 1-3 seconds, then stick
with that.
- keep checking to see which is the fastest way.  Only change modes at most
once every 10 seconds.


3.) naming of the attributes of the DirtySprite: we can change them, but
to what? Are the current names already used?

Haven't had a chance to research this.  Let's look at it in two weeks.

4.) I don't think we can make it backwards compatible, so it will not
replace RenderUpdates (unless the pygame.sprite.Sprite becomes the
DirtySprite with dirty=2 as default, but that would be stupid).

Cool, that's fine if we can't.

btw, Gustavo posted about some code he's done for fast sprite usage:
http://renesd.blogspot.com/2007/06/pygame-weekly-mini-sprint-20070620.html#comments

I think his approach is to break the screen up into tiles of 8x8.  Then in
the sprite code mark each tile as dirty, if the sprite needs to be updated
in those positions.  This way there is a constant number of rectangles
passed through to the update function every frame - and no over draw.



On 6/30/07, DR0ID <[EMAIL PROTECTED]> wrote:


Hi

Today I got the time to do the changes you have suggested in the last
email.
You can download it here:

http://www.mypage.bluewin.ch/DR0ID/pygame_projects.html#fast_dirty1
or direct link:
http://www.mypage.bluewin.ch/DR0ID/pygame/FastRenderGroup_v1.1.78.zip



1.) Change the name: yes, but to what?

2.) you really want to be able to pass in different get_ticks()
functions? I can do it, but I do not see the benefit, because I'm still
unhappy with the solution how to decide which method to use. Perhaps I
could use a Exponential back off strategy (do not know how to implement
it), but I'm not sure if that would be good. Any better ideas?

3.) naming of the attributes of the DirtySprite: we can change them, but
to what? Are the current names already used?

4.) I don't think we can make it backwards compatible, so it will not
replace RenderUpdates (unless the pygame.sprite.Sprite becomes the
DirtySprite with dirty=2 as default, but that would be stupid).


I have modified testsprite.py to use FRG, please test following
configurations:

testsprite.py
testsprite.py -update_rects
testsprite.py -FastRenderGroup

testsprite.py -static
testsprite.py -static -update_rects
testsprite.py -static -FastRenderGroup

What do you think? For that tests I have added a new image, as you can
see.

I have written a demo to demonstrate that all sprites have to be in the
same FRG to be drawn correctly:

multi_FRG_demo.py

use the same arguments as for testsprite.py and you will see what
happens when using the FRG.

If you run the testsprite.py you will have the frame jerking too, so it
is not a problem of the FRG. To avoid the jerking you will have to limit
the Framerate to certain frames per second(or put a sleep(0.001) in
there somewhere).


I can not participate at the next minisprint, but in a week I will have
time.


~DR0ID

Re: [pygame] Starting Window Position

[Ian Mallett]

I think that might work also, but it would mess up everything else too
right?  Like the set variables, etc.

On 6/29/07, DR0ID <[EMAIL PROTECTED]> wrote:


Hi

could it be that you can set it only once, before you call pygame.init()
?? Subsequent calls do not change anything afterwards. (perhaps it would
work if you quit pygame, reset the env var again and initialize pygame
to change the position again)

~DR0ID

Ian Mallett schrieb:
> How about a simple python shell code?
>
> import pygame
> import sys, os
> if sys.platform == 'win32':
> os.environ['SDL_VIDEO_WINDOW_POS'] = '3,23'
> pygame.display.set_mode((400,50), 16)
>
> now, at this point, if I go:
>
> if sys.platform == 'win32':
> os.environ['SDL_VIDEO_WINDOW_POS'] = '3,23'
> pygame.display.set_mode((200,200), 16)
>
> ...the window's position remains at (400,50).
>
> On 6/29/07, * Dave LeCompte (really)* <[EMAIL PROTECTED]
> > wrote:
>
> "Ian Mallett" <[EMAIL PROTECTED] >
> wrote:
> > It still doesn't work though- it works the first time, and
> subsequent
> > changes to the placement fail.
>
> Can you describe what the problem you're seeing is a little more?
> You're
> setting the initial position using the SDL environment variable
> method,
> and after the first time you run the script, the initial position
> isn't
> being set?
>
> Can you send a minimal piece of code that demonstrates the problem?
>
>
> Dave LeCompte
>
>

Re: [pygame] Starting Window Position

[DR0ID]

Hi

could it be that you can set it only once, before you call pygame.init() 
?? Subsequent calls do not change anything afterwards. (perhaps it would 
work if you quit pygame, reset the env var again and initialize pygame 
to change the position again)


~DR0ID

Ian Mallett schrieb:

How about a simple python shell code?

import pygame
import sys, os
if sys.platform == 'win32':
os.environ['SDL_VIDEO_WINDOW_POS'] = '3,23'
pygame.display.set_mode((400,50), 16)

now, at this point, if I go:

if sys.platform == 'win32':
os.environ['SDL_VIDEO_WINDOW_POS'] = '3,23'
pygame.display.set_mode((200,200), 16)

...the window's position remains at (400,50).

On 6/29/07, * Dave LeCompte (really)* <[EMAIL PROTECTED] 
> wrote:


"Ian Mallett" <[EMAIL PROTECTED] >
wrote:
> It still doesn't work though- it works the first time, and
subsequent
> changes to the placement fail.

Can you describe what the problem you're seeing is a little more?
You're
setting the initial position using the SDL environment variable
method,
and after the first time you run the script, the initial position
isn't
being set?

Can you send a minimal piece of code that demonstrates the problem?


Dave LeCompte

Re: [pygame] Starting Window Position

[Ian Mallett]

How about a simple python shell code?

import pygame
import sys, os
if sys.platform == 'win32':
   os.environ['SDL_VIDEO_WINDOW_POS'] = '3,23'
pygame.display.set_mode((400,50), 16)

now, at this point, if I go:

if sys.platform == 'win32':
   os.environ['SDL_VIDEO_WINDOW_POS'] = '3,23'
pygame.display.set_mode((200,200), 16)

...the window's position remains at (400,50).

On 6/29/07, Dave LeCompte (really) <[EMAIL PROTECTED]> wrote:


"Ian Mallett" <[EMAIL PROTECTED]> wrote:
> It still doesn't work though- it works the first time, and subsequent
> changes to the placement fail.

Can you describe what the problem you're seeing is a little more? You're
setting the initial position using the SDL environment variable method,
and after the first time you run the script, the initial position isn't
being set?

Can you send a minimal piece of code that demonstrates the problem?


Dave LeCompte

Re: [pygame] Starting Window Position

[Juan José Alonso.]

on my machine windows xp sp2 not run.

2007/6/29, Ian Mallett <[EMAIL PROTECTED]>:


It still doesn't work though- it works the first time, and subsequent
changes to the placement fail.

On 6/28/07, Lenard Lindstrom < [EMAIL PROTECTED]> wrote:
>
> I admit it was a silly question. The positioning code works on my
> Windows system. I noticed the position is that of the client area.
>
>
> Ian Mallett wrote:
> > Yes...
> >
> > On 6/28/07, *Lenard Lindstrom* <[EMAIL PROTECTED]
> > > wrote:
> >
> > Ian Mallett wrote:
> > > So I would have the original program start a new one that codes
> the
> > > alternate window?
> > >
> > > The centering code, which is what I tested, works, but this
> doesn't:
> > > os.environ ['SDL_VIDEO_WINDOW_POS'] = 'value,value'
> > >
> > > On 6/28/07, *Brian Fisher* < [EMAIL PROTECTED]
> > 
> > >  > >> wrote:
> > >
> > > You can only do that with multiple processes. It's one
> > window per
> > > process for SDL.
> > >
> > > On 6/28/07, Ian Mallett < [EMAIL PROTECTED]
> > 
> > > >>
> > wrote:
> > > > Awesome!  That works!  Thanks!  Just one more question
> > > though...  I want to
> > > > have two or more pygame windows running at the same
> time.  Can
> > > you do that?
> > > > Ian
> > > >
> > >
> > >
> >
> > Do you make the os.environ call before calling pygame.init   ?
> >
> > --
> > Lenard Lindstrom
> > <[EMAIL PROTECTED] >
> >
> >
>
>
> --
> Lenard Lindstrom
> < [EMAIL PROTECTED]>
>
>




--
Juan José Alonso. KarlsBerg.
eMail: [EMAIL PROTECTED]
MSN: [EMAIL PROTECTED]

Re: [pygame] Starting Window Position

[Dave LeCompte (really)]

"Ian Mallett" <[EMAIL PROTECTED]> wrote:
> It still doesn't work though- it works the first time, and subsequent
> changes to the placement fail.

Can you describe what the problem you're seeing is a little more? You're
setting the initial position using the SDL environment variable method,
and after the first time you run the script, the initial position isn't
being set?

Can you send a minimal piece of code that demonstrates the problem?


Dave LeCompte

Re: [pygame] Starting Window Position

[Ian Mallett]

It still doesn't work though- it works the first time, and subsequent
changes to the placement fail.

On 6/28/07, Lenard Lindstrom <[EMAIL PROTECTED]> wrote:


I admit it was a silly question. The positioning code works on my
Windows system. I noticed the position is that of the client area.


Ian Mallett wrote:
> Yes...
>
> On 6/28/07, *Lenard Lindstrom* <[EMAIL PROTECTED]
> > wrote:
>
> Ian Mallett wrote:
> > So I would have the original program start a new one that codes
the
> > alternate window?
> >
> > The centering code, which is what I tested, works, but this
doesn't:
> > os.environ ['SDL_VIDEO_WINDOW_POS'] = 'value,value'
> >
> > On 6/28/07, *Brian Fisher* <[EMAIL PROTECTED]
> 
> >  >> wrote:
> >
> > You can only do that with multiple processes. It's one
> window per
> > process for SDL.
> >
> > On 6/28/07, Ian Mallett < [EMAIL PROTECTED]
> 
> > >>
> wrote:
> > > Awesome!  That works!  Thanks!  Just one more question
> > though...  I want to
> > > have two or more pygame windows running at the same
time.  Can
> > you do that?
> > > Ian
> > >
> >
> >
>
> Do you make the os.environ call before calling pygame.init   ?
>
> --
> Lenard Lindstrom
> <[EMAIL PROTECTED] >
>
>


--
Lenard Lindstrom
<[EMAIL PROTECTED]>

[pygame] FastRenderGroup revised (update4)

[DR0ID]

Hi

Today I got the time to do the changes you have suggested in the last email.
You can download it here:

http://www.mypage.bluewin.ch/DR0ID/pygame_projects.html#fast_dirty1
or direct link:
http://www.mypage.bluewin.ch/DR0ID/pygame/FastRenderGroup_v1.1.78.zip



1.) Change the name: yes, but to what?

2.) you really want to be able to pass in different get_ticks() 
functions? I can do it, but I do not see the benefit, because I'm still 
unhappy with the solution how to decide which method to use. Perhaps I 
could use a Exponential back off strategy (do not know how to implement 
it), but I'm not sure if that would be good. Any better ideas?


3.) naming of the attributes of the DirtySprite: we can change them, but 
to what? Are the current names already used?


4.) I don't think we can make it backwards compatible, so it will not 
replace RenderUpdates (unless the pygame.sprite.Sprite becomes the 
DirtySprite with dirty=2 as default, but that would be stupid).



I have modified testsprite.py to use FRG, please test following 
configurations:


testsprite.py
testsprite.py -update_rects
testsprite.py -FastRenderGroup

testsprite.py -static
testsprite.py -static -update_rects
testsprite.py -static -FastRenderGroup

What do you think? For that tests I have added a new image, as you can see.

I have written a demo to demonstrate that all sprites have to be in the 
same FRG to be drawn correctly:


multi_FRG_demo.py

use the same arguments as for testsprite.py and you will see what 
happens when using the FRG.


If you run the testsprite.py you will have the frame jerking too, so it 
is not a problem of the FRG. To avoid the jerking you will have to limit 
the Framerate to certain frames per second(or put a sleep(0.001) in 
there somewhere).



I can not participate at the next minisprint, but in a week I will have 
time.



~DR0ID