Win a copy of Cross-Platform Desktop Applications: Using Node, Electron, and NW.js this week in the JavaScript forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Game Movement  RSS feed

 
Mark Spritzler
ranger
Sheriff
Posts: 17309
11
IntelliJ IDE Mac Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
OK, I have just finished reading J2ME Games, and in the book they discuss having a game "Environment" that goes beyond the screen. Meaning the game world is bigger than the screen, so the screen only shows a portion of the whole world, and as you move around, the screen updates itself.

This to me seems to lend to a basic, always used algorithm to determine how to move the screen around. Does anyone know this algorithm, and maybe explain it a little bit, because I think the book itself was lacking in that area.

Mark
 
Nick George
Ranch Hand
Posts: 815
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
JOGL works on a x/y axis, and lets you define the view, independant of the actual size of the window. Thus, you just tack 50 onto the xMaxView and xMinView. Not sure exactly what you mean by algorithm, maybe I'm misunderstanding your post.
 
Mark Spritzler
ranger
Sheriff
Posts: 17309
11
IntelliJ IDE Mac Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well basically, when you move your character, and the screen needs to adjust, what is the algorithm used. I would think that it would be an easy algorithm, that is a standard, and can be written simply and cleanly. Like you move one to the right, subtract one from the screen visibility.

Something along those lines. The code that was in the book was confusing to me.

Mark
 
Nick George
Ranch Hand
Posts: 815
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm afraid I still don't entirely follow. Say your character is at (0,0). The viewing window might go from (-10,-10) to (10,10). Now, Chary the Character moves one space to the right. Now, one would set the window to (-9,-10) to (11,10). If he moves up one, the viewing window would become (-9,-9) to (11,11). I'd be hard-pressed to call that an algorithm. What am I missing here? This could obviously be adjusted, to only readjust the screen when the character is significantly far from the center of the screen, i.e. never let the character get within 5 paces from the edge.
 
Lasse Koskela
author
Sheriff
Posts: 11962
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Mark, are you referring to the "algorithm" of figuring out which elements should be drawn and which can be left out as "not in view right now"?
 
Gregg Bolinger
Ranch Hand
Posts: 15304
6
Chrome IntelliJ IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Joseph,

Keep in mind that Mark might not be talking OpenGL. And when you say "JOGL works on a x/y axis, and lets you define the view..." you mean to say that OpenGL works this way. 2D graphics when not using OpenGL don't work the same way.
 
Mark Spritzler
ranger
Sheriff
Posts: 17309
11
IntelliJ IDE Mac Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Lasse Koskela:
Mark, are you referring to the "algorithm" of figuring out which elements should be drawn and which can be left out as "not in view right now"?


Exactly.

and the classes that I use are the classes in microedition.lcdui.game package, like GameCanvas.

I have no idea what JOGL or OpenGL are. I have heard of OpenGL, but that would not be relevant to a Mobile device game.

Mark
 
Gregg Bolinger
Ranch Hand
Posts: 15304
6
Chrome IntelliJ IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Mark Spritzler:
I have heard of OpenGL, but that would not be relevant to a Mobile device game.

Mark


Too bad. Opengl on mobile devices would be cool because you could port so many games over from the desktop (to an extent) to all sorts of different devices without a whole lot of code modification.

Wonder if anyone has started some sort of port...I'll have to google it.
 
Nick George
Ranch Hand
Posts: 815
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I would maintain the idea of a viewing window. Then, draw only the items in that window. Sorry if I'm still missing the point.
 
Mark Spritzler
ranger
Sheriff
Posts: 17309
11
IntelliJ IDE Mac Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Joseph George:
I would maintain the idea of a viewing window. Then, draw only the items in that window. Sorry if I'm still missing the point.


Yes there is a viewing window, so moving the "world" around in correlation to movement is the simple algorithm that I was looking for.

Actually in J2ME, you want to do drawing off screen, and then move it into view when needed for memory reasons. J2ME devices take a while to draw, so if you draw up front, then the game can move at a better pace. It might me slow startup, but it is better up front, then while playing.

Mark
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!