On Thu, Jul 2, 2009 at 2:47 PM, el lauwer wrote:
>
> On 28-jun-09, at 01:13, Tyler Laing wrote:
>
>> Hmm, the comment for gWorld says its a pointer, but thats a static
>> variable. Just an outdated comment?
>
> It is a pointer, I took this from the API:
> Defines a pointer to a structure that your
On 28-jun-09, at 01:13, Tyler Laing wrote:
Hmm, the comment for gWorld says its a pointer, but thats a static
variable. Just an outdated comment?
It is a pointer, I took this from the API:
Defines a pointer to a structure that your application can use to
refer to an offscreen graphics worl
On Thu, Jul 2, 2009 at 6:51 AM, Lorenz Quack wrote:
> Hey,
>
> your patch seems to work as advertised. This is also far less intrusive than
> the last patch which
> IMHO is a good thing since this is just some patch work to fix somebody
> else's bug.
>
> //Lorenz
>
>
Cool...
Committed revision 24
Thanks for that, but it doesn't seem to work. Well, it gives coordinates
of x,y(,z) but when the camera changes angle (but not position), the
coordinates don't change. What else do I need to be doing in this?
Anyway, I also forgot to mention this is how I make the text images:
def __init__(self)
Cool, thanks for the testing.
On Thu, Jul 2, 2009 at 9:19 AM, Lorenz Quack wrote:
> Ok, so here goes my analysis of the failures in ColorTypeTest:
> In src/color.c line 1435 (and some following lines) we bit shift each color
> component and stuff them
> in an unsigned long.
Maybe this should be
Ok, so here goes my analysis of the failures in ColorTypeTest:
In src/color.c line 1435 (and some following lines) we bit shift each color
component and stuff them
in an unsigned long.
I think the problem arises when we bitshift the r value and r is >127
My guess is that C converts r to an intege
The Python syntax defaults to the current matrices, so you only need
the 3 coordinates.
On 7/1/09, Ian Mallett wrote:
> Er, the last three arguments return the data in C. In Python, the syntax is
> different:
>
> C: gluProject(objx,objy,objz,model,proj,view,winx,winy,winz)
> Python: winx,winy,wi
Hi,
I just ran the test suit ("make tests") and got 7 failures and 1 error.
6 of the 7 failures arise in the ColorTypeTest and seem to be 64- vs 32-bit
related.
the last failure comes from SurfaceTypeTest and the error seems to have to do
with midi.
I haven't looked into any of these, yet. I j
Hey,
your patch seems to work as advertised. This is also far less intrusive than
the last patch which
IMHO is a good thing since this is just some patch work to fix somebody else's
bug.
//Lorenz
Lenard Lindstrom wrote:
Hi Lorenz,
I see. I think for now I will add a macro declaration to th
Hi Lorenz,
I see. I think for now I will add a macro declaration to the transform
line in Setup.in. When present Pygame will build with MMX disabled for
64 bit intels (the default). To enable MMX/SSE remove the declaration.
I have included a patch that makes the proposed changes to Pygame Rev
Hi,
I believe __x86_64__ is correct, but it is not only SDL_HasSSE but also
SDL_HasMMX that is causing trouble
because both (amongst others) internally call the SDL function
CPU_getCPUIDFeatures which is the culprit.
//Lorenz
Lenard Lindstrom wrote:
Didn't work? Then what C macro should be c
Didn't work? Then what C macro should be check to determine a 64 bit
build. I used __x86_64__ elsewhere, but it is apparently wrong.
Lenard
Lorenz Quack wrote:
Hi,
unfortunately Lenards patch didn't help. pygame would still crash.
But on the upside the RedHat patch did the trick. With the pat
Hi,
unfortunately Lenards patch didn't help. pygame would still crash.
But on the upside the RedHat patch did the trick. With the patched libsdl the
unpatched pygame trunk
it installs and imports without problems! Open source for the win :)
I also reported this bug to the gentoo bugtracker:
htt
Er, the last three arguments return the data in C. In Python, the syntax is
different:
C: gluProject(objx,objy,objz,model,proj,view,winx,winy,winz)
Python: winx,winy,winz = gluProject(objx,objy,objz,model,proj)
And yes, it returns a z-coord, which should take into account the near
clipping plane
The z doesn't matter, but the x and y are pixel coordinates like
pygame.mouse.get_pos().
Also, gluProject has defaults for the last 3 params, so they aren't needed.
On Wed, Jul 1, 2009 at 3:10 AM, Astan Chee wrote:
> Thanks for that. How do I convert x,y,z to the x,y coordinates of a pygame
> sur
Thanks for that. How do I convert x,y,z to the x,y coordinates of a
pygame surface window? Kinda like the coordinates that
pygame.mouse.get_pos() returns?
Thanks again
Ian Mallett wrote:
You'll definitely want to use glu somewhere. gluLookAt(...) comes to
mind...
Anyway, for gluProject, try
16 matches
Mail list logo
