Re: [pygame] image.load() -->> array?

On 25/10/2007, AlgoMantra <[EMAIL PROTECTED]> wrote: > casey, what do you mean by "hth"? yeah, I found surfarray :) http://catb.org/~esr/jargon/html/H/HTH.html -- - Rikard - http://bos.hack.org/cv/

Re: [pygame] image.load() -->> array?

On 10/26/07, Greg Ewing <[EMAIL PROTECTED]> wrote: > That's not the same thing -- FSAA smooths adjacent pixels > in a single frame, whereas motion blurring is about > smoothing between successive frames.

Re: [pygame] image.load() -->> array?

Just to be pedantic: FSAA is different from motion blur. FSAA renders each frame at a high resolution and then scales it down, which can help remove jaggy pixellated edges. Motion blur renders the scene at a few different points in time and averages them together, which makes the framerate ap

Re: [pygame] image.load() -->> array?

On 10/26/07, Greg Ewing <[EMAIL PROTECTED]> wrote: > > Ian Mallett wrote: > > I'm just saying there is a slight (though meaningless) advantage > > to having really high framerates. > > Well, it can sometimes be useful as a relative measure > of rendering speed -- if you know that e.g. a particular

Re: [pygame] image.load() -->> array?

Ian Mallett wrote: I'm just saying there is a slight (though meaningless) advantage to having really high framerates. Well, it can sometimes be useful as a relative measure of rendering speed -- if you know that e.g. a particular game runs at 50fps on some system, and the same game runs (or can

Re: [pygame] image.load() -->> array?

On 10/26/07, Greg Ewing <[EMAIL PROTECTED]> wrote: > > That's not the same thing -- FSAA smooths adjacent pixels > in a single frame, whereas motion blurring is about > smoothing between successive frames. It's a blur. I don't distinguish between blurs. You're probably right about the name of th

Re: [pygame] image.load() -->> array?

On 10/26/07, Ian Mallett <[EMAIL PROTECTED]> wrote: > Yes. I'm just saying there is a slight (though meaningless) advantage to > having really high framerates. > slight meaningless advantage.

Re: [pygame] image.load() -->> array?

Ian Mallett wrote: At 900fps, then, at max, the frame was rendered 1/900th of a second ago. If, however, your frame rate is 60fps, like your refresh rate, the frame was rendered 1/60th of a second ago. I doubt that human reaction times are anywhere near good enough to notice a 1/60 second dif

Re: [pygame] image.load() -->> array?

On 10/26/07, Brian Fisher <[EMAIL PROTECTED]> wrote: > Basically you are looking at 16.6ms latency vs. 1.1ms latency. It's > big difference as a percentage, but it's better to evaluate each of > those latency amounts in a meaningful context to understand the > difference between the two then it is

Re: [pygame] image.load() -->> array?

On 10/26/07, Ian Mallett <[EMAIL PROTECTED]> wrote: > No, because if your framerate is 900fps, but your refresh rate is 60fps, > then every 60th of a second, the most up-to-date frame to that point is > drawn. At 900fps, then, at max, the frame was rendered 1/900th of a second > ago. If, howe

Re: [pygame] image.load() -->> array?

On 10/26/07, Greg Ewing <[EMAIL PROTECTED]> wrote: > And even if you were doing something, unless you have > a 900fps monitor to go with that, it doesn't do you > any good at all. No, because if your framerate is 900fps, but your refresh rate is 60fps, then every 60th of a second, the most up

Re: [pygame] image.load() -->> array?

Ian Mallett wrote: One's eyes "refresh" at about 12 fps, so anything faster than that looks fluid. It's not quite a simple as that. You need motion blurring to get something looking completely smooth at such a low rate. TV and movies have that, but computer games usually don't. -- Greg

Re: [pygame] image.load() -->> array?

Luke Paireepinart wrote: OpenGL, which is what I use for 3D stuff, runs at about 900fps doing nothing. That's smooth. The inherent flaw in this logic is that, while doing nothing, it really doesn't matter which is faster. And even if you were doing something, unless you have a 900fps monit

Re: [pygame] image.load() -->> array?

I've known people who could detect the difference between 100 and 80 fps, so it's possible. 12 fps may be where we decide that we are seeing movement rather than a cycle of still images, but that doesn't mean there is no difference beyond that. If you draw enough stuff, your framerate will drop l

Re: [pygame] image.load() -->> array?

Of course it's pointless to draw nothing. The framerates are still respectable when drawing stuff. SDL drops to about 40 or 50, OpenGL to 60-120 depending on the render method. One's eyes "refresh" at about 12 fps, so anything faster than that looks fluid. The amount of smoothness, of c

Re: [pygame] image.load() -->> array?

Ian Mallett wrote: On 10/25/07, *Casey Duncan* <[EMAIL PROTECTED] > wrote: On Oct 25, 2007, at 12:11 PM, Ian Mallett wrote: > On 10/25/07, Casey Duncan <[EMAIL PROTECTED] > wrote: >> On Oct 25, 2007, at 9:56 AM, Ian Mallett wr

Re: [pygame] image.load() -->> array?

On 10/25/07, Casey Duncan <[EMAIL PROTECTED]> wrote: > > On Oct 25, 2007, at 12:11 PM, Ian Mallett wrote: > > > On 10/25/07, Casey Duncan <[EMAIL PROTECTED]> wrote: > >> On Oct 25, 2007, at 9:56 AM, Ian Mallett wrote: > >> surface.get_at() can be kinda slow, and typically sequence item > >> access

Re: [pygame] image.load() -->> array?

On Oct 25, 2007, at 12:11 PM, Ian Mallett wrote: On 10/25/07, Casey Duncan <[EMAIL PROTECTED]> wrote: On Oct 25, 2007, at 9:56 AM, Ian Mallett wrote: surface.get_at() can be kinda slow, and typically sequence item access is faster in python then a function call anyway. Regardless, I wouldn't wo

Re: [pygame] image.load() -->> array?

On 10/25/07, Casey Duncan <[EMAIL PROTECTED]> wrote: > On Oct 25, 2007, at 9:56 AM, Ian Mallett wrote: > surface.get_at() can be kinda slow, and typically sequence item > access is faster in python then a function call anyway. > Regardless, I wouldn't worry about it unless it helps makes the code >

Re: [pygame] image.load() -->> array?

On Oct 25, 2007, at 9:56 AM, Ian Mallett wrote: On a not unrelated note, I've been trying to make a 3D map viewer that loads height values from a black/grey/white image. I've been making it a surface, and using surface.get_at() for each pixel. I think surfarray should do it better, though I've

Re: [pygame] image.load() -->> array?

On 10/25/07, Ian Mallett <[EMAIL PROTECTED]> wrote: > > On a not unrelated note, I've been trying to make a 3D map viewer that > loads height values from a black/grey/white image. I've been making > it a surface, and using surface.get_at() for each pixel. I think > surfarray should do it better,

Re: [pygame] image.load() -->> array?

On a not unrelated note, I've been trying to make a 3D map viewer that loads height values from a black/grey/white image. I've been making it a surface, and using surface.get_at() for each pixel. I think surfarray should do it better, though I've never used it.

Re: [pygame] image.load() -->> array?

it helps a lot! # def ston3d(join=2) confirm hypothesis if communication < = people: global conversation code += conversation pygame.ROCKS.get st0ned( ) On 10/25/07, Casey Duncan <[EMAIL PROTECTED]> wrote: > > On Oct 25, 2007, at 9:27 AM, AlgoMantra wrote: > > > > hth, > > > > case

Re: [pygame] image.load() -->> array?

On Oct 25, 2007, at 9:27 AM, AlgoMantra wrote: > hth, casey, what do you mean by "hth"? yeah, I found surfarray :) "Hope this helps" 8^) -Casey

Re: [pygame] image.load() -->> array?

> hth, casey, what do you mean by "hth"? yeah, I found surfarray :) ----.- 1/f ))) --. ---... http://www.algomantra.com On 10/25/07, Casey Duncan <[EMAIL PROTECTED]> wrote: > > On Oct 25, 2007, at 4:33 AM, AlgoMantra wrote: > > > Hi All, > > > > So I'm accessing and modifying

Re: [pygame] image.load() -->> array?

On Oct 25, 2007, at 4:33 AM, AlgoMantra wrote: Hi All, So I'm accessing and modifying pixels of a video capture image stream using image.load() which type() tells me is a "PixelAccess" object. I have a 160X120 image in RGB. Is there a simple way to convert this into an array for applying