Victor Blomqvist | 1 Aug 15:15 2010
Picon

Re: Example of pymunk using images

Interesting. I made a small example which produces the error all the
time and posted it on the chipmunk forum:
http://www.slembcke.net/forums/viewtopic.php?f=1&t=1102 Apparently
there's a problem with acute (<90 degrees) angles on polygons which is
hard to fix in the engine.. Maybe I should do a workaround and create
a more complex shape to match the snake-box image.

/Victor

On Fri, Jul 30, 2010 at 1:44 AM, Jake b <ninmonkeys@...> wrote:
> They are mostly acting like bouncing_balls.py, but less bouncy.
>
> But, they occasional are falling through the floor bottom right corner (
> where walls meet ) FPS is 50.
> Ran it couple times.
>
> Seeing a ghost occasionally. ( One falls on right side of screen, velocity
> is so high it but reaches bottom so fast its only blit 2-3 times. )
>
> bouncing_balls doesn't do this.
> --
> Jake
>

Ian Mallett | 1 Aug 22:30 2010
Picon

Re: 127.5

On Fri, Jul 30, 2010 at 10:04 AM, Brian Fisher <brian-iiL30gvB4m/A2O9SyiQ5LEEOCMrvLtNR@public.gmane.org> wrote:

Another ghetto solution is to not map to 0 to 255. map to 0 to 254, and then 127 is your 0
Unfortunately, the textures map [0,255] to [0.0,1.0], so changing it again would mean rewriting all my shaders . . .

On Fri, Jul 30, 2010 at 7:25 AM, Luke Paireepinart <rabidpoobear-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
Is it really 32 bits _per channel_ and not total?
I've never heard of that much bit depth before, why would that
possibly be necessary?  I mean for practical applications, not using
textures to store data so you can use shaders to run your sim :P
-Luke
About halfway down, there's a table listing color bit depths:
http://www.opengl.org/registry/specs/ARB/texture_float.txt
Other than simulations (which are a fairly considerable usage) I imagine HDR imaging is the other main application.

There was a problem in my texturing code (which turned out to be a bug) in that it didn't like being sent NumPy arrays.  I've subsequently fixed it, and am using NumPy. 

Ian
#avg_ls_inline_popup { position:absolute; z-index:9999; padding: 0px 0px; margin-left: 0px; margin-top: 0px; width: 240px; overflow: hidden; word-wrap: break-word; color: black; font-size: 10px; text-align: left; line-height: 13px;}
stas zytkiewicz | 2 Aug 09:37 2010
Picon

Whatever happend to movieext ?

Hi, I'm battling the pygame.movie object (parachute, segfaults etc)
and I was wondering
what happend to the movieext module.
I seem to remember that it was part of pygame some time ago
but I can't find it.

Thanks,
Stas

--

-- 
Free-source educational programs for schools
http://www.schoolsplay.org  and http://wiki.laptop.org/go/Schoolsplay
http://gvr.sf.net and http://wiki.laptop.org/go/Guido_van_Robot

Marcus von Appen | 2 Aug 12:00 2010

Re: pgreloaded 2.0.0-alpha5 released

Hi Gregor,

On, Fri Jul 23, 2010, Gregor Lingl wrote:

> 
> Hi Marcus,
> > Hi Gregor,
> >   
> ...
> >> It seems to me that there is a certain lack of examples and ported
> >> games to pygame2. Perhaps because porting seems to be quite tedious.
> >>     
> >
> > It's absolutely not tedious, but there is a decent lack of resources and
> > time. pygame2 is currently developed by one person (me), who has a funny
> > and incomplete time sharing model for free time to spend :-D.
> >   
> Would your time sharing model allow for an easy and "asolutely not 
> tedious" converting the appended
> script in a "quasi state of the art" way? It could serve me as a model 
> or pattern for trying to convert one
> of my games, just as a first step to dive into pygame2.
[...]

Here we go with the "state of the art" conversion of your script :-).
As you can see, it is mostly about exchanging the modules and certain
API calls as well as changing some arguments (especially colors).  I
left out the time-based update, you are using with Clock.tick() and
applied a static update cycle. To use an approach matching Clock.tick(),
you could use sdl.time.get_ticks() and calculate the update delta
yourself.

Regards
Marcus
Attachment (movingCircles.py): text/x-python, 3127 bytes
Marcus von Appen | 2 Aug 14:34 2010

Re: pgreloaded 2.0.0-alpha5 released

On, Thu Jul 22, 2010, Gregor Lingl wrote:

[...]

> What did I observe?
> (1) In the cases it works, id doesn't do as in the docs written:
>     if one omits the loop parameter it loops forever

This has been fixed now and will be made available in the next release.

> (2) I was not able to play an *.ogg
> (3) If "someSound.ogg" is loaded, retrieving someSound.len lets the
>     program crash
> (4) A try to play it, results in pygame2.Error: Tried to play a NULL chunk

This was a problem in the SDL_mixer.dll library, which used a wrong
libvorbisfile.dll linkage. The SDL_mixer.dll has been updated to use the
correct version, which is shipped with the installers. It also will be
made available with the next release.
To circumvent the existing issue, please download the updated prebuilt
DLL package from

    http://pgreloaded.googlecode.com/files/win32-prebuilt-20100802.zip

and replace the SDL_mixer.dll from your

    C:\Python31\lib\site-packages\pygame2\dll

path (or something similar) with the one of the package (to be found
under prebuilt\lib).

> Morover I observed, that pixelarray.py crashed after the 4th mouseclick
> without saying why. I only was asked if I wanted a respective message
> to be sent to microsoft. I declined :-)

This has been fixed now and will be made available in the next release.

Regards
Marcus
Lenard Lindstrom | 2 Aug 19:44 2010
Picon

Re: Whatever happend to movieext ?

  Hi,

Which operating system are you using? The movie module works on Windows 
XP and Linux. For Windows you need to use the windib video driver:

os.environ['SDL_VIDEODRIVER'] =  'windib'

As for movieext, I don't remember anything about it. There was an 
ffmovie module, but it was abandoned. The latest attempt at a movie 
module replacement is _movie, but it is still in development.

Lenard Lindstrom

On 02/08/2010 7:37 AM, stas zytkiewicz wrote:
> Hi, I'm battling the pygame.movie object (parachute, segfaults etc)
> and I was wondering
> what happend to the movieext module.
> I seem to remember that it was part of pygame some time ago
> but I can't find it.
>
> Thanks,
> Stas
>

Lenard Lindstrom | 2 Aug 20:39 2010
Picon

Re: Pygame with stackless 3.1

  Okay, I have reproduced the bug. At some point I will look for a cause.

Lenard Lindstrom

On 07/07/2010 6:46 AM, Lenard Lindstrom wrote:
> Then stackless could be exposing a bug in the Pygame build for Python 
> 3.1. Support for 3.1 is incomplete.
>
> Lenard Lindstrom
>
> On 06/07/10 10:11 AM, Nikhil Murthy wrote:
>> I normally run it without any problem on CPython 2.6, I have not 
>> tried it yet with CPython 3.1.
>>
>> On Tue, Jul 6, 2010 at 10:13 PM, Lenard Lindstrom <len-l@... 
>> <mailto:len-l@...>> wrote:
>>
>>     Hi Nikhil,
>>
>>
>>     On 06/07/10 06:56 AM, Nikhil Murthy wrote:
>>
>>         Hello,
>>
>>         I have tried installing pygame 1.9.1 with stackless python 3.1
>>         on windows vista, and whenever I try import pygame in the
>>         interactive prompt, it crashes. Does anyone else have this
>>         problem? It works perfectly fine with stackless 2.5.
>>         --         Nikhil Murthy
>>
>>
>>     On Windows, Python 3.1 uses a different C runtime library
>>     (msvcr90.dll) than does Python 2.5 (msvcr71.dll). It could be a
>>     problem with the linkage to the C runtime rather than it being
>>     Stackless Python. So if it fails with regular Python 3.1 or Python
>>     2.6 then it is a linkage issue. I am currently investigating
>>     problems with Python 2.6 and updated Pygame dependencies I've
>>     built. So I will get back on this.
>>
>>     Lenard Lindstrom
>>
>>
>>
>>
>> -- 
>> Nikhil Murthy
>

stas zytkiewicz | 2 Aug 21:29 2010
Picon

Re: Whatever happend to movieext ?

On Mon, Aug 2, 2010 at 7:44 PM, Lenard Lindstrom <len-l@...> wrote:
>  Hi,
>
> Which operating system are you using? The movie module works on Windows XP
> and Linux. For Windows you need to use the windib video driver:
I'm on GNU/Linux and it's not that that I can't get it to work, it's
that I can't get
it to work stable enough. But never mind.

> os.environ['SDL_VIDEODRIVER'] =  'windib'
>
> As for movieext, I don't remember anything about it. There was an ffmovie
> module, but it was abandoned. The latest attempt at a movie module
> replacement is _movie, but it is still in development.
I thought it was part of pygame some time ago and was wondering if it was
removed or if it's just hard to find.

Stas

> Lenard Lindstrom
>
> On 02/08/2010 7:37 AM, stas zytkiewicz wrote:
>>
>> Hi, I'm battling the pygame.movie object (parachute, segfaults etc)
>> and I was wondering
>> what happend to the movieext module.
>> I seem to remember that it was part of pygame some time ago
>> but I can't find it.
>>
>> Thanks,
>> Stas
>>
>
>

--

-- 
Free-source educational programs for schools
http://www.schoolsplay.org  and http://wiki.laptop.org/go/Schoolsplay
http://gvr.sf.net and http://wiki.laptop.org/go/Guido_van_Robot

Devon Scott-Tunkin | 2 Aug 22:46 2010
Picon

Re: 127.5

Practical graphical applications often use textures to store data as well. Deferred renderers store all the geometry data in a gbuffer texture for example.  For screen space ambient occlusion and many other screen space lighting techniques people often render a float linear depth in one channel and the per pixel normal in the remaining channels.  When you start wanting per pixel 3d vectors of any kind its nice to have 32-bit precision available.

-Devon

On Fri, Jul 30, 2010 at 9:25 AM, Luke Paireepinart <rabidpoobear-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
On Fri, Jul 30, 2010 at 9:10 AM, Ian Mallett <geometrian-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> The problem:
> Because of this, I need a surface filled with the color 127.5.  Obviously,
> more than 8 bits per channel are required.  To update the texture, I'm using
> GL_RGBA32F_ARB, which allocates 32 bits per channel.  Unfortunately, the
> base image created by PyGame has a value of 127 ≈ -0.00196 velocity.  In
> practice, this leads to "drift" in the simulation.  Can something be done to
> send a 32 bit per channel surface filled with 127.5 values to the OpenGL?


Is it really 32 bits _per channel_ and not total?
I've never heard of that much bit depth before, why would that
possibly be necessary?  I mean for practical applications, not using
textures to store data so you can use shaders to run your sim :P
-Luke

Ian Mallett | 2 Aug 22:50 2010
Picon

Re: 127.5

On Mon, Aug 2, 2010 at 1:46 PM, Devon Scott-Tunkin <devon.scotttunkin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

Practical graphical applications often use textures to store data as well. Deferred renderers store all the geometry data in a gbuffer texture for example.  For screen space ambient occlusion and many other screen space lighting techniques people often render a float linear depth in one channel and the per pixel normal in the remaining channels.  When you start wanting per pixel 3d vectors of any kind its nice to have 32-bit precision available.
That's true.  The only other places I've used them personally though are in GPU particles and GPU cloth simulations.

Perhaps PyGame could be made to support extremely high bit depths?

Ian
#avg_ls_inline_popup { position:absolute; z-index:9999; padding: 0px 0px; margin-left: 0px; margin-top: 0px; width: 240px; overflow: hidden; word-wrap: break-word; color: black; font-size: 10px; text-align: left; line-height: 13px;}

Gmane