I wonder if it could also be related to a mismatch between audio driver and
video driver?
does *SDL_VIDEODRIVER*=directx also fix things?
On Sun, Apr 20, 2008 at 8:23 PM, etrek <[EMAIL PROTECTED]> wrote:
> Yeah, don't mess with your DirectX 8 setup.
>
> I tried setting the env var SDL_AUDIODRIVER
the current math I see checked in (where alpha just has the same ops applied
as color) would probably be completely incorrect - at least in the use case
Rene mentioned
You mentioned an additive particle system - for that in particular, you
would never be doing rgba to rgba anyways - as a parti
Your test demonstrates that 1.8 changes are required to cause the problem,
but clearly SDL is involved, otherwise why would waveout solve the problem
as well? If possible, a test of pygame 1.8 against the 1.7 SDL versions
could still help solve the case.
maybe in order to figure out what pygame 1.
t; revisions 990 (1.0.0 rc 0) and 1175 (1.8.0release). SDL may be involved only
> indirectly. Simple C programs using it don't have the problem. It could be
> Pygame doing something it shouldn't. Of course Pygame could be exposing an
> SDL problem that has remained dormant until now
tests/manual/music.py
>
> It would download, and build them all, then run the tests.
>
>
> cu,
>
>
> On Thu, Apr 24, 2008 at 11:13 AM, Brian Fisher
> <[EMAIL PROTECTED]> wrote:
> > sweet, you rock. with 185 revisions between, then it only takes 8 more
> >
On Wed, Apr 23, 2008 at 7:24 PM, Lenard Lindstrom <[EMAIL PROTECTED]> wrote:
> From around line 160 in mixer.c ===
> /*make chunk a power of 2*/
> for (i = 0; 1 << i < chunk; ++i); //yes, semicolon on for loop
> chunk = MAX (1 << i, 256);
> To around line 167
On Wed, Apr 23, 2008 at 7:44 PM, René Dudfield <[EMAIL PROTECTED]> wrote:
>
> But strangely we were having the crackling sound problem way before I
> made that change (about one month ago).
>
> you are right in that the first report was more than one month ago.
however, according to svn, the comm
On Wed, Apr 23, 2008 at 9:12 PM, Brian Fisher <[EMAIL PROTECTED]>
wrote:
> I think the first report of the problem was by Bo Jangeborg on this list,
> and he reported it against RC5. RC5 was built on March 16th, I think.
>
> Sorry, I spoke poorly - I meant that the first report
dang - I didn't even know they had another new runtime...
according to this post though, this should already be fixed?
http://mail.python.org/pipermail/python-dev/2007-November/075473.html
On Fri, Apr 25, 2008 at 4:17 PM, Lenard Lindstrom <[EMAIL PROTECTED]> wrote:
> I thought while I had the c
... I know this is a horrible place to complain... but why on earth do
python devs use the versions of Visual Studio that most other people skip
(2003 & 2008) and skipping the ones that most people use? (6.0 & 2005)
On Fri, Apr 25, 2008 at 4:17 PM, Lenard Lindstrom <[EMAIL PROTECTED]> wrote:
> I
to set up, or link them against msvcrt.dll (like Internet Explorer).
>
> Lenard
>
>
> Quoting Brian Fisher <[EMAIL PROTECTED]>:
>
> > dang - I didn't even know they had another new runtime...
> >
> > according to this post though, this should already be fixe
On Mon, Apr 28, 2008 at 8:35 PM, Lenard Lindstrom <[EMAIL PROTECTED]> wrote:
> The bottom circle is purple, not light blue. Drawing is a fill operation.
> The alpha value is part of the color copied to the surfaces pixels.
>
> I completely disagree that "drawing is a fill operation" - I think as t
why wouldn't we continue to do what is done now, and build SDL ourselves
with the correct runtime?
On Wed, Apr 30, 2008 at 10:51 AM, Lenard Lindstrom <[EMAIL PROTECTED]> wrote:
> When pygame.image.load is given a Python file object it passes the C FILE
> pointer on to SDL by calling SDL_RWFromFP
On Wed, Apr 30, 2008 at 4:22 PM, René Dudfield <[EMAIL PROTECTED]> wrote:
>
> Or maybe we should build python with the correct runtime? ;)
> It sure would make it easier to use the supplied SDL and python rather
> than compiling our own.
>
>
> Practically speaking, there is no such thing as a
Hey Nicholas,
That all sounds great. I have a suggestion about modules that would warrant
an "interactive" test like audio - pygame has had bugs (and probably still
does) that relate to the mundane bits of using an interface - like that the
arguments you pass to create or init something are actual
I'm 99.9% sure that error has nothing to do with Py2Exe at all.
It seems the system that has the problem must not like something about the
way glTexImage2D was called in that case - GL errors like you see there come
from the drivers. I would guess that it is that you are using a non
power-of-2 tex
t it can work?
> Thanks again for your help.
> Astan
>
>
> Brian Fisher wrote:
>
> I'm 99.9% sure that error has nothing to do with Py2Exe at all.
>
> It seems the system that has the problem must not like something about the
> way glTexImage2D was called in that case -
>From looking at SDL_mixer it's hard to tell if it would even support playing
from an offset... Would adding support for playing from an offset in pygame
just be a matter of manually making a new chunk object that would point to a
place within the original chunk for the sample?
On Fri, May 9, 200
that?
On Fri, May 9, 2008 at 12:17 AM, René Dudfield <[EMAIL PROTECTED]> wrote:
> yeah, pretty much.
>
> Doing that from python is just as easy though.
>
>
> On Fri, May 9, 2008 at 5:16 PM, Brian Fisher <[EMAIL PROTECTED]>
> wrote:
> > From looking at SDL
gt;
> Then combined with the constructor... pygame.mixer.Sound(buffer)
> should do the trick.
> http://pygame.org/docs/ref/mixer.html#pygame.mixer.Sound
>
> cheers,
>
> On Fri, May 9, 2008 at 5:20 PM, Brian Fisher <[EMAIL PROTECTED]>
> wrote:
> > I didn't mean copy
My high-level advice is that the approach you are trying to use to achieving
frame-rate independence is a math heavy and complex path to getting right,
and the issue you are seeing here is just the first of many like it (and
some worse). There is a much simpler approach, where all your simulation
u
It's impossible to tell from what you posted whether the error occurs on the
pygame.image.frombuffer() call or the ImageSurface().get_data() call, but
knowing that is very important in determining where the problem lies.
so what do you get if you try to do this?
>>> import cairo
>>>
The display window shouldn't be resize-able unless you passed the
pygame.RESIZABLE
flag to your pygame.display.set_mode call.
Are you getting a display window that can be resized when you aren't passing
the flag? If so, what OS and pygame version? Are you resizing a window in
that case by dragging
does it work any better with:
surf_1 = surf.subsurface((0,0,50,50)).copy()
... convert_alpha should make it have alpha, which may be bad for jpeg,
while copy should keep everything as it was
On Sat, May 17, 2008 at 4:24 PM, Brad Montgomery <[EMAIL PROTECTED]>
wrote:
> I know this a kind of an
Hey Keith,
is the bundle that you built that fails for you available somewhere for
others to test and play with?
Also, like I mentioned earlier in this thread, pygame is swallowing the
exception that occurred when it tried to import the "mixer_music" module and
bind it to the mixer module as pyg
I guess that means it imports correctly, but somehow fails to get bound?
I don't suppose you can access the functionality you need through
mixer_music, can you?
In other words, what happens if you change the first failing
pygame.mixer.music.whatever line to pygame.mixer_music.whatever? (after the
dows_exe_files,
>self.lib_files)
> print "*** creating the inno setup script***"
>script.create()
>print "*** compiling the inno setup script***"
>script.compile()
># Note: By default the fin
So does anybody know why exactly this problem happens? Is there some file
left behind by 1.7.1 that is not replaced with a 1.8.0 file? If so, what
file?
On Wed, May 21, 2008 at 4:12 PM, René Dudfield <[EMAIL PROTECTED]> wrote:
> hey,
>
> I've made a note about uninstalling pygame 1.7.1 first on
On Wed, May 21, 2008 at 12:14 PM, Nathan Whitehead <[EMAIL PROTECTED]>
wrote:
> It appears the documentation is LGPL.
LGPL doesn't make a lot of sense for documentation, it refers to binaries
and linking and source code which don't really apply (the Gnu FDL or Free
Documentation License is what
I haven't tried pygame 1.7 and I haven't tried on other machines yet, but
with pygame 1.8.0release on my vista machine, anytime the mouse is in
virtual input mode (mouse grabbed and cursor hidden, or fullscreen and
cursor hidden) mouse control gets screwy on my Vista machine (seems to get
shoved to
aking sure to use the
'bundle_files':1 option
I still don't know what causes this problem and I don't know why it doesn't
occur when the modules are bundled in an archive, tho
On Wed, May 21, 2008 at 9:54 AM, Brian Fisher <[EMAIL PROTECTED]>
wrote:
> ... however
n and
> the mouse is moved before switching visibility. It is also present in Pygame
> 1.7 as well.
>
> Lenard
>
>
>
> Brian Fisher wrote:
>
>> I haven't tried pygame 1.7 and I haven't tried on other machines yet, but
>> with pygame 1.8.0release
strom <[EMAIL PROTECTED]> wrote:
> Well, ahh, Windows 98.
>
> Lenard
>
>
> Brian Fisher wrote:
>
>> Sounds like it works fine for you - what OS is that?
>>
>> On Thu, May 22, 2008 at 9:45 AM, Lenard Lindstrom <[EMAIL PROTECTED]> [EMAIL PROTECTED]>&
On Fri, May 23, 2008 at 9:15 PM, Noah Kantrowitz <[EMAIL PROTECTED]> wrote:
>
> Anywhere you need that kind of timing accuracy, python is probably not the
> right tool for the job. I would recommend using plain SDL in C, you will
> likely find it much more stable timing-wise.
>
> You may be right
On Sat, May 24, 2008 at 7:59 AM, Francesco Martino <[EMAIL PROTECTED]>
wrote:
> accurate results, the problem is that, if I am not wrong, any signal
> could terminate the sleep
sleep is an interruptible wait state so it can end early, but simple
keyboard presses alone don't wake it.
however it'
> always go back to the distutils executable Windows installer. What I know is
> msi is demanding. You must design your project around it for it to work as
> intended. Also the msi module included with Python 2.5 is inflexible.
>
> Lenard
>
>
> Brian Fisher wrote:
>
t if I
> remember correctly setting a property is not too difficult. The challenge
> will be getting around the machinery of distutils.
>
> Lenard.
>
>
> Brian Fisher wrote:
>
>> It looks like msi has some rules about file replacing files intended to
>> make it so
On Sun, May 25, 2008 at 6:32 PM, Brian Fisher <[EMAIL PROTECTED]>
wrote:
> ... I'd go ahead and make a patch, but I don't know how to figure out the
> name of the installer that's created in Setup.py... anybody know how to get
> that from the bdist command or someth
Cool, thanks Rene & Lenard, that approach seems to work well - I committed
something that makes msi installers have the amus REINSTALLMODE rev 1250
On Mon, May 26, 2008 at 4:25 PM, Lenard Lindstrom <[EMAIL PROTECTED]> wrote:
> You don't have to do anything that extreme. Just subclass bdist_msi in
I don't know all of what it takes to make uninstalling previous versions,
but evidentally there is some property that defaults to off, that must be
set to "true" to get this behavior:
*RemovePreviousVersions*
I think the main complication with it is making sure the "ProductCode" GUID
is the same
Do you have an example of the code you wrote that behaves differently than
you wanted?
It may be by design, but you may have found a bug as well. Also, people on
the list may be able to help you with ways to do what you want without bugs
or problems.
On Fri, Jun 6, 2008 at 12:20 PM, Jake b <[EMAI
from the docs:
"During its lifetime, the PixelArray locks the surface, thus you explicitly
have to delete it once its not used anymore and the surface should perform
operations in the same scope."
so the idea is to do something more like this:
self.pixels = pygame.PixelArray( self.screen ) # l
On Sat, Jun 7, 2008 at 1:19 PM, Marcus von Appen <[EMAIL PROTECTED]> wrote:
> After this manual unlock, the PixelArray is unlikely to work in any
> case. You might expect weird behaviour in some cases, random
> segmentation faults and other crashes on trying to access self.pixels
> after the unloc
On Sat, Jun 7, 2008 at 3:09 PM, Marcus von Appen <[EMAIL PROTECTED]> wrote:
> > > would it be good to try and turn that into an exception? like if the
> > PixelArray would check the lock count or something?
>
> Surfaces do not feature a tracking of lock counts at the moment. And
> checking for an
On Sat, Jun 7, 2008 at 3:43 PM, Marcus von Appen <[EMAIL PROTECTED]> wrote:
> > Also, if people aren't sticking to the docs, then the docs aren't
> effective
>
> If people do no read the docs, they should not wonder about any bugs and
> failures caused by using the stuff in a wrong way. Or would
yeah, one of the unit tests crashes on windows, and it stops the builds.
I haven't figure out a good way to deal with that yet. I think I need to
implement a timeout on the guy that calls the unit tests.
I haven't figured out why they crash yet.
So why is there a segfault on the GL save?
On Sun
the installer from
> that
> page after uninstalling all previous Pygame versions. The error and fails
> are also present for my own build from a fresh SVN copy. I ran the tests on
> Windows 98.
>
> Lenard
>
>
> Lenard Lindstrom wrote:
> > Ah, so that error isn't
For what it's worth, I tested on both Windows XP and Vista and never
experienced any of the problems with the short mixer buffer crackliness that
is unique to pygame 1.8.0 - it's not just on OS thing, it's apparently
hardware dependent.
On Tue, Jun 10, 2008 at 12:51 PM, etrek <[EMAIL PROTECTED]> w
I assume you are saying surface.unlock should throw an exception as opposed
to do nothing in the cases where it's not valid? (if so, I agree)
Or was there some other condition you were thinking of as well?
On Tue, Jun 10, 2008 at 3:23 PM, Charlie Nolan <[EMAIL PROTECTED]>
wrote:
> Errors should
Even bad broken code?
On Tue, Jun 10, 2008 at 4:09 PM, René Dudfield <[EMAIL PROTECTED]> wrote:
> Also note that we *need* to retain compatibility with existing code -
> at least for pygame 1.8.1. We shouldn't break existing code.
>
>
>
I assume the save routine locks the display surface, and then uses the
buffer from the lock, yeah? so if locking an opengl display surface worked,
then wouldn't save work too?
On Tue, Jun 10, 2008 at 4:25 PM, Lenard Lindstrom <[EMAIL PROTECTED]> wrote:
> Current (lack of) progress report. All I c
list of surfarray using code if someone wants to test more:
> http://www.google.com/codesearch?q=import+surfarray
>
> cheers,
>
>
>
> On Wed, Jun 11, 2008 at 10:26 AM, Brian Fisher
> <[EMAIL PROTECTED]> wrote:
> > Even bad broken code?
> >
> > On Tue, Jun 10, 2
wrote:
> No, it only retrieves the display surface to get the size. It creates a new
> SDL surface, retieves a copy of the display using an opengl routine, then
> copies this to the surface. The surface is then written out to the file.
>
> Lenard.
>
>
> Brian Fisher wrote:
;
> Lenard Lindstrom wrote:
>
>> I have no idea why an opengl surface save is handled in such a convoluted
>> way.
>>
>>
>> Brian Fisher wrote:
>>
>>> I get what the new code is trying to do - but my point was that at some
>>> point a surfa
surf->pixels == NULL) {
>>>>> handle_error();
>>>>> }
>>>>>
>>>>>
>>>>> On Fri, Jun 13, 2008 at 9:22 AM, Lenard Lindstrom <[EMAIL PROTECTED]>
>>>>> wrote:
>>>>>
>>>>>
L|DOUBLEBUF)
> if screen.mustlock():
> print "The screen needs locking."
> else:
> print "The screen needs no lock."
> pygame.display.flip()
> screen.lock()
> pygame.draw.circle(screen, (255, 255, 255), (200, 200), 50)
> screen.unlock()
> pygam
hey Nick,
is your desktop set to 16-bit maybe?
I haven't looked at the test code, but if bit depth isn't explicitly set it
will use the desktop depth
On Sat, Jun 21, 2008 at 4:40 PM, Nicholas Dudfield <[EMAIL PROTECTED]>
wrote:
>
>
ably explicit.
>
> Again, thanks!
>
>
>
>
> Brian Fisher wrote:
>
>> hey Nick,
>> is your desktop set to 16-bit maybe?
>> I haven't looked at the test code, but if bit depth isn't explicitly set
>> it will use the desktop depth
>>
>
buffer over-runs and bad memory access are not guaranteed to crash -
especially when they depend on uninitialized memory or the behavior is
dependent on timing. If it crashed before, but not now, that may be why.
FYI, the crashes that are stopping my automated build page from passing
tests appears
If anyone wants to get the code that implements the Automated build page
stuff here:
http://thorbrian.com/pygame/builds.php
I have posted a link to a zip of it on that page itself - here is that link:
http://thorbrian.com/pygame/PygameBuilderSource.zip
there is no version numbers, no docs, it doe
Unsubscribes are done with an email to the list management address.
There is a mailto link for it on this page:
http://www.pygame.org/wiki/info
you get to this page from the "Help (irc, lists)" link from the main page at
http://pygame.org
I'm curious, why are you unsubscribing?
On Sun, Jun 22,
On Sun, Jun 22, 2008 at 4:21 AM, Peter Gebauer <
[EMAIL PROTECTED]> wrote:
> Yeah, SVN tried merging with the sources I changed, that was the prob. But
> I'm definately getting warnings.
>
> Yeah, everybody gets the warnings - they were looked over to check for
obvious errors, and are now mostly c
On Sun, Jun 22, 2008 at 1:42 PM, Gonzalo Castro <
[EMAIL PROTECTED]> wrote:
> This is what it says there: "To get on or off the mailing list, send
> an email message to [EMAIL PROTECTED] with a simple command in the
> body."
> What command whould I send?
>
just below that section it lists the com
I think this is great and I plan on using it - but as it is platform
specific it would be a poor thing to include as a component of pygame, as it
is.
On Mon, Jun 23, 2008 at 4:40 PM, Ian Mallett <[EMAIL PROTECTED]> wrote:
> To the pygame people: This functionality should be supported by pygame.
Hi Sibtey,
would it be possible for you to share a complete working source to a
program that can be used to demonstrate the problem?
If it's a problem to share your code as is, maybe you could make a minimal
example? (i.e. remove everything except the code required to make the
problem happen)
On
Um... isn't SDL_gfx LGPL?
at least, this page says it is:
http://www.ferzkopp.net/joomla/content/view/19/14/
... also, isn't pygame.draw made from copies of an old version of SDL_gfx?
Wouldn't it be natural to adapt this to just be an expanded pygame.draw?
On Fri, Jun 27, 2008 at 9:47 AM, Lenard
It's not true that the relevant source is in SDL - clock.tick does call
SDL_Delay, but all SDL_Delay takes a number of ticks to sleep, and then just
sleeps that long. It's pygame source that is deciding how long to
sleep/wait.
... also no need to guess at the source, you can get at it from the web
2, which is where the loop starts.
>
> I will grant, there are plenty of other code paths based on the
> intricacies of what's available on your system. I don't have the time
> or the patience to go check all of them out, but I'd wager that they
> use the same basic s
fmod works fine with msvc. I don't know why fmodf doesn't. Know it's back to
crashing in some unit test in _numericsurfarray.pyd, possibly because it
doesn't run the tests with numeric installed...
On Fri, Jun 27, 2008 at 6:35 PM, René Dudfield <[EMAIL PROTECTED]> wrote:
> hey,
>
> it looks like
#x27;s a conflict perhaps?
>
> Nicholas tried compiling and testing on windows with mingw gcc and it
> seems to work for him too.
>
>
>
> On Sat, Jun 28, 2008 at 3:38 PM, Brian Fisher <[EMAIL PROTECTED]>
> wrote:
> > fmod works fine with msvc. I don't know why fmod
So the crash on running unittests on my machine was a somewhat crazy
combination of events. Basically the sequence of tests were making it so the
numeric detection would fail and cause a crash when there is no numeric and
no numpy installed, but surfarray was used
---
The long explanation is that
>- build machines ping webpage for update info more reguarly.
> >- probably should put a maximum # of rebuilds/hour setting.
> > - my ubuntu machine could be set up to join the build group.
> > - http upload + http auth for uploading, so uploads can be done with a
>
I think I was wrong when I blamed pygame for this bug. pygame uses all
signed vals in the clock_tick_base calculations and checks for underflow
(below 0) before passing that on to sdl. Like Charlie said, the problem
code is sdl. In particular, the linux sdl code uses the time for
SDL_GetTicks and
LGPL seems perfectly appropriate for pygame to me. SDL is LGPL as well, and
seems to work fine for it. Is someone claiming that LGPL is undesirable for
pygame in some way?
I believe the only time the license terms even matter for a game is when a
game is distributed along with pygame - and then th
I'm not sure that there is a bug in rwobject - I just think that your new
music from a file-like object code is using rwobject in a way that it has
not been designed to support.
SDL's music playing stuff is streaming, while sounds all load at once.
Likewise fonts all load at once. So in existing u
The problem is that you need to tell SDL to process windows messages before
your window can be used (any event getting function should do)
try this:
-
import pygame
pygame.init()
screen = pygame.display.set_mode((400,300))
pygame.event.get()
screen.fill((255,255,255))
pygame.display.flip()
Hmmm... from looking at the patch, it seems that it does not fix the crash
that Forrest discovered (where the file object falls out of scope and gets
deleted so the rwobject ends up having bad pointers) - Is that correct
Forrest?
If that is the case, it seems to me that the feature implementation
; >>> screen.fill((255,240,70))
>
> >>> pygame.display.update()
> >>> blueSquare = ((0,0,255))
> >>> blueSquare = pygame.surface.Surface((50,50))
> >>> blueSquare.fill((0,0,255))
># everything alright up
&g
To be more explicit - the intent with pygame 1.8.1 is that you will not need
to manage this problem - and the audio should work without crackle pop or
significant lag on all platforms using the default mixer init settings.
...However pygame 1.8.0 has a fairly serious bug where the mixer settings
a
t;>> standard rwop, because it shouldn't.
> >>>
> >>> And it is correct, RwopsFromPythonThreaded is obviously meant to be
> >>> used like this (hence the threaded).
> >>>
> >>> Attached is the updated patch.
> >>>
ersion of SDL_mixer are you using?
>
> I think I was wrong... SDL_mixer 1.2.8 supports OGG, MP3, MID, and MOD
> music.
>
> Only SVN supports WAV.
>
> On Sat, Jul 12, 2008 at 1:40 PM, Brian Fisher <[EMAIL PROTECTED]>
> wrote:
> > by svn version do you mean 1.3, or
Hi Gary,
Making the mixer work great in all cases without tweaking numbers is
indeed a goal for pygame. I would guess that in this case the problem may be
something other than the buffer size, which is what was tweaked in 1.8.1 to
be larger. This seems the case to me because you mentioned a highe
worked. This is an SDL_mixer bug.
> >>
> >> On Sat, Jul 12, 2008 at 4:44 PM, Forrest Voight <[EMAIL PROTECTED]>
> wrote:
> >>> Using SDL_mixer SVN, I'm able to load & play WAV and OGG.
> >>>
> >>> MP3 gives me the '
I've tested loading MP3 and OGG as music from file-objects on both Windows
and Mac OS X using pygame SDL_Mixer 1.2.8, and SDL_Mixer failed to load
them.
So if SDL_Mixer 1.2.8 is supposed to support them, then something else is
broken.
Forrest, you said earlier on this list you were able to load
Lenard,
Can you confirm it worked with rev 1236?
cause if it worked then, but not now, it should be an easy binary search to
figure out the change that caused it.
If the older rev. doesn't work then for you, then there is something
different about how the 1236 build Jason used that worked was pro
I got some time to play with this more, testing both on my Vista machine and
OS X 10.5.
with SDL_Mixer 1.2.8, ogg and mp3 and mid and mod all seem to be able to
load from a file or file-like object on my windows machine, so I think
Forrest is right about the level of support in SDL_Mixer 1.2.8
..
how?
On Mon, Jul 21, 2008 at 12:10 PM, David Goldsmith <[EMAIL PROTECTED]>
wrote:
> help
>
>
>
>
What OS are you using? (It may make a big difference as to how to solve)
for Windows, I don't think SDL ever tries to specify refresh rate and lets
the system pick what it believes is valid, in which case you probably need
to update the driver for your monitor, and hope it learns something...
On
try updating your monitor driver (yes, there is a monitor driver, although
it is really just an ini file that says what refresh rates your monitor
supports)
note that forcing the refresh rate to be 60 in code can actually cause other
machines to have similar problems (not all monitors support 60 a
For what it's worth, there's not a single forum I visit with any regularity
- they all have far too low signal-to-noise ratio and I like it that mailing
lists come to me. I think a forum vs. a mailing list is a trade-off, not an
upgrade, no question in my mind.
On Fri, Jul 25, 2008 at 3:08 PM, Pat
So what exactly about this anaglyph game thing is it you want to do in
pygame?
If it's just drawing rects, yeah you can do that (pygame.draw.rect)
If it's drawing lines of different colors on different lines, then you can
do that too (pygame.draw.line)
There are possible issues with each of thos
They are all using the same rect object, and you are positioning that 1
single rect to the location of the wall. So collision is working for all,
but all of them are positioned in the same place.
Instead of calling get_rect once and reusing the result, you should pass the
image to each sprite and
anythings possible - but it's kind of complicated to make it happen. What
would be the benefit if they behaved that way?
On Thu, Jul 31, 2008 at 12:07 AM, techtonik <[EMAIL PROTECTED]> wrote:
> I wonder if it is possible for these .MSI installers to detect
> previous installed version and execute
I'm curious, In what way is Pygame currently sorely lacking in OS X
installation binaries?
What would you like to be different about the binaries here:
http://pygame.org/download.shtml
The reason I ask is cause for me they all work perfectly fine, and if there
was a problem I'd like to help fix i
Pygame using more CPU resources could be completely expected because it uses
software rendering while Pyglet/rabbyt would be using openGL (i.e. hardware)
Also, because pygame basically requires you to write your own main loop
(although it provides facilities to help), it's fairly easy to write loo
There's another instance of blitting a surface to itself crashing on Windows
for a user, it's believed to be a 1.8.1 thing by the poster
http://pygame.motherhamster.org/bugzilla/show_bug.cgi?id=19
last time it came up marcus was thinking about making pygame throw an
exception on blitting a surface
pygame
parachute thing and get an actual crash?
On Sat, Aug 2, 2008 at 3:32 PM, Hugo Arts <[EMAIL PROTECTED]> wrote:
> On Sat, Aug 2, 2008 at 6:30 PM, Brian Fisher <[EMAIL PROTECTED]>
> wrote:
> > There's another instance of blitting a surface to itself crashing on
>
It may certainly be something that is not windows specific but just more
likely to crash on windows, and it may be something that is not dependent on
a specific version of SDL but a certain version made it more likely.
However, SDL version and wndows OS make a huge difference regardless.
I wrote a
I think you are right anatoly, in that doing something special for scrolling
is what is the right thing, and having an api that blocks blitting to itself
but has a special call for "scroll" would be the ideal api.
However I remember way back when SDL was much younger (like late 1990's)
blits of a
OK, so basically I've got an SDL I built myself that I'd like other people
who are experiencing this problem to try out.
SDL is zipped up here:
thorbrian.com/SDL_TestBlitToSelf.zip
basically the idea is to replace the SDL.dll in your pygame subfolder of
site-packages with this, and to see if you s
1 - 100 of 654 matches
Mail list logo
