Mainloop

Introduce your project and write about your work.

Moderator: PPS-Leaders

Post Reply
User avatar
beni
Baron Vladimir Harkonnen
Posts: 949
Joined: Tue Oct 03, 2006 9:15 am
Location: Zurich
Contact:

Mainloop

Post by beni » Mon Nov 19, 2007 1:15 pm

I figured I should write about my progress as well.

Let's first look what we have done until now:
From the tutorials from the Ogre wiki we got to know the engine and how to use it. One tutorial dealt with omitting the "ExampleApplication"-Framework which is used in every tutorial in also in the examples. The result there was our orxonox main class at the moment.
Then 1337 tried to put the Ogre stuff into separate functions and classes, but in the end wasn't that satisfied with what he did.

I work right now on the game's main classes and functions and I came to the conclusion that 1337's approach isn't that bad actually. Some things he did cannot be done easier and are inevitable, so I guess I do it like him. With an eye on the old Orxonox implementation I came to a small framework which works great, but will need a lot other classes that are under development right now (like the class hierarchy) or are not developed at the moment.
I'm not sure yet if some stuff which is missing (like file and directory handling or command line interpretation) should be developed again (needs lot's of time) or just adopted from the old implementation.
I myself think, that the evil stuff which broke the old Orxonox code did not happen that far down in the framework so it should be save to use those things.
On the other hand there may be libraries which help (also for the two examples I mentioned).
"I'm Commander Shepard and this is my favorite forum on the internet."

User avatar
1337
Baron Vladimir Harkonnen
Posts: 521
Joined: Wed Oct 10, 2007 7:59 am

Post by 1337 » Tue Nov 20, 2007 8:56 pm

I'm curious ;)

Moments ago I was thinking again about the orxonox core. It just doesn't add up yet.
What I'm convinced of: We somehow need a main object that handles a lot things that are quite "global". But I hate global variables, so this would be the last option in my opinion.

What I want to exress with "main object" for example:
- A gun would like to know its ammunition type. Of course it could always request ammo by giving a string, but that is very slow. It could however at its creation retrieve an integer from the main object (by giving that string only once). This index could then be directly used to access ammo in an ammo dump (array access) which is millions of times faster. The reason why this is necessary in the first place is of course that the different ammo types are not really knwn during compile time (at least not to all the weapons).

- A bullet needs to be handled somehow, but sure not by the weapon that shot it.

- Anything an object would like to visualise (partricle effects, little temp entities, etc.) on its own requires a pointer to the scene manager.

Question is: Am I right and if yes, how do we do this? Singletons was one of my ideas, because passing a pointer of the main object to every single object ever created is an ineffecient bad idea.

What do you think? Don't worry, I'll bother some people tomorrow... ;)


There is someting else. Three weeks ago I talked to Bensch about the core problem, especially the graphics part. The questions rooted in the concept of loading xml-files into our game.
He explained to us that is a very good idea to separate graphics from the rest of the game. In our case with Ogre I don't see why this is necessary: Ogre's scene manager already does that.
E.g. if a game entity (a ship for instance) wanted to visualise something, it would be easiest to do this directly in the ship class instead of delegating this task to another class dedicated to visualising objects. For this I think we already have the ogre scene manager.
As I see it, it is inevitable to mix up graphics a little bit with the rest of the game (how could the user see anything otherwise?).
http://www.xkcd.com/
A webcomic of romance, sarcasm, math, and language.

User avatar
beni
Baron Vladimir Harkonnen
Posts: 949
Joined: Tue Oct 03, 2006 9:15 am
Location: Zurich
Contact:

Post by beni » Tue Nov 20, 2007 9:41 pm

Hey Reto

You're right. Since Ogre isn't a pure graphics library we just cannot use it only for graphics (okay, yes we could, but that was never the agreement). The whole engine provides this SceneNode system and SceneManager which are perfectly suited to work with. And that's it.

It's really only those two instances which are of importance. To actually start the game we need the root object, a singleton. This root is also useful to actually retrieve the SceneManager which again, provides the nodes we use to display something. The FrameListener is the only class we need, but we need something like that anyway and even though it shouldn't look like yours, it will have a similar function and could be either coded by us or just derived from the Ogre FrameListener.

There is no way around those, let's say four things. We may wrap one or two of them (SceneNode and maybe the FrameListener), but the other ones are good as they are and why not put them where they deserve to be? I'm working on this right now, but I cannot guarantee it to be finished tomorrow.

There will be things that are global, but singleton. We'll have those lists (each one is a singleton of its kind) and then one or two singletons providing global settings and variables. There is again, no way around it. There may be some improvements or alternatives, but in the end we cannot work without them.

To come to your question specifically: I'm not sure about the ammunition. I'm not sure if I understand your approach and I haven't thought about it in detail yet. But your right, that every bullet will be shot by a weapon, handled by the scene manager, will have it's entry in one of the lists to contribute with the collision detections. It will be a free node, not attached to anything but the root node (zero node).
Since the SceneManager is (nearly) a singleton, it's not a problem to get its pointer. But maybe those object do not need to have such a pointer at all. What's important is that every object has a child node which is known to emit some particles. Again, those may be in a list or just known by the SceneManager, so particles shouldn't be a problem either, I guess.

Let's talk about this tomorrow in detail. I'm looking forward to it.
"I'm Commander Shepard and this is my favorite forum on the internet."

User avatar
x3n
Baron Vladimir Harkonnen
Posts: 810
Joined: Mon Oct 30, 2006 5:40 pm
Contact:

Post by x3n » Tue Nov 20, 2007 9:54 pm

1337 wrote:- A gun would like to know its ammunition type. Of course it could always request ammo by giving a string, but that is very slow. It could however at its creation retrieve an integer from the main object (by giving that string only once). This index could then be directly used to access ammo in an ammo dump (array access) which is millions of times faster. The reason why this is necessary in the first place is of course that the different ammo types are not really knwn during compile time (at least not to all the weapons).
You're right: using strings is a bad idea. That's why we use class-identifiers:
string <-> identifier <-> class.

To create an object of a specified type, you first load the string from an xml-file and get the corresponding identifier. Then you're able to create new objects of the specified class through the identifier.

And concerning the array: There are lists of all objects of each class. :)

User avatar
1337
Baron Vladimir Harkonnen
Posts: 521
Joined: Wed Oct 10, 2007 7:59 am

Post by 1337 » Thu Nov 22, 2007 7:25 pm

1337 wrote:I'm curious ;)
There is someting else. Three weeks ago I talked to Bensch about the core problem, especially the graphics part. The questions rooted in the concept of loading xml-files into our game.
He explained to us that is a very good idea to separate graphics from the rest of the game. In our case with Ogre I don't see why this is necessary: Ogre's scene manager already does that.
E.g. if a game entity (a ship for instance) wanted to visualise something, it would be easiest to do this directly in the ship class instead of delegating this task to another class dedicated to visualising objects. For this I think we already have the ogre scene manager.
As I see it, it is inevitable to mix up graphics a little bit with the rest of the game (how could the user see anything otherwise?).
This is crap! (oh, I wrote that..)
I guess the guys from the network department would smash me for that... Graphics needs to be totally separated, but how..
http://www.xkcd.com/
A webcomic of romance, sarcasm, math, and language.

User avatar
beni
Baron Vladimir Harkonnen
Posts: 949
Joined: Tue Oct 03, 2006 9:15 am
Location: Zurich
Contact:

Post by beni » Fri Nov 23, 2007 1:34 am

Your right: that stuff you mention will visualize by itself. Don't worry :)
"I'm Commander Shepard and this is my favorite forum on the internet."

User avatar
1337
Baron Vladimir Harkonnen
Posts: 521
Joined: Wed Oct 10, 2007 7:59 am

Post by 1337 » Sun Nov 25, 2007 8:15 pm

beni wrote:Your right: that stuff you mention will visualize by itself. Don't worry :)
You see, I don't get that one. I totally understand for static objects, but what about dynamic ones? Those need a wrapper of some kind, I guess.
http://www.xkcd.com/
A webcomic of romance, sarcasm, math, and language.

Post Reply

Who is online

Users browsing this forum: No registered users and 7 guests