Jump to content
  • Advertisement
Sign in to follow this  
  • entries
  • comments
  • views


Sign in to follow this  


So, lacking anything better todo... or at least anything I wanted todo [grin] I decided to take a look at recoding the OGLWFW to work sanely with multiple monitors.

The first hurdle to get across was how the hell do I go about this [wink]

You see, up until now you could just pass in a struct which represnted display details and it would change the display to those settings, you could also give raw numbers and a monitor id number (which didn't do anything).

However, upon thinking about this for a while it didn't seem overly sane; supposing you had two monitors and they had different modes to they could with, just throwing numbers at them doesn't seem sane to me.

So, I had a think about this and came up with the idea of a monitor/display owning a set of display properties so that you could query for them and then pass an object back to the manager to say "this is the display mode I want".

So, the mode query function now returns a vector of these 'DisplayDetails' classes (shared ptr, copies, I dunno as I haven't nailed the details down yet), each of which can be queried for the monitor's name (which I still need to work out how to extract [sad]), index and the display details.

You then use the same class to construct a 'DisplayMode' class instance which is what you pass into the 'DisplayModeSetUp' function. This display mode object is tied to a monitor so a monitor can't asked for a display mode it can't do.

In theory it looks like a nice solution, I need to sort out the specifics but I'm happy enuff with it.

I'm also toying with the idea of changing the handles from ints to small objects in their own right. Each one would have a shared_ptr back to the manager and the manger it's self can't be constructed, just a shared_ptr to it returned from a create function or something (or maybe it can be constructed... still need to read some details about how I'm gonna do this).

It won't so much be a singleton as a mono-state.. indeed, the whole idea of 'current' might well be stripped out (or maybe made a build option) to make sure we don't hit any multi-thread sillyness.

Indeed, if handles become objects then 'hide', 'show', 'swap' etc al will go via those handles and the idea of 'state' in the manager won't be that applicable anyways.

Some more scribbles need to be done, I've got some time before college tonight to have some more ideas and write some mode code, have to see what I come up with [smile]
Sign in to follow this  

1 Comment

Recommended Comments

The FBO is still working great, but after consultation with SHilbert for several hours and laborious effort at the debugger I think the machine is crashing inside the OpenGL framework somewhere (on a call about 16MB away from my program's buffers).

Share this comment

Link to comment

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
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!