OpenGL (Game) Engine

Started by
10 comments, last by IamDictator 7 years, 12 months ago

Hi All,

I am fairly new to OpenGL and i was wondering if you guys could give me some usefull insights and advice for a project that I am starting.

I am planning on writing a small OpenGL (game) Engine, this includes rendering a scene/meshes (with camera system) and performing some basic logic (maybe simple physics). I have read quite some literature about OpenGL already and had some examples up and running using QT.

QT seemed nice to use, however i dont want to be dependent on a GUI framework like QT. Therefor I want to create a C++ based engine which would handle the rendering and logic and expose an 'API' that can be used by an external GUI framework like QT/WPF/Windowsforms. This way the engine would not be dependent on a GUI framework.

To achieve this I am planning on using the following libraries and wrappers:

- GLEW

For access to modern OpenGL API functions.

- GLFW

For crossplatform OpenGL context creation and handeling input.
- GLM (GL Mathematics)
Vector/matrix mathematics.
The above libraries seem to provide all functionallity to build the Engine, however i could not find any example of GLFW rendering inside Windows forms or WPF (and QT). Is this even possible? Could anyone provide me an example (or link to some literature) about how this can be done (if it can be done)?
Any thoughts or advice is really appreciated, thank you very much,
IamDictator,
Advertisement
Pick a simple game to create. Just building an engine is nebulous. I've done it before, and I just ended up working on cool features that never actually get used. Feature creep was particularly bad. You can definitely still create the engine, but just view it as reusable code for your game projects. You could make a game as simple as 3d pong.

GLFW is its own window and input manager. You will either have to pick one or the other. If you want to go with Qt then this might be useful
http://doc.qt.io/qt-5/qtgui-index.html
My current game project Platform RPG

Pick a simple game to create. Just building an engine is nebulous. I've done it before, and I just ended up working on cool features that never actually get used. Feature creep was particularly bad. You can definitely still create the engine, but just view it as reusable code for your game projects. You could make a game as simple as 3d pong.

GLFW is its own window and input manager. You will either have to pick one or the other. If you want to go with Qt then this might be useful
http://doc.qt.io/qt-5/qtgui-index.html

Thanks, i completely understand what your saying and i agree, but you didnt really answer most of my questions about the libraries.

- GLFW

For crossplatform OpenGL context creation and handeling input.

If you want to be GUI-independent, leave this out of the engine. Focus on rendering and other game systems. Use GLFW for your test programs, but any code in the engine related to context creation or input handling is going to be tied to a GUI system somewhere. By keeping it out of your engine code, you can let the user choose to use GLFW/QT/SDL or whatever and create the context themselves.

Pick a simple game to create. Just building an engine is nebulous. I've done it before, and I just ended up working on cool features that never actually get used. Feature creep was particularly bad. You can definitely still create the engine, but just view it as reusable code for your game projects. You could make a game as simple as 3d pong.

GLFW is its own window and input manager. You will either have to pick one or the other. If you want to go with Qt then this might be useful
http://doc.qt.io/qt-5/qtgui-index.html

Thanks, i completely understand what your saying and i agree, but you didnt really answer most of my questions about the libraries.

That post actually does answer your questions about GLFW -- "GLFW is its own window and input manager." It does provide an API to get the native window handle which you might be able to use to embed the window in some frameworks, but GLFW is primarily intended to create the main window of your application, i.e. if you're using GLFW, you aren't using QT or anything else. That's why I recommend you avoid it in the engine code.

Pick a simple game to create. Just building an engine is nebulous. I've done it before, and I just ended up working on cool features that never actually get used. Feature creep was particularly bad. You can definitely still create the engine, but just view it as reusable code for your game projects. You could make a game as simple as 3d pong.

GLFW is its own window and input manager. You will either have to pick one or the other. If you want to go with Qt then this might be useful
http://doc.qt.io/qt-5/qtgui-index.html

Thanks, i completely understand what your saying and i agree, but you didnt really answer most of my questions about the libraries.

That post actually does answer your questions about GLFW -- "GLFW is its own window and input manager." It does provide an API to get the native window handle which you might be able to use to embed the window in some frameworks, but GLFW is primarily intended to create the main window of your application, i.e. if you're using GLFW, you aren't using QT or anything else. That's why I recommend you avoid it in the engine code.

^^^^^^ This.

I was thinking the same thing. SDL and GLFW are the two popular cross-platform window managers. They handle the interaction of the application with the operating system. Windows, Keyboard, mouse, controllers, file system. Also, they make it "easier" to get an OpenGL context. These things are really hard to get right. GLM is a library for math, and GLEW loads OpenGL extensions for you and checks versions. These things don't make an engine.

The reason everyone around these forums says "Make games not engines" is because trying to start with an engine will only end in 99% of people giving up.

http://geometrian.com/programming/tutorials/write-games-not-engines/

We need new people to make games so we can play them.

I think, therefore I am. I think? - "George Carlin"
My Website: Indie Game Programming

My Twitter: https://twitter.com/indieprogram

My Book: http://amzn.com/1305076532

My favorite tools so I'll be subjective on this.

These are great tools to pick and start building an engine with.

-----

GLFW does not redner into wpf/winforms because it manages its own window by using the win api.

However, you could integrate gl rendering in a win form host.

Kinda silly because you have much better solutions, like OpenTK, using directX, using WPF instead, it has a pretty neat 3D graphics.

Anyhow, I'd stick with GLFW. Build your engine so you could switch between window handleing if you are serious about switching.

GLFW doesn't renders anything. Period. You can create a window with its API on any of the supported platforms, then just request the API specific window handle if absolutely needed. As for handling input for you, any videogame oriented GUI lib wont handle input polling for you, that would be stupid. Instead it will ask you for input events and work with that, where do those input events come from? Thats your job, and one that GLFW covers well.

Also any videogame oriented GUI lib wont render anything by its own, it will handle render commands to you and you'd use them as you see fit.

"I AM ZE EMPRAH OPENGL 3.3 THE CORE, I DEMAND FROM THEE ZE SHADERZ AND MATRIXEZ"

My journals: dustArtemis ECS framework and Making a Terrain Generator

Update:

I have some simple code working using the same rendering Code (Rendering a triangle) for a Win32 project (integratable with c# and WPF) and GLFW project (for quick testing). Thank you guys for the advice, i will keep you updated.

Pick a simple game to create. Just building an engine is nebulous. I've done it before, and I just ended up working on cool features that never actually get used. Feature creep was particularly bad. You can definitely still create the engine, but just view it as reusable code for your game projects. You could make a game as simple as 3d pong.

GLFW is its own window and input manager. You will either have to pick one or the other. If you want to go with Qt then this might be useful
http://doc.qt.io/qt-5/qtgui-index.html

I'd have to disagree with the notion of just building a simple game. If you're going to build an engine to make a game, you won't run into that situation if you know what the bare minimum is that the engine -must- support for your game to run, and stick to only developing those parts.

Hi All,

I am fairly new to OpenGL and i was wondering if you guys could give me some usefull insights and advice for a project that I am starting.

I am planning on writing a small OpenGL (game) Engine, this includes rendering a scene/meshes (with camera system) and performing some basic logic (maybe simple physics). I have read quite some literature about OpenGL already and had some examples up and running using QT.

QT seemed nice to use, however i dont want to be dependent on a GUI framework like QT. Therefor I want to create a C++ based engine which would handle the rendering and logic and expose an 'API' that can be used by an external GUI framework like QT/WPF/Windowsforms. This way the engine would not be dependent on a GUI framework.

To achieve this I am planning on using the following libraries and wrappers:

- GLEW

For access to modern OpenGL API functions.

- GLFW

For crossplatform OpenGL context creation and handeling input.
- GLM (GL Mathematics)
Vector/matrix mathematics.
The above libraries seem to provide all functionallity to build the Engine, however i could not find any example of GLFW rendering inside Windows forms or WPF (and QT). Is this even possible? Could anyone provide me an example (or link to some literature) about how this can be done (if it can be done)?
Any thoughts or advice is really appreciated, thank you very much,
IamDictator,

Those libraries are relatively low level. You're not going to find some literature telling you how to use them to make a game engine. But you can actually look at other engines to see how they work it.

I think nebula trifid makes use of it. https://github.com/gscept/nebula-trifid

The code base is actually really clean (surprisingly), and easy to understand. However they tend to generate things at compile time so it's logic system is really difficult to understand.

This topic is closed to new replies.

Advertisement