Full screen control
Posted: Wed Sep 02, 2015 1:41 pm
Hello,
I do not know if it is the time, but that is no important.
I think there is now two native answers to start full screen quickly and to insure the coder graphic behavior on every OS environnement, more precisely on changing the task.
Tested on XP sure. I do not forget a few time to test on every platform is necessary. But if no crash nowhere, these two functions could greatly help the beginners to realize the control of full screen.
I did not make a beautiful or attractive graphic demo, just... a black screen, but no really need anymore to test the task flips.
Code : http://www.purebasic.fr/english/viewtop ... 12&t=43632 (2nd message)
1st function:
Just like a 'hidden openscreen', get the size of the desktop and apply it on screen opening.
Same options as 'openscreen' : title string and facultative flip mode flag.
2nd function:Needs the same both arguments as the previewing function. Add two others args:
*StandBy proc address needed to control background game task (for saving, calculate a real time background graphic task, etc..)
Delay duration facultative option could be given depending of the part of ressources taken by the stand by the background graphic task. This option allows the coder to choice a large range of ressources using from a total control (delay(0) ) for WaitWindowEvent() (in ex.) to a simplest silent clock (delay(16) or more and more again...).
These additions do not seem to remove the smallest part of freedom for the coder.
Although IsScreenActive() is linked by FlipBuffers(), a FlipBuffers() automation by growing FlipBuffers() with such a function (see above so) would remove any availabilities of the coder.
That is the reason, just a new easy function within a main accelerated graphic is the best choice. (hoping it will be really considered crossplatform...)
I do not know if it is the time, but that is no important.
I think there is now two native answers to start full screen quickly and to insure the coder graphic behavior on every OS environnement, more precisely on changing the task.
Tested on XP sure. I do not forget a few time to test on every platform is necessary. But if no crash nowhere, these two functions could greatly help the beginners to realize the control of full screen.
I did not make a beautiful or attractive graphic demo, just... a black screen, but no really need anymore to test the task flips.
Code : http://www.purebasic.fr/english/viewtop ... 12&t=43632 (2nd message)
1st function:
Code: Select all
Declare OnFullScreen(ScreenTitle.S,
ScreenFlipMode.I = #PB_Screen_WaitSynchronization)Same options as 'openscreen' : title string and facultative flip mode flag.
2nd function:
Code: Select all
Declare FullScreenResume(ScreenTitle.S,
ScreenFlipMode.I = #PB_Screen_WaitSynchronization,
*StandBy = 0,
DelayDuration.I = 16)*StandBy proc address needed to control background game task (for saving, calculate a real time background graphic task, etc..)
Delay duration facultative option could be given depending of the part of ressources taken by the stand by the background graphic task. This option allows the coder to choice a large range of ressources using from a total control (delay(0) ) for WaitWindowEvent() (in ex.) to a simplest silent clock (delay(16) or more and more again...).
These additions do not seem to remove the smallest part of freedom for the coder.
Although IsScreenActive() is linked by FlipBuffers(), a FlipBuffers() automation by growing FlipBuffers() with such a function (see above so) would remove any availabilities of the coder.
That is the reason, just a new easy function within a main accelerated graphic is the best choice. (hoping it will be really considered crossplatform...)