Re: [pygame] numpy migration (again)
[EMAIL PROTECTED] ha scritto: I for one (as a person with no authorit, though) would support this switch. Te fragmentation between Numeric and NumPy is retarding Python's usage in scientific computing. Talking as someone being into scientific computing in Python, I feel that there is no fragmentation. NumPy is THE way to go, Numeric is old history. IIRC, on the scipy and/or matplotlib mailing list, it has been said that numeric compatibility is being deprecated soon if not already. m.
Re: [pygame] numpy migration (again)
On 7/19/07, René Dudfield [EMAIL PROTECTED] wrote: The current plan is to support numeric, and numpy by using the python 'array' module from C, and hooking into that via python. [explanation] I think this plan let's everyone be happy, and warm inside. It's a great plan. ... now someone just has to code it. I hope it comes soon ;-) -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED]
Re: [pygame] Game State Switching Example
Thank you, kschnee... looks good to me - I will use that in my next game. But imho adding the widget/interface info+sampleclass is too much for an otherwise nice and simple cookbook-entry simon ps.: And you code tells me that calling 'screen' what you call 'state' is not too far fetched ;-) next_screen = self.game_state.pop() On 7/17/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I found a better way than I'd done before to switch between the various states of a game, such as a main gameplay screen and a status screen. Attached is some example code. Something for the Cookbook, maybe?
Re: [pygame] Game State Switching Example
i use the state change raising a ChangeState( newstate ) exception, and the loop are ready for try and except this and change the value self.state Good luck 2007/7/19, Simon Oberhammer [EMAIL PROTECTED]: Thank you, kschnee... looks good to me - I will use that in my next game. But imho adding the widget/interface info+sampleclass is too much for an otherwise nice and simple cookbook-entry simon ps.: And you code tells me that calling 'screen' what you call 'state' is not too far fetched ;-) next_screen = self.game_state.pop() On 7/17/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I found a better way than I'd done before to switch between the various states of a game, such as a main gameplay screen and a status screen. Attached is some example code. Something for the Cookbook, maybe? -- Juan José Alonso. KarlsBerg. eMail: [EMAIL PROTECTED] MSN: [EMAIL PROTECTED]
Re: [pygame] numpy migration (again)
Santiago M. Mola wrote: On 7/19/07, René Dudfield [EMAIL PROTECTED] wrote: The current plan is to support numeric, and numpy by using the python 'array' module from C, and hooking into that via python. How exactly will that work? Are you going to copy stuff from a Numeric/numpy array into an array.array? -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carpe post meridiem! | Christchurch, New Zealand | (I'm not a morning person.) | [EMAIL PROTECTED] +--+
Re: [pygame] numpy migration (again)
Not copying unless asked to. python arrays are mutable, so you need to copy explicitly. So the pixels calls will still work as they do now. On 7/20/07, Greg Ewing [EMAIL PROTECTED] wrote: Santiago M. Mola wrote: On 7/19/07, René Dudfield [EMAIL PROTECTED] wrote: The current plan is to support numeric, and numpy by using the python 'array' module from C, and hooking into that via python. How exactly will that work? Are you going to copy stuff from a Numeric/numpy array into an array.array? -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carpe post meridiem! | Christchurch, New Zealand | (I'm not a morning person.) | [EMAIL PROTECTED]+--+
[pygame] time progression independent of game ticks
Hi list, I'm working on a game in which the player looks after a fishtank full of fish. Each fish ages, gestates while pregnant, grows hungrier, etc. For arguments sake lets say 15 minutes = 1 fish year. I want this passage of time to be independent of frame rate and iterations through the main game loop (or do I?). What is the best way to go about such a thing? Use MVC and run the model in its own thread? If that is the case what is the best way to keep track of the passage of actual time within the model? Thanks for reading. -- Regards Daniel Nixon
Re: [pygame] time progression independent of game ticks
You could try: http://www.pygame.org/docs/ref/time.html#pygame.time.Clock; with Clock.tick(framerate) which would normalize the speed of the program on any computer. Then you wouldn't have to deal with any of the annoying stuff. Of course this means that cutting edge computers would have no faster a fps rate than their slower counterparts. Ian On 7/19/07, Daniel Nixon [EMAIL PROTECTED] wrote: Hi list, I'm working on a game in which the player looks after a fishtank full of fish. Each fish ages, gestates while pregnant, grows hungrier, etc. For arguments sake lets say 15 minutes = 1 fish year. I want this passage of time to be independent of frame rate and iterations through the main game loop (or do I?). What is the best way to go about such a thing? Use MVC and run the model in its own thread? If that is the case what is the best way to keep track of the passage of actual time within the model? Thanks for reading. -- Regards Daniel Nixon
Re: [pygame] time progression independent of game ticks
Ian Mallett [EMAIL PROTECTED] wrote: You could try: http://www.pygame.org/docs/ref/time.html#pygame.time.Clock; with Clock.tick(framerate) which would normalize the speed of the program on any computer. I wouldn't go about it that way - tick(framerate) tries to achieve the framerate, but if you're running on a slow machine and can only run at 10Hz, calling Clock.tick(20) won't make it catch up. That's even what the documentation says: By calling Clock.tick(40) once per frame, the program will never run at more than 40 frames per second. Also, read on: Note that this function uses SDL_Delay function which is not accurate on every platform A few milliseconds every frame, over 15 minutes, who knows how far out of sync you'll end up? On 7/19/07, Daniel Nixon [EMAIL PROTECTED] wrote: Hi list, I'm working on a game in which the player looks after a fishtank full of fish. Each fish ages, gestates while pregnant, grows hungrier, etc. For arguments sake lets say 15 minutes = 1 fish year. I want this passage of time to be independent of frame rate and iterations through the main game loop (or do I?). That plan sounds fine to me. The way I do this sort of thing is to create a clock (as suggested by Ian) and read the amount of time each time through the loop takes, and pass that duration down into your simulation code: theClock=pygame.time.Clock() while (gameIsPlaying): frameTime=theClock.tick() processInput() doSim(frameTime) renderFrame() Inside your doSim function, update the game logic based on frameTime going by. It might look a little like this: FISH_DAYS_PER_MILLISECOND=0.0004 fishDays=0 def doSim(milliseconds): fishDays += milliseconds*FISH_DAYS_PER_MILLISECOND And, you should find that after about 15 minutes of the player's time, the fishDays value has climbed up to about 365 days. I also usually have ways to suspend the sim, so that if the user leaves the window, or brings up a pause menu, or whatever, I no longer call the doSim function, which means the game clock isn't counting up. If you want to combine this with Ian's suggestion, and add a frame rate hint to the tick() call, you can, but even if you don't, you should be able to get some good results. -Dave LeCompte
Re: [pygame] time progression independent of game ticks
OK, I agree, it is probably not the most accurate way to do it, I'm assuming that the problem is that the game won't run basically the same speed and cumulative errors aren't relevant (ex: the speed the fish swims won't be exactly the same but close enough). Ian
Re: [pygame] time progression independent of game ticks
Daniel Nixon [EMAIL PROTECTED] wrote: Thanks Ian, Dave. Passing down the milliseconds sounds like the way to go. Thanks for the great advice. :) Actually, let me refine my suggestion. Back a month or more ago, I kicked off the whole a CPU is not a saw thread with a discussion very similar to this, and what I would suggest based on the opinions voiced at that time would be to make sure that you leave a few cycles each frame for the OS. If you're reasonably confident that you can pick a frame rate that the slowest machines can keep up with, and then some, all you'd have to do is pass in the argument to the tick() call: TARGET_FRAME_RATE=25.0 while(gamePlaying): #[see earlier post] myClock.tick(TARGET_FRAME_RATE) If you want to be extra sure to give up a few cycles to the OS, you can add in an explicit delay: TARGET_FRAME_RATE=25.0 WAIT_TIME=5 # number of milliseconds per frame to yield to other processes while(gamePlaying): #[see earlier post] myClock.tick(TARGET_FRAME_RATE) pygame.time.wait(WAIT_TIME) tune these numbers to where you feel comfortable with them. I feel bad plugging my game over and over again, but if you look at the 0.9 version of the code, it wasn't yielding any time to the OS, and sometimes things felt a little uneven. 0.91 and 0.92 are more aggressive about using more CPU-efficient approaches, and I decided to use a 60fps target. The result was much smoother performance. 0.9: http://www.pygame.org/projects/23/415/?release_id=698 0.92: http://www.pygame.org/projects/23/415/?release_id=767 -Dave LeCompte
Re: [pygame] time progression independent of game ticks
I've been using something like myClock.tick(60), but that's for no other reason than 60 seems to be popular in most of the examples I've read. I doubt my game will require such a high frame rate. Aiming for 60fps seems to cause the game to take an entire core for itself, but using your wait time brought that down to about 10% of one core. What advantage does calling pygame.time.wait() have over simply lowering the frame rate passed to .tick()? On 7/20/07, Dave LeCompte (really) [EMAIL PROTECTED] wrote: Daniel Nixon [EMAIL PROTECTED] wrote: Thanks Ian, Dave. Passing down the milliseconds sounds like the way to go. Thanks for the great advice. :) Actually, let me refine my suggestion. Back a month or more ago, I kicked off the whole a CPU is not a saw thread with a discussion very similar to this, and what I would suggest based on the opinions voiced at that time would be to make sure that you leave a few cycles each frame for the OS. If you're reasonably confident that you can pick a frame rate that the slowest machines can keep up with, and then some, all you'd have to do is pass in the argument to the tick() call: TARGET_FRAME_RATE=25.0 while(gamePlaying): #[see earlier post] myClock.tick(TARGET_FRAME_RATE) If you want to be extra sure to give up a few cycles to the OS, you can add in an explicit delay: TARGET_FRAME_RATE=25.0 WAIT_TIME=5 # number of milliseconds per frame to yield to other processes while(gamePlaying): #[see earlier post] myClock.tick(TARGET_FRAME_RATE) pygame.time.wait(WAIT_TIME) tune these numbers to where you feel comfortable with them. I feel bad plugging my game over and over again, but if you look at the 0.9 version of the code, it wasn't yielding any time to the OS, and sometimes things felt a little uneven. 0.91 and 0.92 are more aggressive about using more CPU-efficient approaches, and I decided to use a 60fps target. The result was much smoother performance. 0.9: http://www.pygame.org/projects/23/415/?release_id=698 0.92: http://www.pygame.org/projects/23/415/?release_id=767 -Dave LeCompte -- Regards Daniel Nixon ABN: 62 535 877 916 phone: 04 0109 8560 email: [EMAIL PROTECTED]
