macOS Determining Monitor Type in Mac OS X (CRT, LCD)

[wrldwzrd89]

Is it possible to determine (ignoring multiple monitors - the program will only use the primary one) the type of the monitor - i.e. whether it is an old-school CRT (and can thus change to virtually any resolution without impacting performance) or a new-school LCD (which has only one native resolution, and performs best at that resolution)?

The reason I ask is because I'm writing a game, and I'd prefer to be able to handle CRTs and LCDs differently. If this is not possible, I can use the more restrictive LCD method with CRTs too - this should work perfectly assuming the CRT supports the resolution in question.

Additionally, is it possible to determine an LCD's native resolution programatically? If it is, I can optimize game performance by switching to that resolution, unless the LCD is already in that resolution, in which case I don't have to do anything.

Finally, I'm trying to make the game as flexible as possible regarding resolutions - this is done to make it play optimally on all systems it is run on. That's the biggest reason for this thread existing.

 

[kainjow]

Looks like you can do some of this with the Quartz Display Services.

As for detecting an LCD, this might help. I'm guessing you'd have to use IOKit either way.

 

[Yvan256]

Unless there's something really weird going on inside of Mac OS X, a non-native resolution won't impact performance, only image quality (it should be the LCD controller itself which resizes the picture).

Also, running at the LCD native resolution will impact performance compared to running at a lower resolution (less pixels for the GPU to move around).

As a good example, I play Final Fantasy XI on my old Win98SE PC. My monitor is a ViewSonic VP171s which has a native resolution of 1280x1024. I play FF XI in 640x480, which means that at least horizontally the pixels are perfect (two LCD pixels for every game pixel). I should try to mess with the game setting to be able to play in 640x512, to remove the vertical blurring. Mind you, it's an old PC with an old videocard, and 640x480 or 640x512 is the best it can do for acceptable frame rates (especially in crowded areas with dozens and dozens of players to display).

 

[Berlepsch]

Wouldn't it be easiest to let the user decide?

You could probably run a quick graphics test after installation to see if the frame rate is OK for the current system resolution, and offer lower resolutions if the system is too slow. Add something about possible quality losses due to LCD interpolation in the dialog, and you should be fine.

 

[wrldwzrd89]

Unless there's something really weird going on inside of Mac OS X, a non-native resolution won't impact performance, only image quality (it should be the LCD controller itself which resizes the picture).

Also, running at the LCD native resolution will impact performance compared to running at a lower resolution (less pixels for the GPU to move around).

As a good example, I play Final Fantasy XI on my old Win98SE PC. My monitor is a ViewSonic VP171s which has a native resolution of 1280x1024. I play FF XI in 640x480, which means that at least horizontally the pixels are perfect (two LCD pixels for every game pixel). I should try to mess with the game setting to be able to play in 640x512, to remove the vertical blurring. Mind you, it's an old PC with an old videocard, and 640x480 or 640x512 is the best it can do for acceptable frame rates (especially in crowded areas with dozens and dozens of players to display).

I was not aware of this. Thanks for the input - that makes what I have to do a lot simpler.

Wouldn't it be easiest to let the user decide?

You could probably run a quick graphics test after installation to see if the frame rate is OK for the current system resolution, and offer lower resolutions if the system is too slow. Add something about possible quality losses due to LCD interpolation in the dialog, and you should be fine.

Yes - based on what Yvan256 said above, this makes the most sense.

 

[gnasher729]

Is it possible to determine (ignoring multiple monitors - the program will only use the primary one) the type of the monitor - i.e. whether it is an old-school CRT (and can thus change to virtually any resolution without impacting performance) or a new-school LCD (which has only one native resolution, and performs best at that resolution)?

The reason I ask is because I'm writing a game, and I'd prefer to be able to handle CRTs and LCDs differently. If this is not possible, I can use the more restrictive LCD method with CRTs too - this should work perfectly assuming the CRT supports the resolution in question.

Additionally, is it possible to determine an LCD's native resolution programatically? If it is, I can optimize game performance by switching to that resolution, unless the LCD is already in that resolution, in which case I don't have to do anything.

Finally, I'm trying to make the game as flexible as possible regarding resolutions - this is done to make it play optimally on all systems it is run on. That's the biggest reason for this thread existing.

Actually, you shouldn't change the resolution at all. If the user wants to change the resolution, they can do so easily. They can go to System Preferences and put a menu to change the screen resolution into the menu bar. Changing the screen resolution can have unpleasant side effects, like resizing windows to make them fit. If you think the hardware is not powerful enough to handle your game at the current screen size, you can always limit the game to a smaller area - or let the user change the resolution.

 

[wrldwzrd89]

Actually, you shouldn't change the resolution at all. If the user wants to change the resolution, they can do so easily. They can go to System Preferences and put a menu to change the screen resolution into the menu bar. Changing the screen resolution can have unpleasant side effects, like resizing windows to make them fit. If you think the hardware is not powerful enough to handle your game at the current screen size, you can always limit the game to a smaller area - or let the user change the resolution.

This I was aware of. What my intention was is to use the current resolution if at all possible, else switch to a "better" one then switch back on exit, else display an error message and quit. However, there are limits on how many resolutions I can easily support. Sure, I can support all the common Mac resolutions without many problems. What about Windows and Linux though? The game will be cross-platform, so this complicates things.

 

[mufflon]

This I was aware of. What my intention was is to use the current resolution if at all possible, else switch to a "better" one then switch back on exit, else display an error message and quit. However, there are limits on how many resolutions I can easily support. Sure, I can support all the common Mac resolutions without many problems. What about Windows and Linux though? The game will be cross-platform, so this complicates things.

Well I don't really know a great deal of your game, but wouldn't it be a wise decision to separate the rendering part of the game from the rest and make it as screen size agnostic as possible? E.g. auto-stretch the visual elements according to 4:3 / 16:9 / 16:10 / whatever strikes your fancy?
Thus you won't have to support every screen size possible (e.g. hard coded) but only the aspect ratios you prefer.

 

[wrldwzrd89]

Well I don't really know a great deal of your game, but wouldn't it be a wise decision to separate the rendering part of the game from the rest and make it as screen size agnostic as possible? E.g. auto-stretch the visual elements according to 4:3 / 16:9 / 16:10 / whatever strikes your fancy?
Thus you won't have to support every screen size possible (e.g. hard coded) but only the aspect ratios you prefer.

Problem is, that doesn't work so well when...
1. The game is not 3D, or at least the vast majority of it isn't
2. The game is tile-based, and thus looks horrid when stretched
3. Both of the above are true (which is the case for my game).