Whenever we declare the render(float deltatime) or update(float deltatime), in any class, it automatically become a method that is repeated 60 times per second. But what makes this method repeat itself 60 fps? What makes the method do that? In some classes, I am not implementing any other interface or expending any abstract class but that still makes the render(float deltatim) and update(float deltatime) work. Also, even though I do expend a interface like Game, how does the render(float deltatime) work? I mean, there is no special code within the render() in the Game interface class as well.
\$\begingroup\$
\$\endgroup\$
Add a comment
|
2 Answers
\$\begingroup\$
\$\endgroup\$
4
Libgdx will do that. Part of the arguments passed to the project generator is --mainClass MyGame. The libgdx will then look for the methods in that class (either using reflection or by creating it's own class during project generation that refers to that class directly).
After that it's a standard gameloop buried somewhere inside the libgdx code.
-
\$\begingroup\$ The project generator is the thing that turns the code into a game right? So according to you, the libgdx project generator looks for the methods (in this case the render() method) and make it into a gameloop by using some complex code hiding in the dark within the libgdx api. (Please correct me if I misunderstood this part) \$\endgroup\$– chanu19Commented Feb 8, 2017 at 10:06
-
\$\begingroup\$ Oh but the second part of my question was how the render() method work s as a gameloop in classes other than the main class. In my game, I created a method called Renderer that renders all the code from another method called Updater. In the render() method of the main class, MyGame, I wrote something like this: private void render() { renderer.render(); } Then the renderer.render code is called 60times per second just like the render() method in the main class \$\endgroup\$– chanu19Commented Feb 8, 2017 at 10:11
-
\$\begingroup\$ because the MyGame.render method gets called 60 times a second and it calls renderer.render(). libgdx has nothing to do with that. \$\endgroup\$ Commented Feb 8, 2017 at 10:14
-
\$\begingroup\$ Oh ok thank you. I see. Then can I ask you one final question? In my game, in the main class, I declared a SecondClass(that has its own render() method) using its constructor in the create() method. Then, I didn't have any render() method in the MainClass. When I did this, the render() in the SecondClass worked. However, when I created the render() method in the MainClass, the render() from the MainClass worked but not the render() method in the SecondClass. Does that mean that the project generator access the first render() it can see as the GameLoop? \$\endgroup\$– chanu19Commented Feb 8, 2017 at 10:36
\$\begingroup\$
\$\endgroup\$
One has to write code that does this. libGDX happens to generate this code for you using its project generator tool, to avoid making you build that boilerplate. All it is doing is producing a set of stub source files based on your target platform. For example, this is the file used for desktop platforms. %PACKAGE% and %MAIN_CLASS% are replaced, by the generator, with the names of your package and game class.
You can see that all this code does is create a new LwjglApplication and pass it an instance of your class. When constructed, LwjglApplication calls initialize(), which in turn starts a thread to call the mainLoop function.
mainLoop simply runs until the game is done. Within that loop, it does work related to gathering input and updating state and ultimately calls render() on the listener (your game instance) provided to it.
You can follow a similar path of execution for different platforms you may be interested in; there's nothing magic here. The project generator is just saving you some typing by instantiating the correct things for you, but ultimately all it is doing is copy-pasting some code on your behalf. It does not introspect your source code at all.