Skip to main content
added 131 characters in body
Source Link
LaVolpe
  • 1.8k
  • 3
  • 13
  • 18

I think you miss the point of what an engine is a little bit.

Game engines are developed in order to make game creation easier, without having the users of the engine to take care of complex low-level APIs. Therefore I would manage OpenGL resources internally, inside the engine.

So, let's go through your points.

  1. It depends on how you build your system. In my tiny render engine(s) I used to have factories (Factory-Pattern) which created the resources for me. Thus it wasn't even possible for me to create a resource without having the factory instantiated. For example, you could create a OpenGL context class, which is acting as a factory for resources as well.

  2. I don't get this point. As someone who wants to develop a game engine, you should aim for making game creation easier and more streamlined.

  3. I would take into consideration, that one would create 2 or more windows with a context. This doesn't necessarily mean that each window should have its own context. One context can be shared across multiple windows. However, you can render only to one window at one time.

  4. About multi threading and OpenGL: Just don't. I assume, that you want to issue multiple drawcalls from multiple threads. A OpenGL context is bound to a certain thread, usually by the '*MakeCurrent' calls exposed by the windowing systems. Multi threading won't buy you much using OpenGL. For more, just read here: https://www.opengl.org/wiki/OpenGL_and_multithreadinghere.

Disclaimer: I am not a professional graphics engineer. My complete knowledge is self-taught using the reference or sites like SO.

EDIT: I forgot the obligatory "Write games, not engines!"

I think you miss the point of what an engine is a little bit.

Game engines are developed in order to make game creation easier, without having the users of the engine to take care of complex low-level APIs. Therefore I would manage OpenGL resources internally, inside the engine.

So, let's go through your points.

  1. It depends on how you build your system. In my tiny render engine(s) I used to have factories (Factory-Pattern) which created the resources for me. Thus it wasn't even possible for me to create a resource without having the factory instantiated. For example, you could create a OpenGL context class, which is acting as a factory for resources as well.

  2. I don't get this point. As someone who wants to develop a game engine, you should aim for making game creation easier and more streamlined.

  3. I would take into consideration, that one would create 2 or more windows with a context. This doesn't necessarily mean that each window should have its own context. One context can be shared across multiple windows. However, you can render only to one window at one time.

  4. About multi threading and OpenGL: Just don't. I assume, that you want to issue multiple drawcalls from multiple threads. A OpenGL context is bound to a certain thread, usually by the '*MakeCurrent' calls exposed by the windowing systems. Multi threading won't buy you much using OpenGL. For more, just read here: https://www.opengl.org/wiki/OpenGL_and_multithreading

Disclaimer: I am not a professional graphics engineer. My complete knowledge is self-taught using the reference or sites like SO.

I think you miss the point of what an engine is a little bit.

Game engines are developed in order to make game creation easier, without having the users of the engine to take care of complex low-level APIs. Therefore I would manage OpenGL resources internally, inside the engine.

So, let's go through your points.

  1. It depends on how you build your system. In my tiny render engine(s) I used to have factories (Factory-Pattern) which created the resources for me. Thus it wasn't even possible for me to create a resource without having the factory instantiated. For example, you could create a OpenGL context class, which is acting as a factory for resources as well.

  2. I don't get this point. As someone who wants to develop a game engine, you should aim for making game creation easier and more streamlined.

  3. I would take into consideration, that one would create 2 or more windows with a context. This doesn't necessarily mean that each window should have its own context. One context can be shared across multiple windows. However, you can render only to one window at one time.

  4. About multi threading and OpenGL: Just don't. I assume, that you want to issue multiple drawcalls from multiple threads. A OpenGL context is bound to a certain thread, usually by the '*MakeCurrent' calls exposed by the windowing systems. Multi threading won't buy you much using OpenGL. For more, just read here.

Disclaimer: I am not a professional graphics engineer. My complete knowledge is self-taught using the reference or sites like SO.

EDIT: I forgot the obligatory "Write games, not engines!"

Source Link
LaVolpe
  • 1.8k
  • 3
  • 13
  • 18

I think you miss the point of what an engine is a little bit.

Game engines are developed in order to make game creation easier, without having the users of the engine to take care of complex low-level APIs. Therefore I would manage OpenGL resources internally, inside the engine.

So, let's go through your points.

  1. It depends on how you build your system. In my tiny render engine(s) I used to have factories (Factory-Pattern) which created the resources for me. Thus it wasn't even possible for me to create a resource without having the factory instantiated. For example, you could create a OpenGL context class, which is acting as a factory for resources as well.

  2. I don't get this point. As someone who wants to develop a game engine, you should aim for making game creation easier and more streamlined.

  3. I would take into consideration, that one would create 2 or more windows with a context. This doesn't necessarily mean that each window should have its own context. One context can be shared across multiple windows. However, you can render only to one window at one time.

  4. About multi threading and OpenGL: Just don't. I assume, that you want to issue multiple drawcalls from multiple threads. A OpenGL context is bound to a certain thread, usually by the '*MakeCurrent' calls exposed by the windowing systems. Multi threading won't buy you much using OpenGL. For more, just read here: https://www.opengl.org/wiki/OpenGL_and_multithreading

Disclaimer: I am not a professional graphics engineer. My complete knowledge is self-taught using the reference or sites like SO.