Display mode selection

Started by EvilOne, May 16, 2004, 08:53:48

Previous topic - Next topic

EvilOne

Hi folks,

It would be nice to query the current display mode. Because at game startup I would set the display modes refresh frequency to the one found in the current display mode (i.e. the current mode the desktop is in).
Because making a safety switch to always 60Hz sucks, and I dont want to annoy the user with a Dialog selecting the refresh rate. So switching to desktop refresh rate would be a nice option :D

Another thing is the strict checking of the returned pixelformat in the native findPixelFormat function. As the windows API says, the function tries a "close match". Which is a very nice thing. So the gl context is up and running, maybe not with all the requested features. It is up to the application to query for context features. For instance, if the context is without a stencil buffer (but stencil were requested), I would disable shadows in my application or terminate... it's up to the application, to decide about further operation or termination imho. Hmmm, this brings us up to query the context features  :D

Cheers,
E1.

P.S. This SWT binding rocks hard, I'm happy with it  :D
If you got a shiny new hammer, every problem looks like a nail!

Matzon

Quote from: "EvilOne"
It would be nice to query the current display mode. Because at game startup I would set the display modes refresh frequency to the one found in the current display mode (i.e. the current mode the desktop is in).
There already is: Display.getFrequency()

Quote from: "EvilOne"
Another thing is the strict checking of the returned pixelformat in the native findPixelFormat function. As the windows API says, the function tries a "close match". Which is a very nice thing. So the gl context is up and running, maybe not with all the requested features. It is up to the application to query for context features. For instance, if the context is without a stencil buffer (but stencil were requested), I would disable shadows in my application or terminate... it's up to the application, to decide about further operation or termination imho. Hmmm, this brings us up to query the context feauture
I've never used multiple contexts (apart from testing), so I'll refrain from making any comments on this - others?

princec

Strict checking stays - you are guaranteed to get at least what you ask for and never less. If you can't get it it throws an exception - which you can catch and try asking for less (say, not asking for a stencil buffer)

Cas :)

aldacron

Quote from: "princec"Strict checking stays - you are guaranteed to get at least what you ask for and never less. If you can't get it it throws an exception - which you can catch and try asking for less (say, not asking for a stencil buffer)

Well, now you get into a situation as to 'Why did it fail?'. Do a try again with a 16 bit depth buffer rather than 24? or do I try with no stencil? What if I try with a different color depth? I'm with EvilOne on this and think it should be up to the app to test the selected pixel format.

elias

As I see it, there are two possible callers of Window.create():

1. The passed values really are the absolute minimum values you can live with. It won't help anything if we return something worse than required.
2. The passed values are not the absolute minimum and you can live with lower values. Is it not better if you got to specify what the next best format is with a second create(), and not some arbitrary one Window.create selects?

- elias

fbi

Dear EvilOne,
I'm very happy you are having fun with the SWT binding...but BTW are you a cool X programmer?  :wink:
To all the other X programmer out here: is there anybody who wants and can help me to get the binding done?
Oh well...we would need some help my MacOS X programmers, too  :wink:

EvilOne

Hi fbi, I'm a win32 only programmer  :D
I dislike any flavor of unix/linux for coding, crappy IDE's, crappy libraries...

The only reason, I use Java again: SWT+LWJGL+JET! This makes Java a usable language for my purposes. I can't wait for a real C# compiler to benchmark against JET :twisted:

Can't help with X, sorry. Btw, my "target audience" is on windows, and I don't really care about those unix users out there. I'm doing primary demo coding so campatibility is not an issue.

If you are interested you can check out:
http://www.pouet.net/prod.php?which=9447
http://www.pouet.net/prod.php?which=12099

Cheers, E1.

P.S. Currently I'm playing a bit with http://weblog.ikvm.net/ which seems another nice solution to get rid of a jvm...
If you got a shiny new hammer, every problem looks like a nail!

fbi

Ok...I've got the wrong person for this  :D
Anyway I care a lot about demos (I liked the first one very much...also because of the soundtrack)...indeed I started doing a bit of demo coding when I was during my first university years  :wink:
I never was able to get a full operative team but I learnt a lot studying demos and talking to other coders, and I suppose that is basically the reason why today when I teach Virtual Reality guys enjoy my lessons  :)
Anyway I'm happy with the fact that somebody is using the binding (me included because I really needed it)  :D