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 difference in timing. But either way, 1/59 of a second after rendering the last frame, the image is going to be nearly a whole frame out of date. If you're relying on millisecond precision for your shooting, you're already in trouble. With motion blurring, one can do that with OpenGL; it's called Fullscreen Antialiasing. That's not the same thing -- FSAA smooths adjacent pixels in a single frame, whereas motion blurring is about smoothing between successive frames. That's one way you could make use of your 900fps, though -- render several frames and blur them together. That's assuming you wouldn't rather just use the power to render a boatload more polygons instead, or some other fancy effect. -- Greg
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 that sort of blur. Wow! I love to say the word blur! Blur! Blur! Blur! (I'm like this at 11:40) That's one way you could make use of your 900fps, though -- render several frames and blur them together. Sounds good... That's assuming you wouldn't rather just use the power to render a boatload more polygons instead, or some other fancy effect. I think time would be better spent there. Greg Ian
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 like a rock with sdl, no matter how optomized your algorithm. You still have to take into consideration other programming routines that occur besides just drawing. I am looking forward to the gl backend for sdl, that should help level the playing field. Although opengl isn't really that difficult to learn. The main problem is that modern video cards aren't designed for 2d rendering, so the increase in capability doesn't fit that domain. Standard resolutions have grown well beyond 320x240, but 2d drawing routines haven't increased nearly as fast. And every time the resolution doubles, the amount of the screen being drawn quadruples. You could always write a game for gameboy, where the tile engine is built right in to the hardware :) Although even then I think you have to fight the framerate eventually. On 10/25/07, Ian Mallett [EMAIL PROTECTED] wrote: 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 course, is dependent on the framerate of the screen. 12fps vs. 40fps is a big difference. After about 60, most people can't tell any increase. I don't care if I can't see it. It is still cool to know that your computer is doing that. Ian
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 monitor to go with that, it doesn't do you any good at all. -- Greg
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?
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-to-date frame to that point is drawn. 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. That's 15 times the delay. So, if you're moving an object across the screen at a constant speed, you'll get, every 60th of a second, with 900fps/60fps refresh time, a frame that shows, at worst, where the object was 1/900th of a second ago. With 60fps/60fps refresh time, you'll get, at worst, a frame which shows where the object was 1/60th of a second ago. I'd opt for the one which shows more precisely where the object is. True, a small difference, but a difference. With motion blurring, one can do that with OpenGL; it's called Fullscreen Antialiasing. So it is possible. Of course, because this lowers the framerate again, I often don't include it with my programs. Ian
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 to just compute some number. For instance, 13500fps would be better than 900fps cause 900fps would have 15 times the delay, right? but arguing for 13500fps over 900fps in order to make a better game would be a pretty ridiculous argument Yes. I'm just saying there is a slight (though meaningless) advantage to having really high framerates.
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 functions using Numpy? If the (x,y) coordinates for pixel access remain the same, that is... See: http://www.pygame.org/docs/ref/surfarray.html http://www.pygame.org/docs/tut/surfarray/SurfarrayIntro.html hth, -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 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 functions using Numpy? If the (x,y) coordinates for pixel access remain the same, that is... See: http://www.pygame.org/docs/ref/surfarray.html http://www.pygame.org/docs/tut/surfarray/SurfarrayIntro.html hth, -Casey --
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?
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, casey, what do you mean by hth? yeah, I found surfarray :) Hope this helps 8^) -Casey -- ----.- 1/f ))) --. ---... http://www.algomantra.com
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?
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 never used it. 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 simpler or profiling shows you that using get_at() is slowing you down too much. -Casey
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 simpler or profiling shows you that using get_at() is slowing you down too much. It's slowing it down some, but the speed is fine. It's other people running my program that I'm worried about. My computer can do 256 squared calls to surface.get_at() in about 30 seconds, but it is pretty new. Ian
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 worry about it unless it helps makes the code simpler or profiling shows you that using get_at() is slowing you down too much. It's slowing it down some, but the speed is fine. It's other people running my program that I'm worried about. My computer can do 256 squared calls to surface.get_at() in about 30 seconds, but it is pretty new. yeah, it's always a good idea to have an old warhorse machine laying around to test on. Either that or a relative that never upgrades ;^) Even with a fast machine where performance is acceptable, profiling can tell you if you are spending a disproportionate amount of time doing certain things. And if you have capped the framerate, you can experiment with inserting time.sleeps() in there to give away large amounts of time per frame to simulate a slower environment. If you don't cap the framerate, you can improve how smooth things are on your fast machine by refactoring the slow bits. 50-60fps looks a lot more polished than 30fps for instance, but it really depends on the game and how much things are moving frame to frame. -Casey
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 is faster in python then a function call anyway. Regardless, I wouldn't worry about it unless it helps makes the code simpler or profiling shows you that using get_at() is slowing you down too much. It's slowing it down some, but the speed is fine. It's other people running my program that I'm worried about. My computer can do 256 squared calls to surface.get_at() in about 30 seconds, but it is pretty new. yeah, it's always a good idea to have an old warhorse machine laying around to test on. Either that or a relative that never upgrades ;^) Even with a fast machine where performance is acceptable, profiling can tell you if you are spending a disproportionate amount of time doing certain things. And if you have capped the framerate, you can experiment with inserting time.sleeps() in there to give away large amounts of time per frame to simulate a slower environment. If you don't cap the framerate, you can improve how smooth things are on your fast machine by refactoring the slow bits. 50-60fps looks a lot more polished than 30fps for instance, but it really depends on the game and how much things are moving frame to frame. -Casey Yes, more framerates are always better- I've gotten the idea more than once to obtain some high-performance graphics card and play one of those new DirectX 10.0 games with the dynamically changing worlds (think blades of grass moving independently and reacting to everything and being rendered perfectly), or to play one of my older favorite games at like a billion fps. SDL has the limitation that it is really slow. For some reason, it can never run more than 60-80 fps while doing nothing. OpenGL, which is what I use for 3D stuff, runs at about 900fps doing nothing. That's smooth. Ian
Re: [pygame] image.load() -- array?
Ian Mallett wrote: On 10/25/07, *Casey Duncan* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: On Oct 25, 2007, at 12:11 PM, Ian Mallett wrote: On 10/25/07, Casey Duncan [EMAIL PROTECTED] mailto:[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 simpler or profiling shows you that using get_at() is slowing you down too much. It's slowing it down some, but the speed is fine. It's other people running my program that I'm worried about. My computer can do 256 squared calls to surface.get_at() in about 30 seconds, but it is pretty new. yeah, it's always a good idea to have an old warhorse machine laying around to test on. Either that or a relative that never upgrades ;^) Even with a fast machine where performance is acceptable, profiling can tell you if you are spending a disproportionate amount of time doing certain things. And if you have capped the framerate, you can experiment with inserting time.sleeps() in there to give away large amounts of time per frame to simulate a slower environment. If you don't cap the framerate, you can improve how smooth things are on your fast machine by refactoring the slow bits. 50-60fps looks a lot more polished than 30fps for instance, but it really depends on the game and how much things are moving frame to frame. -Casey Yes, more framerates are always better- I've gotten the idea more than once to obtain some high-performance graphics card and play one of those new DirectX 10.0 games with the dynamically changing worlds (think blades of grass moving independently and reacting to everything and being rendered perfectly), or to play one of my older favorite games at like a billion fps. SDL has the limitation that it is really slow. For some reason, it can never run more than 60-80 fps while doing nothing. 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. Especially since my eyes can only distinguish 30 fps or so. -Luke
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 course, is dependent on the framerate of the screen. 12fps vs. 40fps is a big difference. After about 60, most people can't tell any increase. I don't care if I can't see it. It is still cool to know that your computer is doing that. Ian
