Re: [pygame] pygame-ctypes?

On 10/19/06, Alex Holkner <[EMAIL PROTECTED]> wrote: Simon Wittber wrote: > An easy_install'able pygame-ctypes would be very handy... There are .eggs for all versions of Python at http://pygame.org/ctypes/. I haven't looked into whether more is required to make it easy_installable, but would be

Re: [pygame] PyODE

I think that´s because you haven't separeted your graphics code with the physics one. In a pro game, there are 2 updates: the renderer, and the gameplay. The renderer would update every... say, 1/40 of a second, while the gameplay would update every 1/100; that would avoid problems such as colisio

Re: [pygame] PyODE

>What you'd really like is a joint that constrains>motion to a plane, but ODE doesn't seem to provide >any such joint type.--GregI really wish there was a physics engine for 2d that python could use. I have no real interest in doing 3d games, and not having to hack something like ode to work with 2

Re: [pygame] PyODE

Yea well the good news is that either putting those planes in or just zeroing any z axes or a combination seems to have fixed the problems I had with my motion getting messed up.Now however i'm noticing that my boxes get stuck together if the speed is too great. If I accelerate my square really qui

Re: [pygame] pygame performance

Marcelo de Moraes Serpa wrote: I'm not into 3D yet either. But I really don't like slow rendering speeds on 2D games. Blitz has an incredible fast 2D rendering speed but the language is basic and I don't like basic! Most of the rendering work in 2D is blitting, which in pygame is done by C cod

Re: [pygame] pygame performance

Mark Mruss wrote: Not a 3d game of course but a simple 2d game, a side scroller or puzzle game, and PyGame seems like a nice way to keep things simple. So for me I'd love to hear about what kind of performance people have been able to achieve using straight PyGame, and whether or not it makes se

Re: [pygame] pygame performance

Lionel Barret de Nazaris wrote: Complex 3D (like seen in commercial AAA games) is quite out of the question for now *but* simple games are very easy to do. The trick is to find external libraries you can wrap to do most of the hard work, and just write the high level control code in Python. Y

Re: [pygame] PyODE

Patrick Mullen wrote: Also, the first method doesn't deal with any rotation that occurs - the two planes will prevent rotation most of the time. Another way of preventing rotation might be to use a AMotor joint constraining the angular velocity to zero around the x and y axes. What you'd real

Re: [pygame] PyODE

> Hi. Ode is really fidly, you have to set all the values well or it just > wont work as expected. It can be hard to get it to work right, especially > if you are constraining it to 2 axis. (It's designed around 3). I have > used pyode a few times in the past, but am by no means an expert. Thi

Re: [pygame] GLSL Texturing example ? (and ctypes...?)

Thanks Greg, yeah i'm pretty sure its the viewing angle. Quoting Greg Ewing <[EMAIL PROTECTED]>: > JoN wrote: > > the > > perspective of the teapot is strange, it seems a bit 'fisheye' as it > rotates > > around, almost allowing both the spout and the handle to hide behind the > body of > > the p

Re: [pygame] pygame performance

Is it this one, or a different one ? http://wiki.python.org/moin/PythonSpeed/PerformanceTips Quoting Richard Jones <[EMAIL PROTECTED]>: > On Thursday 19 October 2006 04:14, Bob Ippolito wrote: > > There's always ways to optimize things later. Write the code. If it's > > not fast enough, *profi

Re: [pygame] pygame-ctypes?

Simon Wittber wrote: Whats the status of pygame ctypes atm? Functionality is complete. The few modules that are not implemented are unofficially deprecated in Pygame, so will probably never get implemented (pygame.movie, pygame.overlay). There are no outstanding bugs that I'm aware of (th

Re: [pygame] GLSL Texturing example ? (and ctypes...?)

JoN wrote: the perspective of the teapot is strange, it seems a bit 'fisheye' as it rotates around, almost allowing both the spout and the handle to hide behind the body of the pot together This is a normal effect of perspective projection. If you imagine putting your eye right up close to a te

Re: [pygame] pygame performance

I agree with Bob. * Python is a very easy language to prototype in and is quite fast. Very fast sometimes. And it is perfectly suitable for building large programs in. * Psyco (which I only discovered recently btw) can apparently give quite miraculous speedups in some cases. * When you have th

Re: [pygame] PyODE

I attached my little test from a year ago (I forgot to attach it to my first reply).  It's been a while since I looked at it, but I think your last value of the planes are wrong.  In my example they are:frontwall = ode.GeomPlane(sp,normal=(0,0,1),dist=-1)backwall = ode.GeomPlane(sp,normal=(0,0,-1)

Re: [pygame] PyODE

How exactly did you create those planes? My understanding from what you said above is that you'd create one plane at z=1 with a normal facing down the negative Z axis and another at z=-1 facing down the positive Z axis. Which I coded like this: space = ode.Space()plane1 = ode.GeomPlane(space, (0, 0

Re: [pygame] pygame performance

On 10/18/06, Bob Ippolito <[EMAIL PROTECTED]> wrote: Once everything is in place you first replace code that's slow with better algorithms. If you still need better performance, then you try other means. It usually is fast enough at this point, and you're done. In many cases you can beat (naive)

Re: [pygame] pygame performance

On Thursday 19 October 2006 04:14, Bob Ippolito wrote: > There's always ways to optimize things later. Write the code. If it's > not fast enough, *profile* the code to see what's not fast, and take > steps to optimize that part of the code. > > Sometimes using psyco is going to be enough, dependin

Re: [pygame] pygame performance

Once everything is in place you first replace code that's slow with better algorithms. If you still need better performance, then you try other means. It usually is fast enough at this point, and you're done. In many cases you can beat (naive) C or C++ in speed simply because it's more natural to

Re: [pygame] pygame performance

In other words, you could consider python as the "prototype code". it is not fast but it is easy to code and therefore to something working quickly. Once everything, and i mean everything, is in place (i.e you have overcome all obstacles), you replace part of the "prototype code" that need it b

Re: [pygame] pygame performance

Hi MarkMaybe this against all programmers rules but I wouldn't concern performing the game from the beginning. If you have written the game in a proper way its quite easy to optimize later on. I do it that way and was happy about it with one big reason: I didnt spend time on optimizing it when I ha

Re: [pygame] pygame performance

There's always ways to optimize things later. Write the code. If it's not fast enough, *profile* the code to see what's not fast, and take steps to optimize that part of the code. Sometimes using psyco is going to be enough, depending on which platforms you care about. Otherwise you could change

Re: [pygame] pygame performance

I'm not into 3D yet either. But I really don't like slow rendering speeds on 2D games. Blitz has an incredible fast 2D rendering speed but the language is basic and I don't like basic! On 10/18/06, Mark Mruss <[EMAIL PROTECTED]> wrote: Yeah the performance of pyGame has always been a question for m

Re: [pygame] pygame performance

Yeah the performance of pyGame has always been a question for me, especially since I'm thinking of writing the entire game in straight python/pyGame. Not a 3d game of course but a simple 2d game, a side scroller or puzzle game, and PyGame seems like a nice way to keep things simple. So for me I'

Re: [pygame] pygame performance

>So except if you want to code the next Unreal, you should have>everything you need.Actually I want to code Quake 5 :D lol..That was just for the sake of curiosity. Thanks for the the info, it helps knowing how python works. Marcelo.On 10/18/06, Lionel Barret de Nazaris <[EMAIL PROTECTED]> wrote:

Re: [pygame] pygame performance

Marcelo de Moraes Serpa wrote: Hello list! I used to use Blitz Basic to develop games some time ago. Now, I want to play with the wonderful world of game development again. I've found python to be a extremelly elegant, powerful and easy to use language, so, pygame seems to fit perfectly for w

Re: [pygame] pygame performance

hi marcelo performance depends very much on what you do. Using Opengl for the rendering speeds up the performance. Knowing about optimising python also helps. Check this out http://wiki.python.org/moin/PythonSpeed/PerformanceTips enrike Marcelo de Moraes Serpa escribió: Hello list! I used

[pygame] pygame-ctypes?

Whats the status of pygame ctypes atm? An easy_install'able pygame-ctypes would be very handy... -Sw.

[pygame] pygame performance

Hello list!I used to use Blitz Basic to develop games some time ago. Now, I want to play with the wonderful world of game development again. I've found python to be a extremelly elegant, powerful and easy to use language, so, pygame seems to fit perfectly for what I'd like to do. However, I've seen

Re: [pygame] PyODE

The two options I know of are to either force the object to remain on the same axis by arbitrarily setting z=0 after collision response; and to construct two planes at say, z=1 and z=-1 and making your objects of z-width=1.98 or so.  The second method is probably more reliable, as you are using th

Re: [pygame] GLSL Texturing example ? (and ctypes...?)

Quoting Alex Holkner <[EMAIL PROTECTED]>: > JoN wrote: > > >I have a glreport.py that I cooked up and it appears I'm getting all the > goodies. > >The nvidia driver installed nicely and seems to have replaced all the right > >.so's and updated the LD' hints properly. > > > > > Another thought:

Re: [pygame] GLSL Texturing example ? (and ctypes...?)

JoN wrote: I have a glreport.py that I cooked up and it appears I'm getting all the goodies. The nvidia driver installed nicely and seems to have replaced all the right .so's and updated the LD' hints properly. Another thought: AFAIK ctypes doesn't look at the LD variables, so check that th

Re: [pygame] GLSL Texturing example ? (and ctypes...?)

Quoting Alex Holkner <[EMAIL PROTECTED]>: > > > I'm assuming you still had glUseProgram in there ;-) I suppose if you > don't set the value of a uniform parameter it defaults to zero anyway > (first texture unit), so yeah, cool. > Yeah, that sounds right. > >Also - when the teapot spins ro

Re: [pygame] GLSL Texturing example ? (and ctypes...?)

On Wednesday 18 October 2006 17:16, Alex Holkner wrote: > Might > want to also check that you're actually loading the nvidia driver, not > the open source one, or (worse) Mesa. Mesa doesn't do shaders IIRC. Richard

Re: [pygame] GLSL Texturing example ? (and ctypes...?)

JoN wrote: Just thought you might like to know that all works beautifully, thanks! Couple of interesting points. It worked even before these actions: texture_param = glGetUniformLocation(program, "texture"); Set the sampler to use the first texture unit (0): glUseProgram(program)