[android-developers] Re: Maintaining a free and paid version & maybe other version
I use a Git repo to manage all of my project's code. I store the meat of the code on GitHub, while I have local 'free' and 'donate' branches, each with slight modifications of their own. When the time comes to get a new release ready, I just merge the changes from the master branch into each of these local branches, fixing merge conflicts as they appear. Then I just export the application using Eclipse and I'm good to go. On Apr 5, 11:37 pm, Marc wrote: > I used to be a C/C++ programmer before getting in to android. I am not > sure how people maintain 2 versions of a program without using #ifdef > preprocessor macros. Right now I am changing the package name in > eclipse and changing the code manually, but this seems really > inefficient. Can anybody suggest a good way of having 2 or more > projects that share most of the code? -- 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 To unsubscribe, reply using "remove me" as the subject.
[android-developers] Re: How to parse JSON in Java?
By the way, that is invalid JSON.
On Apr 7, 5:05 am, Maxood wrote:
> I have the following JSON text that i need to parse to get pageName,
> pagePic, post_id, etc. What is the required code?
> pageInfo: {
> pageName: abc
> pagePic:http://profile.ak.fbcdn.net/object2/367/…}
>
> posts: [
> {
> post_id: 160119538822_302076968822
> actor_id: 1183856639
> picOfPersonWhoPosted:http://profile.ak.fbcdn.net/hprofile-ak-…
> nameOfPersonWhoPosted: Andrea Raquel
> message: Sounds cool. Can't wait to see it!
> likesCount: 2
> comments: [
> ]
> timeOfPost: 1266036226
>
>
>
> }
--
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
To unsubscribe, reply using "remove me" as the subject.
[android-developers] Re: Development in G1 in Ubuntu 9.04
It is the priority in which that rule is ran. The higher the number,
the later it is run.
By the way, you can also run:
sudo udev restart
After the rule is in place. This worked for me.
Eddie Ringle
On May 30, 2:20 pm, Abdul Mateen wrote:
> I want to know what these number means ?
>
> On Sat, May 30, 2009 at 5:52 AM, Christine wrote:
>
>
>
>
>
> > If 51 doesn't work, try a higher number. For some reason on my MSI
> > Wind with Ubuntu Intrepid, 51 didn't work but 90 did.
>
> > On May 5, 10:46 pm, "Luis E. Yupangui" wrote:
> > > This helped my out as well, Thank Yous sir!
>
> > > On Apr 29, 12:04 pm, Jean-Baptiste Queru wrote:
>
> > > > Try to call your file51-android.rules.
>
> > > > (I think something changed in 9.0.4 where a module that the android
> > > > stuff relies on is also initialized at step 50 which ends up being too
> > > > late).
>
> > > > JBQ
>
> > > > On Wed, Apr 29, 2009 at 9:00 AM, Breno wrote:
>
> > > > > Hi,
>
> > > > > Is Ubunto 9.04 compatible with development in Android? Before i
> > > > > ugrade, deploy on device was normal. Now, using 9.04, doesn't
> > > > > recognize it using "adb devices".
>
> > > > > This below is already set on my ubuntu:
>
> > > > > 1. Login as root and create this file: /etc/udev/rules.d/50-
> > > > > android.rules.
>
> > > > > For Gusty/Hardy, edit the file to read:
> > > > > SUBSYSTEM=="usb", SYSFS{idVendor}=="0bb4", MODE="0666"
>
> > > > > For Dapper, edit the file to read:
> > > > > SUBSYSTEM=="usb_device", SYSFS{idVendor}=="0bb4", MODE="0666"
> > > > > 2. Now execute:
> > > > > chmod a+rx /etc/udev/rules.d/50-android.rules
>
> > > > > Any ideas?
>
> > > > > Thanks a lot
>
> > > > --
> > > > Jean-Baptiste M. "JBQ" Queru
> > > > Android Engineer, Google.
>
> > > > Questions sent directly to me that have no reason for being private
> > > > will likely get ignored or forwarded to a public forum with no further
> > > > warning.
--~--~-~--~~~---~--~~
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: Development in G1 in Ubuntu 9.04
Whoops, that command should look like:
sudo /etc/init.d/udev restart
On Jun 9, 11:06 am, Eddie Ringle wrote:
> It is the priority in which that rule is ran. The higher the number,
> the later it is run.
>
> By the way, you can also run:
>
> sudo udev restart
>
> After the rule is in place. This worked for me.
>
> Eddie Ringle
>
> On May 30, 2:20 pm, Abdul Mateen wrote:
>
>
>
> > I want to know what these number means ?
>
> > On Sat, May 30, 2009 at 5:52 AM, Christine
> > wrote:
>
> > > If 51 doesn't work, try a higher number. For some reason on my MSI
> > > Wind with Ubuntu Intrepid, 51 didn't work but 90 did.
>
> > > On May 5, 10:46 pm, "Luis E. Yupangui" wrote:
> > > > This helped my out as well, Thank Yous sir!
>
> > > > On Apr 29, 12:04 pm, Jean-Baptiste Queru wrote:
>
> > > > > Try to call your file51-android.rules.
>
> > > > > (I think something changed in 9.0.4 where a module that the android
> > > > > stuff relies on is also initialized at step 50 which ends up being too
> > > > > late).
>
> > > > > JBQ
>
> > > > > On Wed, Apr 29, 2009 at 9:00 AM, Breno wrote:
>
> > > > > > Hi,
>
> > > > > > Is Ubunto 9.04 compatible with development in Android? Before i
> > > > > > ugrade, deploy on device was normal. Now, using 9.04, doesn't
> > > > > > recognize it using "adb devices".
>
> > > > > > This below is already set on my ubuntu:
>
> > > > > > 1. Login as root and create this file: /etc/udev/rules.d/50-
> > > > > > android.rules.
>
> > > > > > For Gusty/Hardy, edit the file to read:
> > > > > > SUBSYSTEM=="usb", SYSFS{idVendor}=="0bb4", MODE="0666"
>
> > > > > > For Dapper, edit the file to read:
> > > > > > SUBSYSTEM=="usb_device", SYSFS{idVendor}=="0bb4", MODE="0666"
> > > > > > 2. Now execute:
> > > > > > chmod a+rx /etc/udev/rules.d/50-android.rules
>
> > > > > > Any ideas?
>
> > > > > > Thanks a lot
>
> > > > > --
> > > > > Jean-Baptiste M. "JBQ" Queru
> > > > > Android Engineer, Google.
>
> > > > > Questions sent directly to me that have no reason for being private
> > > > > will likely get ignored or forwarded to a public forum with no further
> > > > > warning.
--~--~-~--~~~---~--~~
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] Android OpenGL Game - App Architecture and Threading Logic
Surprisingly, I don't seem to have issues with the OpenGL side of things (which is very unusual), but my problems stem from getting a clear idea for app architecture and a few other problems. Right now, most tutorials on the net just describe the render portion. I know that when I create a GLSurfaceView and hook a Renderer into it, it uses it's own thread for rendering. I want to do logic operations and other gameplay stuff (like moving characters and whatnot) in it's own thread as well. Can anyone explain a good approach to this? I'm guessing the two threads will have to be synchronized (do logic, render, repeat), and limited based on time so that it performs smoothly across different devices. -- 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 To unsubscribe, reply using "remove me" as the subject.
[android-developers] Re: Android OpenGL Game - App Architecture and Threading Logic
I'm a bit confused. What exactly is Game.sInstance? And can you
explain what the update() and render() methods do? (Well, I know what
they _do_, but I do not know how they are doing it (pseudocode would
work here).)
My gameplay is probably going to be a bit bigger than what you have,
so I don't think I'll be able to keep it inside the renderer class.
On Apr 9, 4:27 am, Clankrieger wrote:
> Hi,
>
> I had a lot of difficulties getting the threading and app lifecycle
> issues done, too. For my part, this was much more confusing than
> getting the actual game done. ;)
>
> The good thing is: you do not have to do too much for the render- and
> logic-thread separation because most of the rendering time is getting
> spent "outside" of your renderer's onDraw method. This is how I got
> this done: The "Game" itself is owned by the glSurfaceView renderer
> instance. the when the game starts (at onResume), I start an
> updatethread that is very simple an does something like
>
> while(bKeeprunning) {
> synchronized(Game.sInstance) {
> Game.sInstance.update();
> }
> Thread.sleep(50);
>
> }
>
> I have to add that my game logic is doing only this: logic. The world
> gets simulated. This is done less than 10 times per second - this is
> why I can have it sleep for 50 ms. sleeping is important here to give
> the render thread time to do this (I don't remember the full method
> signature, but I think you know what I mean):
>
> onDrawGlFrame() {
> synchronized(Game.sInstance) {
> Game.sInstance.render();
> }
> Thread.sleep(5);
>
> }
>
> I defined the updatethread as class inside of the Renderer because it
> is so small. This gave me a huge performance boost. Handling the app
> lifecycle is less easy (at least for me).
>
> On Apr 9, 3:09 am, Eddie Ringle wrote:
>
>
>
> > Surprisingly, I don't seem to have issues with the OpenGL side of
> > things (which is very unusual), but my problems stem from getting a
> > clear idea for app architecture and a few other problems.
> > Right now, most tutorials on the net just describe the render portion.
> > I know that when I create a GLSurfaceView and hook a Renderer into it,
> > it uses it's own thread for rendering.
>
> > I want to do logic operations and other gameplay stuff (like moving
> > characters and whatnot) in it's own thread as well. Can anyone explain
> > a good approach to this? I'm guessing the two threads will have to be
> > synchronized (do logic, render, repeat), and limited based on time so
> > that it performs smoothly across different devices.
--
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
To unsubscribe, reply using "remove me" as the subject.
[android-developers] Re: Android OpenGL Game - App Architecture and Threading Logic
Another thought occurred to me. I'm more comfortable with the old-
fashioned game loop, and I noticed I can turn off auto-rendering. I'll
see if this works out instead.
On Apr 9, 8:55 am, Eddie Ringle wrote:
> I'm a bit confused. What exactly is Game.sInstance? And can you
> explain what the update() and render() methods do? (Well, I know what
> they _do_, but I do not know how they are doing it (pseudocode would
> work here).)
> My gameplay is probably going to be a bit bigger than what you have,
> so I don't think I'll be able to keep it inside the renderer class.
>
> On Apr 9, 4:27 am, Clankrieger wrote:
>
>
>
> > Hi,
>
> > I had a lot of difficulties getting the threading and app lifecycle
> > issues done, too. For my part, this was much more confusing than
> > getting the actual game done. ;)
>
> > The good thing is: you do not have to do too much for the render- and
> > logic-thread separation because most of the rendering time is getting
> > spent "outside" of your renderer's onDraw method. This is how I got
> > this done: The "Game" itself is owned by the glSurfaceView renderer
> > instance. the when the game starts (at onResume), I start an
> > updatethread that is very simple an does something like
>
> > while(bKeeprunning) {
> > synchronized(Game.sInstance) {
> > Game.sInstance.update();
> > }
> > Thread.sleep(50);
>
> > }
>
> > I have to add that my game logic is doing only this: logic. The world
> > gets simulated. This is done less than 10 times per second - this is
> > why I can have it sleep for 50 ms. sleeping is important here to give
> > the render thread time to do this (I don't remember the full method
> > signature, but I think you know what I mean):
>
> > onDrawGlFrame() {
> > synchronized(Game.sInstance) {
> > Game.sInstance.render();
> > }
> > Thread.sleep(5);
>
> > }
>
> > I defined the updatethread as class inside of the Renderer because it
> > is so small. This gave me a huge performance boost. Handling the app
> > lifecycle is less easy (at least for me).
>
> > On Apr 9, 3:09 am, Eddie Ringle wrote:
>
> > > Surprisingly, I don't seem to have issues with the OpenGL side of
> > > things (which is very unusual), but my problems stem from getting a
> > > clear idea for app architecture and a few other problems.
> > > Right now, most tutorials on the net just describe the render portion.
> > > I know that when I create a GLSurfaceView and hook a Renderer into it,
> > > it uses it's own thread for rendering.
>
> > > I want to do logic operations and other gameplay stuff (like moving
> > > characters and whatnot) in it's own thread as well. Can anyone explain
> > > a good approach to this? I'm guessing the two threads will have to be
> > > synchronized (do logic, render, repeat), and limited based on time so
> > > that it performs smoothly across different devices.
--
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
To unsubscribe, reply using "remove me" as the subject.
[android-developers] Re: Android OpenGL Game - App Architecture and Threading Logic
Where do you store all your attributes, like player position?
Currently I just have a "GLQuad" class that I use to create new quads,
texture them, and manage position and velocity. Do you store them in
World, and then each side can access them from the world object?
Also, threading is new to me, so I really have no clue what a lock is.
On Apr 9, 12:03 pm, Robert Green wrote:
> It's pretty easy to do this:
>
> I use a World to write to and read from for the two "sides." Makes
> networking nice too. My World has a simple lock. Only one thing can
> write to it or read from it at a time.
>
> in GameLogicThread:
>
> run() {
> while (!done) {
> // wait for renderer
> world.getLock(); // blocks
> update()
> world.releaseLock();
> }
>
> }
>
> in Renderer:
>
> onDrawFrame() {
> world.getLock(); // blocks
> draw()
> world.releaseLock();
>
> }
>
> On Apr 9, 3:27 am, Clankrieger wrote:
>
>
>
> > Hi,
>
> > I had a lot of difficulties getting the threading and app lifecycle
> > issues done, too. For my part, this was much more confusing than
> > getting the actual game done. ;)
>
> > The good thing is: you do not have to do too much for the render- and
> > logic-thread separation because most of the rendering time is getting
> > spent "outside" of your renderer's onDraw method. This is how I got
> > this done: The "Game" itself is owned by the glSurfaceView renderer
> > instance. the when the game starts (at onResume), I start an
> > updatethread that is very simple an does something like
>
> > while(bKeeprunning) {
> > synchronized(Game.sInstance) {
> > Game.sInstance.update();
> > }
> > Thread.sleep(50);
>
> > }
>
> > I have to add that my game logic is doing only this: logic. The world
> > gets simulated. This is done less than 10 times per second - this is
> > why I can have it sleep for 50 ms. sleeping is important here to give
> > the render thread time to do this (I don't remember the full method
> > signature, but I think you know what I mean):
>
> > onDrawGlFrame() {
> > synchronized(Game.sInstance) {
> > Game.sInstance.render();
> > }
> > Thread.sleep(5);
>
> > }
>
> > I defined the updatethread as class inside of the Renderer because it
> > is so small. This gave me a huge performance boost. Handling the app
> > lifecycle is less easy (at least for me).
>
> > On Apr 9, 3:09 am, Eddie Ringle wrote:
>
> > > Surprisingly, I don't seem to have issues with the OpenGL side of
> > > things (which is very unusual), but my problems stem from getting a
> > > clear idea for app architecture and a few other problems.
> > > Right now, most tutorials on the net just describe the render portion.
> > > I know that when I create a GLSurfaceView and hook a Renderer into it,
> > > it uses it's own thread for rendering.
>
> > > I want to do logic operations and other gameplay stuff (like moving
> > > characters and whatnot) in it's own thread as well. Can anyone explain
> > > a good approach to this? I'm guessing the two threads will have to be
> > > synchronized (do logic, render, repeat), and limited based on time so
> > > that it performs smoothly across different devices.
--
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
To unsubscribe, reply using "remove me" as the subject.
[android-developers] Re: Android OpenGL Game - App Architecture and Threading Logic
One more thing question and I think I will be set. Coming from a C/C++
background, I enjoyed the use of references. I know that there is a
way to pass the reference by value in Java, but am not quite clear on
how. Could I, for example, create my World object, then pass that
object to the renderer and logic objects when I create them? I did a
small bit of reading on this topic, but still am not quite sure.
On Apr 9, 1:55 pm, Robert Green wrote:
> Yeah, you're going to want to model your game like you would model the
> real world:
>
> class World {
> public Player player;
> public Enemy[] enemies;
> public int timeLeft;
> public int level;
> //etc..
>
> }
>
> Then you update the world (usually by calls to player.update,
> enemy.update, etc) from your logic thread.
>
> Then what I like to do is separate the rendering stuff from the
> simulation so that I have renderers for specific things:
>
> class PlayerRenderer extends BaseRenderer {
> // knows about player geometry, knows how to draw the player and
> anything player-related..
>
> }
>
> Then in my main Renderer, I just call out to the individual component
> renderers:
>
> class WorldRenderer implements Renderer {
> onDrawFrame(GL gl) {
> // clear, set up projection, etc
> playerRenderer.draw(gl, world.player);
> enemyRenderer.draw(gl, world.enemies);
> // etc..
> }
>
> }
>
> And that's how I do it. I have just a little bit of initialization
> communication from the Renderer side to the game logic so that we can
> set up positioning of touchable UI components but otherwise it's
> always GameThread updates World, WorldRenderer draws World, repeat.
>
> On Apr 9, 11:25 am, Eddie Ringle wrote:
>
>
>
> > Where do you store all your attributes, like player position?
> > Currently I just have a "GLQuad" class that I use to create new quads,
> > texture them, and manage position and velocity. Do you store them in
> > World, and then each side can access them from the world object?
> > Also, threading is new to me, so I really have no clue what a lock is.
>
> > On Apr 9, 12:03 pm, Robert Green wrote:
>
> > > It's pretty easy to do this:
>
> > > I use a World to write to and read from for the two "sides." Makes
> > > networking nice too. My World has a simple lock. Only one thing can
> > > write to it or read from it at a time.
>
> > > in GameLogicThread:
>
> > > run() {
> > > while (!done) {
> > > // wait for renderer
> > > world.getLock(); // blocks
> > > update()
> > > world.releaseLock();
> > > }
>
> > > }
>
> > > in Renderer:
>
> > > onDrawFrame() {
> > > world.getLock(); // blocks
> > > draw()
> > > world.releaseLock();
>
> > > }
>
> > > On Apr 9, 3:27 am, Clankrieger wrote:
>
> > > > Hi,
>
> > > > I had a lot of difficulties getting the threading and app lifecycle
> > > > issues done, too. For my part, this was much more confusing than
> > > > getting the actual game done. ;)
>
> > > > The good thing is: you do not have to do too much for the render- and
> > > > logic-thread separation because most of the rendering time is getting
> > > > spent "outside" of your renderer's onDraw method. This is how I got
> > > > this done: The "Game" itself is owned by the glSurfaceView renderer
> > > > instance. the when the game starts (at onResume), I start an
> > > > updatethread that is very simple an does something like
>
> > > > while(bKeeprunning) {
> > > > synchronized(Game.sInstance) {
> > > > Game.sInstance.update();
> > > > }
> > > > Thread.sleep(50);
>
> > > > }
>
> > > > I have to add that my game logic is doing only this: logic. The world
> > > > gets simulated. This is done less than 10 times per second - this is
> > > > why I can have it sleep for 50 ms. sleeping is important here to give
> > > > the render thread time to do this (I don't remember the full method
> > > > signature, but I think you know what I mean):
>
> > > > onDrawGlFrame() {
> > > > synchronized(Game.sInstance) {
> > > > Game.sInstance.render();
> > > > }
> > > > Thread.sleep(5);
>
> > > > }
>
> > > > I defined the updatethread as class inside of the Renderer because it
> > > > is so small. Th
[android-developers] Re: Android OpenGL Game - App Architecture and Threading Logic
Is it as simple as:
In GameView.java (my custom GLSurfaceView class):
World _world = new World();
GameRenderer _renderer = new GameRenderer(_world);
In GameRenderer.java:
public World _world;
public GameRenderer(World world)
{
_world = world;
}
In GameRenderer.java, _world would now have the address of world,
which is the address of GameView.java's _world, right?
On Apr 9, 2:49 pm, Eddie Ringle wrote:
> One more thing question and I think I will be set. Coming from a C/C++
> background, I enjoyed the use of references. I know that there is a
> way to pass the reference by value in Java, but am not quite clear on
> how. Could I, for example, create my World object, then pass that
> object to the renderer and logic objects when I create them? I did a
> small bit of reading on this topic, but still am not quite sure.
>
> On Apr 9, 1:55 pm, Robert Green wrote:
>
>
>
> > Yeah, you're going to want to model your game like you would model the
> > real world:
>
> > class World {
> > public Player player;
> > public Enemy[] enemies;
> > public int timeLeft;
> > public int level;
> > //etc..
>
> > }
>
> > Then you update the world (usually by calls to player.update,
> > enemy.update, etc) from your logic thread.
>
> > Then what I like to do is separate the rendering stuff from the
> > simulation so that I have renderers for specific things:
>
> > class PlayerRenderer extends BaseRenderer {
> > // knows about player geometry, knows how to draw the player and
> > anything player-related..
>
> > }
>
> > Then in my main Renderer, I just call out to the individual component
> > renderers:
>
> > class WorldRenderer implements Renderer {
> > onDrawFrame(GL gl) {
> > // clear, set up projection, etc
> > playerRenderer.draw(gl, world.player);
> > enemyRenderer.draw(gl, world.enemies);
> > // etc..
> > }
>
> > }
>
> > And that's how I do it. I have just a little bit of initialization
> > communication from the Renderer side to the game logic so that we can
> > set up positioning of touchable UI components but otherwise it's
> > always GameThread updates World, WorldRenderer draws World, repeat.
>
> > On Apr 9, 11:25 am, Eddie Ringle wrote:
>
> > > Where do you store all your attributes, like player position?
> > > Currently I just have a "GLQuad" class that I use to create new quads,
> > > texture them, and manage position and velocity. Do you store them in
> > > World, and then each side can access them from the world object?
> > > Also, threading is new to me, so I really have no clue what a lock is.
>
> > > On Apr 9, 12:03 pm, Robert Green wrote:
>
> > > > It's pretty easy to do this:
>
> > > > I use a World to write to and read from for the two "sides." Makes
> > > > networking nice too. My World has a simple lock. Only one thing can
> > > > write to it or read from it at a time.
>
> > > > in GameLogicThread:
>
> > > > run() {
> > > > while (!done) {
> > > > // wait for renderer
> > > > world.getLock(); // blocks
> > > > update()
> > > > world.releaseLock();
> > > > }
>
> > > > }
>
> > > > in Renderer:
>
> > > > onDrawFrame() {
> > > > world.getLock(); // blocks
> > > > draw()
> > > > world.releaseLock();
>
> > > > }
>
> > > > On Apr 9, 3:27 am, Clankrieger wrote:
>
> > > > > Hi,
>
> > > > > I had a lot of difficulties getting the threading and app lifecycle
> > > > > issues done, too. For my part, this was much more confusing than
> > > > > getting the actual game done. ;)
>
> > > > > The good thing is: you do not have to do too much for the render- and
> > > > > logic-thread separation because most of the rendering time is getting
> > > > > spent "outside" of your renderer's onDraw method. This is how I got
> > > > > this done: The "Game" itself is owned by the glSurfaceView renderer
> > > > > instance. the when the game starts (at onResume), I start an
> > > > > updatethread that is very simple an does something like
>
> > > > > while(bKeeprunning) {
> > > > > synchronized(Game.sInstance) {
> > > > > Game.sInstance.update();
> > > > > }
> > > > > Thread.sleep(50);
&g
[android-developers] Re: Android OpenGL Game - App Architecture and Threading Logic
Robert,
Silly question, but how do you get input to the logic thread? I have
to get sensor and touch data from the main Activity class and somehow
get it to the logic thread.
Current program flow is as follows:
onCreate() -> GameView() -> World() & Renderer() & GameLogic()
On Apr 9, 3:24 pm, Robert Green wrote:
> Eddie,
>
> Yes, that'll do the trick.
>
> As far as the multiple threads goes, sure you can drive your logic off
> of the call to onDrawFrame but there is a situation in which having a
> separate thread makes sense:
>
> After onDrawFrame, the rendering thread is finishing/swapping. That
> can actually take a decent amount of time to do in certain cases and
> most of it is happening on the GPU, especially on a device like the
> Droid which has a discrete CPU/GPU. During that time, the CPU is
> available and can be used on the logic thread. Properly implemented,
> in a heavy scene you can get some or all of the logic processed before
> the rendering thread is ready again, which is why I favor it.
>
> My question is: onDrawFrame is only called once the GPU is ready for
> another draw. Why waste those precious GPU idle moments just doing
> CPU stuff like physics and collisions? You can maximize with another
> thread.
>
> Also - 2 (game and UI) or 3 threads (game logic, rendering and UI)
> does make sense because you never want to block the UI thread in
> Android. Get out of its way as fast as possible! :)
>
> On Apr 9, 1:58 pm, Eddie Ringle wrote:
>
>
>
> > Is it as simple as:
>
> > In GameView.java (my custom GLSurfaceView class):
> > World _world = new World();
>
> > GameRenderer _renderer = new GameRenderer(_world);
>
> > In GameRenderer.java:
> > public World _world;
>
> > public GameRenderer(World world)
> > {
> > _world = world;
>
> > }
>
> > In GameRenderer.java, _world would now have the address of world,
> > which is the address of GameView.java's _world, right?
>
> > On Apr 9, 2:49 pm, Eddie Ringle wrote:
>
> > > One more thing question and I think I will be set. Coming from a C/C++
> > > background, I enjoyed the use of references. I know that there is a
> > > way to pass the reference by value in Java, but am not quite clear on
> > > how. Could I, for example, create my World object, then pass that
> > > object to the renderer and logic objects when I create them? I did a
> > > small bit of reading on this topic, but still am not quite sure.
>
> > > On Apr 9, 1:55 pm, Robert Green wrote:
>
> > > > Yeah, you're going to want to model your game like you would model the
> > > > real world:
>
> > > > class World {
> > > > public Player player;
> > > > public Enemy[] enemies;
> > > > public int timeLeft;
> > > > public int level;
> > > > //etc..
>
> > > > }
>
> > > > Then you update the world (usually by calls to player.update,
> > > > enemy.update, etc) from your logic thread.
>
> > > > Then what I like to do is separate the rendering stuff from the
> > > > simulation so that I have renderers for specific things:
>
> > > > class PlayerRenderer extends BaseRenderer {
> > > > // knows about player geometry, knows how to draw the player and
> > > > anything player-related..
>
> > > > }
>
> > > > Then in my main Renderer, I just call out to the individual component
> > > > renderers:
>
> > > > class WorldRenderer implements Renderer {
> > > > onDrawFrame(GL gl) {
> > > > // clear, set up projection, etc
> > > > playerRenderer.draw(gl, world.player);
> > > > enemyRenderer.draw(gl, world.enemies);
> > > > // etc..
> > > > }
>
> > > > }
>
> > > > And that's how I do it. I have just a little bit of initialization
> > > > communication from the Renderer side to the game logic so that we can
> > > > set up positioning of touchable UI components but otherwise it's
> > > > always GameThread updates World, WorldRenderer draws World, repeat.
>
> > > > On Apr 9, 11:25 am, Eddie Ringle wrote:
>
> > > > > Where do you store all your attributes, like player position?
> > > > > Currently I just have a "GLQuad" class that I use to create new quads,
> > > > > texture them, and manage position and velocity. Do you store them in
> > > > > World, and then each side can access them from th
[android-developers] Re: Android OpenGL Game - App Architecture and Threading Logic
Okay, I figured I could just pass the Activity through parameters, but
wanted to know if a better way was possible.
Thanks for all the help everyone.
On Apr 9, 5:56 pm, Mario Zechner wrote:
> That depends on what kind of input you need. If your game is happy
> with just checking the current state of the accelerometer/touch screen/
> keyboard/trackball simply polling will do the trick. This means that
> in the UI thread, where you have your event listeners installed, you
> simply save the last state reported to you. In your logic thread you
> can savely access this state even without synchronization as it will
> only be composed of plain old data types like booleans or ints (of
> course there are cases where you catch the x coordinate of the
> previous event and the y coordinate of the current event but i dare
> say that the differences are so tiny, it doesn't make a difference).
>
> Other things might need event based input handling, like a GUI you
> implement yourself with say OpenGL. In that case you will need a queue
> that gets filled in the Android GUI thread by the listeners you have
> installed for the input devices. The logic thread acts as a consumer
> and takes the events from the queue. As you are working with a complex
> data structure you need to synchronize the adding and removing of
> events to and from the queue in both the Android GUI thread and your
> logic thread. This is a classical consumer/producer pattern which can
> be found frequently in multithreaded applications. Check out Robert's
> site athttp://www.rbgrn.net, i think he wrote an article on that sort
> of thing once.
>
> it basicaly boils down to this (pseudo code, written from the top of
> my head, will not compile)
>
> public class GameActivity extends Activity implements
> MotionEventListener
> {
> Queue events = new Queue();
>
> public void onTouch( MotionEvent event )
> {
> synchronized( events )
> {
> events.add( new Event( event.getX(), event.getY() );
> }
> }
>
> }
>
> public class GameLogic
> {
> GameActivity activity;
>
> public GameLogic( GameActivity activity )
> {
> this.activity = activity;
> }
>
> public void handleInput( )
> {
> synchronized( gameActivity.events )
> {
> // proces events here
> }
> }
>
> }
>
> Now, a couple of comments: You don't want to instantiate a new Event
> everytime a listener method in the GameActivity is called. You will
> need to implement a simple object pool and reuse events. That way the
> garbage collector will stay calm. Also note that the design above is a
> bit nasty, i would directly pass the GameActivity to the GameLogic
> among other things. But that's up to you.
>
> Polling input handling would work like above but without a queue and
> without the need for the synchronized blocks. All you do is set some
> members of GameActivity, say touchX and touchY in the onTouch method
> and read those values in the GameLogic class' handleInput method.
>
> hth,
> Mario
>
> On 9 Apr., 22:39, Eddie Ringle wrote:
>
>
>
> > Robert,
>
> > Silly question, but how do you get input to the logic thread? I have
> > to get sensor and touch data from the main Activity class and somehow
> > get it to the logic thread.
>
> > Current program flow is as follows:
> > onCreate() -> GameView() -> World() & Renderer() & GameLogic()
>
> > On Apr 9, 3:24 pm, Robert Green wrote:
>
> > > Eddie,
>
> > > Yes, that'll do the trick.
>
> > > As far as the multiple threads goes, sure you can drive your logic off
> > > of the call to onDrawFrame but there is a situation in which having a
> > > separate thread makes sense:
>
> > > After onDrawFrame, the rendering thread is finishing/swapping. That
> > > can actually take a decent amount of time to do in certain cases and
> > > most of it is happening on the GPU, especially on a device like the
> > > Droid which has a discrete CPU/GPU. During that time, the CPU is
> > > available and can be used on the logic thread. Properly implemented,
> > > in a heavy scene you can get some or all of the logic processed before
> > > the rendering thread is ready again, which is why I favor it.
>
> > > My question is: onDrawFrame is only called once the GPU is ready for
> > > another draw. Why waste those precious GPU idle moments just doing
> > > CPU stuff like physics and collisions? You can maximize with another
> > > thread.
>
> > > Also - 2 (game and UI) or 3 thre
[android-developers] Re: Opengl
The way I'm doing it right now is drawing a quad with dimensions identical to that of the world size, and texturing the whole thing with my background image. (Works pretty well because my world isn't so big.) On Apr 18, 11:42 pm, risha wrote: > Let me know how to set up a background image in opengl > > -- > 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 > athttp://groups.google.com/group/android-developers?hl=en -- 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: Is the bad MotionEvent/Touch slowdown stuff actually fixed on first-gen 2.1 updates?
Starring it. My poor G1 has a tough enough time with hardware
rendering, no need to put added strain on it.
On Apr 19, 3:29 am, Robert Green wrote:
> I filed a bug for this here
> -http://code.google.com/p/android/issues/detail?id=7836
>
> I believe I did a thorough job with the report.
>
> Please star it or comment on it if it affects you.
>
> Thanks!
>
> On Apr 19, 12:52 am, Robert Green wrote:
>
>
>
> > Excellent work, Mario. I think it's quite clear that the input
> > processing code in Android needs help. Eating 20-30% of a Cortex A8
> > is a pretty big deal.
>
> > On Apr 18, 4:21 pm, Mario Zechner wrote:
>
> > > For fun i extended the example i posted earlier. It now feature cpu
> > > usage output derrived from /proc/stat which should be enough to given
> > > an indication of the slow down occuring due to touch events.
>
> > > The setup:
>
> > > - A GLSurfaceView
> > > - An OnTouchListener that does nothing but return true
> > > - A simple renderer thread which is throttled via a Thread.sleep(200)
> > > to 5 frames per second which outputs the frames per second as well as
> > > the cpu usage
>
> > > Observation on Milestone with 2.0.1:
> > > - load without touching the screen - 4%-12%
> > > - load with touching the screen - 24%-44%
>
> > > due to the way i measure the cpu usage it of course fluctuates quiet a
> > > bit, the overall tendency can be easily derrived though.
>
> > > You can find the apk athttp://www.file-pasta.com/file/1/touchflood.apk,
> > > the Eclipse project with all the source can be found
> > > athttp://www.file-pasta.com/file/0/touchflood.zip.
>
> > > On 18 Apr., 22:18, Robert Green wrote:
>
> > > > The fundamental issue is that there are too many instructions per
> > > > event being executed. There is no way around it other than optimizing
> > > > the event handling code in KeyInputQueue. No amount of waiting or
> > > > sleeping will fix that because those events must run through that code
> > > > and that code appears to be very slow. It surprises me because it's
> > > > truly performance critical code and this issue has been known since
> > > > 1.1/1.5 and it still doesn't appear to be fixed in master. I'm
> > > > looking at it now and the author(s) didn't even follow Android's best
> > > > optimization practices. Simple things like declaring virtuals with
> > > > local variables aren't done.
>
> > > > For a moment today I was considering taking the input stack (EventHub,
> > > > KeyInputQueue and InputDevice) and hacking it into my own input stack
> > > > which reads off the event devices much more efficiently but I can't
> > > > find any way to stop the system stack from running and consuming CPU,
> > > > so that hack is out (and probably good because I really didn't want to
> > > > go there - waste of time and probably wouldn't work right anyway).
>
> > > > In my activity:
> > > > public boolean onTouchEvent(MotionEvent e) {
> > > > return false;
>
> > > > }
>
> > > > And system_server still consumes about 36% of the CPU while moving my
> > > > finger around. That proves there is nothing a developer can do to
> > > > work around this. I think I'll take this issue to the platform group
> > > > now and try to file more specific bugs.
>
> > > > On Apr 18, 10:38 am, Ralf Schneider wrote:
>
> > > > > I have already talked a lot about the touch slow down in this forum.
> > > > > There is another observation I would like to add, may be this can
> > > > > help to
> > > > > track the problem down.
>
> > > > > One of my projects is an Argumented Reality Game.
> > > > > Of course this kind of App eats energy (CPU cycles) like crazy:
>
> > > > > In my app I process:
> > > > > The camare, OpenGL graphics, Pseudo-3D-Sound mixing (8 simultaneous
> > > > > samples
> > > > > + ogg-music), 2 constant sensor imputs (acceleration, magnetic) and
> > > > > additional input from trackball, hardware keys and the touch screen.
>
> > > > > The largest slow down occurs with the touch-events.
>
> > > > > But the next big slow down occurs with the accleration and magnetic
> > > > > events!
> > > > > I gained up to 4 FPS on a N1 by switching from SENSOR_DELAY_FASTEST to
> > > > > SENSOR_DELAY_GAME.
>
> > > > > => So I just wonder: May be the slow down is in no way specific to
> > > > > touch
> > > > > events! Instead the whole input-queue-event handling is just horribly
> > > > > slow.
> > > > > As everyonw has observed: Touching the screen will trigger (flood)
> > > > > lots of
> > > > > events - This is similar as enabling input from other sensors - which
> > > > > can
> > > > > slow down the app in a compareable way, too!
> > > > > The main differences is only: Touching the screen will still trigger
> > > > > more
> > > > > event than using a sesnor in *SENSOR_DELAY_FASTEST*. So the slow down
> > > > > appears as less drastically...
>
> > > > > After working a while with Android, I must say:
> > > > > The design and architecture of the Java-API seems to be nice and well
> >
[android-developers] "Swipe" to next screen
If you look at the Google News & Weather app, you can "swipe" over to the next page. Anyone know how this is done? I'm suspecting that it is all one activity, the tabs at the top are a custom TabView, and it works similar to that? Eddie Ringle ed...@eringle.net http://eddieringle.com/ -- 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: "Swipe" to next screen
Okay, thanks. Just wanted a second opinion. On Apr 20, 3:26 pm, patbenatar wrote: > I would assume this is done by having the Views you'd like the user to > be able to switch between with a fling of the finger all contained > within one Activity and in that Activity you can listen for > MotionEvents on the currently displaying View. When you detect the > event you're looking for (a swipe, in this case.. although I don't > know how exactly to detect certain gestures) you can use an animation > (Google for "android animation") to push the current View off screen, > replacing it with the next one. > > I have seen this tutorial posted on this group before regarding this > topic:http://whyandroid.com/android/174-flipping-your-views.html ... > I have not tried it, however. > > -Nick > > On Apr 20, 5:11 am, Eddie Ringle wrote: > > > If you look at the Google News & Weather app, you can "swipe" over to the > > next page. Anyone know how this is done? > > I'm suspecting that it is all one activity, the tabs at the top are a custom > > TabView, and it works similar to that? > > > Eddie Ringle > > ed...@eringle.nethttp://eddieringle.com/ > > > -- > > 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 > > athttp://groups.google.com/group/android-developers?hl=en > > -- > 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 > athttp://groups.google.com/group/android-developers?hl=en -- 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: 14-year-old Android Developer:
Yeah, I'm 15 (will be 16 in May), and I haven't made much just yet, but that is more due to the target audience of my app (GitHub users) and the fact that a free version is available. I only make money if someone chooses to buy the donate version (there are ads on the free verison, but they aren't really effective). Good job though. :) On Apr 21, 8:26 pm, joshbeck wrote: > Hello, > > I'm writing a curriculum this year that is designed to get high- > achieving 8th grade students to write and publish > Android apps. One of my students broke the $50 this week. > > Here's an article: > > http://www.neisd.net/ComRel/News/Krueger_PaidApp_10.htm > > He's basically spent the last 2 months camped out in my computer lab, > but hard work pays off for sure. > > I'm doing my best to document my instruction through YouTube > athttp://linuxclassroom.com > > Thanks all, > Josh Beck > > -- > 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 > athttp://groups.google.com/group/android-developers?hl=en -- 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: JIT compiler explanation
The upcoming JIT for Dalvik will look for "hot" pieces of code and compile it to native machine code, resulting in a speed boost. The JIT is not there to convert Java bytecode to Dalvik bytecode, as Android applications should already compile to Dalvik bytecode. On May 3, 1:04 am, Justin King wrote: > Hello everyone, > > Is anyone able to explain to me exactly what the upcoming JIT compiler will > provide? For example, I have Java programs that generate bytecode at runtime > which I would like to port to android. Will the JIT compiler make this > possible by converting the runtime generated Java byte code to Dalvik at > runtime as required? > > Thanks! > > Justin > > -- > 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 > athttp://groups.google.com/group/android-developers?hl=en -- 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: best way to debug ANR...
adb logcat? On Aug 11, 5:21 pm, sdphil wrote: > hi. what is the best way to debug ANR. ideally, it would be nice to > know what call / thread / file and line number it is stalled at when > the ANR occurs, but every time I look at /anr/traces.txt, I can't seem > to find anything that points to something I can start tracking down. > > tia. -- 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: Android Dev Phone with 2.x?
I think the Nexus One counts as the current unofficial Android Developer Phone. (Unofficial in that it hasn't been given that title officially) On May 14, 9:36 am, Tomáš Hubálek wrote: > Hello, > > I'm owner of ADP1 (1.6 device) but majority of my users have 2.x > version. Does anybody have any idea whether there will be 2.x > developer devices? Currently there is just something like HTC Hero > available that is still IMHO 1.x device. > > Also I have one suggestion regarding pricing: Android Device Seeding > program is over but Google could support developers while upgrading > their dev phones according success of their apps (like > 1 > downloads with rating > 50% discount, > 25 downloads with > rating * 100% discount etc). I believe that this can be small > support to developers in countries where it is prohibited to sell apps > (which is IMHO majority of the world) and they are doing good job for > Android. > > I'm currently providing free apps (as I can't buy and sell on Android > Market from my country) and to buy multiple phones to cover various > flavors of Android is quite expensive hobby ;-) > > Have a good day > Tom > > -- > 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 > athttp://groups.google.com/group/android-developers?hl=en -- 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: Change Developer Account
Renaming the apk will do nothing, you would have to at least change the package name. On Jun 2, 1:36 am, Brad Gies wrote: > My guess is that it won't work. I unpublished an app several months ago, > and it still shows in my developer account. > > I think you will have to rename your .apk, publish the new one and then > modify the old one and add a message encouraging users to download the > new one. You can always give them a dialog box with a link to get the > new one. > > On 01/06/2010 10:55 PM, String wrote: > > > > > > > On Jun 1, 9:05 pm, Breon Nagy wrote: > > >> I work for a mobile development company. We deployed an app to the > >> Market under the client's developer account. We now want to transfer > >> the app to a different developer account. > > > Have you tried unpublishing the app (from the first account), then > > publishing it anew from the second? I don't really expect that to > > work :^), but there's nothing to lose by trying. Ordinarily, the > > Developer Console won't let you upload an app whose package name > > collides with an existing Market entry, but I'm not sure what happens > > if the first one is unpublished. > > > Don't worry if it doesn't work; you can always republish from the > > first account, and all you'll have lost will be a few minutes' > > downloads. > > >> One idea we had was publish both. The existing one would get a nag > >> screen that tells the user that this app is no longer supported and > >> directs them to download the new version. > > > Otherwise, a solution like this is probably your best option. The > > Market isn't set up for real enterprise-level application lifecycle > > management, not by a long shot. > > > String > > -- > Sincerely, > > Brad Gies > --- > Bistro Bot - Bistro > Blurbhttp://www.bgies.comhttp://www.bistroblurb.comhttp://www.bistrobot.com > --- > > Never doubt that a small group of thoughtful, committed people can > change the world. Indeed. It is the only thing that ever has - Margaret Mead- > 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 android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
