Think of it this way -- there is no such thing as pass-by-value in
Java, and no such thing as references, either. Everything is
equivalent to a pointer, except there is NO pointer arithmetic, and no
-> operator, that role being handled by '.', so it LOOKS like a
reference with C++ eyes.
To add to the confusion, the Java term for all this is 'reference'.
(And there's another use of the term 'reference' in Java as well).
There are no smart pointers, either -- they're not necessary, as
nothing is reference counted. There are times when they'd be useful,
but you have to do that another way, generally a bit more verbose.
On Apr 9, 11:49 am, Eddie Ringle <ed...@eringle.net> 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 <rbgrn....@gmail.com> 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 <ed...@eringle.net> 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 <rbgrn....@gmail.com> 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 <tob...@googlemail.com> 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 <ed...@eringle.net> 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.
