Hi!
I want to avoid using start() and simpleUpdate(). Is that possible? I want to have finer control over when things happen. What do I need to do instead of calling start?
So what do you want to control? Using simpleInit and simpleUpdate doesn’t take any control from you.
I basically want to be able to separate input stuff from graphics, and use them both as subsystems/libraries instead of using jME as an overarching framework. And I want to program to abstractions, meaning that from my game logic I don’t want to need to know anything about the implementation of the graphics or input subsystems, only that they implement an interface. Imagine that I were to switch game engine to something else, and I used simpleUpdate. Then I would have to change that part of my game. Ideally I would just have to do a new implementation of the graphics interface and leave the rest of my code exactly the way it was.
I have become a simplicity zealot ever since watching this http://www.infoq.com/presentations/Simple-Made-Easy (best video ever).
Nothing is stopping you, but you have to abstract away the angine yourself.
Simplicity is not always what you think.
Well for beginners version
Interface MainUpdater(){
void update(float tpf)
}
My game extends SimpleApplication implements MainUpdater
…
simpleupdate(float tpf){
update(tpf)
}
update(float tpg){
mystugg wich nolonger knows it is in jme logic as its coded only against my own interface
}
bonus points if you do that stuff in a seperate class, give your simpleapplication only an instance of your interface in a setter and it does only the wiring.
<cite>@zarch said:</cite> Simplicity is not always what you think.
Whom are you talking to and what do you mean?
<cite>@kwando said:</cite> Nothing is stopping you, but you have to abstract away the angine yourself.
<cite>@Empire Phoenix said:</cite> Well for beginners versionInterface MainUpdater(){
void update(float tpf)
}My game extends SimpleApplication implements MainUpdater
…
simpleupdate(float tpf){
update(tpf)
}update(float tpg){
mystugg wich nolonger knows it is in jme logic as its coded only against my own interface
}bonus points if you do that stuff in a seperate class, give your simpleapplication only an instance of your interface in a setter and it does only the wiring.
Yes I could do something like that, but I want to separate input from graphics too. That does not separate anything. And that interface is not that helpful. You can’t program everything that has to do with graphics to it. What I want is something that has methods like:
- Add model
- Add particle effect
- Play animation
- Transform model
- Pick target
- Position camera
- Start
- Stop
- Update
It’s hard to make a minimal (only essential stuff) interface for a graphics engine. 
And I have to assume that there is a scene graph etc, but that should be pretty standard for most graphics engines. Notice that the graphics interface does not deal with input in any way, because I think that’s a separate thing, and the more I can break things apart, the easier it becomes to deal with the subsystems.
Also I want to be able to shut down and restart the engine without restarting the JVM. Is that possible? It would save time when trying things out.
I do not see your problem really, just create a interface with the methods you need and program your game against that interface. Then you just need to make a jME application implements that interface.
Yes, you can start and restart a jME-application in the same JVM.
I think you should spend some time playing around with jME/tutorials before trying to abstract away everything.
If you want to write your own game engine you can just go directly to lwjgl or jogl. Essentially, that’s what “abstracting everything away” will be equivalent to.
<cite>@tuffe said:</cite> Whom are you talking to and what do you mean?
You.
In your quest for “simplicity” you are rewriting the interface to what is already an abstraction layer. Speaking with many years of architectural experience - you are massively complicating the work you have to do…not simplifying it at all.
<cite>@kwando said:</cite> I do not see your problem really, just create a interface with the methods you need and program your game against that interface. Then you just need to make a jME application implements that interface.Yes, you can start and restart a jME-application in the same JVM.
I think you should spend some time playing around with jME/tutorials before trying to abstract away everything.
Yes I almost can. It’s just the small problem of using simpleUpdate. What I want is to update the graphics engine from my main game loop, and not the other way around, i.e., putting my main game loop in simpleUpdate as jME suggests. If I do it the latter way, I have to change the code around the main game loop if I were to change graphics engine, and I shouldn’t have to.
<cite>@pspeed said:</cite> If you want to write your own game engine you can just go directly to lwjgl or jogl. Essentially, that's what "abstracting everything away" will be equivalent to.
I don’t want to write my own game engine. jME seems perfectly capable of what I need in terms of graphics. It’s just the small problem that I mentioned above. Also, I don’t see how erecting an interface between my game and jME will lead to me having to reimplement the whole engine. Indeed, abstacting means that the game does not need to know about the implementation of the subsystems, so the fact that it’s jME behind the graphics interface should be perfectly fine.
<cite>@zarch said:</cite> You.In your quest for “simplicity” you are rewriting the interface to what is already an abstraction layer. Speaking with many years of architectural experience - you are massively complicating the work you have to do…not simplifying it at all.
It’s not abstract enough, because abstract enough means that I should be able to swap out the underlying implementation/engine and have zero changes on the other side of the interface. And I simply can’t see how that is a bad thing. I don’t even think that I will swap engine, but thinking that way assures that I don’t make the mistake of having the game logic depend on the graphics implementation, and thereby making the game logic harder to think about.
jme is that layer. For example the audio or the rendering engine, even the graphics card or OS can be swapped out under you and your code doesn’t change.
If you really must do it this way then create an interface to be your application with its own update method and call that from simpleUpdate.
Then your hypothetical other engine can just call that update method from its own relevant thread.
Just post all graphics updates from your game code into the enqueue method of the application object. The jME application will then take care of performing those updates both thread safe and asynchronously.
<cite>@zarch said:</cite> jme is that layer. For example the audio or the rendering engine, even the graphics card or OS can be swapped out under you and your code doesn't change.If you really must do it this way then create an interface to be your application with its own update method and call that from simpleUpdate.
Then your hypothetical other engine can just call that update method from its own relevant thread.
Yes, jME abstacts away hardware and low-level graphics libs, but I want an even higher-level interface. Instead of, for example, having to do all this
Material mat_tt = new Material(assetManager, "Common/MatDefs/Misc/Unshaded.j3md");
mat_tt.setTexture("ColorMap", assetManager.loadTexture("Textures/ColoredTex/Monkey.png"));
mat_tt.getAdditionalRenderState().setBlendMode(BlendMode.Alpha);
window_frame.setMaterial(mat_tt);
/** Objects with transparency need to be in the render bucket for transparent objects: */
window_frame.setQueueBucket(Bucket.Transparent);
rootNode.attachChild(window_frame);
to make something transparent, I want to just pass like “transparent” or something as an extra argument to my “add model” method of the interface. The game logic should not have to deal with that stuff.
<cite>@kwando said:</cite> Just post all graphics updates from your game code into the enqueue method of the application object. The jME application will then take care of performing those updates both thread safe and asynchronously.
Interesting! But how do I make sure update is not called by jME automatically? Doesn’t start do that? And if I don’t call start then will jME be properly initialized? Also, I don’t understand exactly what the argument to enqueue should be.
<cite>@tuffe said:</cite> Yes, jME abstacts away hardware and low-level graphics libs, but I want an even higher-level interface. Instead of, for example, having to do all thisMaterial mat_tt = new Material(assetManager, "Common/MatDefs/Misc/Unshaded.j3md"); mat_tt.setTexture("ColorMap", assetManager.loadTexture("Textures/ColoredTex/Monkey.png")); mat_tt.getAdditionalRenderState().setBlendMode(BlendMode.Alpha); window_frame.setMaterial(mat_tt);
/** Objects with transparency need to be in the render bucket for transparent objects: */
window_frame.setQueueBucket(Bucket.Transparent);
rootNode.attachChild(window_frame);
to make something transparent, I want to just pass like “transparent” or something as an extra argument to my “add model” method of the interface. The game logic should not have to deal with that stuff.
Really? So every transparent object is going to be blend alpha (there are others)? Are going to have the same texture? Are going to be in the same queue bucket (there are others)? Is going to use the unshaded material?
All those options…and the hundreds more…all do something. They are there for a reason.
If you cannot answer the question you pose yourself using the source code, why do you think you can make anything in the engine work better for you?
jME will always have its own update/render loop, and it needs to be running in order to be able to display something on the screen. To make it run you have to call application#start(). Your game logic is going to need a update method and something needs to be calling that method so why not just let jME do it for you?
IMHO you are overthinking this. If you want to hide some setup code, put in a factory object or create a factory method somewhere and you are done.
<cite>@zarch said:</cite> Really? So every transparent object is going to be blend alpha (there are others)? Are going to have the same texture? Are going to be in the same queue bucket (there are others)? Is going to use the unshaded material?All those options…and the hundreds more…all do something. They are there for a reason.
I’m not sure exactly what I will need and want yet. But still, the classes used, Material and so on, are all jME classes, and if I were to swap engine, those would not work.
<cite>@normen said:</cite> If you cannot answer the question you pose yourself using the source code, why do you think you can make anything in the engine work better for you?
Maybe I can given some more time. Also, I don’t know if “better” is exactly the right word. I just want it to work slightly differently. What I was asking was just if it is possible to have my game loop call update on jME instead of the other way around.
<cite>@kwando said:</cite> jME will always have its own update/render loop, and it needs to be running in order to be able to display something on the screen. To make it run you have to call application#start(). Your game logic is going to need a update method and something needs to be calling that method so why not just let jME do it for you?IMHO you are overthinking this. If you want to hide some setup code, put in a factory object or create a factory method somewhere and you are done.
I understand that I will have to update, somehow, jME in order for it to display stuff. I just don’t like the structure it imposes. In my mind, the graphics engine is a subsystem, and the game should call it, and not the other way around. Yes, possibly I am overthinking, but again, I’m just asking if it’s possible in a fairly easy way (to have the call go in the other direction), and if there are any gotchas.
umh… i’m kind of in the middle of the two. The abstraction idea and the “dude you are overthinking” side…
Let me state my self:
@tuffe
-
Game engine should be optimized enough for real-time computing. More level of abstractions (performance affected) in the main entry of the Engine such as SimpleApplication are problematic. Think about it again,
-
But you can if you really want to, update are just public method, you can override it in SimpleApllication, recomment out one line such as Render stuff…and go. But then you have to handler everything else and take care your your self!
@Override
public void update() {
super.update(); // makes sure to execute AppTasks
if (speed == 0 || paused) {
return;
}
float tpf = timer.getTimePerFrame() * speed;
// update states
stateManager.update(tpf);
// simple update and root node
simpleUpdate(tpf);
rootNode.updateLogicalState(tpf);
guiNode.updateLogicalState(tpf);
rootNode.updateGeometricState();
guiNode.updateGeometricState();
// render states
stateManager.render(renderManager);
renderManager.render(tpf, context.isRenderable());
simpleRender(renderManager);
stateManager.postRender();
}
- May be you read too much software design papers at a time. You know, they talk sh#%t that go wrong immediately in 3 years or even shorter, wrong in many other aspect (ex: Game development)… I my self went wrong because I was mislead of Spring concept when I first came to game developing. That’s it, you can not just apply the concept of something else, like the Web to Game and hope it work at first time!
http://www.theserverside.com/news/1364527/Introduction-to-the-Spring-Framework
Check this out and I can tell you it will hurt when something you love too much are not going with you in this Game adventure (kind of…)
- And of course, you can change the code, this is an Open - source project with BSD license. Try it or come up with better design more detailed explanation please :p.
@guys:
I also believe Application need to know more Modes and Settings for broader range of usecases… I my self overrided SimpleApplication once for a while.
@tuffe can be observed too much about such abstraction thinking but was him the first one tell us JME is not modulized enough?
I’m not talking about the propose to omit update loop but eventually we not enough of expose the underlying application routine for new applications to hook in. Beside of that, people may want to shut the Rendering or completely, or just a moment to do something else. They also to disable just GUI, just the sound… And why not RenderAppState? Consider JME become more like a game engine or even appropriate for simulation base application, not just a rendering engine wich richer API than lwjgl?
Dont be harsh with newcomer, they don’t understand or have a clear view yet!
1 Like
interface GameEngine{
public void addTransparentModel();
// start the game engine
public void start();
}
class MyGame{
private GameEngine engine;
public MyGame(GameEngine engine){
this.engine = engine;
}
public void update(float tpf){
// update your game
// use methods on the engine object..
}
}
public class JMEEngine extends SimpleApplication implements GameEngine{
private MyGame game;
public JMEEngine(MyGame game){
super();
this.game = game;
}
public void simpleInit(){
}
public void simpleUpdate(float tpf){
game.update(tpf);
}
// all game engine interface methods...
}
class Main{
public static void main(String[] arg){
MyGame game = new MyGame();
GameEngine engine = new JMEngine(game);
engine.start();
}
}Something like this might work, but it will probably get messy pretty fast…