[android-developers] Re: Emulator Performance VS Real Phone Performance
Usually 15fps - 60 fps, depends on the game. 15 fps is good enough for puzzle/card game. For fast-action game, 30 fps is good enough. You can aim for 60 fps, but your code must be very very optimized. You have to make sure that each frame execution must be fast enough, not longer than 1/60 sec. For example, you may have to sacrifice the game physics calculation or collision detection, from high-precision calculation to good-enough calculation. Well, it's the art of game development. On Oct 17, 10:50 am, Tjerk Wolterink [EMAIL PROTECTED] wrote: Ok, if you have a steady framerate that is possible,the point is that i want the framerate to be as high as possible. Or is that a stupid approach? What framerate is good enough. Too high framerates will result in bad audio performance. I read some stuff about gameprogramming and also understand that frame-skipping is also a technique too keep performance good enough. I am just new to the game / physiscs game programming kind of stuff. 2008/10/17 abiyasa [EMAIL PROTECTED] I thought about decoupling the movement from the framerate (speed = pixels/second), but this requires the use for floats, which make the calculation rather slow. In agameyou should never tie the speed of movement to the frame rate, because that will of course vary across different hardware. Even if we were doing a google phone and completely controlling the hardware, we'd want to release new hardware in the future that goes faster, and yourgamethen wouldn't work well with it. There is no problem in using the frame rate for the movement speed. It is still common in modern game programming where you define speed or other physics based on frame rate (not real-time). Just make sure that your game loop maintains a stabile frames-per- second and having a maximum fps by using sleep on game thread. Even if the new hardware is 5x faster, as long as you have maximum FPS, your game will work fine. -- -- Tjerk Wolterink @ GMail- Hide quoted text - - Show quoted text - --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Emulator Performance VS Real Phone Performance
I thought about decoupling the movement from the framerate (speed = pixels/second), but this requires the use for floats, which make the calculation rather slow. In agameyou should never tie the speed of movement to the frame rate, because that will of course vary across different hardware. Even if we were doing a google phone and completely controlling the hardware, we'd want to release new hardware in the future that goes faster, and yourgamethen wouldn't work well with it. There is no problem in using the frame rate for the movement speed. It is still common in modern game programming where you define speed or other physics based on frame rate (not real-time). Just make sure that your game loop maintains a stabile frames-per- second and having a maximum fps by using sleep on game thread. Even if the new hardware is 5x faster, as long as you have maximum FPS, your game will work fine. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Emulator Performance VS Real Phone Performance
Ok, if you have a steady framerate that is possible,the point is that i want the framerate to be as high as possible. Or is that a stupid approach? What framerate is good enough. Too high framerates will result in bad audio performance. I read some stuff about gameprogramming and also understand that frame-skipping is also a technique too keep performance good enough. I am just new to the game / physiscs game programming kind of stuff. 2008/10/17 abiyasa [EMAIL PROTECTED] I thought about decoupling the movement from the framerate (speed = pixels/second), but this requires the use for floats, which make the calculation rather slow. In agameyou should never tie the speed of movement to the frame rate, because that will of course vary across different hardware. Even if we were doing a google phone and completely controlling the hardware, we'd want to release new hardware in the future that goes faster, and yourgamethen wouldn't work well with it. There is no problem in using the frame rate for the movement speed. It is still common in modern game programming where you define speed or other physics based on frame rate (not real-time). Just make sure that your game loop maintains a stabile frames-per- second and having a maximum fps by using sleep on game thread. Even if the new hardware is 5x faster, as long as you have maximum FPS, your game will work fine. -- -- Tjerk Wolterink @ GMail --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Emulator Performance VS Real Phone Performance
int x; // pixel position int xscaled = 0; // pixel position scaled by 1000 ... int movement=BULLETSPEED*deltaT; /// v*t = d // don't divide by 1000 here xscaled += movement; // calculate movement more accurately x = xscaled / 1000; // scale down only when you want to plot draw(x); If you scale by 1024, you can also write x = xscaled 10; // divide by 1024. Could be faster than integer division. Peli www.openintents.org On Oct 15, 11:55 am, TjerkW [EMAIL PROTECTED] wrote: On 15 okt, 00:48, hackbod [EMAIL PROTECTED] wrote: The emulator in no way tries to emulate the performance characteristics of real hardware. For this and many other reasons, every developer should run their application on real hardware before considering it to be ready for for release to the public. I do not have to money to buy a android phone. I thought the emulator emulates a real phone, too bad. Re: I thought about decoupling the movement from the framerate (speed = pixels/second), but this requires the use for floats, which make the calculation rather slow. In a game you should never tie the speed of movement to the frame rate, because that will of course vary across different hardware. Even if we were doing a google phone and completely controlling the hardware, we'd want to release new hardware in the future that goes faster, and your game then wouldn't work well with it. I understand that. Also there should be no reason to need floats to deal with this, you can use fixed point integers. How should i do it. Supposei have the following: int BULLET_SPEED=30; // 30 pixels/second // then on a frameDraw long deltaT=thread.getFrameTime(); // the time it took to move to a new frame, in millis int movement=(BULLETSPEED*deltaT)/1000; /// v*t = d The problem here is that movement is always zero because the devision is done with 1000 (1 second). So either i use this: int movement=(int)((BULLETSPEED*deltaT)/(float)1000); Which required FLOATING POINT calculation. Or i make the bullet speed a float. But this also requires floating point calculation. So how is it done, without the need of floating points? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Emulator Performance VS Real Phone Performance
On 15 okt, 00:48, hackbod [EMAIL PROTECTED] wrote: The emulator in no way tries to emulate the performance characteristics of real hardware. For this and many other reasons, every developer should run their application on real hardware before considering it to be ready for for release to the public. I do not have to money to buy a android phone. I thought the emulator emulates a real phone, too bad. Re: I thought about decoupling the movement from the framerate (speed = pixels/second), but this requires the use for floats, which make the calculation rather slow. In a game you should never tie the speed of movement to the frame rate, because that will of course vary across different hardware. Even if we were doing a google phone and completely controlling the hardware, we'd want to release new hardware in the future that goes faster, and your game then wouldn't work well with it. I understand that. Also there should be no reason to need floats to deal with this, you can use fixed point integers. How should i do it. Supposei have the following: int BULLET_SPEED=30; // 30 pixels/second // then on a frameDraw long deltaT=thread.getFrameTime(); // the time it took to move to a new frame, in millis int movement=(BULLETSPEED*deltaT)/1000; /// v*t = d The problem here is that movement is always zero because the devision is done with 1000 (1 second). So either i use this: int movement=(int)((BULLETSPEED*deltaT)/(float)1000); Which required FLOATING POINT calculation. Or i make the bullet speed a float. But this also requires floating point calculation. So how is it done, without the need of floating points? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Emulator Performance VS Real Phone Performance
nice, thanks... didnt see it this way 2008/10/15 Peli [EMAIL PROTECTED] int x; // pixel position int xscaled = 0; // pixel position scaled by 1000 ... int movement=BULLETSPEED*deltaT; /// v*t = d // don't divide by 1000 here xscaled += movement; // calculate movement more accurately x = xscaled / 1000; // scale down only when you want to plot draw(x); If you scale by 1024, you can also write x = xscaled 10; // divide by 1024. Could be faster than integer division. Peli www.openintents.org On Oct 15, 11:55 am, TjerkW [EMAIL PROTECTED] wrote: On 15 okt, 00:48, hackbod [EMAIL PROTECTED] wrote: The emulator in no way tries to emulate the performance characteristics of real hardware. For this and many other reasons, every developer should run their application on real hardware before considering it to be ready for for release to the public. I do not have to money to buy a android phone. I thought the emulator emulates a real phone, too bad. Re: I thought about decoupling the movement from the framerate (speed = pixels/second), but this requires the use for floats, which make the calculation rather slow. In a game you should never tie the speed of movement to the frame rate, because that will of course vary across different hardware. Even if we were doing a google phone and completely controlling the hardware, we'd want to release new hardware in the future that goes faster, and your game then wouldn't work well with it. I understand that. Also there should be no reason to need floats to deal with this, you can use fixed point integers. How should i do it. Supposei have the following: int BULLET_SPEED=30; // 30 pixels/second // then on a frameDraw long deltaT=thread.getFrameTime(); // the time it took to move to a new frame, in millis int movement=(BULLETSPEED*deltaT)/1000; /// v*t = d The problem here is that movement is always zero because the devision is done with 1000 (1 second). So either i use this: int movement=(int)((BULLETSPEED*deltaT)/(float)1000); Which required FLOATING POINT calculation. Or i make the bullet speed a float. But this also requires floating point calculation. So how is it done, without the need of floating points? -- -- Tjerk Wolterink @ GMail --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Emulator Performance VS Real Phone Performance
The emulator in no way tries to emulate the performance characteristics of real hardware. For this and many other reasons, every developer should run their application on real hardware before considering it to be ready for for release to the public. Re: I thought about decoupling the movement from the framerate (speed = pixels/second), but this requires the use for floats, which make the calculation rather slow. In a game you should never tie the speed of movement to the frame rate, because that will of course vary across different hardware. Even if we were doing a google phone and completely controlling the hardware, we'd want to release new hardware in the future that goes faster, and your game then wouldn't work well with it. Also there should be no reason to need floats to deal with this, you can use fixed point integers. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
