[android-developers] Re: Emulator performance
You know I thought about doing that as a next step - good point - I will run the app standalone and see how that compares. I do have a feeling the combination of eclipse and the debugging tools are adding to the whole performance degradation. Thanks for the good info On Sep 29, 3:29 pm, ADRA wrote: > > Is this a common trend? > > I find the emulator to be pretty slow in comparison to my NexusOne > sitting right next to my PC. The factor is probably around 0.5x - > 0.75x the speed. The PC is a Core2Duo 5400 3Ghz so no slouch by any > means. I suppose that if they bothered to accelerate the GFX / etc.. > and better utilize the virtualization functions they could squeeze out > some more into the emulator. That said, having the emulator slower > than most devices is a good (though incidental) test of how your app > will run in the real world. > > I don't know if its related, but in the last tooling update the > debugger is killing my processing performance, like horribly. Try > running the app stand-alone vs. debugging and make sure it isn't just > debugging/profiling cutting into emulator performance. > > > And regarding memory - I am loading Eclipse with close to 1G to be > > able to > > run the emulator and its basic services - is that normal? > > The emulator runs in its own process. If you mean to actually get your > app to launch then well Eclipse is a ram heavy platform. You get a ton > of features for that investment. If you really need a slimmer eclipse, > try to find features you don't use and remove them. Personally I peg > my eclipse at heap 1.5g and permgen 256 and it never blinks (Even with > the J2EE tools which eats resources like crazy). -- 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 android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Emulator performance
> Is this a common trend? I find the emulator to be pretty slow in comparison to my NexusOne sitting right next to my PC. The factor is probably around 0.5x - 0.75x the speed. The PC is a Core2Duo 5400 3Ghz so no slouch by any means. I suppose that if they bothered to accelerate the GFX / etc.. and better utilize the virtualization functions they could squeeze out some more into the emulator. That said, having the emulator slower than most devices is a good (though incidental) test of how your app will run in the real world. I don't know if its related, but in the last tooling update the debugger is killing my processing performance, like horribly. Try running the app stand-alone vs. debugging and make sure it isn't just debugging/profiling cutting into emulator performance. > And regarding memory - I am loading Eclipse with close to 1G to be > able to > run the emulator and its basic services - is that normal? The emulator runs in its own process. If you mean to actually get your app to launch then well Eclipse is a ram heavy platform. You get a ton of features for that investment. If you really need a slimmer eclipse, try to find features you don't use and remove them. Personally I peg my eclipse at heap 1.5g and permgen 256 and it never blinks (Even with the J2EE tools which eats resources like crazy). -- 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 android-developers+unsubscr...@googlegroups.com 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
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
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
> > 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
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
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
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 -~--~~~~--~~--~--~---
