No way to get desktop hertz?

BlitzMax Forums/MaxGUI Module/No way to get desktop hertz?

QuickSilva

(Posted 2009) [#1]

After a quick search of the forums I see that there is not way to get hold of the users desktop hertz like you can with the width and height of their desktop. Is there a reason that such a necessary command would be omitted?

If I set up a window that I want to run at the users desktop hertz what options do I have apart from using a .dll or similar?

Can a proper hertz command please be implemented in a future BMax?

Jason.

skidracer

(Posted 2009) [#2]

// monhertz.cpp

#include <windows.h>

extern "C" int monhertz();

int hertz=0;

int monhertz(){
	DEVMODE mode;
	int res;
	mode.dmSize=sizeof(mode);
	mode.dmDriverExtra=0;
	mode.dmSpecVersion=DM_SPECVERSION;
	res=EnumDisplaySettings(0,ENUM_CURRENT_SETTINGS,&mode);
	if(res==0){
		return 0;	// failed :(
	}	
	return mode.dmDisplayFrequency;
}

Import "monhertz.cpp"

Extern "C" 
Function monhertz()
End Extern

DebugLog monhertz()

It is a little simpler to do in c on windows than blitzmax.

The directx driver used to reserve graphicsmode index 0 for desktop resolution so GetGraphicsMode 0, could be used for this problem.

This behavior seems to have been lost, it is still true I hope for linux systems.

QuickSilva

(Posted 2009) [#3]

Thanks for that skidracer, very much appreciated. Hopefully something similar can be added to a future build?

Jason.

d-bug

(Posted 2009) [#4]

[merchandise]

For Windows and OSX you can use my desktopextension module if you like.

Simply use:

Import chaos.desktopext
Local Hertz:Int = DesktopHertz ()

Find the link in my sig.

[/merchandise]

:)

skidracer

(Posted 2009) [#5]

yes that code is better:

Import pub.win32

DebugLog GetDeviceCaps(GetDC(0), VREFRESH)

BlitzSupport

(Posted 2009) [#6]

Nope, GetDeviceCaps with VREFRESH is only for NT systems:

http://msdn.microsoft.com/en-us/library/dd144877(VS.85).aspx

skidracer

(Posted 2009) [#7]

The average windows98 machine possibly reports 0 with all methods including the low level directdraw layer. Users typically had to have a vsync interupt enabled on their pc which wasn't a given back in the day or were using the - "plug and play monitor with no particular identity"
monitor driver which also failed most tests.

QuickSilva

(Posted 2009) [#8]

Can I just ask a further question. Without resorting to using WaitTimer events in MaxGUI is there a way to replicate the standard update process that you get in a normal BMax program using flip so that it correctly waits for the monitors refresh rate, in my case 60 hertz? WaitTimer events seem to be the only way to achieve this but if I didn`t have to use them then I would not need to grab the users desktop hertz in the first place.

Thanks for any further help,

Jason.

skidracer

(Posted 2009) [#9]

Short answer: no.

Notes on windowed mode you may not have considered:

it is not OK to peg the cpu at 100%

it is not OK to run your app at max frame rate

if your window does not have focus then above is even less rubbish

a single core windows system will not share system resources and other running programs will suffer unless your app yields regularly for 5ms+

many people have multi monitor setups, some completely unmatched in the refresh department