Re: [pygame] What's next for Pygame project?

2015-07-13 Thread Peter Shinners
I like the sound of all of this. On 07/13/2015 06:02 AM, René Dudfield wrote: Hi, a few notes: * I have dropped the ball, but would like to finish the new website and get 1.9.2 out the door. * pygame_sdl2 seems the best choice going forward. For backward compat reasons, platform su

Re: [pygame] What's next for Pygame project?

2015-07-13 Thread Jason Marshall
René, What aspects of being the lead developer & website maintainer give you enjoyment and pride?And which parts of your roles are a bore or a nuisance to you? I want to help you to find the job in the pygame community that gives you the most satisfaction and maximizes the impact of your talents

Re: [pygame] erratic behavior with 'display.update(Rect)'

2015-07-13 Thread Ian Mallett
On Mon, Jul 13, 2015 at 5:34 PM, Tom Rothamel wrote: > There isn't a way to update a portion of the display using OpenGL. OpenGL > expects you to redraw the screen from scratch every frame, and then flip to > the next frame. > > How are you drawing to the screen? Are you using GL calls? Or pygame

Re: [pygame] erratic behavior with 'display.update(Rect)'

2015-07-13 Thread Tom Rothamel
On Mon, Jul 13, 2015 at 6:54 PM tom arnall wrote: > > If display.update()' doesn't work with OPENGL, what do you use to > update just one area of the display? > > > There isn't a way to update a portion of the display using OpenGL. OpenGL expects you to redraw the screen from scratch every frame,

[pygame] erratic behavior with 'display.update(Rect)'

2015-07-13 Thread tom arnall
Greetings! I am seeing what seems to be erratic behavior with 'display.update()' when used with a Rect argument. In all cases but one, it works fine with 'display.update()'. In the exception case, it has no effect on the referenced Rect area. MY QUESTIONS Is it possible that the cause is that OP

Re: [pygame] What's next for Pygame project?

2015-07-13 Thread Ian Mallett
Hi, ​As a long-time member here, I recall many *many* different attempts to redesign the website. Three in memory, which is several years. Probably more if I looked through my archives. The model is that someone gets fed up with the current design and mentions it on this list. There's some discus

Re: [pygame] What's next for Pygame project?

2015-07-13 Thread Daniel Foerster
I'll look at it, but 2009 is still pre-HTML5/CSS3. On 07/13/2015 05:15 PM, Jason Marshall wrote: In 2009, there was a prototype of a redesign of the pygame website. It was written in Python (Django) instead of PHP (SiteSwing). The redesign was not adopted and the people who had worked it lost

Re: [pygame] What's next for Pygame project?

2015-07-13 Thread Jason Marshall
In 2009, there was a prototype of a redesign of the pygame website. It was written in Python (Django) instead of PHP (SiteSwing). The redesign was not adopted and the people who had worked it lost interest in volunteering and left the pygame community.  http://article.gmane.org/gmane.comp.pyth

Re: [pygame] What's next for Pygame project?

2015-07-13 Thread Daniel Foerster
On 07/12/2015 10:05 AM, Paul Vincent Craven wrote: * I don't think a Pygame website needs to be build on Python. I've got the pygame.info domain and I think a Wordpress site that has several verified contributers would be the way to go. Share the 'love' and eff

Re: [pygame] Problem with pytmx and tiled

2015-07-13 Thread Daniel Foerster
On 07/13/2015 09:01 AM, ck421 wrote: Hello, I am new to these forums and to pygame in general. I have been trying to use pytmx in order to load in a tiled .tmx file but I keep getting this error: File "C:\Python32\lib\site-packages\pytmx\pytmx.py", line 258, in __init__ self.parse_xml(Elem

Re: [pygame] What's next for Pygame project?

2015-07-13 Thread Lenard Lindstrom
Hi, On 15-07-13 04:09 AM, Jake b wrote: cases. ​ ​I expect much of the code that defines extension classes will be rewritten. Pygame extensions to SDL, such as custom blitters, may be salvaged. ​ Much of the work will be writing code to support the new SDL 2.0 features.

Re: [pygame] Problem with pytmx and tiled

2015-07-13 Thread Ian Mallett
​Assuming you're using a PyTMX version > 2.16.5, this looks like a bug in its Python 3 support. I'd try replacing "data = b64decode(data_node.text.strip())" with something like "data = b64decode(data_node.text.strip().encode())" and seeing if that improves anything. But this isn't a PyGame issue.

[pygame] Problem with pytmx and tiled

2015-07-13 Thread ck421
Hello, I am new to these forums and to pygame in general. I have been trying to use pytmx in order to load in a tiled .tmx file but I keep getting this error: File "C:\Python32\lib\site-packages\pytmx\pytmx.py", line 258, in __init__ self.parse_xml(ElementTree.parse(self.filename).getroot())

Re: [pygame] What's next for Pygame project?

2015-07-13 Thread René Dudfield
Hi, a few notes: - I have dropped the ball, but would like to finish the new website and get 1.9.2 out the door. - pygame_sdl2 seems the best choice going forward. For backward compat reasons, platform support, and C/asm code is needed. Many things have been put into SDL and relate

Re: [pygame] What's next for Pygame project?

2015-07-13 Thread René Dudfield
The cffi bindings have the downside that iOS doesn't work. On Sun, Jul 12, 2015 at 5:15 AM, Peter Shinners wrote: > The cffi style bindings would be so tempting because they get away from > all the binary challenges. Originally, the SDL bindings needed some utility > C code to be useful. After a

Re: [pygame] What's next for Pygame project?

2015-07-13 Thread Jake b
> cases. > ​​I expect much of the code that defines extension classes will be > rewritten. Pygame extensions to SDL, such as custom blitters, may be > salvaged. > ​Much of the work will be writing code to support the new SDL 2.0 features. > ​ > > ​​ ​There's also the problem of Texture vs Surfaces

Re: [pygame] What's next for Pygame project?

2015-07-13 Thread Jake b
Correct me if I'm wrong, but it appears you are using SDL_Surface instead of SDL_Textures? https://wiki.libsdl.org/MigrationGuide#If_your_game_just_wants_to_get_fully-rendered_frames_to_the_screen > One problem is blend modes - many of the pygame blend modes, including the default alphablend mode