How a game engine basically works?

If you are a new Irrlicht Engine user, and have a newbie-question, this is the forum for you. You may also post general programming questions here.
Post Reply
aeronmike
Posts: 45
Joined: Thu May 24, 2012 5:00 am
Location: Rio de Janeiro, Brazil

How a game engine basically works?

Post by aeronmike »

Hi

Obviously I'm new to game programming.
I was leraning how to use Irrlicht and so on...

But a question that ALWAYS annoys me is, how, basically, a game engine works?
I got this piece of code:

Code: Select all

while(device->run())
        {
                driver->beginScene(true, true, SColor(255,100,101,140));
 
                smgr->drawAll();
                guienv->drawAll();
 
                driver->endScene();
        }
device->drop();
from the "Hello World" tutorial.

OK. It says it draws a scene in each loop. Is a scene a frame?
...
The game engine has its code. Where would I put MY code? For example, to handle health, armor, current weapon on hand, inventory, and so on. Does that stuff go inside that loop?
...
If possible, could you explain how things work, in details, but clear, please?
I'm pretty newbie. :P

Thanks!
mongoose7
Posts: 1227
Joined: Wed Apr 06, 2011 12:13 pm

Re: How a game engine basically works?

Post by mongoose7 »

The loop you show draws one picture on the screen. In a movie you call that a frame. smgr->drawAll draws the "scene graph" as it is at that moment.

So, you need to create a scene graph, and you need to change it in each "frame" so that the picture on the screen changes the way you want it.

If you look at the Hello World example, you should see where a node is created: node = smgr->addAnimatedMeshSceneNode(). This adds a node to the scene graph, so it will be drawn by smgr->drawAll(). Sydney.md2 contains a number of animations, so the picture of Sydney will change with time. But this kind of animation has to be created in a modeller outside of Irrlicht. Another way of animating is to change the positions of things like, for example, the camera. You might like to change smgr->addCameraSceneNode() to smgr->addCameraSceneNodeFPS() to get a camera you can move.
aeronmike
Posts: 45
Joined: Thu May 24, 2012 5:00 am
Location: Rio de Janeiro, Brazil

Re: How a game engine basically works?

Post by aeronmike »

OK.

And, what about my code? Where does it go in?
mongoose7
Posts: 1227
Joined: Wed Apr 06, 2011 12:13 pm

Re: How a game engine basically works?

Post by mongoose7 »

Well, if you understand the program, you will know that anything dynamic will have to be in the loop. But there are two ways it can be put into the loop - explicitly and implicitly. For example, every time Sydney is rendered, the animation is advanced automatically. If you use an FPS camera, that will apeear to move automatically as well. To handle health, say, you should make a call to your code at the top of the loop, I think (if you use vsync it may be important). Then your function can update its variables. If you want to draw a health bar, then you would set it, inside or outside the loop, but you would change, say, its length in the loop (well, in the function that is called from inside the loop). Changing a weapon might involve making the old one invisible, making the new one visible and possibly changing its position. Well, in summary, call your code before the beginScene() call.
theweirdn8
Posts: 21
Joined: Sun Feb 19, 2012 10:05 pm

Re: How a game engine basically works?

Post by theweirdn8 »

Game engines in general work like this:
//start game
Initialize game;
///Loop
(if bla bla bla)
{
take input;
process Input and data;
Render;
}
end game;
Mel
Competition winner
Posts: 2292
Joined: Wed May 07, 2008 11:40 am
Location: Granada, Spain

Re: How a game engine basically works?

Post by Mel »

Your game code goes normally before the drawing code.

What you have to do is to understand what Irrlicht does. The device->run(); code is used to update all the internal structures of Irrlicht, (timer, input....) but it doesn't perform any rendering. You do that later with the beginScene(), smgr->drawAll() and endScene() calls,so, basically, you need the so called "Main Loop", normally an endless loop with a condition to exit it so the program may end properly, that's why device->run() returns a boolean value, for instance.

Each time inside the loop, call the device run() method, then the video driver beginScene() method. After, you can tell the nodes to render, or you can call the scene manager drawAll() so everything renders properly and when you are done, call endScene(), all of them in this order. When that happens, the frame is presented to the window or screen.

Between all those calls, you can do whatever you want. But keep in mind that the drawAll() call will only work properly when it is between beginScene() and endScene(). And these work properly only after the call to run() of the device object you have created. Other than that, you can do anything in the order you want.
"There is nothing truly useless, it always serves as a bad example". Arthur A. Schmitt
aeronmike
Posts: 45
Joined: Thu May 24, 2012 5:00 am
Location: Rio de Janeiro, Brazil

Re: How a game engine basically works?

Post by aeronmike »

Thank you all!
But, just one more question:

Once, with those questions in mind, I decided to test if that "main loop" was really the right place I was thinking of inserting my code.
I performed this test duplicating the existing GUI in the scene (same "Hello World" example).
In each loop, I was creating a new static text box, in a different position.

Well, Sydney got a bit slow so you could see it.

Was that because Irrlicht was handling thousands of GUI elements, or it was really because of the performance of the engine?
I bet the first choice, once no game programmer would want to draw thousands of GUI elements on screen, without an end. That wasn't made for that.
But... Just to be sure. LoL
blAaarg
Posts: 94
Joined: Tue Mar 02, 2010 9:11 pm
Location: SoCal

Re: How a game engine basically works?

Post by blAaarg »

In each loop, I was creating a new static text box, in a different position.

Well, Sydney got a bit slow so you could see it.

Was that because Irrlicht was handling thousands of GUI elements, or it was really because of the performance of the engine?
I think you've guessed right. Generally speaking, you shouldn't create things within a loop, but rather, create them before the loop and then just update them within the loop. So, use your Irrlicht devicePointer that you get before the loop to do just what is done in Tutorial 1: get/keep a pointer to both the scene manager and the gui

Code: Select all

        ISceneManager* smgr = device->getSceneManager();
        IGUIEnvironment* guienv = device->getGUIEnvironment();
 
and later, within the loop, make whatever changes to them after calling drawAll() on both of them.

Code: Select all

        while(device->run())
        { 
 
                driver->beginScene(true, true, SColor(255,100,101,140));
 
                smgr->drawAll();
                guienv->drawAll();
 
                driver->endScene();
 
                guienv->//pseudocode: change/move static test block position//
 
        }
"Computers don't make mistakes! What they do they do on purpose!!"

-Dale Gribble
aeronmike
Posts: 45
Joined: Thu May 24, 2012 5:00 am
Location: Rio de Janeiro, Brazil

Re: How a game engine basically works?

Post by aeronmike »

Hmm.

Thanks a lot! :P
Post Reply