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

Your renderer should not have to care about window creation code, which in any case is only a tiny part of your game.

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.

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).

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.

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.