Sign in to follow this  
ashstampede

OpenGL OpenGL render type for game engine question

Recommended Posts

OK, i have a architectural design for a game i want to do, that i will post else where as i have not finalized and will want some suggestions. but the question is for my opengl render, I truly would like it to be platform depended but i will be soly doing it under windows so at lease i want to be able to do minimal rewrite when and if i ever get a mac again. so my question is, should my opengl be used with glut and opengl, or opengl and windows. I.E. instead of glut handling the creation of the game window and resizing etc or usinging the windows system and opengl to create everything. Is there any true benifit for either? the tutorials i am running through are glut based but i just wondered when it truly started to matter, where models and a game world exsist. which should me render be built off

Share this post


Link to post
Share on other sites
ok so then using glut and simply fullscreen is all that is needed, i guess i was just worried if some how a performance hit in anyway could happen based on those choices.

Share this post


Link to post
Share on other sites
Just write it in such a way that you can replace the Window creation code, and you can replace it with native versions if it ever becomes a problem (which I don't think it will, but I don't use GLUT so I don't know for sure).

Share this post


Link to post
Share on other sites
If you're writing your engine in a object oriented fashion, then your renderer should not take care of the window creation...

you should have a renderer interface with an opengl implementation of that interface. then a window/renderable/drawable/whatever you prefer interface with an implementation for each system you want your engine to run on.

for exemple in my engine, I have a Renderable interface, and a RenderableWGLWin (windows), RenderableGLXWin (linux X11), RenderableSDL (using SDL for other platforms), RenderableGTKGLArea (for inserting the engine in a gtk window)...I even have a RenderableFBO to do rendertotexture...

my Renderer itself is platform independent, it does not care on which Renderable it is rendering on.

Share this post


Link to post
Share on other sites
Mawww, I have but one question; why all those classes?

imo you've over engineered the problem;

Take all your platform renderables; they all impliment the 'Renderable' interface, yes? So they all have the same functions just platform specific functionality?

Now, assuming that each of these requires the application to be compiled for the target OS, why not simply have ONE class which gets selected by the build enviroment? So building for Windows; at build time you'd include the .cpp file which handles Win32 window setup. Building for OS X you include the .cpp file which handle OS X window setup, and so on. Any commonality between them can be pulled into a common.cpp which is compiled whatever.

As for the RenderableFBO, I'm not convinced. While a renderable target is a good thing it doesn't do the same thing as the other 'rendables' which setup physical windows (or attach to them), this manages 'virtual' render targets if anything.

At best you'll want a render target class which represents the default framebuffer, although you could just include a 'rtt::disable()' function in the class which swaps back to the default framebuffer.

This way you get rid of a class heirachy which already contained unrelated functionality while maintaining the overall functionality. Your 'renderable' systems is only really useful if you can switch between window creation types at runtime, which you plainly can't do based on your descriptions.

Share this post


Link to post
Share on other sites
Quote:
Original post by Mawww
If you're writing your engine in a object oriented fashion, then your renderer should not take care of the window creation...

you should have a renderer interface with an opengl implementation of that interface. then a window/renderable/drawable/whatever you prefer interface with an implementation for each system you want your engine to run on.

for exemple in my engine, I have a Renderable interface, and a RenderableWGLWin (windows), RenderableGLXWin (linux X11), RenderableSDL (using SDL for other platforms), RenderableGTKGLArea (for inserting the engine in a gtk window)...I even have a RenderableFBO to do rendertotexture...

my Renderer itself is platform independent, it does not care on which Renderable it is rendering on.


I don't like this approach at all. A render target and a window have very little in common at all - one manages a drawing target, and one manages an OpenGL context.

For my engine, there is a ContextProvider which supports only querying the width and height of the context, and swapping the buffers. Then there is a RenderTarget class, which targets either the default framebuffer, an FBO (for render-to-texture), or a viewport on another renderTarget. This way we have separated out the functionality in a sensible manner, and by making ContextProvider generic, we can also have multiple contexts (for tools with several views embedded in native controls, etc.).

Share this post


Link to post
Share on other sites
well there are tons of suggestions here, since i only need a baisc render as i'm not focusing on graphics since i really dont have any for my game and its basically going to be place holders, place holders, place holders.

I am going to take the approach of lightbringer and phantom's suggestions, to have a windows creation class/.cpp file for the platform. I really was just trying to get a guage on if it really mattered at the end of the day on what you do for the windows creation part as I know the render is dependent of the OS. I suppose i wasnt very clear.

Share this post


Link to post
Share on other sites
Quote:
Original post by ashstampede
I am going to take the approach of lightbringer and phantom's suggestions, to have a windows creation class/.cpp file for the platform. I really was just trying to get a guage on if it really mattered at the end of the day on what you do for the windows creation part as I know the render is dependent of the OS. I suppose i wasnt very clear.

I am afraid that is not quite correct. The Renderer is *not* platform dependant (some platforms only support one rendering API, but not all). The Windowing code however is.

And really, they have nothing to do with each other. One is just a context to render into, and the other actually manages the details of how to render.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this