GraphicsModeExists() and HDMI

BlitzMax Forums/BlitzMax Programming/GraphicsModeExists() and HDMI

Richard Betson(Posted 2013) [#1]
Hi,

I was wondering if anyone has issues with GraphicsModeExists() and HDMI displays. I have some users testing my game application reporting some modes missing and others not working. Basically using GraphicsModeExists() with an HDMI display will crash my game app because GraphicsModeExists() seems to report a mode exist but when initialized fails.

Just wondering. :)

Thanks,


xlsior(Posted 2013) [#2]
Possibility: There is a setting in the graphics card drivers settings to hide unsupported modes -- if that is disabled, then the computer may list display modes that the screen doesn't actually support which can cause issues.

Another (really annoying) problem is that some displays flat-out LIE about their abilities, and their EDID codes return some resolutions that are not actually supported. Not much that you can do about that, unfortunately... :-/


Richard Betson(Posted 2013) [#3]
Hi,

Possibility: There is a setting in the graphics card drivers settings to hide unsupported modes -- if that is disabled, then the computer may list display modes that the screen doesn't actually support which can cause issues.

I will ask my users about this. Good to know.

Another (really annoying) problem is that some displays flat-out LIE about their abilities, and their EDID codes return some resolutions that are not actually supported. Not much that you can do about that, unfortunately... :-/

This is true and it seems with OpenGL maybe doubly so. And there is really no way to test each mode if it can potentially crash an compiled app. I suppose I could old school it and run a app to qualify each mode and log ligament modes, that way if it crashes it can step through other modes skipping the bad one. But that seems not to elegant.


Richard Betson(Posted 2013) [#4]
I could use a guide or some cool intel on G-Cards and issues with Bmax graphic drivers. I updated to a recent driver in a Windows 7 update that killed OpenGL on my system for BMax. Normally I would not used a MS driver but it was a way to see what problems my users were having. I am though a bit concerned that MS is updating drivers that just do not work though Windows 7 Update.

I get reports of DX7/9 and OpenGL just flat out misreporting graphic modes. When I see if they exist, they do, but when graphics are initialized it all fails with an exception error. DX7/9 are legacy and DX10/11 g-cards should really be using DX10/11 (thank you COL) and might fail do to poor emulation/support. Col's DX10/11 driver is looking as a lifeline to future Bmax driver support. I wish it would be adopted into the BMax build.

Just grouping for help. :) All very frustrating. :(


skidracer(Posted 2013) [#5]
Unless your users are running CRT monitors I can't think of a single good reason to not drive the display at the native resolution.


Richard Betson(Posted 2013) [#6]
Hi Simon,

You are probably right about that. I'm thinking it's cheaper HD TV's that are just reporting bad EDID data. The problems seem to be centered around VGA to the display instead of HDMI. I'm making a little progress sticking to native resolutions supported by HD TV's.

Right now I'm updating BMax from 1.45 to 1.48 just in case. But, you now how it is when you think you have it fixed and find out you didn't.

For the record I'm plus one on getting DX10/11 into BlitzMax officially.

Joy. :)