Here we just charge extra for the extra *function*.
---
//Alex
On Wed, Apr 28, 2010 at 7:15 PM, Daniel Tousignant-Brodeur
wrote:
> We're using the 'Code 18' here usually used in the context when you found
> the error and that it is approx. 18 inches in front of the monitor.
> Daniel Tousignant
We're using the 'Code 18' here usually used in the context when you found
the error and that it is approx. 18 inches in front of the monitor.
Daniel Tousignant-Brodeur
On Wed, Apr 28, 2010 at 11:03 AM, Lee Buckingham
wrote:
> ID ten T errors. =)
>
> -Lee-
>
>
> On Wed, Apr 28, 2010 at 7:33 AM,
ID ten T errors. =)
-Lee-
On Wed, Apr 28, 2010 at 7:33 AM, B W wrote:
>
>
> On Wed, Apr 28, 2010 at 1:31 AM, René Dudfield wrote:
>
>> On Wed, Apr 28, 2010 at 5:26 AM, Ian Mallett
>> wrote:
>>
>
>
>> > several hundred files every time it tries to save. Oh well, user error.
>>
>>
>
>> hehe.
>
On Wed, Apr 28, 2010 at 1:31 AM, René Dudfield wrote:
> On Wed, Apr 28, 2010 at 5:26 AM, Ian Mallett wrote:
>
> > several hundred files every time it tries to save. Oh well, user error.
>
>
> hehe.
>
> A place I worked at in the 90's would call an 'user error' an UBD error ;)
>
> Luckily no
On Wed, Apr 28, 2010 at 5:26 AM, Ian Mallett wrote:
> Huh, well I found a way to monitor RAM in Python. Memory usage is not
> spiking up.
>
> I found the problem though! The screenshot code was trying to open all the
> previous paths (so it wouldn't overwrite any). When I keep track of it via
>
Huh, well I found a way to monitor RAM in Python. Memory usage is not
spiking up.
I found the problem though! The screenshot code was trying to open all the
previous paths (so it wouldn't overwrite any). When I keep track of it via
a variable, it works much better, because it doesn't have to tr
My first instinct is that the first several frames' data is sent to
your hard drive, where it's cached to be written, which fills up
faster than it's depleted since the file size per second is higher
than your disk can handle writing it. I had this issue myself trying
to do something similar. If
On Tue, Apr 27, 2010 at 8:23 PM, Luke Paireepinart
wrote:
> Sounds like you're leaking memory somewhere, or maybe just you're
> re-allocating space for your temporary framebuffers and the
> interpreter's not garbage-collecting them fast enough?
> Check your memory usage while you run your app. If
On Tue, Apr 27, 2010 at 9:56 PM, Ian Mallett wrote:
> Hi,
>
> In a related email thread here, I've been trying (now successfully) to
> render a movie from a series of frames captured from a program I wrote.
>
> The screen capturing is done via pygame.image.save(...). In my case, the
> surfaces th
Hi,
In a related email thread here, I've been trying (now successfully) to
render a movie from a series of frames captured from a program I wrote.
The screen capturing is done via pygame.image.save(...). In my case, the
surfaces that are being saved are derived from OpenGL framebuffer readbacks.
hi,
bug fixed. to avoid copying the whole image it changed the flags
temporarily. except the colorkey flag wasn't restored correctly.
Committed revision 2737.
thanks.
On Tue, Jan 26, 2010 at 8:22 AM, Patrick Mullen wrote:
> Problem: When calling pygame.image.save(colorkey_surface, "surf.pn
Problem: When calling pygame.image.save(colorkey_surface, "surf.png"), the
colorkey_surface in memory loses the color_key information.
Workaround: I call the set_colorkey function after the save
It's not a big issue, but I wouldn't expect that saving an image should
affect the actual surface bein
cool, test updated.
Committed revision 1215.
On Tue, Apr 15, 2008 at 5:38 PM, Brian Fisher <[EMAIL PROTECTED]> wrote:
> FYI, the bug in 1.8.0release also meant that saving as .JPG saved as
> .tga - having the test try out both all caps and all lower would be
> good.
>
>
>
> On Mon, Apr 14, 200
FYI, the bug in 1.8.0release also meant that saving as .JPG saved as
.tga - having the test try out both all caps and all lower would be
good.
On Mon, Apr 14, 2008 at 8:47 PM, René Dudfield <[EMAIL PROTECTED]> wrote:
> ah, oops.
>
> Now that test_magic is fixed, the saving test fails in the pygam
ah, oops.
Now that test_magic is fixed, the saving test fails in the pygame
1.8.0release version(png saved as jpg only, other formats work)... but
passes in svn.
cheers,
On Tue, Apr 15, 2008 at 1:09 PM, Lenard Lindstrom <[EMAIL PROTECTED]> wrote:
> This works better. The other keeps returning 1
This works better. The other keeps returning 1:
def test_magic(f, magic_hex):
""" tests a given file to see if the magic hex matches.
"""
data = f.read(len(magic_hex))
if len(data) != len(magic_hex):
return 0
for i in range(len(magic_hex)):
if magic_hex[i] != ord(da
Ian Mallett wrote:
The screenshot I used for
http://www.pygame.org/project/698/?release_id=1226 was generated this way.
Beautiful picture. And indeed ViewerExe works. It is also using a Pygame
1.8.0rc3 built on Feb. 11. So whatever went wrong happened after that.
The bug is definitely in 1.8.0
Good point about pygame.image.load not caring about file extensions,
and only file contents...
I just updated the unittest to check the magic hex numbers of the file
to test if the file is actually getting saved how we want it to be.
Below is the magic testing function I used - in case you want t
The screenshot I used for
http://www.pygame.org/project/698/?release_id=1226was generated this
way.
Ian Mallett wrote:
Well, it worked for me--saving it to a valid .png file.
Are you sure? I just tried it with a .png picture. It was certainly not
saved as a PNG image. Changing the file extension to .jpg let me view it
with ImageNavigator. The reason this bug may have slipped through is
that
Well, it worked for me--saving it to a valid .png file.
eek. That must have slipped by in that last set of changes to the
saving code :( Which I think fixed some other type of bug.
I've added some unittests for image saving to svn. Committed revision 1208.
I think we have enough fixes for a 1.8.1 release soonish.
cheers,
On Tue, Apr 15, 2008 at
pygame 1.8 has a bug where it saves everything you ask to be a png as a jpeg.
http://pygame.motherhamster.org/bugzilla/show_bug.cgi?id=13
it's fixed in svn though
On Mon, Apr 14, 2008 at 5:06 PM, René Dudfield <[EMAIL PROTECTED]> wrote:
> hello,
>
> I think this might be to do with the pygame ver
On Mon, Apr 14, 2008 at 5:06 PM, René Dudfield <[EMAIL PROTECTED]> wrote:
> hello,
>
Hi
> I think this might be to do with the pygame version?
I think that is a better explanation.
Thanks,
Ian
hello,
I think this might be to do with the pygame version?
Older pygame (1.7.1) can save to .tga I think - I think it also is
buggy and names files in any way, even though the file is actually a
bmp.
You could add a test in there to see what type of file is produced, or
save a different type de
Hi,
On my project, http://www.pygame.org/project/698/?release_id=1226, there
is a render option, which allows you to render an image of an arbitrary size
using the coordinates on the viewport. The image is then saved.
Unfortunately, for some people this works, and for others, it returns an
inval
26 matches
Mail list logo
