Re: [pygame] Documenting the pygame C API and making the API consistent

[Lenard Lindstrom]

I know from experience how much more of a headache it is to 
build/distribute native extensions that depend on other native 
extensions' ABIs (numpy, specifically).


Do Pygame Surface/Sound objects support the Buffer Protocol? This 
would be a convenient way to to read and update object data without 
needing to compile against Pygame.

Pygame has better buffer support than Python 3.
To be clear, pygame Surfaces and Sound objects export their data with 
the New Buffer Protocol. The numpy specific surfarray and sndarray 
modules are wrappers for the buffer based pixelcopy module. At the time 
when I added New Buffer support to pygame, it was better developed than 
that provided by the Python 3 buffer object.


Lenard Lindstrom

Re: [pygame] Documenting the pygame C API and making the API consistent

[Lenard Lindstrom]

On 18-06-18 01:45 AM, Daniel Pope wrote:

Is this for a public C API or just internal to Pygame?
It is internal to Pygame, though if it is formalized and documented 
someone might use it in another package.




I know from experience how much more of a headache it is to 
build/distribute native extensions that depend on other native 
extensions' ABIs (numpy, specifically).


Do Pygame Surface/Sound objects support the Buffer Protocol? This 
would be a convenient way to to read and update object data without 
needing to compile against Pygame.

Pygame has better buffer support than Python 3.



On Sun, 17 Jun 2018, 12:19 Thomas Kluyver, <mailto:tak...@gmail.com>> wrote:


I'm not really familiar with C APIs, but I thought that the 0/-1
inconsistency was necessary because 0 may be a valid return value
in some contexts, and there is no -1 if you're using a unsigned
integer type. Looking quickly at the Python docs, the pattern
seems to be that functions returning a pointer return NULL on
error, and the rest use -1 to indicate an error - though I don't
know if that's always followed.

I would think that API changes don't belong in a 1.9.x release,
but that's not my decision. :-)

On 15 June 2018 at 23:45, Lenard Lindstrom mailto:le...@telus.net>> wrote:

Hi everyone,

A part of the preparation for pygame 2 I have documented the
functions and types exported by various pygame extension
modules. For instance, the pygame.surface module exports C
functions for creating and accessing pygame.Surface instances.
These are used in other modules, such as pygame.display and
pygame.image, where surfaces are created. In total, twelve
extension modules make C functions available for use in other
extension modules.

While documenting the C API I renamed C types, functions, and
variables to be consistent with Python's PEP 7. Names starting
with 'Py' and 'Pg' were changed to use the 'pg' prefix. This
avoids conflicts with possible future Python C functions as
well as make the pygame naming convention consistent. I have
also found other inconsistencies in the pygame C API.
Functions that return a Python object are consistent in
returning NULL to indicate an error. However, for functions
that return an error code, some may use -1 to indicate an
error, while others use 0. Should I make an effort to make
pygame error handling consistent within the C API? Would it
make sense to do this before pygame 1.9.4 is released, or wait
until pygame 2? Python is not much help since it has mixed
error codes within its C API.

Lenard Lindstrom

Re: [pygame] Documenting the pygame C API and making the API consistent

[Lenard Lindstrom]

Hi Thomas,

On 18-06-17 03:17 AM, Thomas Kluyver wrote:
I'm not really familiar with C APIs, but I thought that the 0/-1 
inconsistency was necessary because 0 may be a valid return value in 
some contexts, and there is no -1 if you're using a unsigned integer 
type. Looking quickly at the Python docs, the pattern seems to be that 
functions returning a pointer return NULL on error, and the rest use 
-1 to indicate an error - though I don't know if that's always followed.


The most obvious example I found of returning 0 on failure are the 
Python function argument parsing functions, such as int 
PyArg_ParseTupleAndKeywords(...), which return true on success, or raise 
a Python exception and return false. This is contrary to many other 
functions, such as int PyObject_SetAttr(...), which returns 0 on 
success, -1 on failure. But yes, numeric version functions, such as 
double PyFloat_AsDouble(...) and Py_ssize_t PyNumber_AsSsize_t (...) 
also return -1 on failure.


I would think that API changes don't belong in a 1.9.x release, but 
that's not my decision. :-)
I am in no rush to change the pygame C API. If changes are made, they 
can wait until pygame 2.


Lenard Lindstrom




On 15 June 2018 at 23:45, Lenard Lindstrom <mailto:le...@telus.net>> wrote:


Hi everyone,

A part of the preparation for pygame 2 I have documented the
functions and types exported by various pygame extension modules.
For instance, the pygame.surface module exports C functions for
creating and accessing pygame.Surface instances. These are used in
other modules, such as pygame.display and pygame.image, where
surfaces are created. In total, twelve extension modules make C
functions available for use in other extension modules.

While documenting the C API I renamed C types, functions, and
variables to be consistent with Python's PEP 7. Names starting
with 'Py' and 'Pg' were changed to use the 'pg' prefix. This
avoids conflicts with possible future Python C functions as well
as make the pygame naming convention consistent. I have also found
other inconsistencies in the pygame C API. Functions that return a
Python object are consistent in returning NULL to indicate an
error. However, for functions that return an error code, some may
use -1 to indicate an error, while others use 0. Should I make an
effort to make pygame error handling consistent within the C API?
Would it make sense to do this before pygame 1.9.4 is released, or
wait until pygame 2? Python is not much help since it has mixed
error codes within its C API.

    Lenard Lindstrom

[pygame] Documenting the pygame C API and making the API consistent

[Lenard Lindstrom]

Hi everyone,

A part of the preparation for pygame 2 I have documented the functions 
and types exported by various pygame extension modules. For instance, 
the pygame.surface module exports C functions for creating and accessing 
pygame.Surface instances. These are used in other modules, such as 
pygame.display and pygame.image, where surfaces are created. In total, 
twelve extension modules make C functions available for use in other 
extension modules.


While documenting the C API I renamed C types, functions, and variables 
to be consistent with Python's PEP 7. Names starting with 'Py' and 'Pg' 
were changed to use the 'pg' prefix. This avoids conflicts with possible 
future Python C functions as well as make the pygame naming convention 
consistent. I have also found other inconsistencies in the pygame C API. 
Functions that return a Python object are consistent in returning NULL 
to indicate an error. However, for functions that return an error code, 
some may use -1 to indicate an error, while others use 0. Should I make 
an effort to make pygame error handling consistent within the C API? 
Would it make sense to do this before pygame 1.9.4 is released, or wait 
until pygame 2? Python is not much help since it has mixed error codes 
within its C API.


Lenard Lindstrom

Re: [pygame] Pygame for SDL 2, and how it may look.

[Lenard Lindstrom]

On 17-04-20 05:32 PM, Greg Ewing wrote:

Lenard Lindstrom wrote:
Unfortunately, the special parser machinery to support Cython 
includes is only implemented at the module level. It was never 
generalized to work in any code block.


The include statement in Pyrex was something of a hack that I
used for sharing declarations before the cimport mechanism
existed. I regarded it as more or less obsolete after that
and didn't develop it any further.

You could put in a feature request to the Cython developers.

I did consider submitting a patch. But since the consensus is to have a 
distinct Window class, there is no need for it in Pygame. But, just for 
the fun of it, I would like to add a proper mixin system like D's, 
possibly with parameters:


def mixin foo(a):

def f(self, x):

return self.a * x


class C:

def __init__(v):

self.v = v


mixin foo(v)


Just a thought.

Re: [pygame] Pygame for SDL 2, and how it may look.

[Lenard Lindstrom]

Hi Marcus,

I was certain I had read about restrictions regarding a window's surface 
and a renderer. But I can't find anything in the SDL API docs.


Lenard Lindstrom

On 17-04-20 10:14 AM, Marcus von Appen wrote:



On 4/20/2017 8:13:22 AM, "Greg Ewing" <greg.ew...@canterbury.ac.nz> 
wrote:



Lenard Lindstrom wrote:
However, after a bit of experimenting I find a window can have both 
a renderer and a display surface.


In that case, I'd suggest the Window object should have
'renderer' and 'surface' attributes. If the Renderer or
Surface keeps a reference back to the window, it should
probably be a weak reference, so that they won't keep
each other alive.


You (not necessarily pointed towards Greg) definitely should dig deeper
into the SDL renderer API.

Renderers can be created for windows, surfaces (and window surfaces).
You can retrieve a renderer for a window (via SDL_GetRenderer()).

Avoid pythonic OO pitfalls, which will create a reference mess. Keep
both, renderers and windows separate and use dynamic properties
(if necessary) instead.

Personally, I'd leave it up to the user code instead of getting in the
way.

Cheers
Marcus

Re: [pygame] Pygame for SDL 2, and how it may look.

[Lenard Lindstrom]

Hi Greg,

On 17-04-19 11:06 PM, Greg Ewing wrote:

Lenard Lindstrom wrote:
Extension type WindowSurface would add an SDL window C pointer to its 
pygame.Surface parent. This window pointer cannot be factored out 
into a separate WindowBase parent class. And any methods which access 
that pointer will be specific to WindowSurface's C structure type.


And consequently, it would be impossible to write code that
generically works with either type of window at the C level
without going through Python method or property dispatch.

* Cython has an include statement. Unfortunately, include statements 
are not allowed in class declarations.


Even if it worked, the effect would be no different from
writing out a copy of the code in each class. You would still
have two unrelated sets of fields with different offsets.

Splitting it into two objects sounds like the best solution
to me. Then you can have a Window object with the same interface
whether it has a Renderer or a Surface attached, and a Renderer
with the same interface whether it's attached to a Window
or something else.

I was thinking of a generic mixin rather than a shared functions mixin. 
Code written in one place, a .pxi file, gets duplicated in multiple 
classes by including it in each class declaration body. Unfortunately, 
the special parser machinery to support Cython includes is only 
implemented at the module level. It was never generalized to work in any 
code block. What irked me is this restriction is not mentioned in the 
Cython docs. So with anticipation of having found a simple solution to 
my problem I am greeted with a "include statement not allowed here" 
compiler error.


Lenard

Re: [pygame] Pygame for SDL 2, and how it may look.

[Lenard Lindstrom]

Thanks for the link. I had not even thought of OpenGL yet. OpenGL was 
something to be tackled later.


One thing to note though, a programming choice in C may not make sense 
in a higher level language such as Python. C encourages choices based on 
physical data representations. Python types and objects allow for 
abstractions independent of physical representation. So Classes can be 
designed around what you want to do, not what you are actually working 
on. Too me, if there was a strict one-to-one relation between a window 
and a renderer, then why not have an object that can be both a renderer 
and a window.


But yes, if a separate Window and Renderer is more intuitive to most 
people, then that is the way to go. Anyway, the complicated, and unclear 
to me, window/renderer relationship makes a combined object a 
questionable choice.


Lenard Lindstrom

On 17-04-19 10:54 PM, Leif Theden wrote:
While I have not personally tested it, there seems to be more evidence 
that windows can contain (use?  manage?) more than one Renderer:


https://forums.libsdl.org/viewtopic.php?t=10187=0=asc=15=3fe959dc04bb7cd484c3ee453df8f5de


I'll just stop the back-and-forth and say that I don't support 
RendererWindow, but I support separate Window and Renderer objects.


On Wed, Apr 19, 2017 at 11:12 PM, Lenard Lindstrom <le...@telus.net 
<mailto:le...@telus.net>> wrote:


Hello,

On 17-04-19 04:26 PM, Leif Theden wrote:

While I can understand why you wouldn't like the create_
syntax, I'm not convinced that combining the window and the
renderer makes sense for the API. As was mentioned, a window
can have multiple renderers (or none at all!), so I'm not sure
what combining them together grants for pygame users.


No, a window can have only one renderer at a time. And a renderer
will have only one window in its lifetime.

However, after a bit of experimenting I find a window can have
both a renderer and a display surface. This does support a
separate window object. Whether or not it is useful, I don't know.

Anyway, I am still getting a handle on SDL 2, so don't favor any
particular approach yet.


Lenard Lindstrom

Re: [pygame] Pygame for SDL 2, and how it may look.

[Lenard Lindstrom]

Hello,

On 17-04-19 04:26 PM, Leif Theden wrote:
While I can understand why you wouldn't like the create_ syntax, 
I'm not convinced that combining the window and the renderer makes 
sense for the API.  As was mentioned, a window can have multiple 
renderers (or none at all!), so I'm not sure what combining them 
together grants for pygame users.


No, a window can have only one renderer at a time. And a renderer will 
have only one window in its lifetime.


However, after a bit of experimenting I find a window can have both a 
renderer and a display surface. This does support a separate window 
object. Whether or not it is useful, I don't know.


Anyway, I am still getting a handle on SDL 2, so don't favor any 
particular approach yet.



Lenard Lindstrom

Re: [pygame] Pygame for SDL 2, and how it may look.

[Lenard Lindstrom]

Hi,

On 17-04-19 03:23 PM, Daniel Foerster wrote:


On 04/19/2017 01:16 AM, Lenard Lindstrom wrote:


Now I have experimented with separate Window and Renderer. I found a 
somewhat acceptable solution to the problems mentioned above. But it 
still felt clunky. Then, when I combined the window and renderer into 
on class, much of the complexity went away. The only real downside is 
that the window management code, the window method definitions, will 
be duplicated in both the WindowRenderer and WindowSurface classes. 
But then that is just cut and paste, provide one remembers to do it.


Why cut and paste when you can factor it out into a WindowBase class?


Extension type WindowSurface would add an SDL window C pointer to its 
pygame.Surface parent. This window pointer cannot be factored out into a 
separate WindowBase parent class. And any methods which access that 
pointer will be specific to WindowSurface's C structure type. The 
Renderer extension type will differ from Surface, so the WindowRenderer 
subclass will also differ from WindowSurface.


What is missing are mixins. I am writing new code in Cython. I believed 
I had found a way to create a rudimentary mixin, but it failed*. Anyway, 
I am still trying to make sense of SDL 2, so I may find a functional 
reason to keep windows and renderers separate in Pygame.



* Cython has an include statement. Unfortunately, include statements are 
not allowed in class declarations.


Lenard Lindstrom

Re: [pygame] Pygame for SDL 2, and how it may look.

[Lenard Lindstrom]

Hi Leif,

On 17-04-18 09:10 AM, Leif Theden wrote:
The renderer should have its own class, and for simplicity, I think it 
should be instanced by calling a method on the window that contains 
it.  Just preference.


Having both a Window and a Renderer class makes sense if renderers are 
cheap to create and discard. For practical purposes, a window's renderer 
will live as long as it's window. If a Window class has a 
create_renderer() method, then what happens when it is called more then 
once. Also, what happens to the renderer instance when the window is 
closed. Does the renderer keep a reference to the Window? Does the 
Window keep a reference to the renderer? How is a reference cycle prevented?


To complicate matters, a window can have a display surface instead of a 
renderer. So we add a create_surface() method. Now the Window class must 
track whether it has a renderer or a surface. And a Pygame Surface does 
not know about windows. So if we want the Surface instance to reference 
a window we need a new WindowSurface subclass.


My thinking is if we need a WindowSurface to reference a window, then it 
can directly manage the SDL window as well. The same goes for a 
WindowRenderer Renderer subclass. Everything relating to a particular 
window is in one convenient place. And when the window is closed, there 
is only one, not two, dead objects lying around.


Now I have experimented with separate Window and Renderer. I found a 
somewhat acceptable solution to the problems mentioned above. But it 
still felt clunky. Then, when I combined the window and renderer into on 
class, much of the complexity went away. The only real downside is that 
the window management code, the window method definitions, will be 
duplicated in both the WindowRenderer and WindowSurface classes. But 
then that is just cut and paste, provide one remembers to do it.


Lenard Lindstrom

Renderer does not below with the draw module, because it is not for 
drawing lines, and primitives on software surface.  It is a 
cross-platform and simple API for high-speed accelerated graphics with 
textures and includes some facilities for drawing primitives.


==
What about something like this?


import pygame as pg

window = pg.display.new_window()# new Window class method
screen = pg.display.set_mode(...)   # creates a new window, return 
surface


renderer = window.create_renderer() # renderer, yay!
renderer = pg.renderer.Renderer(window) # alternative. "window" optional


surf = pg.image.load(filename)
texture = renderer.create_texture(surface=surf)   # clean syntax?
texture = pg.texture.from_surface(surface, renderer)  # alternative, 
"renderer" optional



while running:
renderer.clear()# you should do this each frame

   for tex, rect in textures:
renderer.render_copy(tex, rect)  # this is analogous to "blit", 
but is HW accel'd


renderer.present()  # like display.flip()


==
# texture sprites

sprite = pg.sprite.TextureSprite()
sprite.texture = tex
sprite.rect = text.get_rect()
sprite.origin = 0, 0  # where the origin of texture is
sprite.rotation = 76  # rotation of the sprite

group = renderer.create_group(all_the_sprites, flags=0xDEADBEEF)  # clean?
group = pg.sprite.TextureSpriteGroup(renderer) # alternative

==
# sample of a SpriteGroup
# Group.add

if hasattr(sprite, 'texture'):
raise ICannotDoThatDaveError   # legacy group will not render a 
texture sprite



# TextureSpriteGroup.draw
for sprite in self._hw_sprites:
renderer.render_copy_ex(sprite.tex,
None,
sprite.rect,
sprite.rotation,
sprite.origin,
sprite.flipped)

The group module should become simplified.  Choose a group type that 
works well for software sprites, and develop a new one for Renderers.  
Add some checks to legacy groups to prevent Sprites with textures from 
being added.


==

# pygame.display will be an alias for a Window


pygame.init()
window = pygame.display.get_window(0)   # return instance of created 
window


>>> window is pygame.display
True


==
# Consider the following

  * When a renderer is created for a window, the window will raise an
exception if a blit or draw is attempted on it.
  * All windows are py1 until a renderer is created on it.
  * Once renderer is created, leave window in renderer mode. (or not?)
  * Blits between software surfaces will always work, regardless of
the window mode.

screen = pg.display.set_mode(...)  # automatic py1 window
screen.blit(legacy_cruft) # works!

renderer = pg.display.create_renderer()  # works b/c display is alias 
to first window
renderer = pg.renderer.Renderer()# imp

Re: [pygame] Pygame for SDL 2, and how it may look.

[Lenard Lindstrom]

Hi Gumm,

Renderers and textures will be a part of Pygame. They will be new 
features rather than disguised as blits to a display surface. SDL 2 
supports display surface as well, so Pygame will continue to do so as 
well. My intention is add all this, plus multi-window support, with the 
addition of new classes to what already exists in Pygame.


An SDL Window can have only one rendering context, or renderer. Now a 
renderer can have multiple textures, with render mode a per-texture 
feature. All that will be supported.


Lenard Lindstrom

On 17-04-17 04:17 PM, B W wrote:

Hi, Leonard,

If you're talking HW textures (which require a hardware display 
context), one can have multiple renderers; and it can be beneficial to 
do so. The renderer determines blend mode and other aspects. It could 
be more manageable and preferable to have a renderer for every 
occasion, so to speak.


Textures are not very compatible with the surface paradigm. It would 
behoove us to examine these side by side, and figure out a way to 
foster both. Surface code will likely just drop in if you keep the 
same API, but working with textures is a departure from the surface 
workflow. We do not want to try and make textures behave like 
surfaces, or vice versa. E.g. one does not blit a texture, and one 
does not flip the screen buffer. It requires one to be cognizant of 
what data structure one is dealing with.


IMO, support for textures should not be an afterthought. They are a 
premiere feature of SDL2, and will likely be appreciated and preferred 
as people delve into them. You folks are probably already realizing 
this at least a little bit. If so, then good. :)

Re: [pygame] Pygame for SDL 2, and how it may look.

[Lenard Lindstrom]

Hi again,

On 17-04-17 07:59 AM, Ian Mallett wrote:
On Mon, Apr 17, 2017 at 12:01 AM, Lenard Lindstrom <le...@telus.net 
<mailto:le...@telus.net>> wrote:


​Is it possible to combine the renderer with the window? I
don't see why the renderer needs to be pulled out of the
pygame.draw module, and indeed, this could be confusing for
existing code.

I don't quite understand. The renderer associated with the
RendererWindow instance is returned by the window's renderer property.

Why are the window and the renderer separate objects? There is a
one-to-one relation between a window and its renderer or a display
surface. And a window cannot have both. To avoid duplicating a
bunch of window specific methods I created a Window class, with
RendererWindow and SurfaceWindow (not shown) as subclasses. Also,
a surface can have a renderer, and a combined surface-renderer
object makes no sense. Still, I haven't ruled out renderer-window
and surface-window types yet. However it is done, I don't see an
elegant representation of the relationships among SDL windows,
surfaces, renders, and textures.


​I guess I'm asking why they have to be separate objects. At the OS 
level, there's a region of the screen which is backed either by a 
software buffer and managed by the compositor or a GPU buffer managed 
by the compositor via the graphics context. It's a buffer either way, 
and the difference is sortof only where it lives and what operations 
are fast on it.


I agree that a window and its renderer or a window and its display 
surface belong together as a single object. And I am looking at doing 
that now. It is just I am now running into the limitations of Python and 
Cython. Extension types only support single inheritance. To add full 
window support—title, hiding, resizing, brightness, and more—to both a 
Surface subclass and a Renderer subclass means duplicating all that 
window specific code for both subclass declarations. If Cython supported 
mixins (and I thought it could, but no such luck), it would be easy. It 
just seemed safer avoid code duplication with a Window class instead.


So, it's not really clear to me what a "renderer" is (I guess it's 
supposed to wrap the graphics context?).
According to the SDL Wiki, a renderer is for "2D accelerated 
rendering"[1]. It "[s]upports easy rotation, scaling and alpha blending, 
all accelerated using modern 3D APIs".[2] I guess it uses the GPU to 
manipulate textures loaded into video memory. At least that is what the 
C api suggests. And I don't see how it can be made to resemble surface 
blits.




Separately, I was thinking also that anything that does "rendering" 
ought to be combined with pygame.draw, because principle of least 
astonishment. However, this sortof depends on the new drawing API, and 
whether it can/should remain backward compatible with pygame.draw.
A SDL 2 renderer has little to do with pygame.draw. A renderer is a 
collection of textures and some functions to draw them to a window.




For maximum backcompatibility, something like the following
would seem to fit better with the existing API:

surf1 = pygame.display.Window(rect1,flags)
surf2 = pygame.display.Window(rect2,flags)
#...
surf1.blit(...)
surf2.blit(...)
#...
pygame.display.flip()

I don't recall what was decided about the feasibility of
implementing SDL2-style or hardware-accelerated rendering, but
I'd hazard that this sort of API wouldn't map well to it.
OTOH, I don't think the decision to implement a modern
graphics interface was decided in the first place (just that
we're currently adding some SDL2 stuff).

The user can choose either a renderer or a display surface for a
window. And pixels can be copied between textures and surfaces. So
hardware accelerated rendering is available, as shown in the example.

As for set_mode(), flip(), and update(), they remain in Pygame SDL
2. Keeping as much of the Pygame SDL 1 API in Pygame SDL 2 is a
priority. This example explores how new SDL 2 specific
capabilities can be added to Pygame. It uses a Python feature
unavailable when Pygame was created, the new-style class.


​My point was more that the proposed API substantially changes the way 
programming in pygame feels. I don't know; maybe this is necessary.​
It will if using a renderer and textures or opening multiple windows. 
But the old display surface api will remain. Also, Pygame's Python API 
is old. A class based approach adds more flexibility.




It's worth noting that switching the graphics context between
windows (to do hardware draws) isn't free, and simple code
(that e.g. draws a bunch of things on two windows, switching
every draw call for code clarity) might not run 

Re: [pygame] Pygame for SDL 2, and how it may look.

[Lenard Lindstrom]

Hi Ian,

Thanks for replying.

On 17-04-16 01:43 AM, Ian Mallett wrote:
On Thu, Apr 13, 2017 at 3:25 PM, Lenard Lindstrom <le...@telus.net 
<mailto:le...@telus.net>> wrote:


"""Render an image to a window
This is adapted from the SDL 2 example at
<http://www.willusher.io/sdl2%20tutorials/2013/08/17/lesson-1-hello-world
<http://www.willusher.io/sdl2%20tutorials/2013/08/17/lesson-1-hello-world>>.
"""


​Heh, I'm friends with Will. We're at the same university.​

import pygame
from pygame.display import RendererWindow
import os


def get_resource_path():
my_dir = os.path.dirname(os.path.abspath(__file__))
return os.path.join(my_dir, 'data')


def run():
pygame.display.init()
title = "Hello World!"
rect = (100, 100, 640, 480)
flags = RendererWindow.SHOWN
with RendererWindow(title, rect, flags) as win:
ren = win.renderer
flags = (ren.ACCELERATED  |
 ren.PRESENTVSYNC   )
ren.open(flags)
image_path = os.path.join(get_resource_path(), 'hello.bmp')
bmp = pygame.image.load(image_path)
tex = ren.new_texture_from_surface(bmp)

for i in range(3):
ren.clear()
tex.copy_to_renderer()
ren.update()
pygame.time.delay(1000)
pygame.quit()

if __name__ == '__main__':
run()


A window with renderer and a window with surface are implemented
as distinct subclasses of a standard Window extension type. Each
Window instance is an open window on the display. Window updates
are perform by methods on the corresponding renderer or surface.
Window and renderer specific constants, such as SDL_WINDOW_SHOWN
and SDL_RENDERER_ACCELERATED are class attributes, though they
could also be included in pygame.locals.

This is preliminary design work, so feedback is not only welcome
but also necessary.


​Is it possible to combine the renderer with the window? I don't see 
why the renderer needs to be pulled out of the pygame.draw module, and 
indeed, this could be confusing for existing code.


I don't quite understand. The renderer associated with the 
RendererWindow instance is returned by the window's renderer property.


Why are the window and the renderer separate objects? There is a 
one-to-one relation between a window and its renderer or a display 
surface. And a window cannot have both. To avoid duplicating a bunch of 
window specific methods I created a Window class, with RendererWindow 
and SurfaceWindow (not shown) as subclasses. Also, a surface can have a 
renderer, and a combined surface-renderer object makes no sense. Still, 
I haven't ruled out renderer-window and surface-window types yet. 
However it is done, I don't see an elegant representation of the 
relationships among SDL windows, surfaces, renders, and textures.


For maximum backcompatibility, something like the following would seem 
to fit better with the existing API:


surf1 = pygame.display.Window(rect1,flags)
surf2 = pygame.display.Window(rect2,flags)
#...
surf1.blit(...)
surf2.blit(...)
#...
pygame.display.flip()

I don't recall what was decided about the feasibility of implementing 
SDL2-style or hardware-accelerated rendering, but I'd hazard that this 
sort of API wouldn't map well to it. OTOH, I don't think the decision 
to implement a modern graphics interface was decided in the first 
place (just that we're currently adding some SDL2 stuff).
The user can choose either a renderer or a display surface for a window. 
And pixels can be copied between textures and surfaces. So hardware 
accelerated rendering is available, as shown in the example.


As for set_mode(), flip(), and update(), they remain in Pygame SDL 2. 
Keeping as much of the Pygame SDL 1 API in Pygame SDL 2 is a priority. 
This example explores how new SDL 2 specific capabilities can be added 
to Pygame. It uses a Python feature unavailable when Pygame was created, 
the new-style class.




It's worth noting that switching the graphics context between windows 
(to do hardware draws) isn't free, and simple code (that e.g. draws a 
bunch of things on two windows, switching every draw call for code 
clarity) might not run very well. Perhaps the API should discourage 
this somehow, especially if full HW drawing is encouraged.


Again I don't understand. Given a window, its renderer, and a bunch of 
textures: render the textures to various locations on the window, update 
(expose) the renderer, then repeat. How is this not hardware drawing. 
What am I missing?


SDL 2 supports multiple open windows. Pygame will too. Let the designer 
choose how many windows are open, and if hardware acceleration is 
appropriate. Not all Pygame applications need be fast-paced games.


Lenard Lindstrom

Re: [pygame] Re: pygame with SDL2 proposal

[Lenard Lindstrom]

I would add that I have some proof-of-concept code for SDL 2 window and 
renderer support at https://github.com/llindstrom/pygame_SDL2. It 
includes an experimental Cython window module with Window classes added 
to display. See examples/window_render.py for example Python code. It 
can be built on Gnu/Linux if the SDL 2.0.4 (or 2.0.5) library and dev 
files are installed. Tested for Python 2.7.


Lenard Lindstrom

On 17-04-09 01:47 AM, René Dudfield wrote:

(In case there's anyone interested on the list who wants to follow along).

Lenard has been adding the SDL2 patches in these branches.

https://github.com/pygame/pygame/tree/SDL2_patches 
<https://github.com/pygame/pygame/tree/SDL2_patches>

https://github.com/pygame/pygame/tree/SDL2_patches_incomplete

[pygame] Pygame for SDL 2, and how it may look.

[Lenard Lindstrom]

Hello everyone,

I have written some proof-of-concept code on how SDL 2 windows and 
renderers may be incorporated into the Pygame Python API. Here is the 
latest incarnation of a previous post 
(http://archives.seul.org/pygame/users/Mar-2017/msg00139.html) as a 
pygame.example program:


"""Render an image to a window
This is adapted from the SDL 2 example at
<http://www.willusher.io/sdl2%20tutorials/2013/08/17/lesson-1-hello-world>.
"""

import pygame
from pygame.display import RendererWindow
import os


def get_resource_path():
my_dir = os.path.dirname(os.path.abspath(__file__))
return os.path.join(my_dir, 'data')


def run():
pygame.display.init()
title = "Hello World!"
rect = (100, 100, 640, 480)
flags = RendererWindow.SHOWN
with RendererWindow(title, rect, flags) as win:
ren = win.renderer
flags = (ren.ACCELERATED  |
 ren.PRESENTVSYNC   )
ren.open(flags)
image_path = os.path.join(get_resource_path(), 'hello.bmp')
bmp = pygame.image.load(image_path)
tex = ren.new_texture_from_surface(bmp)

for i in range(3):
ren.clear()
tex.copy_to_renderer()
ren.update()
pygame.time.delay(1000)
pygame.quit()

if __name__ == '__main__':
run()


A window with renderer and a window with surface are implemented as 
distinct subclasses of a standard Window extension type. Each Window 
instance is an open window on the display. Window updates are perform by 
methods on the corresponding renderer or surface. Window and renderer 
specific constants, such as SDL_WINDOW_SHOWN and 
SDL_RENDERER_ACCELERATED are class attributes, though they could also be 
included in pygame.locals.


This is preliminary design work, so feedback is not only welcome but 
also necessary.


Lenard Lindstrom

Re: [pygame] The long-ish pygame github migration status email.

[Lenard Lindstrom]

Well, I am not showing up in GitHub. And almost everything in src having 
the last commit on Dec. 1, 2016.


Lenard Lindstrom

On 17-03-26 10:38 AM, René Dudfield wrote:

Hello,

https://github.com/pygame/pygame

TLDR; git repo, and issues are there. A bit more work to do on other 
things. Authors, please check your github email privacy settings if 
you care right away.


cheers,


*Import, and Author mapping.
*

I used the built in github tool for importing the pygame repo from 
bitbucket.


Everything seems to be there, including branches and tags.

If you have permission for the repo you can see the authors, and how 
they were mapped. I managed to find everyone almost.

https://github.com/pygame/pygame/import/authors

(If you don't have permissions on github, that just link just shows 
the pygame repo)


If you don't have your email set to public on your github profile, or 
a private hidden email via github, you don't get linked up on the 
pygame/pygame repo page. (I guess if you do want to be private, then 
that is no problem to you... but maybe someone didn't realise). But if 
you want to be visible, please either make your email public, or use a 
github hidden email. I can change the mapping still... but I don't 
know for how long that page will be there, or if that has an effect later.


Here's some relevant email help pages on github:

  * public email can be set here: https://github.com/settings/profile
  * verify email if you haven't(really old account)
https://help.github.com/articles/verifying-your-email-address/
  * using the private address
https://help.github.com/articles/keeping-your-email-address-private/



*Issue migration*

Then I migrated the issues from bitbucket to github with this script.
https://github.com/jeffwidman/bitbucket-issue-migration

The issue numbers are the same on each one. Issue 147 on github is 
issue 147 on bitbucket. The issues on gh link to the old bb issue, and 
the old username.


Unfortunately the script does not make a note on the bitbucket issue 
about the move. Probably a good idea to do this, but I couldn't find a 
tool to do it.




*What's next?
*
I'll update the bitbucket to point a url to the github page where I can.

The things below still need to be done.

*Buildbots.
*

All of the places should be able to be moved to git. appveyor, travis, 
launchpad, ...



*Downloads.*
https://bitbucket.org/pygame/pygame/downloads/

Github doesn't really have downloads. We could put all the files in a 
repo though. This is better I think.


We can leave those downloads as they are on bitbucket for now.

However, we need to go around the web and find links which might need 
updating. (well, at least on our websites).



*Website integration.
*

Need to add a new webhook when something has been moved into the 
default branch.

The downloads repo could go into /ftp/

*Maintainers contacted, and announcements
*

We need to contact various system maintainers to let them know of the 
updates. eg, Debian maintainers.



*Other repos on pygame to be moved*

There's a few other repos that might need moving.

https://bitbucket.org/pygame/

Maybe just these ones?

  * https://bitbucket.org/pygame/build-external-dlls
  * https://bitbucket.org/pygame/pygamegsoc12
  * https://bitbucket.org/pygame/imgblit

Lennard, what do you think about which ones need moving to bitbucket?

*Wiki.
*

The bitbucket wiki was spammed into oblivion, and most updates then 
happened on the pygame webpage wiki. I'll make a backup, and then 
disable the bitbucket wiki in time.


If someone wants to go through and manually check if there's useful 
content in there that's not already in the main wiki... please feel 
free. I guess the easiest way to do that is not through the web, 
because I couldn't see a history button (maybe it's there somewhere). 
There is a wiki repo though.


*pygame. bitbucket. org
*

Seems they disabled this some time ago.


*Keeping bitbucket repositories there.
*
I think we need to keep the pygame bitbucket there for the foreseeable 
future. There's still things we need to migrate, and there's no way of 
redirecting links. Can decide later if we want to remove it entirely.

Re: [pygame] Re: pygame with SDL2 proposal

[Lenard Lindstrom]

Hi Ian,

I think people are hung up on option 2), SDL1/SDL2 compile option, 
thinking it means no SDL2 features, or no option 3), transition to SDL2 
only. First, I gather René's proposal to keep Pygame development on a 
single branch is not about freezing the Pygame at SDL1 only 
functionality. Rather it is about logistics: How do we continue to 
distribute Pygame while updating the automated building systems for 
SDL2? How do we avoid breaking every Pygame program that has been 
written up to now?


I won't argue whether be kept as one branch or split into two. But I 
don't think creating an SDL1/SDL2 compiler switch will be overly 
difficult. It will also encourage keeping SDL1 support alive while SDL2 
development proceeds.


Next issue, backwards compatibility. The SDL1/SDL2 compiler switch is 
just the starting point. It is the foundation upon which new, SDL2 
specific code is written. Pygame has become more than a thin wrapper 
over SDL. It should be quicker to add a few new classes to support the 
window/texture/renderer framework of GPL acceleration than to start from 
scratch. Meanwhile Pygame maintains the display surface/blit interface, 
which is also supported in SDL2, for backward compatibility.


Much of the work in adapting Pygame to SDL2 has been done. This will 
reduce the time taken until coding for new SDL2 features begins. Using 
Cython will reduce coding time further, and hopefully allow more people 
to participate. All in all I believe this incremental approach will give 
quicker, more solid, results than writing a new package from scratch.


Finally, I threw together a code example of how I envision Pygame 2 
(taken from 
http://www.willusher.io/sdl2%20tutorials/2013/08/17/lesson-1-hello-world):


# Simple Pygame 2 example using a window, renderer, and texture.

import pygame as pg

pg.display.init()
win = pg.display.Window("Hello World!", (100, 100, 640, 480), 
pg.WINDOW_SHOWN)

ren = win.renderer(-1, pg.RENDERER_ACCELERATED | pg.RENDERER_PRESENTVSYNC)
bmp = pg.image.load("hello.bmp")
tex = ren.texture(bmp)

for i in range(3):
ren.clear()
tex.copy_to_renderer()
ren.present()
pg.time.delay(1000)

pg.quit()


Notice that surfaces, as returned by image.load(), still exist. Also, 
pygame.display.Window is an addition. Module pygame.display functions 
set_mode(),  flip() and, update() remain and work as expected.


Lenard Lindstrom


On 17-03-21 10:31 AM, Ian Mallett wrote:

​​Hi,

On Mon, Mar 20, 2017 at 11:55 PM, René Dudfield <ren...@gmail.com 
<mailto:ren...@gmail.com>> wrote:


There are few people on this mailing list which have a lot of
knowledge about GPU rendering, and Ian is definitely one of them.
I think he was genuinely trying to be helpful. His claim isn't
even controversial - GPU, ASIC, and CPU rendering all have
different trade offs. As do game libraries like pygame.

On Mon, Mar 20, 2017 at 5:18 PM, Leif Theden <leif.the...@gmail.com 
<mailto:leif.the...@gmail.com>> wrote:


Ian, you are really trying to make the case that a software
renderer making simple shapes around the on the screen is better
than a GPU?  Why then are basically all games these days using a
GPU?  Please, don't answer it, because I'm not sure if you are
trolling or not, and don't want to risk derailing the tread with
this...honestly quite ludicrous assertion you've made.  The proof
is in the pudding, so to speak, and the pudding is certainly not
software rendering anything.

Thanks René! And to clarify: (1) Leif, the answers to your objections 
are in that wall of text, which is of course why I wrote it. (2) I do 
not troll. (3) You're right that if hardware acceleration is off the 
table, then this conversation is orthogonal here. But, it's unclear to 
me if it /is/ off the table.


At the risk of over-simplification, but in the interest of moving the 
conversation forward, let's try to put the current issues in context. 
As I understand it, the proposals vis-à-vis SDL2 are:


1: Do nothing

2: (Progressively) integrate SDL2 patch into existing pygame with
goal of eventual SDL1/SDL2 compile option (René and Lenard OP,
many detailed variations)

3: Transition (as above or rewrite) to use SDL2 only (various)

. . . any of which implemented with the following options, which are 
not necessarily mutually incompatible:


A: Share/relicense pygame_sdl2
B: Expose a different API designed for performance (for graphics
especially)
C: Base largely on hardware acceleration for performance

D: Expose new SDL2 features in the pygame API

​. . . and under the following serious constraint, which I think is 
accurate:​
On Tue, Mar 21, 2017 at 6:27 AM, Leif Theden <leif.the...@gmail.com 
<mailto:leif.the...@gmail.com>> wrote:


Let's be realistic, there are very few people who have the will or
ability to deal with the pygame code base
​​


I

Re: [pygame] pygame with SDL2 proposal

[Lenard Lindstrom]

Okay, let's clear up a misunderstanding. This not an /either/ GPUs /or/ 
CPUs issue here. SDL2 adds windows, textures, and renderers. But it 
still supports surfaces, even screen surfaces. So a Pygame 2 will add 
new object types for the new features while keeping surfaces, unless we 
no longer want image file support or text on the screen. The only big 
compatibility issue I see is that events are reorganized in SDL2. I 
emulate SDL1 events in my patch set to maintain backwards compatibility.


The real question is do we want to add SDL2 features to the existing 
Pygame code base or pull a Python 3 and redesign the Pygame api for 
ascetic reasons.


Lenard Lindstrom

On 17-03-20 04:18 PM, Leif Theden wrote:
I'm not really sure how to respond to this wall of text. Ian, you are 
really trying to make the case that a software renderer making simple 
shapes around the on the screen is better than a GPU?  Why then are 
basically all games these days using a GPU?  Please, don't answer it, 
because I'm not sure if you are trolling or not, and don't want to 
risk derailing the tread with this...honestly quite ludicrous 
assertion you've made.  The proof is in the pudding, so to speak, and 
the pudding is certainly not software rendering anything.


Anyway, I don't think the typical use case for games is drawing 
lines.  People want sprites, and they want them to rotate, scale, and 
translate quickly.  Pygame1 cannot do this, but SDL2 can.


I would say maybe there is a niche for pygame1, a toy for drawing 
lines and breaking students dreams of building a game using python.  
There is a real desire for a fast python library that doesn't have the 
magic of say, Kivy, or even pyglet, but isn't slow and cumbersome either.

Re: [pygame] pygame with SDL2 proposal

[Lenard Lindstrom]

Hi René and everyone else,

I like this approach. My patches achieve the first step, using SDL2. The 
next step is to introduce new SDL2 features as new modules and classes.


I suppose the SDL2 patches can be incorporated as conditionally compiled 
code. They can be added one at a time, but must all be in place to work 
properly. Then any new Pygame modules will expose SDL2 features only, so 
not be built for SDL1.


As a long term goal SDL1 can be removed and SDL1 legacy modules 
reimplemented on top of the SDL2 specific code.


Is there any reason new modules should not be written in Cython? If not 
then we could try to use parts of pygame_sdl2 to quickly introduce SDL2 
specific features.


Lenard Lindstrom


On 17-03-18 05:02 AM, René Dudfield wrote:

Hello,

so, I've spent some more time reading source code, and investigating 
SDL2 and the options a lot.


I *think* this plan below could be the best way forward for us.

tldr;
 * have a single source SDL1, and SDL2 code base with a compile time 
option. (like we have single source py2 and py3).

 * move bitbucket/pygame repo to github/pygame.


Rather than reimplementing everything, and introducing lots of 
compatibility bugs, Instead I think a gradual approach would work 
better. I'm starting to think that perhaps pygame_sdl2 by Tom, is not 
such a great way forward (for the pygame project, I think it was 
necessary and good for Ren'Py).


A big breaking change is kind of silly for how little resources we 
have. Python 3 managed to pull it off... after a decade, and with 
massive resources having poured into it. And it only took off once 
they put compatibility code back in. Here's the thread where some 
discussion has been happening.

https://bitbucket.org/pygame/pygame/issues/174/pygame-20-the-sdl2-edition


What we do have is some patches to get the current code base working 
with SDL2.

https://bitbucket.org/llindstrom/pygame-1.10-patch

I think it should be possible with some work to improve an SDL2 
compatibility layer, so that pygame code base can work with either (as 
a compile time option). Then newer APIs can be introduced in time, in 
a non break-every-program kind of way. Also, it's been proven that 
'hardware' blitting does not need to break SDL1 API compatibility to 
use hardware accelerated APIs (Angle, SDL_gpu, [insert 4 or 5 other 
projects], ...).


Having a pygame2, or whatever separate repo would also make 
maintenance harder. Since for the foreseeable future, we will likely 
need to do maintenance releases for this anyway (at least I want to!, 
and I know other users of pygame will).


---

For pip uploads, they would continue to be for SDL1, until we can 
finish the SDL2 changes, and it works better. There would be no new 
additions until compatibility is mostly there.


The work would progress by slowly adding in compatibility changes 
whilst keeping pygame working. By keeping the SDL2 patch set as is, 
and slowly reducing the patch set until it is size zero. So we always 
have a pygame with sdl2, and a pygame with sdl1 that is producible. 
Eventually the patch set will disappear.


---

A pygame2 module would just cause confusion amongst users, and that 
really boring 'pygame 1 or pygame 2' type debate would go on, and on 
like the "python 2, verses python 3" one did. For me, just avoiding 
that discussion for the next decade would be worth it.


Then there would need to be two sets of documentation on the website. 
And two sets of tutorials... and... we'd have 2 of everything to *do*, 
and 2 of everything for people to look at.


Finally, "import pygame2" looks kind of weird. I've grown used to 
"import pygame".


...



I'm keen to get moving on this. I've been trying to get feedback on 
the 'pygame sdl2 addition' issue for the last month, and the issue has 
been open since 2013. So I'd like to put a time limit on this decision 
for one more week.


I'd really like to hear back from contributors, and users (everyone).




ps. Interestingly SDL_gfx has an SDL2 release now. 
http://www.ferzkopp.net/wordpress/2016/01/02/sdl_gfx-sdl2_gfx/

Re: [pygame] pygame with SDL2 proposal

[Lenard Lindstrom]

Hello,

Pygame relies heavily on the new buffer protocol to interact with 
external modules like NumPy. The new buffer protocol is a CPython C api 
level protocol for exposing array data. There is nothing comparable at 
the Python level. In particular, the new buffer protocol allows for a 
callback to call when a client releases a buffer. For a Pygame surface, 
the callback unlocks the surface. The alternative to a callback is to 
unlock the surface when the client object is garbage collected. This 
will not work in PyPy, which lacks reference counting. So much of Pygame 
needs to remain as extension modules to continue to use the new buffer 
protocol, making CFFI less useful.


Lenard Lindstrom

On 17-03-18 10:32 PM, bw wrote:

Hi, thanks for inviting me to opine. :)

[snip]


Having had much recent experience with a SDL2 implementation (pypy, 
CFFI, plus all the SDL2 libs), I found that I would really like to see 
in the next generation:




[snip]


2. CFFI would also make pygame compatible with pypy, something which 
is sorely needed in my opinion. One can use optimization tricks to 
compensate for CPython's speed limit, but one cannot do many things 
that are computationally intensive without farming out to a 
third-party opaque library. pypy could let coders do a lot more in 
Python, when a full blown physics/geometry/numeric/scientific opaque 
lib is overkill.

Re: [pygame] pygame.pixelcopy.array_to_surface(Dest, Src) not working

[Lenard Lindstrom]

A FORTRAN array should work. The pixelcopy routines do understand array 
strides.


On 16-12-24 10:25 AM, Russell Jones wrote:


On 24 December 2016 at 17:39, Mikhail V > wrote:


The problem is however, transpose adds overhead, ca. 10-15%
performance hit,

Have you played with order='FORTRAN'? See
https://docs.scipy.org/doc/numpy/reference/generated/numpy.isfortran.html

Re: [pygame] New pygame.org website

[Lenard Lindstrom]

The ad appears to be added by Disqus, which powers the comments.

On 16-12-18 02:36 AM, Thomas Kluyver wrote:
Yuck. I always use an adblocker, so I hadn't seen the 'sponsored 
links' until now. I agree that they're hideous, and we definitely 
shouldn't have them on the new site. I wonder if they were put on 
there deliberately, or if the site has been compromised.


On 18 December 2016 at 09:42, Charles Cossé > wrote:


Would it be possible to eliminate those unsightly "sponsored
links" advertisements going forward?
I just logged-in for first time in 2 years and there's Donald
Trump and Angelina Jolie on my project page
 ...
yikes!

Re: [pygame] New pygame.org website

[Lenard Lindstrom]

I was looking at Pelican: http://blog.getpelican.com/

It looks like Sphinx lite for web sites. Page content can be reST, 
Markdown, or AsciiDoc. Jinja templates are used for page generation.


On 16-12-17 02:26 PM, Thomas Kluyver wrote:



So far, I think the proposals for the static information part of the 
site are Nikola (a static site generator oriented around blogs) and 
Sphinx (oriented around docs). Both are written in Python. Does anyone 
want to make the case for any other system?

Re: [pygame] New pygame.org website

[Lenard Lindstrom]

Bitbucket also has static web site support. I set one up for the Pygame 
docs awhile ago, but have not maintained it:


http://pygame.bitbucket.org/docs/pygame/

The repository is here:

https://bitbucket.org/pygame/pygame.bitbucket.org

Lenard Lindstrom

On 16-12-17 09:16 PM, Daniel Foerster wrote:

You know, I suppose we could just use GitHub pages.

On Dec 17, 2016 17:32, "Charles Cossé" <cco...@gmail.com 
<mailto:cco...@gmail.com>> wrote:




On Sat, Dec 17, 2016 at 4:12 PM, Daniel Foerster
<pydsig...@gmail.com <mailto:pydsig...@gmail.com>> wrote:

Using S3/CloudFront is a lot cheaper than the EC2 setup you're
imagining (and which a Django stack would require).



I never said to use Amazon at all.  Just use the current server,
whatever it is (unless it's Amazon).

On 12/17/2016 05:11 PM, Charles Cossé wrote:

Yikes!  who's gonna pay the Amazon bill?

On Sat, Dec 17, 2016 at 4:09 PM, Paul Vincent Craven
<p...@cravenfamily.com <mailto:p...@cravenfamily.com>> wrote:

If most of the site is static, then I think Django would
be overkill. The static portion of the site can easily be
deployed via Amazon S3/CloudFront and then we'd not have
to maintain a server.

Paul Vincent Craven

On Sat, Dec 17, 2016 at 5:00 PM, Charles Cossé
<cco...@gmail.com <mailto:cco...@gmail.com>> wrote:


On Sat, Dec 17, 2016 at 3:26 PM, Thomas Kluyver
<tak...@gmail.com <mailto:tak...@gmail.com>> wrote:


So far, I think the proposals for the static
information part of the site are Nikola (a static
site generator oriented around blogs) and Sphinx
(oriented around docs). Both are written in
Python. Does anyone want to make the case for any
other system?


Can Django factor-in there? I guess it would reside
underneathe the other pkgs ... but might as well run
Python through-and-through imho.





-- 


Linkedin <https://www.linkedin.com/in/charles-cosse> |
E-Learning <http://www.asymptopia.org>







-- 


Linkedin <https://www.linkedin.com/in/charles-cosse> | E-Learning
<http://www.asymptopia.org>

Re: [pygame] New pygame.org website

[Lenard Lindstrom]

Hello,

My experience is in setting up the Pygame documentation generator under 
Sphinx. So all the hacks to get a unsphinx-like banner with links to all 
the module pages was my work.


On 16-12-16 09:59 AM, Thomas Kluyver wrote:
On 16 December 2016 at 10:12, Radomir Dopieralski > wrote:


As for the tools, I wonder if we could just use Sphinx like all the
PyGame documentation does, and not get extra tools involved.


I've made websites with Sphinx before (ipython.org 
), and my experience was that it's not a great 
tool for that task - it's designed around docs, and you have to do a 
fair bit to suppress docs-oriented features and checks that don't make 
sense for a website, such as having all the pages in a strict order 
for conversion to PDF.


My experience is that Sphinx organizes document source files in a tree 
structure, with a root document linking to child documents which can 
have children in turn. When adding a new document, the main concern is 
that it is added into the tree somewhere. Sphinx supports wild card 
patterns and directory recursion to simplify this.


A downside is all pages built with a particular theme share the same 
layout. For example, in the Pygame docs the same Jinja2 templates 
generate the index page, module reference pages, and tutorial pages. So 
if you want a sidebar on one page, you get it on all pages. And I 
imagine to get around this needs another level of complexity, such as 
multiple document trees with each tree using a different theme.

[pygame] Should Pygame be recognized for using Sphinx document generator

[Lenard Lindstrom]

Hi everyone,

If you did not already know, the Pygame documentations is written in 
reStructuredText (.rst) and is compiled to html with the Sphinx Python 
Document Generator <http://www.sphinx-doc.org/>. The Sphinx website has 
an page showing Projects using Sphinx 
<http://www.sphinx-doc.org/examples.html>. Do we want our project added 
to this page? I believe in the past one had to be on the Sphinx mailing 
list to request addition, so I never seriously tried. Now it looks like 
I can use my Google+ account. Let me know what you think.


Lenard Lindstrom

Re: [pygame] Another PixelArray memory leak

[Lenard Lindstrom]

Fixed in changeset d61ea8eabd56

Thanks Martti for reporting the bug.

Lenard Lindstrom

On 15-12-04 01:19 PM, Lenard Lindstrom wrote:

Ok, I am l looking into it.

Lenard Lindstrom

On 15-12-04 11:31 AM, Martti Kühne wrote:

Hello pygame list!

On a similar note as [0], using PixelArray's index operator with two
arguments spa = pygame.PixelArray(surf); spa[x, y] continuously went
allocating memory on my pygame build r3442.30ee31659166. Memory that
was lost that way would survive the lifteime of both the surface lock
and the object itself. The switch to spa[x][y] fixed the leakage for
me currently, however it would be great to see this handled correctly
upstream.

cheers!
mar77i

[0] 
https://bitbucket.org/pygame/pygame/issues/175/memory-leak-when-setting-pixels-with

Re: [pygame] `pygame`: on Ubuntu, using `pygame.image.save` to save PNG causes `pygame.error: SavePNG: could not create png write struct`

[Lenard Lindstrom]

ERROR: ImageextModuleTest.test_save_unicode_path
--
Traceback (most recent call last):
  File 
"/home/brian/anaconda2/lib/python2.7/site-packages/pygame/tests/imageext_test.py", 
line 65, in test_save_unicode_path

imageext.save_extended(im, temp_file)
error: SavePNG: could not create png write struct
--
Ran 708 tests in 28.894s
FAILED (failures=2, errors=6)

The results of these tests makes me think that the issue is unlikely 
to be due to issues specific to the porting of my code from Windows 
to Ubuntu (so for instance, I have tried to fix pathnames, etc. 
wherever possible, and the `pygame` tests should be platform 
independent, but still fail?).


What should I do to fix this issue?

Kind regards,
Brian




Hope this is of some help,

Lenard Lindstrom

Re: [pygame] Closing issue 211 with big-endian CPU test

[Lenard Lindstrom]

Hi,

On 15-10-25 04:19 PM, Ian Mallett wrote:
On Sun, Oct 25, 2015 at 4:27 PM, Lenard Lindstrom <le...@telus.net 
<mailto:le...@telus.net>> wrote:


Is there a need to continue big-endian support?

​Bi-endian architectures are still around (ARM, MIPS in particular). 
AFAICT little endian won the war, but big endian is still around 
mainly for compatibility. The Raspberry Pi, for example, is almost 
universally configured to little endian, despite being a bi processor.
If Pygame is built for one of these platforms configured as big-endian, 
its big-endian code will be tested then.




Also, notionally, programs could swap endian-ness when operating on 
certain memory regions for performance improvements. Though, I don't 
know of any modern programs that do that.

Pygame's endian support is set at compile time.


​

I mean, we leave in the big-endian specific code, but just leave
it untested. Worry about it only if the need arises.

I like this solution. Making endianness go both ways with a compile 
flag isn't really extra effort.


Lenard Lindstrom

​Ian

Re: [pygame] Closing issue 211 with big-endian CPU test

[Lenard Lindstrom]

Is there a need to continue big-endian support? I mean, we leave in the 
big-endian specific code, but just leave it untested. Worry about it 
only if the need arises.


Lenard Lindstrom

On 15-10-23 08:07 AM, René Dudfield wrote:

Hi,

Interesting. I didn't know you could do that ( and that, and that).

Thanks for the information.

By the way, the webhooks can be added through the bitbucket admin 
interface. Any of the admins can add them in there.


Am I able to add other users to the launchpad pygame team? I'd 
probably want a separate "pygame Robot" user which is able to upload 
to launchpad repos+PPAs.


I think for now, the code is building and all but one test is running. 
For me, this is enough for now. I'll concentrate on fixing the failing 
test in the lib/compat.py and getting a qemu build going. I have a 
mate running a freebsd PPC laptop that might be able to give pygame a 
build... I'll see how that goes. According to him the more recent 
debian/ubuntu releases don't work so well, so he had to change to freebsd.



best,






On Fri, Oct 23, 2015 at 11:12 AM, Thomas Kluyver <tak...@gmail.com 
<mailto:tak...@gmail.com>> wrote:


On 23 October 2015 at 07:33, René Dudfield <ren...@gmail.com
<mailto:ren...@gmail.com>> wrote:

I guess we should incorporate the Debian changes, but I wanted
to check with Thomas if what I did was ok? (see revs 14-19).


Fine by me. I just copied the packaging from Debian/Ubuntu
originally anyway, so bringing in the updates is probably useful.

They use an interesting method to do a hg clone. I'm not sure
how to actually use this though... (see get-orig-source-hg in
rules). In rev 19 I changed that to get the latest rev from
hg. But I guess they want to specify a specific version.


AFAIK, the builders never actually run that target (and even if
they did, they don't have outside network access). Unlike
everything else in debian/rules, it's there for human packagers to
run to get the data and then upload it. Debian packaging can be
pretty ugly at times.

Since you already have a machine running a custom webhook when
there are new commits, perhaps it's best to use that to upload
directly to Launchpad for PPA builds, bypassing Launchpad's code
import and recipe builds:
https://help.launchpad.net/Packaging/PPA/Uploading

You'd need to work out how to get from a source tree to a Debian
source package locally, though. I'm sure GPG signatures are
involved somehow.

Best wishes,
Thomas

Re: [pygame] build bot badges on README

[Lenard Lindstrom]

There have been a couple of isolated reports of anti-virus software 
being triggered by a Pygame installer. But follow-up with a different 
anti-virus program found no problems. The new x64 installers where built 
on Appveyor, which provides a fresh environment for each build. The 
external libraries where built with MinGW-W64 on my computer. I only use 
Windows when I have to. The rest of the time it's Gnu-Linux.


Lenard Lindstrom

On 15-09-27 09:43 AM, diliup gabadamudalige wrote:

has anybody come across any viruses in the pygame download?

[pygame] x64 Windows installers and prebuilts with stdint.h included

[Lenard Lindstrom]

Pygame installers for 64-bit Python 2.7 and 3.4 are now available at the 
Bitbucket download page:


https://bitbucket.org/pygame/pygame/downloads

Also, prebuilt library zip files with stdint.h added for MSVC 9.0, where 
it is missing. This is needed for Python 2.7.


md5sums:

eea876349ea3bd203e5c8288aa4573ec 
pygame-1.9.2a0-hg_8d9e6a1f2635+.win-amd64-py2.7.msi
0c35f7778766a781b8b388909ec29866 
pygame-1.9.2a0-hg_8d9e6a1f2635+.win-amd64-py3.4.msi

4d4146cacc13a6a40b24c19e38026870 prebuilt-x86-pygame-1.9.2-20150922.zip
8707b5cbb2ab8c7531e3a304a2531c04 prebuilt-x64-pygame-1.9.2-20150922.zip

Lenard Lindstrom

Re: [pygame] New Pygame 1.9.2a0 Windows x86 installers for Python 2.7 and 3.4

[Lenard Lindstrom]

Hi everyone,

Well, the original message was not supposed to be blank. So I will try 
again.


I have added new x86 (32-bit) Windows installers to the Pygame download 
to the download page:


https://bitbucket.org/pygame/pygame/downloads

As well,  x86 and x64 versions of SDL.dll and the other external 
libraries included in the installer are available in a separate zip file 
along with headers and .lib VC++ export libraries. Most notable is that 
SDL_mixer.dll now uses libmpg123 for MP3 playback. The smpeg library has 
been dumped. Please be aware that MP3 files may play too fast or too 
slow. This is an SDL issue. By SDL_mixer convention, SDL_ConvertAudio() 
does sample rate conversion. It is fine for doubling or halving the 
sample rate, but refuses to do other adjustments (from 32000 to 44100, 
or event 48000, for instance). Just be sure SDL_mixer is initialized 
with a frequency consistent with any files to be played.


Building Pygame against the x64 (64-bit) prebuilts is untested, but I do 
know VC 9.0 (used to compile Python 2.7) can link to SDL.dll, and the 
resulting program can call an SDL function without crashing.


md5sums:

ff8a4f5ceb01dbf10c56240e28f25680 
*pygame-1.9.2a0-hg_ea3b3bb8714a.win32-py2.7.msi
49fd20db98fd5de98a2cf523be7d92a8 
*pygame-1.9.2a0-hg_ea3b3bb8714a.win32-py3.4.msi

ffa51afdfd80abce7c345b19f843d8b6 *prebuilt-1.9.2-src-20150907.zip
d04d00e84289b36eb37eb4bcfb664858 *prebuilt-x86-pygame-1.9.2-20150907.zip
ec819494e14ff85115ebcc5bc72dbb3a prebuilt-x64-pygame-1.9.2-20150907.zip

Enjoy,

Lenard Lindstrom

On 15-09-08 01:15 PM, Lenard Lindstom wrote:



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

P.S. I suspect the anti-virus program ate the original message. It may 
be time to replace Avast.

[pygame] Playing MP3 with SDL_mixer 1.2 using libmpg123

[Lenard Lindstrom]

Hi everyone,

I have taken the last couple of weeks to prepare a patch to SDL_mixer 
1.2 that replaces SMPEG and the MAD library with libmpg123 as the MPEG 
decoder. The SDL_mixer interface to SMPEG is simply broken, and has 
probably been removed from SDL_mixer 2 by now. Also, I have read 
criticisms of SMPEG's ability to handle MP3 music files. The MAD library 
is GPL licensed, which is incompatible with Pygame's LGPL license, or so 
I have been lead to understand. The mpg123 library is LGPL, and appears 
to support many MP3 flavors.


The patch is available at 
https://bitbucket.org/llindstrom/sdl_mixer-1.2-patches/overview . I 
intend to use it in the prebuilt x86 and x64 Windows binaries for Pygame 
1.9.2. I will have 32-bit Pygame 1.9.2 installers out shortly for Python 
3.4, and hopefully 2.7. I will also have x64 prebuilt libraries ready 
for download (They work on Wine 64, but are untested in an actual Pygame 
build on an actual x64 Windows system.)


Have fun,

Lenard Lindstrom

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

[Lenard Lindstrom]

Hi René,

If I can get into the AppVeyor account I believe I can fix the build 
script. The setup.py command to create the msi installer is incorrect.


Lenard

On 15-07-14 12:28 AM, René Dudfield wrote:
On Sun, Jul 12, 2015 at 2:20 AM, Lenard Lindstrom le...@telus.net 
mailto:le...@telus.net wrote:


Hi Peter,

On 15-07-10 07:47 PM, Peter Shinners wrote:

I haven't been paying close attention to Pygame, but it
doesn't seem controversial to say things have stalled. I
haven't gotten much feedback from Rene, but I'd like to give
him time to put something together. Some of the main things
that may need help are:

* Getting 1.9.2 actually released

Much of the delay is due to logistics. With the loss of the
automated build site a few years back there is no simple way to
check a commit against all supported operating systems. It also
limits user testing.


The various build bot links are collected here:
http://www.pygame.org/wiki/Hacking#Links%20to%20individual%20buildbot%20pages

I guess that is still not so easy to check the builds - so I've 
started a scraper script to collect the results together.



best,

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

[Lenard Lindstrom]

On 15-07-15 05:44 AM, Sam Bull wrote:

On Sun, 2015-07-12 at 18:48 -0700, Lenard Lindstrom wrote:

A Pygame buildbot two tasks, building a Pygame installer for a
particular operating system, then running the Pygame unit tests on the
new build.

On the note of testing, I would also like to see pygame's unittest to be
removed and for the tests to use Python's built-in unnittest module.

Does anybody know the reason this exists? Is there a valid reason we're
not already using the standard library unittest module?

Pygame's unittest appears to emulate the standard library, but the
implementation is different, and some things aren't tested properly.

For example, assertNotEqual does not test if they are not equal (with
!=), but rather if their equality is false (with ==). When running the
rect tests under the standard library implementation which actually
tests not equals, one of the tests failed.

I've fixed that test now, but it would make more sense to be using the
standard library implementation that everyone else is using and is well
maintained.
The reasons for a custom unittest are listed at the bottom of 
test/test_utils/unittest_patch.py. The unittest is taken from Python 
2.5, updated for Python 3 compatibility. But I agree, we should try to 
use the standard unittest library.

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

[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.
​

​ ​
​ There's also the problem of Texture vs Surfaces.​

For future code to be backwards compatible we can default to Texture.
But if the user needs pixel access he will need to create a Texture 
and Surface.


The 3 options are summarized: https://wiki.libsdl.org/MigrationGuide#Video
Actually, Pygame Surfaces would stay about the same. What would go are 
such pixel format manipulations such as set_masks(). SDL2 has a strict 
policy on valid formats.


Textures would be an addition. I see Textures as a limited form of 
Surface. In fact, Textures and Surfaces could share a common parent class.


Also, SDL2 does support display surfaces and the flip and update 
operations. They are tied to individual windows rather than being global 
operations.


​  I'm pretty sure it should be possible to make a version of pygame 
that runs existing pygame code while exposing new features to new code 
- allowing people to exploit much of their existing knowledge.


and​

On Sun, Jul 12, 2015 at 8:48 PM, Lenard Lindstrom le...@telus.net 
mailto:le...@telus.net wrote:


Hi Jake,

For the parts of SDL2 that did not see a major redesign, such as
Surfaces, there are enough small differences that simply replacing
SDL 1.2 calls with equivalent SDL 2.0 functions is not enough. The
event types SDL2 posts has undergone some reorganization. There is
no longer a clear mapping equivalence SDL 2.0 and 1.2 in some 



Do you think we should​
​ start pygame2 to support SDL2 design decisions rather than trying to 
support both old and new code at once? I figured if there was a time 
to make potentially breaking design changes to follow modern SDL, now 
would be the time to do it.


If we decide pygame2 must be fully backward compatible, I was worried 
it would limit future changes. Or that supporting both old with new is 
adding too much complexity for something that might not be needed?
Pygame2 can never be fully backward compatible. SDL2 is more strict that 
SDL 1.2 in some areas. Overlays and cd rom support are gone. Pygame2 can 
support a large subset of Pygame1 though.


--
Jake

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

[Lenard Lindstrom]

Hi Jake,

On 15-07-12 09:52 AM, Jake b wrote:

Lenard

On Sat, Jul 11, 2015 at 7:20 PM, Lenard Lindstrom le...@telus.net 
mailto:le...@telus.net wrote:


Much of the delay is due to logistics. With the loss of the
automated build site a few years back there is no simple way to
check a commit against all supported operating systems. It also
limits user testing.

What would we need?
A Pygame buildbot two tasks, building a Pygame installer for a 
particular operating system, then running the Pygame unit tests on the 
new build. Building Pygame is probably the easier task. The second task, 
to properly test Pygame, requires video and audio hardware. I saw 
someone having problems with the unit tests on a Ubuntu build site, as 
the SDL drivers had to be set to 'dummy'.


As for operating systems, Windows and OS X buildbots are most critical. 
It is easy to break Pygame on OS X.




I need someone to take over official Windows support from me,
since I am stuck on Windows XP. I have the MinGW based dependency
build chain working again for 32bit Windows, but did not get
everything to build for 64bit Windows. So no official 64bit
prebuilt libraries yet on the Bitbucket download page.


​I have surgery this week, but ​
​ if nobody ​does this by then I will look into setting something up. 
I have win8 64bit.
Building the Pygame Windows dependencies—SDL, SDL_mixer, freetype2, 
libJPEG, and such—is not well suited to a buildbot. The default builds 
of SDL_mixer and SDL_image are unusable with Pygame, as the working 
directory is not in their DLL search path. This is where I could use the 
help. But I am back to using MinGW/Msys, which takes some special effort 
to set up. Maybe I can cross compile from Linux. Something to look into.




The structure of SDL 2 differs from SDL 1.2. It does not fit well
Pygame's api. So I expect a significant redesign of modules and
classes for Pygame 2. For instance, the display module will
basically go away, replaced with a Window class.


​ I think there's (a lot​?) of new non-backward compatible features? 
[multi windows, default hardware support, touch events, etc]. Are 
there other changes that were previously skipped because it wasn't 
backward compatible.


What I mean is maybe pygame2 should start with design changes, rather 
than worrying on making a completely backward compatible choices?
For the parts of SDL2 that did not see a major redesign, such as 
Surfaces, there are enough small differences that simply replacing SDL 
1.2 calls with equivalent SDL 2.0 functions is not enough. The event 
types SDL2 posts has undergone some reorganization. There is no longer a 
clear mapping equivalence SDL 2.0 and 1.2 in some cases.




This is an opportunity to replace C coded extension modules with
Cython and a Python level foreign function interface. Personally,
I would like to see Pygame fully support PyPy as well as CPython.
Also, some of the Pygame code can be separated out as stand-alone,
Python independent, libraries to encourage support from outside
the Pygame community.


​Do you know​
​ what or how much needs to be done?​

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.




* Website replacement and love
* Migrate forum to Reddit (or community forum)


I think we should leverage the existing:

- https://www.reddit.com/r/pygame
- ​http://stackoverflow.com/questions/tagged/pygame

--
Jake

Lenard Lindstrom

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

[Lenard Lindstrom]

Hi Peter,

On 15-07-10 07:47 PM, Peter Shinners wrote:
I haven't been paying close attention to Pygame, but it doesn't seem 
controversial to say things have stalled. I haven't gotten much 
feedback from Rene, but I'd like to give him time to put something 
together. Some of the main things that may need help are:


* Getting 1.9.2 actually released
Much of the delay is due to logistics. With the loss of the automated 
build site a few years back there is no simple way to check a commit 
against all supported operating systems. It also limits user testing.


I need someone to take over official Windows support from me, since I am 
stuck on Windows XP. I have the MinGW based dependency build chain 
working again for 32bit Windows, but did not get everything to build for 
64bit Windows. So no official 64bit prebuilt libraries yet on the 
Bitbucket download page.


Pygame 1.9.2 is nearly ready for release on Linux. I have tackled the 
Linux specific issues I could find, and am now going through the 
operating system independent issues.



* Moving on to Pygame 2, whatever that means
Yes, Pygame 2 is overdue. A while back I proposed we wait until Pygame 
1.9.2 was released before starting on 2.0. The plan was to clear out the 
Pygame bugs with SDL 1.2 before moving on to SDL 2. But I also expected 
we would be done with 1.9.2 long before now.


Anyway, a few months back I started a Pygame 1.9.2 patch, 
https://bitbucket.org/llindstrom/pygame-1.10-patch, that replaces SDL 
1.2 with SDL 2.0 api calls. Though it uses SDL 2, it tries to remain 
Pygame 1.9.2 compatible, so adds no new SDL 2 features. It is only a 
bridge to Pygame 2.0. Though it fails unit tests and needs more work, it 
is usable now with SDL 2 from GIT (Earlier SDL 2 releases have buggy 24 
bits-per-pixel surface support.).


The structure of SDL 2 differs from SDL 1.2. It does not fit well 
Pygame's api. So I expect a significant redesign of modules and classes 
for Pygame 2. For instance, the display module will basically go away, 
replaced with a Window class.


This is an opportunity to replace C coded extension modules with Cython 
and a Python level foreign function interface. Personally, I would like 
to see Pygame fully support PyPy as well as CPython. Also, some of the 
Pygame code can be separated out as stand-alone, Python independent, 
libraries to encourage support from outside the Pygame community.



* Catch up on the Bitbucket pull requests

The 5 member limit for a Bitbucket project team is a nuisance.


* Website replacement and love
* Migrate forum to Reddit (or community forum)

It seems there are still many great people involved with the Pygame 
project. Perhaps I can help by getting those people the control they 
need to make progress. I'm completely detached from things at this 
point, so I don't have any context to jump in and try to change 
anything. What parts of the project are going well these days?

[pygame] 32 bit Windows installer for Python 3.4

[Lenard Lindstrom]

Hello everyone,

A much delayed Pygame 1.9.2 for Python 3.4 on Windows is now available 
at the Bitbucket download page: 
https://bitbucket.org/pygame/pygame/downloads .


The md5 sum: b68f441a58ce818ee6629ba968831b86 
pygame-1.9.2a0-hg_5974ff8dae3c+.win32-py3.4.msi


The corresponding library binaries used in the build are also available.

The md5 sum: 5e4bf58598017a5695ac71f30755468a 
prebuilt-pygame1.9.2-msvcrt-win32.zip


Unfortunately, the computer I use to build for Python 2.7 tells me there 
is a video card problem at boot time, and I haven't gotten around to 
checking it. Hopefully I will have a Win 64 Pygame build for Python 3.4 
soon, though progress was delayed by problems building one of the 
library dependencies.


Enjoy,

Lenard Lindstrom

Re: [pygame] pygame 1.9.2 release

[Lenard Lindstrom]

Hi,

I don't expect Pygame 1.9.2 is ready for beta testing. As for PyPi, what 
is needed to add it there?


Lenard Lindstrom

On 15-05-11 11:03 AM, diliup gabadamudalige wrote:

we are all waiting patiently

On Mon, May 11, 2015 at 4:19 PM, Florian Krause 
siebenhundertz...@gmail.com mailto:siebenhundertz...@gmail.com wrote:


It is great to see that an new final release is on the way. Can
this then please also be released on PyPi? Not having Pygame in
PyPi at the moment is a big problem for every other package that
relies on Pygame. I see that Windows wheels are already available
on testpypi, so I really hope that soon PyPi proper also has
wheels for Pygame. Any comment on this would also be appreciated.

Best,
Florian



On Mon, Dec 15, 2014 at 7:27 PM, René Dudfield ren...@gmail.com
mailto:ren...@gmail.com wrote:

Hi Lenard,

Seems to be a few issues with the freetype module. I made a
list of them at the bottom of this issue.

https://bitbucket.org/pygame/pygame/issue/228/freetype-unit-tests-fail-with-travis-ci

Are you able to help with these ones?

best,


On Sun, Dec 14, 2014 at 7:58 PM, Lenard Lindstrom
le...@telus.net mailto:le...@telus.net wrote:

I think we only need builds for Python 2.7 and 3.4.

Lenard

On 14-12-14 06:22 AM, René Dudfield wrote:

Hi Lenard,

I'm still not entirely sure the state of everything,
so can't really say if there's anything more you
should do. I'm still working through the issue tracker
and trying stuff out. Hopefully by the end of my day
today we will have a better idea. I'm going to be
marking everything I think we can avoid doing to the
milestone 1.9.3 in the issue tracker.

Hopefully some windows and mac buildbots will help us
develop there, as well as let us all know what is
broken. I'll focus today on the buildbots too.

best,



On Sat, Dec 13, 2014 at 11:36 PM, Lenard Lindstrom
le...@telus.net mailto:le...@telus.net
mailto:le...@telus.net mailto:le...@telus.net wrote:

Hi René,

Great news. Anything more I should do? I got
distracted earlier
this year when, on the PyPy mailing list, I got
the impression
that new buffer support was of low priority,
making much of the
work I did on Pygame irrelevant to PyPy. But that
is my personal
interpretation, and may be entirely wrong. This is
something I
need to address with the PyPy developers, but can
wait until after
1.9.2 is released. The added new buffer support is
still relevant
to CPython.

I am for doing one final push to get version 1.9.2
release worthy,
but won't add any new features. These can wait
until the basics of
the SDL2 version 2.0 are decided. For now I can
see more work on
the documentation, and looking at unit tests and bugs.
Unfortunately I cannot do much to help with the
Windows build, as
I only have XP i386 installed on my machine, and
little interest
in upgrading (I do have access to a Windows 7
machine, so maybe I
can do a final release build.)

I think an end-of-January release date is
realistic. I will now go
to the bug tracker to see what is left to do.

Lenard Lindstrom

On 14-12-12 10:33 PM, René Dudfield wrote:

Hi,

I've been prodded by a bunch of people on
finally getting this
done. But requests from people in the UK using
it for teaching
are the main motivation. Yes, it's highly
unbelievable it will
actually happen this time... but who knows?

1.9.2 release:

  *
https://bitbucket.org/pygame/pygame/issue/107/pygame-192-release
  *
https://bitbucket.org/pygame/pygame/issues?milestone=1.9.2

Debian python 3:

https://bitbucket.org/pygame/pygame/issue/221/debian-python-3-package-for-192
OS X:
https://bitbucket.org/pygame/pygame/issues

[pygame] Got a bitbucket message while pushing a commit

[Lenard Lindstrom]

Hi,

While pushing a commit to the Pygame repository, this message came up 
(in yellow lettering, no less):


remote: ***
remote:Bitbucket is disabling custom domains (CNAMEs) on 2015-07-01.
remote:
remote:The account that owns this repository has a CNAME configured.
remote:Please update your scripts and your team to use the 
bitbucket.org URL:

remote:https://bitbucket.org/pygame/pygame
remote:
remote:You can remove the CNAME from this account at:
remote:https://bitbucket.org/account/user/pygame/cnames/
remote:
remote:For more information: https://confluence.atlassian.com/x/Eg4zDQ
remote: ***

I didn't even know an alias was set up. So I guess when July rolls 
around *hg.pygame.org* stops working.


Lenard Lindstrom

Re: [pygame] freetype problem

[Lenard Lindstrom]

Hi again,

This is definitely a bug. I have opened issue Issue #237 
https://bitbucket.org/pygame/pygame/issue/237/memory-overrun-when-text-with-descenders. 
It will be fixed for Pygame 1.9.2 release.


Lenard Lindstrom

On 15-03-12 12:27 PM, Bo Jangeborg wrote:

Thanks for the answer. While I am at it I noticed that
when using render() and render_to() with a string with trailing
spaces,  one gets trimed of.

Bo)

Lenard Lindstrom skrev den 2015-03-12 18:15:

Hi,

Thanks for reporting the problem. The freetype module is to be 
released with Pygame 1.9.2, and is stable except for bug fixes. The 
Pygame Windows installers are outdated, so this bug may have already 
been fixed. I will update the installers for next week. Hopefully I 
can add a x86_64 version as well.


Lenard Lindstrom

On 15-03-12 06:38 AM, Bo Jangeborg wrote:

How stable is the freetype module ? I have been running into problems
with it hanging my app completly. The following code should demonstrate
the problem. Pressing ESC and you'll see that it has crashed. However
if you set the underline parameter to 'False' things work nicely.
I am running it on Windows 7.

# -*- encoding: utf-8 -*-
import pygame
from pygame import constants, event, display
from pygame import freetype

pygame.init()
freetype.init()
screen = display.set_mode((300, 200))
display.flip()
screen.fill(pygame.Color('White'))
display.flip()
f = pygame.freetype.SysFont('Times New Roman', 19)
f.underline = True
s, rec = f.render(u'Amazon')
screen.blit(s, (10, 30))
display.flip()

try:
loop = True
while loop:
for ev in event.get():
if ev.type == constants.QUIT:
loop = False
elif ev.type == constants.KEYDOWN and ev.key == 
constants.K_ESCAPE:

loop = False
finally:
freetype.quit()
display.quit()

Re: [pygame] freetype problem

[Lenard Lindstrom]

Hi,

Thanks for reporting the problem. The freetype module is to be released 
with Pygame 1.9.2, and is stable except for bug fixes. The Pygame 
Windows installers are outdated, so this bug may have already been 
fixed. I will update the installers for next week. Hopefully I can add a 
x86_64 version as well.


Lenard Lindstrom

On 15-03-12 06:38 AM, Bo Jangeborg wrote:

How stable is the freetype module ? I have been running into problems
with it hanging my app completly. The following code should demonstrate
the problem. Pressing ESC and you'll see that it has crashed. However
if you set the underline parameter to 'False' things work nicely.
I am running it on Windows 7.

# -*- encoding: utf-8 -*-
import pygame
from pygame import constants, event, display
from pygame import freetype

pygame.init()
freetype.init()
screen = display.set_mode((300, 200))
display.flip()
screen.fill(pygame.Color('White'))
display.flip()
f = pygame.freetype.SysFont('Times New Roman', 19)
f.underline = True
s, rec = f.render(u'Amazon')
screen.blit(s, (10, 30))
display.flip()

try:
loop = True
while loop:
for ev in event.get():
if ev.type == constants.QUIT:
loop = False
elif ev.type == constants.KEYDOWN and ev.key == 
constants.K_ESCAPE:

loop = False
finally:
freetype.quit()
display.quit()

Re: [pygame] Is it safe to subclass Pygame Channels and Sound classes?

[Lenard Lindstrom]

Sprites are a little different. They are Python classes, while Sound and 
Channel are extension types coded directly in C. pygame.mixer.Sound is 
an actual class object, and can be subclassed. mixer.Channel is just a 
function that returns a new Channel instance. The actual Channel type 
has not been updated to support subclassing. If subclassing Channel is a 
desired feature, then I will fix the oversight.


Lenard Lindstrom

On 15-01-05 07:50 PM, Paul Vincent Craven wrote:
That's normal. I usually subclass Sprites every time I use them. They 
even have methods set up that you are expected to override.


Paul Vincent Craven

On Mon, Jan 5, 2015 at 4:10 PM, Brian Madden br...@missionpinball.com 
mailto:br...@missionpinball.com wrote:


Hi Everyone!

In my app I'm making heavy use of Pygame mixer's Channels and
Sound objects. In both cases I need to add additional methods and
attributes to them. Is my code is now, I have my own classes of
each which reference related Pygame classes. (In other words, my
Channel class has a bunch of things like the name, the priority
of the sound that's currently playing, a reference to the Pygame
Channel object, etc.)

My question is whether it's ok to subclass the actual Pygame mixer
Channel and Sound classes for my use? I've never subclassed
anything from an external module before, and I guess I'm wondering
whether that's ok to do or whether that's frowned upon?

Thanks in advance!
Brian

-- 
*Brian Madden*

Mission Pinball (blog http://missionpinball.com | twitter
https://twitter.com/missionpinball | MPF software framework
http://missionpinball.com/framework | sample games
https://missionpinball.com/blog/category/big-shot-em-conversion/)

Re: [pygame] Update on Pygame builds

[Lenard Lindstrom]

Hi Paul,

The Windows pre-built are the external libraries pygame depends upon, 
such as SDL, SDL_image, libpng, freetype2. You can find a list in the 
prebuilt-template subdirectory. These are included in the Windows 
installer as pre-built dlls. When doing a Windows build with setup.py, 
the script looks for the dll's and associated C header files in a pygame 
subdirectory called prebuilt. A x86 Windows example of prebuilt can be 
downloaded from 
https://bitbucket.org/pygame/pygame/downloads/prebuilt-pygame1.9.2pre-msvcr100-win32.zip 
.


As I have only Windows XP, I cannot build or test x86_64 versions of 
these libraries. Also, I tried to keep C runtime linkage compatible with 
the Python version. However, changes made to MinGW made linking to C++ 
code to mscvr100.dll too difficult, so I used Visual Studio instead. 
Personally, I consider this too much of a headache.


I believe the C runtime library compatibility is unnecessary, so 
existing library binaries can be used. The only problem spot I see is in 
imageext.c, where open C files are passed to the libpng and libjpeg 
libraries. But these libraries also except IO callbacks, so the FILE * 
pointer can be kept in imageext.


If there are any further questions I am here to help,

Lenard Lindstrom


In the past I built the libraries with MinGW, using some tricks to link 
against the same Microsoft C runtime library as the Python version.


On 14-12-18 06:04 AM, Paul Vincent Craven wrote:

I'm working on the script now to add 2.6, 3.2,  msi installers. I don't quiet 
understand the issue with Windows pre-built. I'll look at it more.

Paul Vincent Craven


On Dec 18, 2014, at 7:43 AM, René Dudfield ren...@gmail.com wrote:

Hi,

Another repository would be better for windows prebuilt? I have some prebuilt 
mac stuff I could add to a separate repo too. Although maybe I'll stick with 
source there though.

Paul.Craven should be able to do stuff with Pygame pypi now. Unfortunately it's 
'Pygame' and not 'pygame', but I guess that doesn't matter too much for now.

best,

Re: [pygame] pygame 1.9.2 release

[Lenard Lindstrom]

I think we only need builds for Python 2.7 and 3.4.

Lenard

On 14-12-14 06:22 AM, René Dudfield wrote:

Hi Lenard,

I'm still not entirely sure the state of everything, so can't really 
say if there's anything more you should do. I'm still working through 
the issue tracker and trying stuff out. Hopefully by the end of my day 
today we will have a better idea. I'm going to be marking everything I 
think we can avoid doing to the milestone 1.9.3 in the issue tracker.


Hopefully some windows and mac buildbots will help us develop there, 
as well as let us all know what is broken. I'll focus today on the 
buildbots too.


best,



On Sat, Dec 13, 2014 at 11:36 PM, Lenard Lindstrom le...@telus.net 
mailto:le...@telus.net wrote:


Hi René,

Great news. Anything more I should do? I got distracted earlier
this year when, on the PyPy mailing list, I got the impression
that new buffer support was of low priority, making much of the
work I did on Pygame irrelevant to PyPy. But that is my personal
interpretation, and may be entirely wrong. This is something I
need to address with the PyPy developers, but can wait until after
1.9.2 is released. The added new buffer support is still relevant
to CPython.

I am for doing one final push to get version 1.9.2 release worthy,
but won't add any new features. These can wait until the basics of
the SDL2 version 2.0 are decided. For now I can see more work on
the documentation, and looking at unit tests and bugs.
Unfortunately I cannot do much to help with the Windows build, as
I only have XP i386 installed on my machine, and little interest
in upgrading (I do have access to a Windows 7 machine, so maybe I
can do a final release build.)

I think an end-of-January release date is realistic. I will now go
to the bug tracker to see what is left to do.

Lenard Lindstrom

On 14-12-12 10:33 PM, René Dudfield wrote:

Hi,

I've been prodded by a bunch of people on finally getting this
done. But requests from people in the UK using it for teaching
are the main motivation. Yes, it's highly unbelievable it will
actually happen this time... but who knows?

1.9.2 release:

  *
https://bitbucket.org/pygame/pygame/issue/107/pygame-192-release
  * https://bitbucket.org/pygame/pygame/issues?milestone=1.9.2

Debian python 3:

https://bitbucket.org/pygame/pygame/issue/221/debian-python-3-package-for-192
OS X: https://bitbucket.org/pygame/pygame/issues?component=OS%20X
Windows: https://bitbucket.org/pygame/pygame/issues?q=windows

I'm working on it this weekend. I'll concentrate on making
installation of what we have easier, but also getting the
1.9.2 release out which is blocking a new package in Debian.

I'll be moving stuff I deem not critical for the release into
having a 1.9.3 tag, rather than 1.9.2. I'll eventually be
removing modules that are not stable and were not in previous
releases. If they are blocking the release, and no one can fix
them they will be removed.

If anyone is around to help, there are a mountain of tasks to
do. I'll be in #pygame on irc, the mailing list, and in the
issue tracker. Also, if anyone is in Berlin and wants to meet
up to hack on pygame, that would be great.


best,

Re: [pygame] pygame 1.9.2 release

[Lenard Lindstrom]

Hi René,

Great news. Anything more I should do? I got distracted earlier this 
year when, on the PyPy mailing list, I got the impression that new 
buffer support was of low priority, making much of the work I did on 
Pygame irrelevant to PyPy. But that is my personal interpretation, and 
may be entirely wrong. This is something I need to address with the PyPy 
developers, but can wait until after 1.9.2 is released. The added new 
buffer support is still relevant to CPython.


I am for doing one final push to get version 1.9.2 release worthy, but 
won't add any new features. These can wait until the basics of the SDL2 
version 2.0 are decided. For now I can see more work on the 
documentation, and looking at unit tests and bugs. Unfortunately I 
cannot do much to help with the Windows build, as I only have XP i386 
installed on my machine, and little interest in upgrading (I do have 
access to a Windows 7 machine, so maybe I can do a final release build.)


I think an end-of-January release date is realistic. I will now go to 
the bug tracker to see what is left to do.


Lenard Lindstrom

On 14-12-12 10:33 PM, René Dudfield wrote:

Hi,

I've been prodded by a bunch of people on finally getting this done. 
But requests from people in the UK using it for teaching are the main 
motivation. Yes, it's highly unbelievable it will actually happen this 
time... but who knows?


1.9.2 release:

  * https://bitbucket.org/pygame/pygame/issue/107/pygame-192-release
  * https://bitbucket.org/pygame/pygame/issues?milestone=1.9.2

Debian python 3: 
https://bitbucket.org/pygame/pygame/issue/221/debian-python-3-package-for-192

OS X: https://bitbucket.org/pygame/pygame/issues?component=OS%20X
Windows: https://bitbucket.org/pygame/pygame/issues?q=windows

I'm working on it this weekend. I'll concentrate on making 
installation of what we have easier, but also getting the 1.9.2 
release out which is blocking a new package in Debian.


I'll be moving stuff I deem not critical for the release into having a 
1.9.3 tag, rather than 1.9.2. I'll eventually be removing modules that 
are not stable and were not in previous releases. If they are blocking 
the release, and no one can fix them they will be removed.


If anyone is around to help, there are a mountain of tasks to do. I'll 
be in #pygame on irc, the mailing list, and in the issue tracker. 
Also, if anyone is in Berlin and wants to meet up to hack on pygame, 
that would be great.



best,

Re: [pygame] Pygame blitting 8-bit surfaces doesn't ignore palettes?

[Lenard Lindstrom]

Hi Brian,

On 14-12-02 09:56 AM, Brian Madden wrote:
Hi. I'm working with 8-bit surfaces in Python 2.7 with Pygame 
1.9.2pre. Everything I've read says that if I blit an 8-bit surface to 
another 8-bit surface, Pygame will ignore both palettes and only copy 
each pixel's 8-bit integer value from the source surface to the 
destination surface.


A Pygame Surface lets the programmer work with SDL surfaces without the 
concern of how the pixel data is actually represented in memory. A 
Pygame Surface pixel is the decoded--unmapped--(R, G, B, A) 
representation of the color encoded--mapped--into the pixel's actual 
integer value. Since a Pygame Surface is a color representation its 
pixel data, it is natural that Surface methods do high level color 
transformations rather than direct integer value manipulation. So, 
Surface.blit() actually blits unmapped pixel colors, with the result 
mapped back into the destination surface binary format (Of course, 
shortcuts are taken when possible.)


My experience so far is that this is *not* what happens. Rather, I'm 
seeing that that when blitting, Pygame will use the source surface's 
palette to get the 24-bit entry for each pixel, then look for that 
24-bit value in the destination surface's palette, and then write the 
8-bit integer value from the destination surface's palette as the 
pixel value in the destination surface. If there are no matching 
24-bit palette entries for the palettes for both surfaces, then the 
resulting pixel's integer value in the destination surface is 0.
For two 8-bit surfaces without surface alpha or a color key the 
Surface.blit() method has SDL do the blit.




I'm just curious as to whether this is this a bug, or is my 
understanding of how Pygame works with 8-bit surfaces not correct? (In 
my case I have multiple surfaces each with their own palettes, and if 
I blit a pixel value of 1 then I want it to be 1 on my destination 
surface regardless of what any of the palettes are! :)


Yes, the Pygame.blit() method description lacks detail. It assumes the 
reader has some understanding of the SDL library. But this is no longer 
a reasonable expectation. The pygame.Surface documentation needs updating.



It is possible to do a direct integer copy with pygame.PixelArray. Here 
is a basic example:


def pxcopy(source, target, dest=None):
Copy raw surface pixels from source to target

   Argument dest is the (x, y) coordinates within the target surface
   where the source surface will be copied. The default is (0, 0).
   This simple example fails if the source rect does not fit entirely
   within the target boundary.

if dest is None:
dest = (0, 0)
x, y = dest
s = PixelArray(source)
w, h = s.shape
t = PixelArray(target)
t[x:x+w, y:y+h] = s

 import pygame
 pygame.display.init()  # Need this to enable Surface.set_palette()
 from pygame import Surface, PixelArray
 palette = [(i, i, i) for i in range(256)]
 target = Surface((100, 100), 0, 8)
 target.set_palette(palette)
 target.set_palette(palette)
 target.fill((30, 30, 30))
 rect(0, 0, 100, 100)
 target.get_at((10, 15))
(30, 30, 30, 255)
 target.get_at_mapped((10, 15))
30
 source = Surface((20, 30), 0, 8)
 source.fill((255, 0, 0))
rect(0, 0, 20, 30)
 source.get_at((0, 0))
(255, 0, 0, 255)
 source.get_at_mapped((0, 0))
96
 pxcopy(source, target, (10, 15))
 target.get_at_mapped((10, 15))
96
 target.get_at((10, 15))
(96, 96, 96, 255)
 target.get_at((0, 0))
(30, 30, 30, 255)



Lenard Lindstrom

[pygame] Pygame 2.0 software blits

[Lenard Lindstrom]

Hi everyone,

I have taken a side excursion to test ways to replace Pygame's many hand 
coded blit loops with a more abstract loop generating mechanism 
(previously discussed in this tread 
http://article.gmane.org/gmane.comp.python.pygame/21919/match=blit+jit). 
One promising approach is a JIT powered blit 
interpreterhttps://bitbucket.org/llindstrom/blitter written in PyPy's 
RPython http://doc.pypy.org/en/latest/getting-started-dev.html. I have 
written a simple prototype, available at

https://bitbucket.org/llindstrom/blitter.

The blitter is implemented as an interpreted bytecode language that 
supports loops and byte copies. The prototype does integer array copies 
for different integer sizes and byte order. Array strides are supported. 
A code block is generated dynamically for each unique pair of source and 
target integer types encountered. Code blocks are cached. The actual 
blit is done by an interpreter executing the code block. What is useful 
is that the RPython compiler automatically creates the JIT for the 
interpreter loop. So the bytecode gets compiled to machine code and run 
directly. My simple prototype has copy speeds comparable to 
pygame.pixelcopy.array_to_surface(), a hand coded blitter written in C.


To keep the prototype blitter compatible with both CPython and RPython I 
wrote it as a standalone C shared library. The pure Python wrapper 
module uses CFFI. The C library is self contained; it has no Python 
dependencies whatsoever.


A Pygame level production blitter would extend the simple bytecode 
language to support basic arithmetic operations, different integer 
sizes, as well as higher level operations such as pixel 
encoding/decoding and alpha blitting. It would replace code in 
alphablit.c, pixelcopy.c, and freetype/ft_render_cb.c.


Just something to consider.

Lenard Lindstrom

Re: [SPAM: 8.000] [pygame] Pygame 2.0 software blits

[Lenard Lindstrom]

On 14-03-03 02:48 PM, Greg Ewing wrote:

Lenard Lindstrom wrote:
A Pygame level production blitter would extend the simple bytecode 
language to support basic arithmetic operations, different integer 
sizes, as well as higher level operations such as pixel 
encoding/decoding and alpha blitting. It would replace code in 
alphablit.c, pixelcopy.c, and freetype/ft_render_cb.c.


Just something to consider.


This sounds very interesting, especially if it allows a
wider and more useful set of operations to be supported,
such as specifying separate combining functions for rgb
and alpha channels.

If the bytecode is exposed at the Python end then any expression can be 
encoded, a different one for each channel if desired. Conceivably, a 
Python expression, or function, could be compiled into a blit operation.

Re: [pygame] Pygame 2.0 software blits

[Lenard Lindstrom]

Hi Keith,

It's still a little early to know how this will work out. I have to 
confirm that RPython's garbage collector properly handles multiple calls 
into the interpreter without resetting each time. But I don't think 
there is a problem.


Lenard Lindstrom

On 14-03-03 03:29 PM, Keith Nemitz wrote:


thanks for doing all this!
Keith Nemitz
Principal Developer
Mousechief Co.
www.mousechief.com


*From:* Lenard Lindstrom le...@telus.net
*To:* Pygame Mail List pygame-users@seul.org
*Sent:* Monday, March 3, 2014 2:23 PM
*Subject:* [pygame] Pygame 2.0 software blits

Hi everyone,

I have taken a side excursion to test ways to replace Pygame's many 
hand coded blit loops with a more abstract loop generating mechanism 
(previously discussed in this tread 
http://article.gmane.org/gmane.comp.python.pygame/21919/match=blit+jit). 
One promising approach is a JIT powered blit 
interpreterhttps://bitbucket.org/llindstrom/blitter written in 
PyPy's RPython 
http://doc.pypy.org/en/latest/getting-started-dev.html. I have 
written a simple prototype, available at

https://bitbucket.org/llindstrom/blitter.

The blitter is implemented as an interpreted bytecode language that 
supports loops and byte copies. The prototype does integer array 
copies for different integer sizes and byte order. Array strides are 
supported. A code block is generated dynamically for each unique pair 
of source and target integer types encountered. Code blocks are 
cached. The actual blit is done by an interpreter executing the code 
block. What is useful is that the RPython compiler automatically 
creates the JIT for the interpreter loop. So the bytecode gets 
compiled to machine code and run directly. My simple prototype has 
copy speeds comparable to pygame.pixelcopy.array_to_surface(), a hand 
coded blitter written in C.


To keep the prototype blitter compatible with both CPython and RPython 
I wrote it as a standalone C shared library. The pure Python wrapper 
module uses CFFI. The C library is self contained; it has no Python 
dependencies whatsoever.


A Pygame level production blitter would extend the simple bytecode 
language to support basic arithmetic operations, different integer 
sizes, as well as higher level operations such as pixel 
encoding/decoding and alpha blitting. It would replace code in 
alphablit.c, pixelcopy.c, and freetype/ft_render_cb.c.


Just something to consider.

Lenard Lindstrom

Re: [pygame] Python3 version packaged?

[Lenard Lindstrom]

Hi,

On Gnu/Linux it is simpler to just build Pygame from source. The 
dependencies are libsdl-mixer, libsdl-image, libsdl-ttf, and 
libportmidi0. Installing these libraries, and their header file dev 
packages should force the installation of all Pygame dependencies, such 
as SDL and freetype2. Also be sure to include the Python3 dev package. 
Since I do most of my Pygame development on Linux Mint, there should be 
no compatibility issues on Ubuntu, except with libportmidi0. So I 
suggest commenting out the Pygame midi module entry in the Setup file.


Lenard Lindstrom

On 13-12-31 09:36 AM, Sam Bull wrote:

Can we get a working Python3 version of Pygame packaged either in the
Ubuntu repositories or in pip3?

This would be really helpful in allowing us to transition to Python3 for
our projects.

Re: [pygame] Quick OS survey - 2013

[Lenard Lindstrom]

90% Linux Mint
8% Windows XP
2% OS X

On 13-12-05 08:43 PM, Jason Marshall wrote:
pygamers, which computer operating system(s) have you used this year? 
If you have been using more than 1 operating system, approximately 
what percentage of your time are you using each one?


Here's my breakdown:
0.5%Linux Mint
0.5%Mac OS X 10.4
2%Windows ME
4%Windows XP
5%Mac OS X 10.6
88%Windows 7

Re: [pygame] String replace error in docs

[Lenard Lindstrom]

Those docs are for Pygame 1.9.1, and are very outdated. Use 
http://pygame.bitbucket.org/docs/pygame/index.html for up-to-date docs.


Lenard Lindstrom

On 13-11-23 08:40 PM, Jake b wrote:

See the broken output at

http://www.pygame.org/docs/ref/sprite.html#pygame.sprite.LayeredUpdates

--
Jake

Re: [pygame] Midi Crashes on Error

[Lenard Lindstrom]

On 13-11-03 09:57 AM, Christopher Arndt wrote:

Hi Lenard,

On 02.11.2013 02:25, Lenard Lindstrom wrote:

Just wondering, if the Python level callback is found to be too slow, could a
C level callback mechanism be provided?

how would you suggest this should be used? From Python or C?

In python-rtmidi this is currently not possible from Python, because
'MidiIn.set_callback' wraps a Python callback function with a C function
implemented in Cython (and you can't access the C++ object directly in
Python, only in the Cython code).

I guess it would be easy to make the C++ method 'RtMidiIn.setCallback'
available directly in Python, but I'm not sure how a pointer to a C
function could be passed by Python then or how such a pointer could be
obtained by Python.

So any ideas about a suitable API for this? And how it would tie into
PyGame's C code?


Chris

Cython has a C level sharing mechanism with cimport:

http://docs.cython.org/src/userguide/sharing_declarations.html#sharing-declarations-between-cython-modules

This should be usable from a standard C extension module. So something like:

int RtMidi_SetCallback(PyObject *midi_in, RtMidiCallback callback, void 
*data);


Anyway, I don't see any rush in implementing this. It may be that using 
a Python callback will be fast enough.


Lenard

Re: [pygame] Midi Crashes on Error

[Lenard Lindstrom]

Hi Chris,

python-rtmidi looks great. It should replace pyportmidi as the Pygame 
midi backend. In particular, I like the midi event callback which rtmidi 
provides. This will allow midi events to be tied into SDL events. Just 
wondering, if the Python level callback is found to be too slow, could a 
C level callback mechanism be provided?


Lenard Lindstrom


On 13-11-01 05:39 AM, Christopher Arndt wrote:

On 01.11.2013 09:52, William Heatley wrote:

Suggested Solution:
Do not define PM_CHECK_ERRORS.

This is defined in the underlying portmidi library, which AFAIK is
linked dynamically. So it is up to your OS to provide a version of
libportmidi without PM_CHECK_ERRORS defined. This has been a
long-standing issue with debian/Ubuntu. I'd go as far as to say that
portmidi is unmaintained.

Might I suggest you have a look at my python-rtmidi library:

http://chrisarndt.de/projects/python-rtmidi

I've done some important changes in the last few weeks so I would
suggest getting the source code from Subversion for now. I'm planning to
make a 0.4b release soon.

Chris

Re: [pygame] Midi Crashes on Error

[Lenard Lindstrom]

Hello William,

PortMidi is a nuisance. I do Pygame development on a Ubuntu derived 
Gnu/Linux distribution, and had to build a custom PortMidi library for 
use with Pygame.


Lenard Lindstrom

On 13-11-01 01:52 AM, William Heatley wrote:

Python: 2.7.4
PyGame: 1.9.1release
OS: Ubuntu 13.04

Problem:
Any call to the pygame.midi functions which cause PortMidi to return 
an error, will cause the entire program to exit (at the C level; no 
exceptions reach Python).  In the PortMidi interface code, pm_errmsg 
calls prompt_and_exit.  This appears to be because PM_CHECK_ERRORS is 
defined.  I don't believe it should be.  Not defining it will cause 
the interface code to return the error codes back to Python, instead 
of just printing and exiting.


Suggested Solution:
Do not define PM_CHECK_ERRORS.

Reproduction:
# There must be an input midi device at index 1
# This will cause the porgram to exit immediately, no Exception.
import pygame, pygame.midi

pygame.init ()
pygame.midi.init ()

inp = pygame.midi.Input (1)
inp2 = pygame.midi.Input (1)

~William

[pygame] freetype module now stable

[Lenard Lindstrom]

The freetype module is complete and ready for the Pygame 1.9.2 release. 
The Python api is frozen. I promise not to break programs by tweaking 
it. So, please, try out the bonus features freetype offers over the 
SDL_ttf based font module.


For Windows users, I have built an new Python 3.3, x32 installer with 
the completed freetype. It's available at the Pygame download page on 
bitbucket https://bitbucket.org/pygame/pygame/downloads.


md5 stuff:

87f171bd30d529982112347e489af125 
*pygame-1.9.2a0-hg_56e0eadfc267.win32-py3.3.msi


I had hoped to include a Pygame installer for Python 2.7. Unfortunately, 
freetype failed the unit tests. It needs a newer version of the 
FreeType2 library. I intend to release it at some point. Otherwise...


Enjoy,

Lenard Lindstrom

Re: [pygame] Pygame look and feel

[Lenard Lindstrom]

I'm happy. Great work.

Lenard

On 13-10-09 02:07 AM, Aikiman wrote:

Okay had a bit of a play around, added eye brows to accentuate expression and
add character, moved the controller and tucked it in Snakey's tail. I dont
think it can go any deeper as it will conceal too much of the controller.
Also changed the position of Snakey's body so that it no longer conceals the
M or the E and changed the drop shadow to a plain version.
Somebody mentioned that this could be a good option for the release of
Pygame 2.0, that sounds like a good idea whenever that might be.

http://pygame-users.25799.x6.nabble.com/file/n950/pythonLogo_v02.jpg



--
View this message in context: 
http://pygame-users.25799.x6.nabble.com/Pygame-look-and-feel-tp906p950.html
Sent from the pygame-users mailing list archive at Nabble.com.

Re: [pygame] freetype + unusual font format: What am I doing wrong?

[Lenard Lindstrom]

I've added a note to Pygame issue #75 to add a Font.get_sizes() method 
to list available sizes for a bitmap font.


Lenard Lindstrom

On 13-10-08 06:42 PM, Jason Marshall wrote:
Thanks for digging into this. If multiplying the em width by 2 // 3 is 
the most difficult step in using a bitmap font with pygame, then I'm 
happy!


Jason


*From:* Lenard Lindstrom le...@telus.net
*To:* pygame-users@seul.org
*Sent:* Tuesday, October 8, 2013 12:32 AM
*Subject:* Re: [pygame] freetype + unusual font format: What am I 
doing wrong?


I looked at the BDF code in freetype2, and then ran a debugger on
pygame.freetype to confirm. In freetype2, when only a SIZE record in a
BDF file, the width, in pixels-per-em, is calculated as (height * 2 / 3)
[1], which may not be the point size given in the SIZE record. For
c64.dbf this is (8 * 2 / 3) = 5. The width is used as the font size.
This is a quirk of the freetype library. I see no easy work-around.

Lenard Lindstrom

[1] bdfdrivr.c:438, see
http://git.savannah.gnu.org/cgit/freetype/freetype2.git/tree/src/bdf/bdfdrivr.c?id=VER-2-5-0-1#n438

Re: [pygame] freetype + unusual font format: What am I doing wrong?

[Lenard Lindstrom]

Hi Westley,

I don't know enough about the Glyph Bitmap Distribution Format to 
suggest how it should be interpreted. This format was defined by Adobe, 
and used by X11. The latest linux xterm uses freetype for font rendering.


Lenard Lindstrom

On 13-10-07 11:41 PM, Westley Martínez wrote:

Perhaps it'd be a good idea to contact the maintainers of freetype.
Westley Martínez
EPC Treasurer
(562) 343-0403
westley...@gmail.com


On Mon, Oct 7, 2013 at 10:32 PM, Lenard Lindstrom le...@telus.net wrote:

I looked at the BDF code in freetype2, and then ran a debugger on
pygame.freetype to confirm. In freetype2, when only a SIZE record in a BDF
file, the width, in pixels-per-em, is calculated as (height * 2 / 3) [1],
which may not be the point size given in the SIZE record. For c64.dbf this
is (8 * 2 / 3) = 5. The width is used as the font size. This is a quirk of
the freetype library. I see no easy work-around.

Lenard Lindstrom

[1] bdfdrivr.c:438, see
http://git.savannah.gnu.org/cgit/freetype/freetype2.git/tree/src/bdf/bdfdrivr.c?id=VER-2-5-0-1#n438

Re: [pygame] freetype + unusual font format: What am I doing wrong?

[Lenard Lindstrom]

I looked at the BDF code in freetype2, and then ran a debugger on 
pygame.freetype to confirm. In freetype2, when only a SIZE record in a 
BDF file, the width, in pixels-per-em, is calculated as (height * 2 / 3) 
[1], which may not be the point size given in the SIZE record. For 
c64.dbf this is (8 * 2 / 3) = 5. The width is used as the font size. 
This is a quirk of the freetype library. I see no easy work-around.


Lenard Lindstrom

[1] bdfdrivr.c:438, see 
http://git.savannah.gnu.org/cgit/freetype/freetype2.git/tree/src/bdf/bdfdrivr.c?id=VER-2-5-0-1#n438


On 13-10-06 02:44 PM, Lenard Lindstrom wrote:

Okay, setting the resolution to 45 corrects the sizes:

pygame.freetype.init(resolution=45)

Python 2.7.3
pygame 1.9.2a0
pygame.freetype 2.4.10
radon.bdf 12
radon.bdf 13
radon-wide.bdf 12
radon-wide.bdf 13
c64.bdf 8
c64d.bdf 16

I don't know why this is the case. Explicit bitmap font support is not 
built into the freetype module, so is untested.  It is something I 
intended, but have not got around too. Sorry.


Lenard Lindstrom.

On 13-10-05 03:07 PM, Lenard Lindstrom wrote:



[snip]
The freetype version of pygame.font.init() is just 
pygame.freetype.init(). It takes a 'resolution' keyword argument that 
sets the default pitch used in rendering. I suppose setting the pitch 
to the screen resolution, in pixels per inch, makes the point size 
equal pixel size. The pygame.freetype.Font type allows pitch to be 
set individually for each Font instance. It is this pitch twiddling 
which allows pygame.freetype.Font to mimic how pygame.font.Font 
handles the default Pygame font, which is scaled differently from 
other fonts.



On 13-10-05 01:48 PM, Jason Marshall wrote:

Maybe my understanding of size is wrong...
http://www.freetype.org/freetype2/docs/ft2faq.html#other-size

 


*From:* Jason Marshall j...@yahoo.com
*To:* pygame-users@seul.org pygame-users@seul.org
*Sent:* Saturday, October 5, 2013 2:41 PM
*Subject:* Re: [pygame] freetype + unusual font format: What am I 
doing wrong?


Lenard,

Sorry, updating to pygame-1.9.2a0-12de2da43ecb.win32-py3.3.msi 
didn't help.


By passing a different (wrong) size, I was able to get freetype to 
render some fonts but not others. I made a webpage with the only 
documentation that I have found, some demo code that can render from 
some BDF fonts, and a screenshot:

http://www.marshallworkshop.com/pygame/freetype-bug/

I suspect that there's a mistake in the documentation for 
instantiating the pygame.freetype.Font class. If I follow the 
documentation and pass it the font name, style and size, I get an 
error.  If I just pass only the font name and a certain (wrong) 
size, it sometimes renders.


Jason

Re: [pygame] freetype + unusual font format: What am I doing wrong?

[Lenard Lindstrom]

Okay, setting the resolution to 45 corrects the sizes:

pygame.freetype.init(resolution=45)

Python 2.7.3
pygame 1.9.2a0
pygame.freetype 2.4.10
radon.bdf 12
radon.bdf 13
radon-wide.bdf 12
radon-wide.bdf 13
c64.bdf 8
c64d.bdf 16

I don't know why this is the case. Explicit bitmap font support is not 
built into the freetype module, so is untested.  It is something I 
intended, but have not got around too. Sorry.


Lenard Lindstrom.

On 13-10-05 03:07 PM, Lenard Lindstrom wrote:

Hi,

I don't know what exactly you are looking for. The BDF fonts are 
bitmap fonts, so do not scale. Each font supports only a few specifc 
sizes.


Freetype works in point size, which is not pixel size. Point size is 
supposed to represent the size as viewed. By default it assumes there 
are 72 points to an inch. So a point size of 10 should give around 7 
characters per inch. However, the pitch value of 72 points per inch is 
a builtin constant; it is not calculated from the actual screen 
resolution. So actual font size will vary with the monitor used.


The freetype version of pygame.font.init() is just 
pygame.freetype.init(). It takes a 'resolution' keyword argument that 
sets the default pitch used in rendering. I suppose setting the pitch 
to the screen resolution, in pixels per inch, makes the point size 
equal pixel size. The pygame.freetype.Font type allows pitch to be set 
individually for each Font instance. It is this pitch twiddling which 
allows pygame.freetype.Font to mimic how pygame.font.Font handles the 
default Pygame font, which is scaled differently from other fonts.


Lenard Lindstom

On 13-10-05 01:48 PM, Jason Marshall wrote:

Maybe my understanding of size is wrong...
http://www.freetype.org/freetype2/docs/ft2faq.html#other-size


*From:* Jason Marshall j...@yahoo.com
*To:* pygame-users@seul.org pygame-users@seul.org
*Sent:* Saturday, October 5, 2013 2:41 PM
*Subject:* Re: [pygame] freetype + unusual font format: What am I 
doing wrong?


Lenard,

Sorry, updating to pygame-1.9.2a0-12de2da43ecb.win32-py3.3.msi didn't 
help.


By passing a different (wrong) size, I was able to get freetype to 
render some fonts but not others. I made a webpage with the only 
documentation that I have found, some demo code that can render from 
some BDF fonts, and a screenshot:

http://www.marshallworkshop.com/pygame/freetype-bug/

I suspect that there's a mistake in the documentation for 
instantiating the pygame.freetype.Font class. If I follow the 
documentation and pass it the font name, style and size, I get an 
error.  If I just pass only the font name and a certain (wrong) size, 
it sometimes renders.


Jason



*From:* Lenard Lindstrom le...@telus.net
*To:* pygame-users@seul.org
*Sent:* Friday, October 4, 2013 1:21 PM
*Subject:* Re: [pygame] freetype + unusual font format: What am I 
doing wrong?


Hi Jason,

This sounds like issue #144, unable to render text.
https://bitbucket.org/pygame/pygame/issue/144/unable-to-render-text
The issue #144 fix is included in an updated 32bit Windows installer
added to the downloads page
https://bitbucket.org/pygame/pygame/issue/144/unable-to-render-text
earlier this week: pygame-1.9.2a0-12de2da43ecb.win32-py3.3.msi
https://bitbucket.org/pygame/pygame/downloads/pygame-1.9.2a0-12de2da43ecb.win32-py3.3.msi. 


I have taken to adding a changeset identifier to the file name so
tracking installer versions will be easer.

Lenard Lindstrom

On 13-10-04 05:50 AM, Jason Marshall wrote:
 I would like to use the freetype module to render text from a BDF font
 file, but I am getting a vague error. I am using the 8x8 font from
 this site:
 http://beej.us/c64bdf/c64bdf/c64.bdf

 import os
 os.environ[PYGAME_FREETYPE] = 1
 import pygame
  pygame.font
 module 'pygame.ftfont' from
 'C:\\Python33\\lib\\site-packages\\pygame\\ftfont.py'
  import pygame.freetype
  pygame.freetype.init()
  c64 = 
pygame.freetype.Font(r'C:\Users\marshalls\Downloads\c64.bdf', 8)
  s = c64.render('TEST', pygame.Color('white'), 
pygame.Color('blue'))

 Traceback (most recent call last):
  File stdin, line 1, in module
 SystemError: error return without exception set
 

 Can somebody spot what I am doing wrong?

 I am using a recent build of pygame 1.9.2pre and Python 3.3 (32-bit)
 on Windows.

 Thanks,
 Jason

Re: [pygame] Pygame look and feel

[Lenard Lindstrom]

Looks good. Maybe the game controller can be the M in Pygame. Also, a 
matching icon is needed.


Lenard Lindstrom

On 13-10-04 12:45 AM, Aikiman wrote:

For what its worth then here are a couple of designs of the logo. Im only
throwing them up here because i've already done the work but if you are
interested I can continue onward with colors, otherwise I can drop this no
problems. Maybe its something for the future then.

http://pygame-users.25799.x6.nabble.com/file/n912/pygame1.jpg



--
View this message in context: 
http://pygame-users.25799.x6.nabble.com/Pygame-look-and-feel-tp906p912.html
Sent from the pygame-users mailing list archive at Nabble.com.

Re: [pygame] Pygame look and feel

[Lenard Lindstrom]

The python is sometimes referred to as Snakey. I agree, leave the M as 
an M. I do find the lettering in the main example illegible. Too much is 
hidden by Snakey's body. In the top example Shakey is more of an 
afterthought. Maybe the PYGAME can be left out entirely, as in the 
lower right corner example. It can be included under the logo when 
desired. As for the python being frightening, I find it more daring, or 
risky. It reminds me of Sir Hiss 
http://youchew.net/wiki/index.php?title=Sir_Hiss.


On 13-10-05 11:44 AM, Westley Martínez wrote:

Nay, the M should not be the M in Pygame. Replacing letters with objects
is usually a bad idea, esp. when the letter isn't significant.  I think
Aikiman should try putting the controller in the Python's mouth.  Also,
I think the python (perhaps we should name him?) should look a little
less intimidating.  He's a lot more frightening when compared to the old
one.


-Original Message-
From: owner-pygame-us...@seul.org [mailto:owner-pygame-us...@seul.org] On
Behalf Of Lenard Lindstrom
Sent: Friday, October 04, 2013 11:07 PM
To: pygame-users@seul.org
Subject: Re: [pygame] Pygame look and feel

Looks good. Maybe the game controller can be the M in Pygame. Also, a
matching icon is needed.

Lenard Lindstrom

On 13-10-04 12:45 AM, Aikiman wrote:

For what its worth then here are a couple of designs of the logo. Im only
throwing them up here because i've already done the work but if you are
interested I can continue onward with colors, otherwise I can drop this no
problems. Maybe its something for the future then.

http://pygame-users.25799.x6.nabble.com/file/n912/pygame1.jpg



--
View this message in context: http://pygame-

users.25799.x6.nabble.com/Pygame-look-and-feel-tp906p912.html

Sent from the pygame-users mailing list archive at Nabble.com.

Re: [pygame] freetype + unusual font format: What am I doing wrong?

[Lenard Lindstrom]

Hi,

I don't know what exactly you are looking for. The BDF fonts are bitmap 
fonts, so do not scale. Each font supports only a few specifc sizes.


Freetype works in point size, which is not pixel size. Point size is 
supposed to represent the size as viewed. By default it assumes there 
are 72 points to an inch. So a point size of 10 should give around 7 
characters per inch. However, the pitch value of 72 points per inch is a 
builtin constant; it is not calculated from the actual screen 
resolution. So actual font size will vary with the monitor used.


The freetype version of pygame.font.init() is just 
pygame.freetype.init(). It takes a 'resolution' keyword argument that 
sets the default pitch used in rendering. I suppose setting the pitch to 
the screen resolution, in pixels per inch, makes the point size equal 
pixel size. The pygame.freetype.Font type allows pitch to be set 
individually for each Font instance. It is this pitch twiddling which 
allows pygame.freetype.Font to mimic how pygame.font.Font handles the 
default Pygame font, which is scaled differently from other fonts.


Lenard Lindstom

On 13-10-05 01:48 PM, Jason Marshall wrote:

Maybe my understanding of size is wrong...
http://www.freetype.org/freetype2/docs/ft2faq.html#other-size


*From:* Jason Marshall j...@yahoo.com
*To:* pygame-users@seul.org pygame-users@seul.org
*Sent:* Saturday, October 5, 2013 2:41 PM
*Subject:* Re: [pygame] freetype + unusual font format: What am I 
doing wrong?


Lenard,

Sorry, updating to pygame-1.9.2a0-12de2da43ecb.win32-py3.3.msi didn't 
help.


By passing a different (wrong) size, I was able to get freetype to 
render some fonts but not others. I made a webpage with the only 
documentation that I have found, some demo code that can render from 
some BDF fonts, and a screenshot:

http://www.marshallworkshop.com/pygame/freetype-bug/

I suspect that there's a mistake in the documentation for 
instantiating the pygame.freetype.Font class. If I follow the 
documentation and pass it the font name, style and size, I get an 
error.  If I just pass only the font name and a certain (wrong) size, 
it sometimes renders.


Jason



*From:* Lenard Lindstrom le...@telus.net
*To:* pygame-users@seul.org
*Sent:* Friday, October 4, 2013 1:21 PM
*Subject:* Re: [pygame] freetype + unusual font format: What am I 
doing wrong?


Hi Jason,

This sounds like issue #144, unable to render text.
https://bitbucket.org/pygame/pygame/issue/144/unable-to-render-text
The issue #144 fix is included in an updated 32bit Windows installer
added to the downloads page
https://bitbucket.org/pygame/pygame/issue/144/unable-to-render-text
earlier this week: pygame-1.9.2a0-12de2da43ecb.win32-py3.3.msi
https://bitbucket.org/pygame/pygame/downloads/pygame-1.9.2a0-12de2da43ecb.win32-py3.3.msi. 


I have taken to adding a changeset identifier to the file name so
tracking installer versions will be easer.

Lenard Lindstrom

On 13-10-04 05:50 AM, Jason Marshall wrote:
 I would like to use the freetype module to render text from a BDF font
 file, but I am getting a vague error. I am using the 8x8 font from
 this site:
 http://beej.us/c64bdf/c64bdf/c64.bdf

 import os
 os.environ[PYGAME_FREETYPE] = 1
 import pygame
  pygame.font
 module 'pygame.ftfont' from
 'C:\\Python33\\lib\\site-packages\\pygame\\ftfont.py'
  import pygame.freetype
  pygame.freetype.init()
  c64 = 
pygame.freetype.Font(r'C:\Users\marshalls\Downloads\c64.bdf', 8)

  s = c64.render('TEST', pygame.Color('white'), pygame.Color('blue'))
 Traceback (most recent call last):
  File stdin, line 1, in module
 SystemError: error return without exception set
 

 Can somebody spot what I am doing wrong?

 I am using a recent build of pygame 1.9.2pre and Python 3.3 (32-bit)
 on Windows.

 Thanks,
 Jason

Re: [pygame] Pygame look and feel

[Lenard Lindstrom]

That looks nice. Maybe the python can hold the controller with his tail, 
ala Sir Hiss. I played a bit with having Snakey perched atop the 
letters, rather than wrapped around them. Just thoughts.


On 13-10-05 02:38 PM, Aikiman wrote:

Good comments have been made.

Initially I had the idea to make the M the controller but as suggested there
kind of needs to be a reason for it - however I decided to see what it
looked like anyway over last nights session on the computer - I think it
works but perhaps it would be better somewhere else. I could try in the
python's mouth but I dont really want to change his face in anyway as I feel
I have captured its expression pretty well, he needs some character and the
controller would take that away from him.

Which brings me onto my second point how should the snake look. The logo
style is based on 'retro cool' appeal - well at least thats where Ive tried
to draw influence from :) I wanted a cheaky but half serious attitude.
Trying to maintain some of the old logo of retro playfulness but taken out
the goofy and replaced with serious cool.

Note Ive also introduced it as a color concept carrying the old logo colors
through but subduing them somewhat and adding stylistic shading. Also played
with the placement of lettering for clarity bringing the E in front of the
snake.

In the next concept I think I will move the controller somewhere else and
stick the M back in for starters. Ill sit on this for a couple of days and
get back into it then.
Crits and comments welcome.
http://pygame-users.25799.x6.nabble.com/file/n938/pythonLogo_v01.jpg



--
View this message in context: 
http://pygame-users.25799.x6.nabble.com/Pygame-look-and-feel-tp906p938.html
Sent from the pygame-users mailing list archive at Nabble.com.

[pygame] New 32 bit Pygame installer for Python 3.3 on Windows

[Lenard Lindstrom]

Updated Pygame 1.9.2a0 installer for Python 3.3 at 
https://bitbucket.org/pygame/pygame/downloads.


md5 stuff:
60ee67037b7e9ffeca88425d8712fdde 
*pygame-1.9.2a0-12de2da43ecb.win32-py3.3.msi


This addresses issues #144 
https://bitbucket.org/pygame/pygame/issue/144/unable-to-render-text, 
#175 
https://bitbucket.org/pygame/pygame/issue/175/memory-leak-when-setting-pixels-with, 
and #166 
https://bitbucket.org/pygame/pygame/issue/166/events-have-a-type-attribute-which-is-not, 
as well as fixes several bugs detected by CPyChecker (issue #171 
https://bitbucket.org/pygame/pygame/issue/171/check-pygame-with-cpychecker).


Enjoy,

Lenard Lindstrom

Re: [pygame] freetype + unusual font format: What am I doing wrong?

[Lenard Lindstrom]

Hi Jason,

This sounds like issue #144, unable to render text. 
https://bitbucket.org/pygame/pygame/issue/144/unable-to-render-text 
The issue #144 fix is included in an updated 32bit Windows installer 
added to the downloads page 
https://bitbucket.org/pygame/pygame/issue/144/unable-to-render-text 
earlier this week: pygame-1.9.2a0-12de2da43ecb.win32-py3.3.msi 
https://bitbucket.org/pygame/pygame/downloads/pygame-1.9.2a0-12de2da43ecb.win32-py3.3.msi. 
I have taken to adding a changeset identifier to the file name so 
tracking installer versions will be easer.


Lenard Lindstrom

On 13-10-04 05:50 AM, Jason Marshall wrote:
I would like to use the freetype module to render text from a BDF font 
file, but I am getting a vague error. I am using the 8x8 font from 
this site:

http://beej.us/c64bdf/c64bdf/c64.bdf

import os
os.environ[PYGAME_FREETYPE] = 1
import pygame
 pygame.font
module 'pygame.ftfont' from 
'C:\\Python33\\lib\\site-packages\\pygame\\ftfont.py'

 import pygame.freetype
 pygame.freetype.init()
 c64 = pygame.freetype.Font(r'C:\Users\marshalls\Downloads\c64.bdf', 8)
 s = c64.render('TEST', pygame.Color('white'), pygame.Color('blue'))
Traceback (most recent call last):
  File stdin, line 1, in module
SystemError: error return without exception set


Can somebody spot what I am doing wrong?

I am using a recent build of pygame 1.9.2pre and Python 3.3 (32-bit) 
on Windows.


Thanks,
Jason

[pygame] Updated Pygame (changeset 851743cb4c5a) windows installer for Python 2.7

[Lenard Lindstrom]

Hi everyone,

Just recording the md5sum for an updated Pygame 1.9.2a0 (changeset 
851743cb4c5a) 32-bit windows installer for Python 2.7:


https://bitbucket.org/pygame/pygame/downloads/pygame-1.9.2a0.win32-py2.7.msi, 
3,948,544 bytes


31a7797c93d635541cf34fa654167627 *pygame-1.9.2a0.win32-py2.7.msi

Note, it fails a couple of unit tests, but should still be usable.

An updated Python 3.3 installer is also ready, and will be uploaded shortly.

Lenard Lindstrom

Re: [pygame] SDL 2.0

[Lenard Lindstrom]

On 13-08-17 12:28 AM, Marcus von Appen wrote:

On, Sat Aug 17, 2013, Lenard Lindstrom wrote:


Ctypes may be the way to go on PyPy, but it is slow in CPython. It lacks
new buffer support. Well, ctype types have buffers, but they don't work
with NumPy.

Take a look at
https://bitbucket.org/marcusva/py-sdl2/src/963b26e2110449a453efa7fa45328c0062c72697/sdl2/ext/pixelaccess.py?at=default

Accessing ctypes buffers or exposing ctypes buffers to Numpy is not a
problem.

Cheers
Marcus

Hi Marcus,

Is there a way to create a custom bf_releasebuffer function for a ctype 
object? When exporting an SDL_Surface pixel buffer using the 3118 (new) 
buffer interface, I would like the release callback to unlock the 
surface, rather than use a NumPy array's __del__ method.


Lenard

Re: [pygame] SDL 2.0

[Lenard Lindstrom]

Ctypes may be the way to go on PyPy, but it is slow in CPython. It lacks 
new buffer support. Well, ctype types have buffers, but they don't work 
with NumPy. Array support is convoluted and slow (see _numpysurfarray.py 
in Pygame 1.8.0). And Python is unsuited for writing the custom blitters 
added to Pygame. But I agree that more of Pygame should be implemented 
in Python.


Lenard

On 13-08-16 07:48 PM, Paul Vincent Craven wrote:
I started a pygame port based off Marcus's CTypes work. I think it is 
the best way to go for an SDL 2 pygame.

Re: [pygame] SDL 2.0

[Lenard Lindstrom]

On 13-08-17 12:20 AM, Marcus von Appen wrote:

On, Sat Aug 17, 2013, Lenard Lindstrom wrote:


Hi Andrew,

Marcus von Appen has pygame2 as a synonym for PyGame Reloaded. I
noticed, though, that PyGame Reloaded was discontinued (1) in favor of
PySDL2. So if there will be no confusion and Marcus is agreeable, then I
second PyGame 2.0.

Sure, go ahead!

Thanks, Marcus

Lenard

Re: [pygame] PySDL2 0.5.0 released

[Lenard Lindstrom]

Hi,

No criticism intended. I just went straight to installing and trying. I 
have Python 2.5 installed for Pygame testing, so gave it a try. I was 
really interested to see PySDL2 work with PyPy. If I understand 
correctly, the PyPy jit optimizes ctype calls, removing the performance 
hit found in CPython. Pygame does not port cleanly to PyPy, so PySDL2 is 
a good start in getting graphical support into PyPy.


Lenard

On 13-08-15 11:11 PM, Marcus von Appen wrote:

On, Fri Aug 16, 2013, Lenard Lindstrom wrote:


Hi Marcus,

Well, your Hello, World! example
(http://pysdl2.readthedocs.org/en/latest/tutorial/helloworld.html) works
on Linux Mint with Python 2.7 (both CPython and PyPy versions) and
Python 3.3. It failed to install for Python 2.5, though.

This is intended (see
http://pysdl2.readthedocs.org/en/latest/install.html for the version
prerequisites).

Cheers
Marcus

Re: [pygame] SDL 2.0

[Lenard Lindstrom]

Hi,

I recommend we put a feature freeze of Pygame 1.9.2. Personally, I still 
want to see Pygame 1.9.2 reach release status. I expect identifying 
existing bugs in Pygame 1.9.2 is easier than chasing them down later in 
an SDL 2 port. Otherwise, I would rather put time into an SDL2 port than 
patching the 1.9.2.


The SDL2 port of Pygame — Pygame 1.9,10? — can be a fork of Pygame 
1.9.2. Debugging of Pygame 1.9.2 would continue, with fixes merged into 
the SDL2 port. To reduce workload, Pygame 1.9.2 debugging can be limited 
to code that servives in the SDL2 port.


Lenard

On 13-08-13 01:37 AM, René Dudfield wrote:

Happy days...


SDL 2.0 is released!

http://lists.libsdl.org/pipermail/sdl-libsdl.org/2013-August/089854.html


These are the most important new features in SDL 2.0:

- Full 3D hardware acceleration
- Support for OpenGL 3.0+ in various profiles (core, compatibility,
debug, robust, etc)
- Support for OpenGL ES
- Support for multiple windows
- Support for multiple displays
- Support for multiple audio devices
- Android and iOS support
- Simple 2D rendering API that can use Direct3D, OpenGL, OpenGL ES, or
software rendering behind the scenes
- Force Feedback available on Windows, Mac OS X and Linux
- XInput and XAudio2 support for Windows
- Atomic operations
- Power management (exposes battery life remaining, etc)
- Shaped windows
- 32-bit audio (int and float)
- Simplified Game Controller API (the Joystick API is still here, too!)
- Touch support (multitouch, gestures, etc)
- Better fullscreen support
- Better keyboard support (scancodes vs keycodes, etc).
- Message boxes
- Clipboard support
- Basic Drag'n'Drop support
- Proper unicode input and IME support
- A really powerful assert macro
- Lots of old annoyances from 1.2 are gone
- Many other things!

Re: [pygame] SDL 2.0

[Lenard Lindstrom]

Hi Andrew,

Marcus von Appen has pygame2 as a synonym for PyGame Reloaded. I 
noticed, though, that PyGame Reloaded was discontinued (1) in favor of 
PySDL2. So if there will be no confusion and Marcus is agreeable, then I 
second PyGame 2.0.


Lenard

(1) https://code.google.com/p/pgreloaded/

On 13-08-16 01:26 PM, Andrew Barlow wrote:

I favour this hugely.
I'd love to have a feature freeze on 1.9.2... squish any final bugs on 
it... start SDL2 port for a PyGame 1.9.10 (Maybe even just PyGame 2.0?)



On 16 August 2013 21:12, Lenard Lindstrom le...@telus.net 
mailto:le...@telus.net wrote:


Hi,

I recommend we put a feature freeze of Pygame 1.9.2. Personally, I
still want to see Pygame 1.9.2 reach release status. I expect
identifying existing bugs in Pygame 1.9.2 is easier than chasing
them down later in an SDL 2 port. Otherwise, I would rather put
time into an SDL2 port than patching the 1.9.2.

The SDL2 port of Pygame — Pygame 1.9,10? — can be a fork of Pygame
1.9.2. Debugging of Pygame 1.9.2 would continue, with fixes merged
into the SDL2 port. To reduce workload, Pygame 1.9.2 debugging can
be limited to code that servives in the SDL2 port.

Lenard


On 13-08-13 01:37 AM, René Dudfield wrote:

Happy days...


SDL 2.0 is released!

http://lists.libsdl.org/pipermail/sdl-libsdl.org/2013-August/089854.html


These are the most important new features in SDL 2.0:

- Full 3D hardware acceleration
- Support for OpenGL 3.0+ in various profiles (core,
compatibility,
debug, robust, etc)
- Support for OpenGL ES
- Support for multiple windows
- Support for multiple displays
- Support for multiple audio devices
- Android and iOS support
- Simple 2D rendering API that can use Direct3D, OpenGL,
OpenGL ES, or
software rendering behind the scenes
- Force Feedback available on Windows, Mac OS X and Linux
- XInput and XAudio2 support for Windows
- Atomic operations
- Power management (exposes battery life remaining, etc)
- Shaped windows
- 32-bit audio (int and float)
- Simplified Game Controller API (the Joystick API is
still here, too!)
- Touch support (multitouch, gestures, etc)
- Better fullscreen support
- Better keyboard support (scancodes vs keycodes, etc).
- Message boxes
- Clipboard support
- Basic Drag'n'Drop support
- Proper unicode input and IME support
- A really powerful assert macro
- Lots of old annoyances from 1.2 are gone
- Many other things!

Re: [pygame] PySDL2 0.5.0 released

[Lenard Lindstrom]

Hi Marcus,

Well, your Hello, World! example 
(http://pysdl2.readthedocs.org/en/latest/tutorial/helloworld.html) works 
on Linux Mint with Python 2.7 (both CPython and PyPy versions) and 
Python 3.3. It failed to install for Python 2.5, though.


Good work.

Lenard

On 13-08-13 11:59 PM, Marcus von Appen wrote:

PySDL2 0.5.0 has been released.

PySDL2 is a wrapper around the SDL2 library and as such similar to the
discontinued PySDL project. In contrast to PySDL, it has no licensing
restrictions, nor does it rely on C code, but uses ctypes instead.

Version 0.5.0 is a feature release, which comes with

* a new sdl2.ext.FontManager class, which provides simple TTF font
   rendering
* a new sdl2.ext.SpriteFactory.from_text() method, which creates text
   sprites
* a fix for Win32 platforms; sometimes third party DLLs are not properly
   loaded, if the DLL path is not placed at the beginning of PATH
* minor documentation fixes

You can download it from http://bitbucket.org/marcusva/py-sdl2/downloads.
The documentation, listing all of its features, can be browsed online at
http://pysdl2.readthedocs.org/.

Note:
The SDL2 third party DLL package for Windows is not offered anymore with
SDL2 being officially released now. Please use the official Windows
builds of the DLLs instead.

Cheers
Marcus

Re: [pygame] Re: Re: playing sound on Windows

[Lenard Lindstrom]

Hi Sarah,

There are two audio drivers pygame.mixer can use on Windows. I believe 
the default is waveout. Try setting the SDL_AUDIOMIXER environment 
variable to dsound to use the directX. This can be done within Python 
by adding these two lines to the top of the file:


import os
os.environ['SDL_AUDIODRIVER'] = dsound


This will work for Windows, but not Linux. So add add some conditional 
code to only set SDL_AUDIODRIVER when the program is running on Windows.


Hope this helps,

Lenard Lindstrom

On 13-06-29 07:34 PM, sarah wrote:

Hi, reallyvery strange. I did these tests (actually I had already done
them, when I was programming it to work on Linux, but unfortunately the
final user of the program this script is part needs it to work on
windows). I also tested what Christoph suggested, but the result is the
same. My wav files still play in windows players. the print of
get_init() showed the same result you've got. So I'm keeping trying
comand combinations unsuccessfully, for what I still need you guys'
help.

Sarah

-Mensagem original-
De: James Paige b...@hamsterrepublic.com
Para: pygame-users@seul.org
Data: Quinta, 27 de Junho de 2013 10:48
Assunto: Re: [pygame] playing sound on Windows

I don't know why this problem is happening, but I can reproduce it.

I tested your script (with my own 0.wav file) and it worked fine on
Linux, but on Windows 7 (64 bit) with both python 2.6 + pygame 1.9.1 and
python 2.7 and pygame 1.9.2 there is no sound.

Although this does not solve your problem, I think you should remove the
pygame.mixer.pre_init() because inside the class but not inside a
function is definitely the wrong place for it, and even if you move it,
all it does is change the defaults for pygame.mixer.init() to the same
values those defaults have already.

You can also add

print pygame.mixer.get_init()

and it will display the settings with which the mixer was initialized,
or if mixer init failed entirely it will return None.

When I tested, .get_init() returned (22050, -16, 2) indicating that the
init succeeded with the default settings.

Before I tested your script on my windows box, I tested my 0.wav file in
audacity and it sounded fine.

After I tested your script, and the sound failed to play, I tried it
again in audacity, and then it would not play.

Even though I could not get the .wav file to play anymore either in
python or in audacity, the windows volume mixer test sound still worked
find.

Very strange.

On Thu, Jun 27, 2013 at 01:04:12PM -0300, sarah marques wrote:

Yes, I meant that. Sorry, I translated my code from Portuguese to send
it to the list, and this word 'som' slipped.

Sarah Barreto Marques

2013/6/27, James Paige b...@hamsterrepublic.com:

On Thu, Jun 27, 2013 at 08:11:39AM -0700, sarah wrote:

Hi all,
I've just subscribed to this list hoping someone can hplease elp me with
the
following problem: I wrote the class bellow (I also attached it) that
simply plays a sound
file when its method play_file() is called. It works on Linux perfectly,
but
on Windows, no sound is played and I do need to find the reason of it.
Configurations are:
Windows 7 (32 bits), Python 2.6 and Pygame 1.9.1 (win32). Thank very
much for any help!
Sarah Barreto Marques

www.audiogames.com.br
@sarahbmarques




import sys, pygame
import time

class Sound:
 pygame.mixer.pre_init(frequency=22050, size=-16, channels=2,
buffer=1024)

 def play_file(self, name):
#pygame.mixer.pre_init(frequency=44100, size=-16, channels=2,
buffer=1024)
#pygame.mixer.get_init()
 sound=pygame.mixer.Sound(name)

 print 'playing'
 sound.play()

 print 'done'
 time.sleep(2)
 return sound

if __name__=='__main__':
 pygame.init()
 sound=Sound()
 som.play_file('0.wav')


did you mean:

   sound.play_file('0.wav')

in the last line? som does not seem to be defined anywhere.

---
James Paige

Re: [pygame] new buffer code from Lenard

[Lenard Lindstrom]

Hi,

I've been wanting to add new buffer protocol support to Pygame for 
awhile now. It includes a release mechanism which is needed for 
unlocking a surface when a buffer view is no longer needed. Previously, 
the surface lock could only be released when its BufferProxy view was 
garbage collected. It relied on the prompt object reclamation possible 
with CPython's reference counting memory management. It is unworkable 
with garbage collection based interpreters, such as PyPy. With the 
introduction of Python 3.3, the new buffer protocol finally became 
stable, and usable. Hopefully the new protocol will let Pygame interact 
more cleanly with other Python packages.


The array interface -- 
http://http://docs.scipy.org/doc/numpy/reference/arrays.interface.html 
-- remains for legacy reasons: Python 2.5 lacks new buffer support. I 
find no reason to deprecate it, but also no need to maintain it beyond 
bug fixes.


Since I only make 32bit builds on an Intel based machine, the code badly 
needs testing in 64bit mode and with big-endian processors. So any help 
in this area is appreciated. For anyone maintaining an existing Pygame 
build, a complete rebuild from the config.py stage is necessary. The 
code changes basically affect anything using NumPy.


Thanks, and enjoy,

Lenard Lindstrom

On 13-06-19 01:04 AM, René Dudfield wrote:

Hellos,

Lenard made some new buffer improvements to pygame.  If anyone has 
time to test it with their apps that would be cool.  Just installing 
it from source, and seeing if your app still works ok. Especially if 
you use any of the buffer related code directly.


https://bitbucket.org/pygame/pygame/

Re: [pygame] new buffer code from Lenard

[Lenard Lindstrom]

Thanks for the feedback. These two failures are unrelated, but will be 
addressed.


Lenard

On 13-06-19 12:15 PM, Christoph Gohlke wrote:
Looks good. Up to date binaries for 32 and 64 bit Windows are at 
http://www.lfd.uci.edu/~gohlke/pythonlibs/#pygame. There is one test 
error and one Python 3.3 specific test failure. The examples seem work 
OK.


==
ERROR: SurfaceTypeTest.test_image_convert_bug_131
--
Traceback (most recent call last):
  File X:\Python33\lib\site-packages\pygame\tests\surface_test.py, 
line 678, in test_image_convert_bug_131

self.assertEqual(repr(im2.convert(32)), 'Surface(469x137x32 SW)')
pygame.error: Empty destination palette

==
FAIL: FontTypeTest.test_metrics
--
Traceback (most recent call last):
  File X:\Python33\lib\site-packages\pygame\tests\font_test.py, line 
275, in test_metrics

self.assert_(len(bm) == 1 and bm[0] is None)
AssertionError: None

--
Ran 665 tests in 57.157s

FAILED (failures=1, errors=1)


Christoph


On 6/19/2013 11:52 AM, Lenard Lindstrom wrote:

Hi,

I've been wanting to add new buffer protocol support to Pygame for
awhile now. It includes a release mechanism which is needed for
unlocking a surface when a buffer view is no longer needed. Previously,
the surface lock could only be released when its BufferProxy view was
garbage collected. It relied on the prompt object reclamation possible
with CPython's reference counting memory management. It is unworkable
with garbage collection based interpreters, such as PyPy. With the
introduction of Python 3.3, the new buffer protocol finally became
stable, and usable. Hopefully the new protocol will let Pygame interact
more cleanly with other Python packages.

The array interface --
http://http://docs.scipy.org/doc/numpy/reference/arrays.interface.html
-- remains for legacy reasons: Python 2.5 lacks new buffer support. I
find no reason to deprecate it, but also no need to maintain it beyond
bug fixes.

Since I only make 32bit builds on an Intel based machine, the code badly
needs testing in 64bit mode and with big-endian processors. So any help
in this area is appreciated. For anyone maintaining an existing Pygame
build, a complete rebuild from the config.py stage is necessary. The
code changes basically affect anything using NumPy.

Thanks, and enjoy,

Lenard Lindstrom

On 13-06-19 01:04 AM, René Dudfield wrote:

Hellos,

Lenard made some new buffer improvements to pygame.  If anyone has
time to test it with their apps that would be cool.  Just installing
it from source, and seeing if your app still works ok. Especially if
you use any of the buffer related code directly.

https://bitbucket.org/pygame/pygame/

Re: [pygame] Using bitbucket to host latest Pygame docs in the repository

[Lenard Lindstrom]

Hi Radomir,

This web site also looks interesting. As for building the docs with 
standard Sphinx, I tried to keep the reST markup standard. One reason 
for choosing Sphinx was flexibility. The hacked Sphinx extension was to 
imitate the original document format. But I neither expect, nor even 
encourage, to copy that style. So if readthedocs.org is better with the 
Python Document look, go with that. Bitbucket web page support, on the 
other hand, simply serves up what one gives it. This is more suited to 
displaying documents generated with the Pygame build chain. Verity is good.


Lenard Lindstrom

On 13-05-29 12:36 PM, Radomir Dopieralski wrote:

By the way, did I mention about http://pygame.readthedocs.org already?
It's not complete, as the current pygame docs build system is hacked
and doesn't work cleanly with out-of-the box sphinx, but that can be
fixed.

On Wed, May 29, 2013 at 9:17 PM, Lenard Lindstrom le...@telus.net wrote:

Good. I will now try to create a bitbucket document site in pygame
(http://pygame.bitbucket.org/docs/pygame) and see if the docs display
properly. As for updating, a bitbucket web site maintained as any other , so
updates are simply HG pushes.

Lenard


On 13-05-29 01:28 AM, René Dudfield wrote:

Nice.  There's a script on the server which gets notified on commit from
bitbucket... which then then does a few tasks (one is publishing latest docs
to the website).

So if you have a script which can upload to bitbucket... then I can drop
it in to also get run.

cheers,


On Wed, May 29, 2013 at 7:00 AM, Lenard Lindstrom le...@telus.net
mailto:le...@telus.net wrote:

 Hi everyone,

 I was looking through the bitbucket documents and found a section
 on static web site hosting:


https://confluence.atlassian.com/display/BITBUCKET/Publishing+a+Website+on+Bitbucket

 It looks like a handy place to have the latest document builds
 when the Spectacularly Adequate Automated Pygame Build Page is up
 and running again. I would like to give it a try.

 Lenard Lindstrom

Re: [pygame] Using bitbucket to host latest Pygame docs in the repository

[Lenard Lindstrom]

Good. I will now try to create a bitbucket document site in pygame 
(http://pygame.bitbucket.org/docs/pygame) and see if the docs display 
properly. As for updating, a bitbucket web site maintained as any other 
, so updates are simply HG pushes.


Lenard

On 13-05-29 01:28 AM, René Dudfield wrote:
Nice.  There's a script on the server which gets notified on commit 
from bitbucket... which then then does a few tasks (one is publishing 
latest docs to the website).


So if you have a script which can upload to bitbucket... then I can 
drop it in to also get run.


cheers,


On Wed, May 29, 2013 at 7:00 AM, Lenard Lindstrom le...@telus.net 
mailto:le...@telus.net wrote:


Hi everyone,

I was looking through the bitbucket documents and found a section
on static web site hosting:


https://confluence.atlassian.com/display/BITBUCKET/Publishing+a+Website+on+Bitbucket

It looks like a handy place to have the latest document builds
when the Spectacularly Adequate Automated Pygame Build Page is up
and running again. I would like to give it a try.

Lenard Lindstrom

Re: [pygame] Using bitbucket to host latest Pygame docs in the repository

[Lenard Lindstrom]

Okay, the link is alive.

Lenard

On 13-05-29 12:17 PM, Lenard Lindstrom wrote:
Good. I will now try to create a bitbucket document site in pygame 
(http://pygame.bitbucket.org/docs/pygame) and see if the docs display 
properly. As for updating, a bitbucket web site maintained as any 
other , so updates are simply HG pushes.


Lenard

On 13-05-29 01:28 AM, René Dudfield wrote:
Nice.  There's a script on the server which gets notified on commit 
from bitbucket... which then then does a few tasks (one is publishing 
latest docs to the website).


So if you have a script which can upload to bitbucket... then I can 
drop it in to also get run.


cheers,


On Wed, May 29, 2013 at 7:00 AM, Lenard Lindstrom le...@telus.net 
mailto:le...@telus.net wrote:


Hi everyone,

I was looking through the bitbucket documents and found a section
on static web site hosting:

https://confluence.atlassian.com/display/BITBUCKET/Publishing+a+Website+on+Bitbucket

It looks like a handy place to have the latest document builds
when the Spectacularly Adequate Automated Pygame Build Page is up
and running again. I would like to give it a try.

Lenard Lindstrom

[pygame] Using bitbucket to host latest Pygame docs in the repository

[Lenard Lindstrom]

Hi everyone,

I was looking through the bitbucket documents and found a section on 
static web site hosting:


https://confluence.atlassian.com/display/BITBUCKET/Publishing+a+Website+on+Bitbucket

It looks like a handy place to have the latest document builds when the 
Spectacularly Adequate Automated Pygame Build Page is up and running 
again. I would like to give it a try.


Lenard Lindstrom

Re: [pygame] Pygame Docs, Sphinx 1.1 is now out

[Lenard Lindstrom]

On 23/03/12 01:03 AM, Sam Bull wrote:

On Thu, 2012-03-22 at 17:12 -0700, Lenard Lindstrom wrote:

On 22/03/12 02:07 PM, Sam Bull wrote:

The only issue is that no toctree appears in Devhelp's side panel,
which is somewhat annoying. Python's documentation seems to have a
similar problem though, only showing one level deep.

You may need to edit conf.py to change the theme to default or something.


If I remove the ':hidden:' part from the toctree directive at the top, I
get a 1 level deep toctree in the side bar. I think you would basically
need to put all the links on the index page into a visible toctree. I
might have a go later.

Ah, yes. The custom Pygame theme generates its own table of contents at 
the top of the page.

[pygame] Pygame Docs, Sphinx 1.1 is now out

[Lenard Lindstrom]

Hi,

A while back it was agreed to update to Sphinx 1.1 when it was released 
http://article.gmane.org/gmane.comp.python.pygame/22431. It now at 
1.1.3 http://pypi.python.org/pypi/Sphinx. I propose we update the 
repository docs to 1.1, allowing them to be built with Python 3 *.


Lenard Lindstrom

* I'm also using 1.1.3 for another project, and don't feel like 
re-installing 1.0.7 just to make a small update to the scrap doc.

Re: [pygame] Pygame Docs, Sphinx 1.1 is now out

[Lenard Lindstrom]

On 22/03/12 11:41 AM, Sam Bull wrote:

On Thu, 2012-03-22 at 11:01 -0700, Lenard Lindstrom wrote:

A while back it was agreed to update to Sphinx 1.1 when it was released
http://article.gmane.org/gmane.comp.python.pygame/22431. It now at
1.1.3http://pypi.python.org/pypi/Sphinx. I propose we update the
repository docs to 1.1, allowing them to be built with Python 3 *.

If Pygame is using Sphinx, is there somewhere I can get a devhelp build
of the docs? I've just started using Sphinx for my own project too, and
was pleasantly surprised to find out I could create devhelp
documentation simply by running 'make devhelp'.

I don't know. The reason for choosing Sphinx is to let others build the 
docs in other formats. I took care to keep the reST sources compatible 
with vanilla Sphinx. In the Pygame source distribution, the reST sources 
are in the docs/reST subdirectory. You should be able to use 
sphinx-build to create the devhelp documentation.


Also, there is an open invitation for anyone to provide alternate Pygame 
document themes, though pygame/docs/reST/themes/classic will continue to 
be the default theme maintained in the repository.


Lenard Lindstrom

Re: [pygame] Pygame Docs, Sphinx 1.1 is now out

[Lenard Lindstrom]

On 22/03/12 02:07 PM, Sam Bull wrote:

On Thu, 2012-03-22 at 13:26 -0700, Lenard Lindstrom wrote:

I don't know. The reason for choosing Sphinx is to let others build the
docs in other formats. I took care to keep the reST sources compatible
with vanilla Sphinx. In the Pygame source distribution, the reST sources
are in the docs/reST subdirectory. You should be able to use
sphinx-build to create the devhelp documentation.

OK, just pulled the branch. By copying the make file from my project
into docs/reST, I was able to simply run 'make devhelp' which worked
without a problem.
The only issue is that no toctree appears in Devhelp's side panel,
which is somewhat annoying. Python's documentation seems to have a
similar problem though, only showing one level deep.

You may need to edit conf.py to change the theme to default or something.

Re: [pygame] Python 3, scrap, and the Mac

[Lenard Lindstrom]

Scrap is now been enabled for Python 3.x on Windows (see issue 105).

Lenard Lindstrom

On 18/03/12 12:16 PM, Lenard Lindstrom wrote:

Hi David,

Apparently I did not port scrap to Python 3.x on Windows. I remember 
one of the ports would be more difficult than the others: some 
function returned the raw buffer of a Python string, and would not 
work as is for a unicode object.


Lenard Lindstrom

On 17/03/12 12:30 AM, David Burton wrote:

Hi Lenard,

Did your scrap module ever get merged into Python 3?

Re: [pygame] Making Games with Python Pygame free book

[Lenard Lindstrom]

The pygame.Color type converts between RGB, CMY, HSVA, and HSLA.

Lenard Lindstrom

On 20/03/12 07:47 AM, Joseph Halvarson wrote:
Can someone just whip up a quick Color Theory module so we can easily 
import all of this relevant information into Pygame?


Thanks!

Re: [pygame] Python 3, scrap, and the Mac

[Lenard Lindstrom]

Hi David,

Apparently I did not port scrap to Python 3.x on Windows. I remember one 
of the ports would be more difficult than the others: some function 
returned the raw buffer of a Python string, and would not work as is for 
a unicode object.


Lenard Lindstrom

On 17/03/12 12:30 AM, David Burton wrote:

Hi Lenard,

Did your scrap module ever get merged into Python 3?

Pydoc fails on pygame 1.9.2pre using Python 3.2.1 (32-bit) on Windows 7:

NotImplementedError: scrap module not available (ImportError: No
module named scrap)


server c:\python32\Lib\inspect.py:103: RuntimeWarning: use scrap:
No module named scrap
(ImportError: No module named scrap)
  return (hasattr(object, __get__)

[I'm using your new (29 day old, 4.0 MB) 
https://bitbucket.org/pygame/pygame/downloads/pygame-1.9.2a0.win32-py3.2.msi 
 installed on top of the standard (6.4 MB) 
http://pygame.org/ftp/pygame-1.9.2a0.win32-py3.2.msi ]


To get pydoc to work with pygame I added a try/except to 
 \Python32\Lib\inspect.py  -- here's the diff:

http://www.burtonsys.com/python32/inspect.diff

With that patch, pydoc works with pygame, and reports just a few issues:
*scrap* = pygame.MissingModule object
*sndarray* = pygame.MissingModule object
*surfarray* = pygame.MissingModule object

Dave



On *Mon, Feb 28, 2011* at 7:58 PM, Lenard Lindstrom le...@telus.net 
mailto:le...@telus.net wrote:


Hi everyone,

I started a Pygame branch, port_scrap_py3, to update the scrap
module for Python 3.x. So far I have ported it for Linux and
Windows. Would someone try it on OS X? It looks like no changes
are necessary, but it needs testing before merging back into trunk.

Thanks,

Lenard Lindstrom

Re: [pygame] Pygame crashes reliably when clicking away.

[Lenard Lindstrom]

Hi Dan,

If re-installing Python 2.7.2 and Pygame 1.9.1 fixed the problem, it 
would appear the pygame package was somehow corrupted. Installing 
different Pygame versions over each other may do this. Running Pygame 
for the wrong Python version would definitely cause problems. But these 
are just possibilities. I don't know what caused your particular problem.


Lenard Lindstrom

On 17/03/12 03:50 PM, Dan Uznanski wrote:

After some poking I fixed it.  Had to nuke Python /and/ Pygame to do
so, which was no fun, and I'm still disappointed because I have no
idea what actually went wrong.

Dan

On Sat, Mar 17, 2012 at 3:51 PM, Dan Uznanskiduznan...@gmail.com  wrote:

I've started building a little pygame program.  Unfortunately I've
been having a huge problem: the second time I click out of the window
on another thing that completely obscures the pygame window, using
pygame.event.get() crashes with a segfault.

I'm running Windows XP/32 latest on 2009 mac pro hardware, Python
2.7.2, Pygame 1.9.1.

Re: [pygame] Another Pygame 1.9.2 pre-alpha release for Win32

[Lenard Lindstrom]

I can't reproduce it on gnu/linux. Haven't tried it on Windows yet.

Lenard Lindstrom

On 14/03/12 11:20 AM, René Dudfield wrote:

Hi ya,

I just tried again, and get the same error.  I'm guessing it doesn't 
happen on other platforms?  I'll get into the debugger later.


cheers,

On Wed, Mar 14, 2012 at 5:22 PM, Lenard Lindstrom le...@telus.net 
mailto:le...@telus.net wrote:


Hi,

Issue 109 contains x86_64 related changes to freetype. Maybe this
fixes the Zanthor problem on the Mac.

Lenard Lindstrom


On 19/02/12 01:33 AM, René Dudfield wrote:

Hi,

I just tested it with the Zanthor game... and get an error on
OS X 10.7.

 File /Users/rene/dev/zanthor/zanthor/intro.py, line 111, in
update
   img = fnt.render(text,1,(0,0,0))
 File

/usr/local/Cellar/python/2.7.2/lib/python2.7/site-packages/pygame/ftfont.py,
line 68, in render
   s, r = super(Font, self).render(text, color, background)
SystemError: error return without exception set


The 'text' variable there is you.

Zanthor can be found here...
   svn checkout http://zanthor.googlecode.com/svn/trunk/
zanthor-read-only

Re: [pygame] Another Pygame 1.9.2 pre-alpha release for Win32

[Lenard Lindstrom]

Hi,

Issue 109 contains x86_64 related changes to freetype. Maybe this fixes 
the Zanthor problem on the Mac.


Lenard Lindstrom

On 19/02/12 01:33 AM, René Dudfield wrote:

Hi,

I just tested it with the Zanthor game... and get an error on OS X 10.7.

  File /Users/rene/dev/zanthor/zanthor/intro.py, line 111, in update
img = fnt.render(text,1,(0,0,0))
  File 
/usr/local/Cellar/python/2.7.2/lib/python2.7/site-packages/pygame/ftfont.py, 
line 68, in render

s, r = super(Font, self).render(text, color, background)
SystemError: error return without exception set


The 'text' variable there is you.

Zanthor can be found here...
svn checkout http://zanthor.googlecode.com/svn/trunk/ 
zanthor-read-only

Re: [pygame] Declaring variables in function as if at code's line-level

[Lenard Lindstrom]

Hi,

To answer Nick's, question: yes. Anything in a module's global namespace 
is directly visible from a function declared within the module, unless 
hidden by a function argument or local variable having the same name. 
Even then, you can use the globals function to access the global names.


And yes Lee, you have it right. The Python compiler would notice the 
assignment to font with function something and therefore create a 
function local variable that hides the global font variable. Of course, 
the global font can still be accessed directly through the module's 
global dictionary:


from game import font

def something():
  font = 1
  globals()['font'].render(or other)  # call imported global font 
function

  print font  # print local font value: 1

On 10/03/12 09:45 PM, Lee Buckingham wrote:

I believe so.  Just don't say something like:

def something():
  font = 1

...not that you would, but if for whatever reason it happened, you
would have created a fuction variable called 'font'  and the global
namespace would be ignored because of it.

(Do I have this right, guys?)


-Lee-



On Sat, Mar 10, 2012 at 9:34 PM, Nick Arnoeytsnickarnoe...@gmail.com  wrote:

I have a little additional question about the explanation Lee gave.

Is it possible to use class instances from the global namespace in a
function? For example:

from game import screen, font

def get_text(string):
 font.render(string) # parts cut out because I'm in a hurry

I figure this is probably possible, but it can't hurt to ask for future
reference.

Re: [pygame] Re: Mac OS X MIDI support success (MacPorts)

[Lenard Lindstrom]

I get into problems with gcc and msvcr90.dll on Windows. Certain paths 
are hard-coded into gcc. On Windows, compiler generated dependencies 
automatically link to msvcrt.dll. I get around this by creating a new 
directory with the msvcr90.dll import libraries renamed to their 
msvcrt.dll equivalents, then using the LIBRARY_PATH environment variable 
to redirect the linker to this directory. Maybe the same kind of 
spoofing can be used on OS X. The

INCLUDE environment variable adds precompiler search paths.

Lenard Lindstrom

On 07/03/12 05:28 AM, René Dudfield wrote:
One other thing to try if that doesn't work... maybe we can just 
include the port midi files in there.  There's not many on the mac at 
all.  That way it will use the python build system... and it should 
just work.


On Wed, Mar 7, 2012 at 9:22 AM, René Dudfield ren...@gmail.com 
mailto:ren...@gmail.com wrote:


Maybe try symlinking to try and trick it?
sudo ln -s /Developer/SDKs/MacOSX10.4.sdk
/Developer/SDKs/MacOSX10.5.sdk




On Tue, Mar 6, 2012 at 7:48 PM, Russell E. Owen ro...@uw.edu
mailto:ro...@uw.edu wrote:

In article 4f554b23.9010...@chrisarndt.de
mailto:4f554b23.9010...@chrisarndt.de,
 Christopher Arndt ch...@chrisarndt.de
mailto:ch...@chrisarndt.de
 wrote:

 On 05.03.2012 23 tel:05.03.2012%2023:13, Russell Owen wrote:
  The problem I'm having is that it insists on trying to use
Mac OS X 10.5
  SDK, which doesn't even exist on my operating system
 
  I have tried everything I can think of, based on google
searches,
  including:
  $ export MACOSX_DEPLOYMENT_TARGET=10.4
  $ export CMAKE_OSX_DEPLOYMENT_TARGET=10.4
  $ export CMAKE_OSX_SYSROOT=/Developer/SDKs/MacOSX10.4.sdk

 Have you tried using the -D option to cmake like in my example?

I'm afraid so. Same problem (see appended log). cmake is bound and
determined to use the 10.5 SDK, which is not even installed! I
looked
through the config files I could find, but none of them
contain 10.5.
It may be getting its information from the xcode project,
which was
built for a newer XCode (I'm not sure how much newer, but it
certainly
is not compatible with Mac OS X 10.4).

-- Russell

$ cmake -DCMAKE_C_COMPILER:FILEPATH=/usr/bin/gcc-4.0 \
 -DCMAKE_C_FLAGS:STRING=-mmacosx-version-min=10.4 \
 -DCMAKE_OSX_SYSROOT:PATH=/Developer/SDKs/MacOSX10.4u.sdk \
 -G Unix Makefiles
-- The C compiler identification is GNU
-- The CXX compiler identification is GNU
-- Checking whether C compiler has -isysroot
-- Checking whether C compiler has -isysroot - yes
-- Checking whether C compiler supports OSX deployment target flag
-- Checking whether C compiler supports OSX deployment target
flag - yes
-- Check for working C compiler: /usr/bin/gcc-4.0
-- Check for working C compiler: /usr/bin/gcc-4.0 -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Checking whether CXX compiler has -isysroot
-- Checking whether CXX compiler has -isysroot - yes
-- Checking whether CXX compiler supports OSX deployment
target flag
-- Checking whether CXX compiler supports OSX deployment
target flag -
yes
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- SYSROOT: /Developer/SDKs/MacOSX10.5.sdk
-- DEFAULT_DEBUG_FLAGS not nil: -g
-- SYSROOT: /Developer/SDKs/MacOSX10.5.sdk
-- Configuring done
-- Generating done
-- Build files have been written to:
/Archives/UnixSoftware/portmidi

At this point if I try to make it fails immediately --
naturally,
since it cannot find the standard C headers!

Re: [pygame] Antialiased circle

[Lenard Lindstrom]

On 25/02/12 07:07 PM, Christopher Arndt wrote:

Am 18.01.12 22:39, schrieb jug:

Here is a small module that works on top of pygame.gfxdraw to draw some
nice (filled) aacircles, lines and rounded rects (have a look at the
examples):

https://bitbucket.org/schlangen/pexdra

this was mainly a test to see whats possible and also to compare
different methods. Of course its damn slow :)


It looks nice though and it seems that some functions could be easily 
put in a Cython module. Probably all of it if the code directly calls 
the PyGame C-Code.


There's a small bug in the advanced_example.py script: line 86 
should be i = int(i % 360) instead of i %= 360.


I'll run some tests with this module to see how it performs on my 
Android tablet...



I guess I need to take another look at pexdra.

Lenard Lindstrom

Re: [pygame] Trouble with PixelArray

[Lenard Lindstrom]

On 19/02/12 09:00 AM, Erik Grahn J. wrote:

Hey all,

I'm writing something where I load 4-colour indexed PNG images (8x8 tiles) with 
a simple greyscale palette (four entries, in order: black, dark grey, light 
grey, white) off disk. I then intend to recolour these in different ways by 
replacing the palette indices using PixelArray.replace, but I'm kind of getting 
stuck because I'm not getting the palette values I want from the file.

In the 8-bit PNG, my four greyscale colours are unquestionably palette indices 
0-3 (I have verified this with a hex editor even, they are the first four 
values in the PLTE chunk) but when I turn my surface into a PixelArray and 
print it, it looks like this:

PixelArray(
  [0, 0, 86, 127, 127, 0, 0, 0]
  [0, 86, 127, 86, 86, 86, 0, 0]
  [86, 127, 86, 86, 41, 86, 86, 0]
  [86, 127, 86, 86, 41, 86, 86, 0]
  [86, 127, 86, 86, 41, 86, 86, 0]
  [86, 127, 86, 41, 41, 86, 86, 0]
  [0, 86, 127, 86, 86, 86, 0, 0]
  [0, 0, 86, 86, 86, 0, 0, 0]
)

So instead of the values I want (0, 1, 2, 3), I'm getting 0, 41, 86 and 127. I 
have no idea where it gets these numbers from. Possibly a conversion to some 
internal default palette somewhere? I have tried calling set_palette on the 
surface to no avail -- same results.

Any help would be super appreciated.



Hi,

I am at a loss here. When I load a grayscale PNG, or BMP, file I don't 
get an 8 bit palette surface. Instead it is 24 bit. Something may have 
changed in SDL_image or libpng. If so, there is nothing that can be done 
about it (unless someone volunteers to rewrite imageext.c to not use 
SDL_image).


Lenard Lindstrom