Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length

 
Advanced search

1364485 Posts in 63827 Topics- by 55712 Members - Latest Member: SolaceShard

August 19, 2019, 12:56:05 AM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsJobsCollaborationsMonocle Engine: Pseudocode Sketches
Pages: 1 [2] 3 4
Print
Author Topic: Monocle Engine: Pseudocode Sketches  (Read 26758 times)
Will Vale
Level 4
****



View Profile WWW
« Reply #20 on: March 10, 2009, 12:59:56 PM »

I've started another thread on RTTI to avoid derailing this one. If you have time, can you elaborate there? I'm curious since my experience is RTTI allows me to write less code with less repetition, but your experience seems to be the exact opposite  Huh?

Cheers,

Will
Logged
Mikademus
Level 10
*****


The Magical Owl


View Profile
« Reply #21 on: March 14, 2009, 05:09:54 PM »

Having developed a zillion engines myself I feel drawn to this thread but at the same time want to stay away from it.

Nonetheless, I think you have some cool ideas in your head but they don't get through in your posts, could you pseudo-code an example game here to show the benefits of this system? For some reason I have a spontaneous reaction that an aggregational system as this seems to be would not be amenable to an MVC anatomy.

Coding style aspects, feel free to ignore:
[spoiler]
Also, for the sake of code standard and maintainability, could you please group the pointer glyph with the symbol rather than the type (MyGoodClass *pGoodHabit rather than MyBadClass* pConfusing)? Further, if you plan to use 3rd party solutions and want a consistent conde style you should start class member names with lower-case. If you wonder why I nag about what might appear like trivialities I'd be happy to provide reasons.
[/spoiler]

[fake_edit]
We don't have [spoiler] tags here?!
Logged

\\\"There\\\'s a tendency among the press to attribute the creation of a game to a single person,\\\" says Warren Spector, creator of Thief and Deus Ex. --IGN<br />My compilation of game engines for indies
medieval
Guest
« Reply #22 on: March 15, 2009, 01:12:44 PM »

[ abbr ] [ /abbr ]

Use that.
Logged
Will Vale
Level 4
****



View Profile WWW
« Reply #23 on: March 15, 2009, 07:08:33 PM »

MVC and components can work together OK - you create the model, view and controller as different components of the entity, and let them see the (appropriately-const) versions of just the components they need to work with.

Code:
class Model;
class View;
class Controller;

class Model : public Component
{
};

class View : public Component
{
    const Model *m_model;
};

class Controller : public Component
{
    Model *m_model;
};

I like MVC, but in general I prefer to encapsulate the input state for a component and have the model pull from that (Controller -> Model -> View) rather than allow the controller to push state to the model. But I'd argue that's just a variation on a theme.

Also, Jim Blinn makes quite a good argument for T* t being preferable to T *t. It's not worth being too draconian about global standards though - projects should choose (and then stick rigidly to) what they're comfortable with.
Logged
makr
Guest
« Reply #24 on: March 16, 2009, 08:25:50 AM »

[EDIT]I am retarded.  I incorrectly assumed Jim Blinn == Mikademus, which lead to confusion about pointer declaration etiquette.[/EDIT]

However, I'm in this thread to hear about high level design discussion about Monocle; I hope everything else can find their way into their own threads.

I'm curious how one would deal with component coupling this type of engine design.  Physics-based components may need to communicate with geometry/transform-based components, etc.  How would something like this be handled?

Mark
« Last Edit: March 16, 2009, 08:40:15 AM by makr » Logged
Snakey
Level 2
**


View Profile WWW
« Reply #25 on: March 16, 2009, 02:26:56 PM »

Hmm, the structure there Will Vale is quite dangerous. Const pointers don't really protect anything. It just means the pointer itself is constant, but the what it's pointing to isn't ... meaning you can still delete what the constant pointer is pointing too.
Logged

I like turtles.
Will Vale
Level 4
****



View Profile WWW
« Reply #26 on: March 16, 2009, 04:08:12 PM »

I'm hesitant to post here again since I don't want to clutter the topic, but it's important to respond to this point. Maybe we need a "C++ issues" thread elsewhere for dealing with this stuff?

Hmm, the structure there Will Vale is quite dangerous.

Can you provide a safer alternative? I think MVC + components is a good idea, so I'd be interested in seeing other ways to combine the two ideas.

Quote
It just means the pointer itself is constant, but the what it's pointing to isn't ...

Maybe you're misreading the code? View::m_model points to a const model. So trying to write to non-mutable members or use non-const methods of *m_model will not compile.

Detail: In the general case, you can still delete through a const pointer, although in my implementation of this sketch, facets *are* protected against deletion by third parties. But in C++ it's always possible to screw things up, the language is in no way a safe sandbox - one of the reasons being a good C++ programmer is not straightforward.

Cheers,

Will

----
Refresher course:

Code:
void test()
{
int foo;
int bar;

// Normal pointer
int *pointer = &foo;

// OK
*pointer = 1;

// OK
pointer = &bar;

// Const pointer
int * const const_pointer = &foo;

// OK
*const_pointer = 1;

// Not OK
const_pointer = &bar;

// Pointer-to-const, int const * is the same thing.
const int *pointer_to_const = &foo;

// Not OK
*pointer_to_const = 1;

// OK
pointer_to_const = &bar;
}

1>d:\work\sil\projects\sil\src\data\test.cpp(22) : error C3892: 'const_pointer' : you cannot assign to a variable that is const
1>d:\work\sil\projects\sil\src\data\test.cpp(28) : error C3892: 'pointer_to_const' : you cannot assign to a variable that is const
Logged
Alec
Level 10
*****



View Profile WWW
« Reply #27 on: March 16, 2009, 08:26:00 PM »

Erm, maybe I haven't explained the direction very well or something. Tongue
Logged

Ryan
Level 1
*



View Profile
« Reply #28 on: March 16, 2009, 11:28:58 PM »

Quote
Erm, maybe I haven't explained the direction very well or something. Tongue

I've been following this and the original thread daily, and the idea seems very interesting.

I've always programmed in a simple way, where my "engines" merely consisted of simple data structures, and simple functions. For example, I had no texture manager, just a Texture struct and a LoadTexture and DeleteTexture function (and later, when I started using C++, a Texture class with a constructor / destructor).

The Object/Component style system seems like a cool, modern direction. Since we seem to not understand fully what you're talking about, I'm looking forward to reading a more in-depth description of what you're describing.

 Hand Money Left Well, hello there! Hand Shake Right

(Also, I seem to have missed when all these new smiley components were added, whoever came up with the idea is a genius.)
Logged
Alec
Level 10
*****



View Profile WWW
« Reply #29 on: March 16, 2009, 11:51:06 PM »

The component system is pretty simple, and its mainly for the high-level user-end programming.

The lower level stuff would be more traditionally structured. (generally speaking)

The component idea is following what works for Unity. There doesn't need to be a lot of communication between components, but there are a couple methods already described in this thread.

For general stuff like say you have a physics and a mesh renderer on the same gameObject, they'd just both reference a common transform object.

If you needed a mesh collider and a mesh renderer to both use the same mesh, you'd just point them at the same mesh object.

Its probably hard to describe to people who haven't used Unity, so I'm not really going to bother until later on in the process. But I think some people are jumping to conclusions that aren't accurate.

I also want to weigh that route against other alternatives by thinking about it for a while. Smiley
Logged

Mikademus
Level 10
*****


The Magical Owl


View Profile
« Reply #30 on: March 17, 2009, 07:14:26 AM »

The component model seems like a C++ adaptation of the mix-in concept. Still, I am deeply habituated to my observer- and visitor-based anatomies, which excellently divide up the code into modules, and would really appreciate an example of a practical component anatomy to understand why it is preferable, and in what situations it would be so.

[abbr]
About the pointer asterisk: the main reason it should always be placed together with the type is to avoid one of the most common bugs, namely "MyClass* inst1, inst2;" This gotcha catches even competent programmers. And yeah, a C++ technicalities thread would probably be advisable.
[/abbr]
Logged

\\\"There\\\'s a tendency among the press to attribute the creation of a game to a single person,\\\" says Warren Spector, creator of Thief and Deus Ex. --IGN<br />My compilation of game engines for indies
Alec
Level 10
*****



View Profile WWW
« Reply #31 on: March 17, 2009, 07:53:59 AM »

The point of what I'm trying to do is set up a system somewhat similar to how Unity functions, (in terms of its component system) because I really like the way it works.

If you haven't used Unity, you might not understand what that means.

Of course it works so well, that I might just be tempted to continue developing games with it rather than making this engine. Smiley

But it feels like there's a place for a cross-platform open source engine that can be setup in a way "somewhat similar" to what Unity does, while still being its own beast and having some other strengths. (and weaknesses)
Logged

Mikademus
Level 10
*****


The Magical Owl


View Profile
« Reply #32 on: March 17, 2009, 09:30:22 AM »

Checked out the Unity web page but it didn't really say much either. Well, if you can't explain it you can't, and no reason for me to push for details. Best of luck.
Logged

\\\"There\\\'s a tendency among the press to attribute the creation of a game to a single person,\\\" says Warren Spector, creator of Thief and Deus Ex. --IGN<br />My compilation of game engines for indies
Alec
Level 10
*****



View Profile WWW
« Reply #33 on: March 17, 2009, 12:37:11 PM »

Checked out the Unity web page but it didn't really say much either. Well, if you can't explain it you can't, and no reason for me to push for details. Best of luck.

I don't want to explain it right now because I want to come up with a good example to illustrate how it works, rather than have the idea ripped apart before its ready to be presented. But I use Unity and like how it works. I was going to put together a demo of how it works on my site for general interest, but there are already a number of videos like that on the 'net.

I'm not in a big rush, so sorry if that ruffles your feathers buddy.
Logged

Snakey
Level 2
**


View Profile WWW
« Reply #34 on: March 17, 2009, 08:28:05 PM »

I also really like the component model as well, as I use this in all of my newer game engines. However, it wasn't Unity that inspired me to do this, rather it was Unreal Engine 3. I've actually just written the latest iteration of my component system last night ... so I'll briefly explain it here with ASCII diagrams (woot!).

Component Tree
Code:
Component -> RenderComponent -> SpriteComponent
          |                  |
          |                  \-> Etc
          \-> Etc

With the component tree, these set of classes just hold data related with their roles. So for example, a RenderComponent may hold a set a rendering data such as scale size, location offset, rotation offset and so forth. The SpriteComponent may hold data that defines what texture is used for the sprite.

Viewport Tree
Code:
Viewport -> OpenGL -> Pathway -> SpritePathway
         |
         \-> DirectX -> Pathway -> SpritePathway
          |
          \-> Etc
These are component implementations. So for which ever type the viewport is, it should have a pathway implementation that handles a specific component. Viewports can also choose to ignore components as well, so, say you have a Geometry Shader component, the OpenGL viewport can ignore this component if OpenGL reports back that it doesn't support it. Depending on the time length of projects, I often write fall back pathways, as well as specialized pathways. Rendering a sprite just involves drawing a camera orientated quad onto the screen. However, this can be done using say, hardware shaders to calculate the vertex positions using a quad vertex array within memory, using OpenGL compiled command lists, vertex buffer objects with CPU camera orientation or just straight OpenGL commands. So, the viewports can adjust which pathway they want to use depending on the hardware. The main benefit of this, is that it is totally transparent to the gameplay programmer and to the user. The user just sees the faster FPS and the gameplay programmer just knows that a sprite will be rendered on the screen.

Actor
Code:
class Actor
{
  hash_map_implementation<std::string, RenderComponent*> m_rendercomponents;
}

This all ties together with Actors. Let's just say that Actors all all class instances which represent entities within the world. Let's say a barrel.

A barrel would subclass an Actor, and to render a sprite to represent itself it would simply need to add a SpriteComponent to it's m_rendercomponents. Actor itself will handle everything else, from rendering it, to management of it, to destroying it.

Let's say you have a super barrel, and all that means is that it has to render another sprite that perhaps shows its glowing or whatever. You would subclass barrel, and then add another SpriteComponent.

Depending on the games complexity, you may require all sorts of other components that handle rendering such as a StaticMeshComponent, VertexMeshComponent, SkeletalMeshComponent, ParticleSystemComponent and so forth. Adding these is some what easy (provided you understand the implementation) but the benefit is totally trivial for the end user (the game developer).

The rendering pass would be somewhat like this,
Application->Viewport->World->[Actor->Render->[RenderComponent->Register]]->Render

So what's going on is the application requests the viewport to render. The viewport can refuse to render of course (because it may not be initialized, or some effect is going on which blacks out the whole screen ... or for any other reason). The viewport then tells the world to 'render', what this means is that the world has calculated what needs to be rendered using the camera and the world entity list (frustrum culling, portal culling, whatever floats your boat) it then asks all of the actors to register their render components. When render components register themselves to the viewport, the viewport copies the data. When all of the components have registered themselves, the viewport then processes the data (it may need to alpha sort, perform extra culling, etc), and then finally using the provided render pathways it will then render the frame.

So far, it's been reasonbly fast with no real performance slow downs, but then again I haven't done crazy testing such as a marching cube performance test. Just to note, this entire system does not use RTTI nor does it have unsafe pointers floating around. All pointers are encapsulated within private classes, and are completely managed, thus gameplay programmers never have to worry about memory leaks (although the engine programmer will have to ... someone has to in the end).

Thats my structure and its benefits, for gameplay programmers and even scripters it can be a real breeze to do anything.
« Last Edit: March 17, 2009, 08:31:38 PM by Snakey » Logged

I like turtles.
Impossible
Level 3
***



View Profile
« Reply #35 on: March 18, 2009, 12:20:49 AM »

Component systems are nice, I really need to get around to refactoring my game objects to be component based.  Alec's original code looks (almost) like it was ripped from Unreal 3 Smiley.  I don't know what Unity's component system looks like under the hood, but it seems a little cleaner than Unreal's.
Logged
Mikademus
Level 10
*****


The Magical Owl


View Profile
« Reply #36 on: March 18, 2009, 03:15:51 AM »

Checked out the Unity web page but it didn't really say much either. Well, if you can't explain it you can't, and no reason for me to push for details. Best of luck.

I don't want to explain it right now because I want to come up with a good example to illustrate how it works, rather than have the idea ripped apart before its ready to be presented. But I use Unity and like how it works. I was going to put together a demo of how it works on my site for general interest, but there are already a number of videos like that on the 'net.

I'm not in a big rush, so sorry if that ruffles your feathers buddy.

No aggression meant and no insult taken, just poorly phrased by me Smiley Sometimes it is simply too difficult to explain things, which is why I asked for a practical example. So no negativity intended. But it you feel interested in trying to explain I can give you my word to listen and try to understand rather than attack to destroy. I have this academic damage to attempt to understand by questioning ideas, which can be perceived as confrontational even though it is not intended that way.

Snakey, thanks for the explanation and illustrations. My spontaneous impression of your system is that it promotes a fine-granular modularity but may be less amenable to high-level modularity, which seems to make it a nice and pleasant-to-work-with framework for not-huge systems. It also seems like some pure iteration overhead is added to each update cycle. So it does seem like the mix-in concept (from f.i. Ruby and Python) in a C++ context.
Logged

\\\"There\\\'s a tendency among the press to attribute the creation of a game to a single person,\\\" says Warren Spector, creator of Thief and Deus Ex. --IGN<br />My compilation of game engines for indies
nihilocrat
Level 10
*****


Full of stars.


View Profile WWW
« Reply #37 on: March 24, 2009, 01:10:31 PM »

So is Alec / the community going to get cracking on this anytime soon? Don't mean to pressure anyone, it just sounds like we should try and gain some momentum. It looks like we know we at least want an object/component model, OpenGL rendering, and homegrown data structures.

After the cockpit compo I will look into at least bringing mangled textured-quad-rendering code to the table for everyone to critique.
Logged

PGGB
Level 8
***



View Profile
« Reply #38 on: March 24, 2009, 02:13:16 PM »

So is Alec / the community going to get cracking on this anytime soon? Don't mean to pressure anyone, it just sounds like we should try and gain some momentum. It looks like we know we at least want an object/component model, OpenGL rendering, and homegrown data structures.

After the cockpit compo I will look into at least bringing mangled textured-quad-rendering code to the table for everyone to critique.
Once the GDC is over I guess it will start taking momentum.
Logged
Alec
Level 10
*****



View Profile WWW
« Reply #39 on: March 28, 2009, 09:05:20 AM »

We have a few different ideas now... Jeff Lindsay has a pretty crazy one that might just work...
Logged

Pages: 1 [2] 3 4
Print
Jump to:  

Theme orange-lt created by panic