Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 09 Nov 2010
Offline Last Active Jan 10 2016 02:40 AM

Posts I've Made

In Topic: Inversion of control across libraries

08 November 2015 - 05:14 PM

Why can EngineLib not be dependant? Would you ever use engine without graphics and physics? If so, perhaps the stuff that is common to both graphics and physics can be broken out into it's own lib?


I'm not an expert by any means, but i have dealt with an issue similar to what i think you are describing. I bundled up anything math related into it's own library. The graphics library objects includes the headers it needs from this, and the physics library behaves the same way. The engine includes the graphics, physics, and math headers, and the application being worked on includes the engine headers. Since the actual translation units exist only once in their respective libs, I have no issues including each library into the application.


I've even kept the graphics library as agnostic as possible, and created one library that implements a dx9 version(which is what all of my existing code was based on), and another for DX11(which i have slowly been implementing), and yet another for gl4(which i've barely done anything with. The engine only knows about the base graphics library, while the app has the choice of including/linking to the implementation it wants.

#include "GraphicsDX9.h"
App game(new GraphicsEngineDX9( ... ), new PhysicsEngine(...), new InputEngine(...));

GraphicsEngineBase * renderer = game.GetGraphics();

// or

#include "GraphicsGL4.h"
App game(new GraphicsEngineGL4( ... ), new PhysicsEngine(...), new InputEngine(...));

GraphicsEngineBase * renderer = game.GetGraphics();

// etc

Yes it's a bit of the PITA, but it works well enough for what i need.

Yes, this sounds a lot like what I am trying to do. My confusion comes from the three separate libraries in your example (Engine lib, GraphicsGL4 lib, and the Graphics DX9 lib) all needing to know of some kind of abstract/interface GraphicsEngine class. In your example it looks like App game's constructor take some kind of abstract GraphicsEngine pointer, so app must know of this abstract class. In that case GraphicsEngineDX9 and GraphicsEngineGL4 must both also know about this abstract class, as they would be children of it so they can be passed into that constructor. Each of these classes are in different libraries though, so where does this abstract class exist? Does a copy of it just exist in all the libraries? If it exists in the Engine so that App can use it in its constructor, then how will GraphicsEngineDX9 or GraphicsEngineGL4 know about it? If it exists in GraphicsEngineDX9 then the engine would contain it since it contains the GEDX9 Lib, but then would a copy of it have to exist in GEGL4? That seems a little odd to me, but maybe it is fine? Perhaps I'm just missing some concept of abstract classes that is important here?



"Since the actual translation units exist only once in their respective libs, I have no issues including each library into the application." 

There might be something I'm missing in what you are saying though, because I'm not entirely sure what you mean by "translation unit."

In Topic: Communication between objects and systems in Game engines.

21 May 2015 - 01:50 AM

I am liking the idea of the higher level code with knowledge of both ideas, and then keeping the actual character in the dark about everything, seems to be what most of you are suggesting too. So if I'm getting this right, the player itself will basically just be a block of data, it has some render information, its transform, and maybe some collider information, but it doesn't really do anything. Then I have some higher level systems like one for keeping objects grounded that has information about the physics world. the gamestate passes everything that needs to be effected by this system to it, all the players/npc's etc. Another example could be like... a player controller that tells the player to move based on input or something. Nothing is actually done by the character, only by things who's purpose is telling the player to do things. 



write games, not engines

Yeah haha, this is something I'm trying to push on myself, it's so easy to get lost in the idea of engine construction and completely forget about what you wanted to use the engine to make. I'm just making small scale 2D stuff too, so I really don't need to go overboard on engine construction.

In Topic: Smoothing out the ray tracing of a surface on a curve

16 October 2013 - 05:14 PM

For the hover mechanic, I shoot a raycast straight down from the center of the ship, if the distance from the start of the ray to where the ray hits is shorter then a specific amount it moves it back up to the minimum distance. As for the physics engine, It seems as though Unity uses the PhysX engine. Unfortunately I can't give you specific pieces of code right now as I am not at my house, but when I return there I will put up some more info on how I am doing everything. I think this first suggestion AllEightUp gave will probably do the trick though! Thanks very much for your input. I'm also thinking of doing something like what rumblesushi suggested, I'm thinking having a raycast at the middle, nose, and back, all checking would probably be best.

In Topic: Depth Transparecy issues.

19 June 2013 - 03:35 AM

So I literally need to just make sure that when something is rendered it is rendered before everything that it needs to cover?

In Topic: Rotation in 3D

15 June 2013 - 02:30 PM

Inverting it seems to have fixed everything! Thanks so much.