Charlie Nolan wrote:
You can apparently support python 2.4 by changing the one place where
you have "class foo():" to read "class foo:".
The main interface is going to be too tall for 1280x800. If you move
the second section of the Object Editor to the right of the first
(instead of below), you
You can apparently support python 2.4 by changing the one place where
you have "class foo():" to read "class foo:".
The main interface is going to be too tall for 1280x800. If you move
the second section of the Object Editor to the right of the first
(instead of below), you should be able to drop
Looking over this whole thread, I can't help but think a lot of the thinking
towards opengl display surfaces is wrong with respect to the way SDL is
meant to work - the whole idea of locking surfaces with SDL is that the
pixels member is invalid unless the surface is locked. As long as a routine
re
The more that I look at this the more it becomes apparent that an opengl
screen should not be a Surface, but its own type. There are not just
pixel arrays and buffers. There are also the draw and transform modules.
These are a lot of places where explicit tests must be added, while they
already
Typo in Player Details -> Total "Ammount"
Ian
Marius Gedminas wrote:
The main window doesn't fit on my 1280x800 screen.
Hmm, is it too long or too wide? or both?
If I blindly tab down there and press Enter, without changing any of the
default settings, I get this exception:
Traceback (most recent call last):
File "wxSol.py", line 192
OK, I will add the NULL tests to PySurface_Blit, _numericsurfarray,
Surface.get_buffer() and PixelArray. That way the errors will be consistent.
Lenard
René Dudfield wrote:
hi,
I think that should raise an exception too - because it's never been
expected to work.
I think mostly opengl stuff
hi,
I think that should raise an exception too - because it's never been
expected to work.
I think mostly opengl stuff should be kept separate for now except for
the existing screenshot use case. SDL 1.3+ has more direct opengl
mode stuff - so I think we should probably wait until then before
ad
The array stuff should raise an exception as currently an opengl surface
cannot be directly altered. But what about blitting an opengl surface to
another surface?
Lenard
René Dudfield wrote:
I think they should just check:
if (surf->pixels == NULL) {
handle_error();
}
On Fri, Jun 13, 2
I think they should just check:
if (surf->pixels == NULL) {
handle_error();
}
On Fri, Jun 13, 2008 at 9:22 AM, Lenard Lindstrom <[EMAIL PROTECTED]> wrote:
> What I see is an opengl SDL screen surface has a NULL pixels pointer while a
> HWSURFACE surface (screen or otherwise) does not. Beyond
What I see is an opengl SDL screen surface has a NULL pixels pointer
while a HWSURFACE surface (screen or otherwise) does not. Beyond that I
have no explanation. What it means is that PixelArray and surfarray will
also fail on opengl surfaces.
Lenard
Brian Fisher wrote:
So isn't that the sam
I appreciate the color extension module is still under construction for
1.8.1 but this bug is unusual and could easily be missed. This is for
Python 2.5.2 on Windows. When running the shadow effects array example
in the Pygame cookbook, http://www.pygame.org/wiki/ShadowEffects, I get
this excep
Hi,
I just uploaded an early beta of something I've been fiddling around with on
Windows:
http://pymultimouse.googlecode.com/files/pymultimouse0.1.zip
If you download it and run the pygamedemo.py, you will see an empty screen.
When you start moving around all you mice connected to the computer,
Marcus von Appen wrote:
Hi,
Pygame is known for having a good backwards compatibility towards SDL
and related packages. This also means maintaining a lot of overhead, a
complex build structure with flags unknown to the most and a lot of work
for packagers and distributors.
SDL 1.2.10 added a hu
So isn't that the same as a HWSURFACE display surface when you're not using
openGL?
On Thu, Jun 12, 2008 at 9:57 AM, Lenard Lindstrom <[EMAIL PROTECTED]> wrote:
> Further testing shows that the pixels pointer for an opengl SDL surface is
> NULL.
>
> Lenard
>
>
> Lenard Lindstrom wrote:
>
>> I hav
OK.
I'd find that extremely useful too.
Ian Mallett wrote:
If it is possible to draw 2D pygame things over an OpenGL surface, I
would like that.
No, that raises an exception. I am talking about going the other way,
drawing an OpenGL surface over 2D pygame things.
--
Lenard Lindstrom
<[EMAIL PROTECTED]>
March forward the stampede of progress I say.
Personally I don't use SDL for anything except pygame, so it doesn't affect
me. I'm sure it may affect someone though. Everything does.
Hi,
Pygame is known for having a good backwards compatibility towards SDL
and related packages. This also means maintaining a lot of overhead, a
complex build structure with flags unknown to the most and a lot of work
for packagers and distributors.
SDL 1.2.10 added a huge set of definitions, con
Hi All,
just writing to say that this months PyGameSF meet up is on Monday June
16th from 7pm at the Metreon food court in San Francisco. This month's
presentations are:
- Tim Thompson (http://nosuch.com/tjt/index.html) "Artistic Mashups with
Python and VST/Freeframe Plugins." This talk will
If it is possible to draw 2D pygame things over an OpenGL surface, I
would like that.
While fixing the save bug for opengl surfaces on Windows I found that a
blit segfaults when the source surface is opengl. Do we want to do this?
At the very least Pygame.blit needs to raise an exception if the source
surface is opengl. This means additional overhead per blit anyway.
--
Lenard
Further testing shows that the pixels pointer for an opengl SDL surface
is NULL.
Lenard
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
This patch re-adds support for playing (and queueing) music from
python file-like objects.
While support for WAV music streams is still in SDL_mixer svn, there
is support for mp3, mikmod and other formats already.
Cheers,
Forrest
music.diff
Description: Binary data
That was SVN 1318.
Lenard
Lenard Lindstrom wrote:
Bug squashed (SVN 1317). Please confirm that Unix builds are unaffected.
Bug squashed (SVN 1317). Please confirm that Unix builds are unaffected.
Lenard
Lenard Lindstrom wrote:
I have no idea why an opengl surface save is handled in such a
convoluted way. But it made me try blitting an opengl surface to a
software surface.
import pygame, unittest, os, test_util
On Thu, Jun 12, 2008 at 06:20:25PM +1000, Astan Chee wrote:
> I've been working on my 3d planet game and now it is finally done. For
> those of you interested the source can be found at:
> http://code.google.com/p/planetgame/
> Also, this is kinda like a post-prototype, so any feedback is much
Hi guys,
I've been working on my 3d planet game and now it is finally done. For
those of you interested the source can be found at:
http://code.google.com/p/planetgame/
If you are using linux, I dont think it should be a problem. If you are
using windows and cant get it to run, tell me your msn
28 matches
Mail list logo
