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

Author Topic: Groogy's Game Engine  (Read 26027 times)

0 Members and 1 Guest are viewing this topic.

Groogy

  • Hero Member
  • *****
  • Posts: 1469
    • MSN Messenger - groogy@groogy.se
    • View Profile
    • http://www.groogy.se
    • Email
Groogy's Game Engine
« on: June 21, 2011, 08:20:56 pm »
GG Engine - Groogy's Game Engine
Groogy's Game Engine is a multi-threaded 3D game engine I have been working on for the past year. I don't got much of imagination when it comes to names so I named it to Groogy's Game Engine but lucky enough it's acronym results into GG Engine, GG which is also an acronym for Good Game.

So what's so good about it? Well I've tried to make the complex and hard things to be simple to work with. For instance threading in the SDK is non-existent for the user and does not need to concern himself about it at all. Most of the 3D math for rendering is also handled internally by the engine and most optimisations that needs to be done will be hidden behind the public API. What will be in focus is to make a game and not a decent frame rate or how things are culled by a frustum.

The Users
Who is this aimed at? Well I made it for use by myself but who knows there might be someone else that want to jump straight into game making without having to worry about multi threading, model loading, skeleton animation, efficient culling and the like.

Features
Here's a list of the features that it currently support:
  • Seamless multi-threaded input, logic, rendering. The user only need to define the logics.
  • Nice wrap around OpenGL for 3D rendering.
  • Nice wrap around SFML for Windowing, Input and 2D Rendering.
  • Object-oriented interface to rendering.
  • Instance-Model Graphs.
  • Wavefront Object and Material file parsing.
  • Helper Design Patterns like Singleton, Component-based Objects, Observer Objects, etc. etc. (These are added overtime, not all have been made yet)
  • Resource Management.
  • Flexible post master system(though I call it signals)
  • Vector and Matrix classes for 3D uses.
  • An Orientation class that makes Matrixes and Vector's easier to use for newcommers to 3D math.
  • Automatic Frustrum against Oct-tree culling for rendering thread.
  • Easy to implement and use debug information at runtime.
And a list for things that is planned to be implemented:
  • Generate bounding boxes when loading a model.
  • A modifiable origin for 3D objects.(Kind of like sprites in SFML)
  • Skeleton Animations.
  • An interface that is easier to work against
  • System to handle configurations and parsing from a file or maybe the OS.
  • State stack with some predefined states.
  • Properly pass material parameters to OpenGL for use in shaders.
  • Lighting interface to the rendering thread.
  • Allow object-specific shaders.
  • Shader function library for common used things.
What I am thinking about but is not my highest priority:
  • Encapsulate SFML entirely so the user don't even need to know that SFML is used.
  • Bindings to ruby, since only one thread is exposed to the user it's perfect.
  • Base GUI system.
  • Plugin system.
  • Rendering Optimization, currently everything is rendered intermediate.
  • Dynamical Destructible Objects(Won't look good but can be disabled)
Example
An example that will render a sprite and a rotating 3D model on screen. Will handle the even that the window closes and also let's you move around in the 3D world.
Code: [Select]
#include <GGE/Application/Application.hpp>
#include <GGE/Application/ApplicationLogics.hpp>
#include <GGE/Application/Sprite.hpp>
#include <GGE/Application/Text.hpp>
#include <GGE/Application/Object.hpp>
#include <GGE/Application/Camera.hpp>
#include <GGE/Application/BasicCameraController.hpp>

class MyApplication : public GGE::ApplicationLogics, GGE::Signals::Receiver
{
public:
MyApplication()
{
myRotation = 0;
GetSignalSender().SubscribeReceiver( this, "Signal.Window.Quit" );

GetSignalSender().SubscribeReceiver( &myPlayer, "Signal.Mouse.Moved" );
GetSignalSender().SubscribeReceiver( &myPlayer, "Signal.Keyboard.Pressed" );
GetSignalSender().SubscribeReceiver( &myPlayer, "Signal.Keyboard.Released" );
}

~MyApplication()
{
GetSignalSender().UnsubscribeReceiver( this, "Signal.Window.Quit" );
}

void Initiate()
{
GGE::Graphics::TextureHandle texture = GGE::Graphics::TextureManager::Instance().Get( "resources/hal-9000-eye.jpg" );
GGE::Graphics::ModelHandle model = GGE::Graphics::ModelManager::Instance().Get( "resources/TexturedCube.obj" );

myTestText = GGE::Interface::Text( "test.text" );
myTestText.SetString( "Hello World!" );
myTestText.EnableRender();

myTestSprite = GGE::Interface::Sprite( "test.sprite" );
myTestSprite.SetTexture( texture );
myTestSprite.SetScale( 0.5f, 0.5f );
myTestSprite.SetPosition( 100, 100 );
myTestSprite.EnableRender();

myTestObject = GGE::Interface::Object( "test.object" );
myTestObject.SetModel( model );
myTestObject.EnableRender();

GetContext().GetCamera().SetPosition( 0, 0, 10 );
myPlayer.SetCamera( GetContext().GetCamera() );
}

void Update( const sf::Uint32 aDelta )
{
myRotation += aDelta / 1000.f;
myTestObject.SetRotation( 0, myRotation, 0 );

myPlayer.Update( aDelta );
}
private:
bool ReceiveSignal(const GGE::Signals::Base &aSignal)
{
if( aSignal.GetType() == "Signal.Window.Quit" )
{
GGE::Application::Instance().Exit();
return true;
}
return false;
}

GGE::Interface::Text myTestText;
GGE::Interface::Sprite myTestSprite;
GGE::Interface::Object myTestObject;
GGE::Utilities::BasicCameraController myPlayer;
float myRotation;
};

int main()
{
   GGE::Application::Create( new MyApplication() );
   GGE::Application::Instance().MainLoop();
   GGE::Application::Release();
   return 0;
}

The SDK
Alright I would say an alpha version has been released now: https://github.com/Groogy/GGE
So far everything to my knowledge works and it's stable.
A lot of more features will be implemented. If you feel "I need this thing now" then just give me a message about it and I'll implement it as fast as  I can.

Documentation
Groogy's Game Engine Tutorial 1 - Introduction: Youtube, Download
Groogy's Game Engine Tutorial 2 - Getting Started Part 1: Youtube, Download
Groogy's Game Engine Tutorial 2 - Getting Started Part 2: Youtube, Download part 1, Download part 2
Groogy's Game Engine Tutorial 3 - Drawing 3D: Youtube, Download part 1, Download part 2

Questions & Suggestions
I am very happy to answer any questions or listen to suggestions you might have. You can ask/suggest privately or here in the thread. Of course you can also send me a message on Github or use any of the great tools Github provides for communication.
Developer and Maker of rbSFML and Programmer at Paradox Development Studio

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6286
  • Thor Developer
    • View Profile
    • Bromeon
Groogy's Game Engine
« Reply #1 on: June 21, 2011, 09:02:10 pm »
Cool project! It seems like game engines are the most recent trend :D

Quote from: "Groogy"
Nice wrap around OpenGL for 3D rendering.
Of which abstraction level do you speak here? And isn't this a giant effort, especially when such wrappers have already been written again and again? ;)

By the way, which libraries do you use internally?
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

Groogy

  • Hero Member
  • *****
  • Posts: 1469
    • MSN Messenger - groogy@groogy.se
    • View Profile
    • http://www.groogy.se
    • Email
Groogy's Game Engine
« Reply #2 on: June 21, 2011, 09:09:27 pm »
Quote from: "Nexus"
Cool project! It seems like game engines are the most recent trend :D

Yeh but I started this project because of the second year in my University we will be developing 3D games and it would be nice to have a complete engine by that time.

Quote from: "Nexus"
Quote from: "Groogy"
Nice wrap around OpenGL for 3D rendering.
Of which abstraction level do you speak here? And isn't this a giant effort, especially when such wrappers have already been written again and again? ;)

Well don't know really, since all OpenGL calls are handled in the rendering thread which is completely hidden from the user. The interface consists of a couple of classes which are probably not complete. The Context class which represents a render target/context, like Window or Image. A Renderer class that handles actual rendering to a Context. ShaderProgram class and associated VertexShader and FragmentShader class for writing shaders. And then there is the Object and Model classes for actually representing the 3D Geometrics. Though most of these things are handled trough interface classes in the logic thread so you don't directly affect opengl.

To give a better example, for instance to set opengl to only render lines between vertexes instead of fill you don't say that directly but does instead a call of "context.ShowWireframe()".
So actually it doesn't need to be OpenGL behind it all, it's pretty abstracted from OpenGL so it can be changed.

Quote from: "Nexus"
By the way, which libraries do you use internally?

SFML, OpenGL and GLEW I guess... That's the only ones.
Like I said it was intended for my school project and it's a requirement from the school that the games are done with no middleware so I try to keep away as many libraries I can.
Developer and Maker of rbSFML and Programmer at Paradox Development Studio

Groogy

  • Hero Member
  • *****
  • Posts: 1469
    • MSN Messenger - groogy@groogy.se
    • View Profile
    • http://www.groogy.se
    • Email
Groogy's Game Engine
« Reply #3 on: June 23, 2011, 01:39:23 am »
Alright the interface is shaping up, got something I need to look over at the signal module as it's pretty clumsy to add a new type of signal at the moment. Though I have no idea on how to improve it.

All that is left after that is to put everything in GGE namespace and maybe move around the classes a little to organize the chaos better.

Thinking about using Cmake depending on how hard it is to learn and how you actually use it on the developer side. Laurent got any special tutorial sites to recommend or their main-site give enough information?

Updated the example to also show how to listen for signals and a pre-made controller class for the camera.
Developer and Maker of rbSFML and Programmer at Paradox Development Studio

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Groogy's Game Engine
« Reply #4 on: June 23, 2011, 07:39:33 am »
Quote
Laurent got any special tutorial sites to recommend or their main-site give enough information?

Copy-n-paste from other projects is the best way to get something working :D
The basics are easy to learn, but then you need a lot of tweaking to get what you want.
Laurent Gomila - SFML developer

Alejandro

  • Newbie
  • *
  • Posts: 27
    • View Profile
Groogy's Game Engine
« Reply #5 on: June 23, 2011, 08:33:40 am »
Will it be possible to use only parts (modules) of the engine, without having to initialize everything else?

For example I would want to use your 3D rendering procedures as I haven't found something that would work with SFML in an easy way. Could I just initialize the renderer, define the object which I want to render and just put the rendering line between my 2D rendering code in SFML?

I am very happy with the input and other logic in SFML, just want to be able to kick in some 3D drawings, without having to learn how to use a new framework for things that are already implemented in SFML.

Groogy

  • Hero Member
  • *****
  • Posts: 1469
    • MSN Messenger - groogy@groogy.se
    • View Profile
    • http://www.groogy.se
    • Email
Groogy's Game Engine
« Reply #6 on: June 23, 2011, 12:55:58 pm »
Hmm yes you would. Actually no initialization would be needed you would only need to do this I think:
Code: [Select]

#include <SFML/Graphics.hpp>
#include <GGE/Graphics/Context.hpp>

int main()
{
        sf::RenderWindow window( sf::VideoMode( 800, 600 ), "My GGE Project" );
        GGE::Graphics::WindowContext context( window );
        /* All done for rendering now */
        return 0;
}


There is also GGE::Graphics::ImageContext for sf::RenderImage.

I am not sure but I think that should be enough. The Graphics module only dependency should be the Utility module because of the core class for resource management.

Quote
For example I would want to use your 3D rendering procedures as I haven't found something that would work with SFML in an easy way. Could I just initialize the renderer, define the object which I want to render and just put the rendering line between my 2D rendering code in SFML?

You should do all the 2D rendering trough the context provided through the library as it handles SFML sf::Drawables too and it makes sure that all settings are properly set for the 2D to be drawn(SFML misses to set and reset some states)
Developer and Maker of rbSFML and Programmer at Paradox Development Studio

Alejandro

  • Newbie
  • *
  • Posts: 27
    • View Profile
Groogy's Game Engine
« Reply #7 on: June 23, 2011, 01:42:07 pm »
Thank you for the quick and accurate answer. In this case I will have to wait a little more before writing any library dependent code for my project as I hope I will become one of the first users of your engine :)

Groogy

  • Hero Member
  • *****
  • Posts: 1469
    • MSN Messenger - groogy@groogy.se
    • View Profile
    • http://www.groogy.se
    • Email
Groogy's Game Engine
« Reply #8 on: June 23, 2011, 03:26:54 pm »
Quote from: "Alejandro"
Thank you for the quick and accurate answer. In this case I will have to wait a little more before writing any library dependent code for my project as I hope I will become one of the first users of your engine :)


Glad to hear it, but just so you know what I will be releasing is the developing version. I am not quite done yet :P Things that is not complete yet are more advanced stuff like materials and so on. I'm still learning how this works and tries to figure out how I am supposed to link a Wavefront material to a shader? There are so many values there that I have no clue about!

But if you only want to render 3D models and apply a texture to them at this point of time, then this engine will be more than enough :)

Anyway the public interface won't change much, for instance material values I don't know what to do with I silently ignore but still parse. So when those values are supported properly you won't notice a thing :)

When you start and you got any special requests then feel free to give them to me and I'll try and fix it. Since I'll create a github repo for it you could use the issue tracker.
Developer and Maker of rbSFML and Programmer at Paradox Development Studio

Alejandro

  • Newbie
  • *
  • Posts: 27
    • View Profile
Groogy's Game Engine
« Reply #9 on: June 23, 2011, 06:02:58 pm »
At the current point of development for me it will be more than enough to be able to load a 3D model and render it with textures. By the time I need skeletal animation (which will also probably support attached objects to the model; if not I doubt it will be hard to code, since the joints' position could be known) it would have been implemented a thousand times over :D and I will only need to change a few lines of code to implement it.

My current aim is to link all the libraries I will be using in the project from the beginning so that once I have started dealing with logic, networking, input, rendering and whatnot I won't have to worry about things like incompatible libraries with my compiler or having to drastically change the way I manage everything in the game.

Groogy

  • Hero Member
  • *****
  • Posts: 1469
    • MSN Messenger - groogy@groogy.se
    • View Profile
    • http://www.groogy.se
    • Email
Groogy's Game Engine
« Reply #10 on: June 23, 2011, 07:36:19 pm »
Of course for the skeletal animation there will be an application that will let you define the hierarchy and assign joints between meshes and so on. Though that might take some time before I get that one done so the skeletal animation system will be available before that.
Developer and Maker of rbSFML and Programmer at Paradox Development Studio

Groogy

  • Hero Member
  • *****
  • Posts: 1469
    • MSN Messenger - groogy@groogy.se
    • View Profile
    • http://www.groogy.se
    • Email
Groogy's Game Engine
« Reply #11 on: June 27, 2011, 06:55:19 am »
I have new found respect for you Laurent... Tried with just stealing your Cmake config files right off and it still felt like I went trough hell and back. Can't imagine how it must have been making those for hand. Or maybe it's just me that has a problem with it :P

Anyway just finished the Cmake build system for GGE and it works even though it feels a bit inflexible for how it finds the SFML library to link with.
Also it has only been tested out on Windows using Visual Studio 2010 so far so don't know if it will be able to generate properly to any other system.

Yet again, Laurent I tip my hat for you.
Developer and Maker of rbSFML and Programmer at Paradox Development Studio

Groogy

  • Hero Member
  • *****
  • Posts: 1469
    • MSN Messenger - groogy@groogy.se
    • View Profile
    • http://www.groogy.se
    • Email
Groogy's Game Engine
« Reply #12 on: June 27, 2011, 06:02:13 pm »
Hmm having some problem with my template classes. Can't import them properly into my example application or something I don't know. Anyway it's my singleton class that looks like this:
Code: [Select]

template< class Class >
class Singleton
{
public:
static void Create();
static void Release();
static Class &Instance();

protected:
static Class *ourInstance;

Singleton();
virtual ~Singleton();
};

template< class Class >
void GGE::Utilities::Singleton< Class >::Create()
{
SAFE_DELETE( ourInstance );
ourInstance = new Class();
}

template< class Class >
void GGE::Utilities::Singleton< Class >::Release()
{
SAFE_DELETE( ourInstance );
}

template< class Class >
Class &GGE::Utilities::Singleton< Class >::Instance()
{
return *ourInstance;
}

template< class Class >
GGE::Utilities::Singleton< Class >::Singleton()
{
}

template< class Class >
GGE::Utilities::Singleton< Class >::~Singleton()
{
}

template< class Class >
Class *GGE::Utilities::Singleton< Class >::ourInstance = NULL;


The error's I'm getting are:
Quote
Error   2   error LNK2001: unresolved external symbol "protected: static class GGE::Application * GGE::Utilities::Singleton<class GGE::Application>::ourInstance" (?ourInstance@?$Singleton@VApplication@GGE@@@Utilities@GGE@@1PAVApplication@3@A)   C:\Users\Groogy\Documents\Work\GGE\VS2010\examples\helloworld\HelloWorld.obj


The thing is that the frameworks Application class inherits from the Singleton class, how do I get that static member variable to be linked with the DLL? Gaaah these Windows specific things are driving me crazy.

The definition of Application looks like this:
Code: [Select]
class GGE_API Application : public Utilities::Singleton< GGE::Application >

Why does Windows have such a problem with keeping things simple....
Anyone out there that could lend me a helping hand?

UPDATE: I have a few other classes inheriting from Singleton that is also used in the example(resource managers) and they work perfectly without complaint. So checked what the difference is, and it's this function I added before to give a simple way for the user to hijack the logic class.
Code: [Select]
template< class LogicsClass >
static void Create()
{
SAFE_DELETE( ourInstance );
ourInstance = new GGE::Application( new LogicsClass() );
}


Don't know how this would make the linker freak out.
Developer and Maker of rbSFML and Programmer at Paradox Development Studio

Groogy

  • Hero Member
  • *****
  • Posts: 1469
    • MSN Messenger - groogy@groogy.se
    • View Profile
    • http://www.groogy.se
    • Email
Groogy's Game Engine
« Reply #13 on: June 27, 2011, 07:36:48 pm »
Got it to work in a non-optimal way so would still like to have the previous post solved.

Anyway this new post is to announce that I will release the engine on Sunday(3rd July) and until then I will just add some more stuff like allowing the user to change rendering context on the run, change title on the window, set fullscreen and so on trough the logic thread.

These changes are will add a new interface class so I would like to squeeze them in before releasing my Alpha version.
Developer and Maker of rbSFML and Programmer at Paradox Development Studio

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6286
  • Thor Developer
    • View Profile
    • Bromeon
Groogy's Game Engine
« Reply #14 on: June 27, 2011, 07:39:55 pm »
Quote from: "Groogy"
Why does Windows have such a problem with keeping things simple....
I don't think this is a Windows-specific problem. Defining static variables in templates works perfectly, you don't have to export them since templates are header-only. Of course, the variable definition must be located in a header file.

By the way, why don't you use a proper smart pointer instead of that ugly SAFE_DELETE? And why can't the singleton initialize and destroy itself?
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development: