NewsForumsCodeLogsGallerySpecsSearch

Full Screen / Windowed

BlitzMax Forums/BlitzMax Programming/Full Screen / Windowed

Zumwalt(Posted 2006) [#1]
Option A) Graphics(800, 600)
Option B) Graphics(800, 600,0)

Initially I was running in full screen, thus Option A, I was using the 1.20 release, so I downloaded 1.20d and used it, well, it worked initially, I wanted then to move to windowed mode for troubleshooting, so I set my Graphics to Option B, now, no matter what I do in the code, (change back to option A), it stays windowed mode.

Windowed mode for some reason takes up 100% cpu, which is crappy, but it just does, I even rolled my editor back to just the 1.20, no luck.

How do I make it full screen again now that I have made it windowed?

I have even went as far as writing an external C code version of DoEvents to try to eliviate the CPU, that didn't do squat.


H&K(Posted 2006) [#2]
Are you in debug mode?


Zumwalt(Posted 2006) [#3]
Yes and no, I have tried both, same results on both.
Below is an image of it running with both graphics levels from 2 screen shots merged together, this is not debug in this screenshot.




Yan(Posted 2006) [#4]
The depth param of the Graphics command defaults to 0 (which is windowed).

It used to default to 16, I think, but I'm sure that changed a few versions ago?

Use a depth for full screen. IE. Graphics 800, 600, 16


Zumwalt(Posted 2006) [#5]
So either 16 or 32 then are the settings for full screen and 0 is windowed?

Either way, the set to 16 or 32 works to set it back to full screen, so not a bug, maybe a change, but not a bug.


Grisu(Posted 2006) [#6]
Yeppa!

Graphics 800,600,0 ' Windowed
Graphics 800,600,16 or 32 ' Bit Fullscreen


xlsior(Posted 2006) [#7]
Windowed mode for some reason takes up 100% cpu, which is crappy, but it just does


So does full screen. A blitz application will try to run as fast as possible, meaning that it will not give any free time to the operating system, and the 100% CPU that you see.

You can address that by telling your application to 'wait' periodically, giving other programs (and the OS) a chance to do things as well -- this drops the CPU load considerable. For a quick test, just add a 'delay 1' in your main loop, and watch it drop.


Grey Alien(Posted 2006) [#8]
Or try detecting when your game is suspended, and call Delay(1) then so that Windows gets the CPU time, but only when you game isn't focused. This worked for me.


Zumwalt(Posted 2006) [#9]
Very good points, I will look into it, both wait and delay. I need to find a way to focus the events so I run at a consistant speed that allows for cpu freedom.

Edit:
Wait has no identifier, what module is it in?

Edit: found another solution:

Local timer:ttimer = CreateTimer(150)

Repeat
	Cls 
	DrawImage background, 0, 0
	hi_THighGUI.Render()
	hi_THighGUI.Update()
	chkKeys()
	Flip 0
	TFPSCounter.Update()
	DoEvents()
	GCCollect()	
	WaitTimer(timer)
Until Not running


Although the timer doesn't make much sense, the higher the number, the more cpu that is used, so if I have it at 100 vs 150, my cpu utilization is at 15%, at 150 it ranges from 30-50%, at 200 its 50-60%.


ImaginaryHuman(Posted 2006) [#10]
I thought it was always like that ... If you specify the depth, you get full-screen, if you dont (or you give 0) you get windowed. Been like that as long as I remember?


Grey Alien(Posted 2006) [#11]
yeah me to. no specify = 0 thus windowed mode. specify 32 or 16 for full-screen.

btw Zumwalt, I don't think Wait exists, I think Delay is the only option. Also the higher the number the timer, the more times per second it will run your main loop as WaitTimer won't be waiting as long for the timer to "tick".


H&K(Posted 2006) [#12]
Is it? I allways thought no specify was always windowed in debug, but full screen 32bit in release.
Good manual with Bmax;)


Zumwalt(Posted 2006) [#13]
To round this thing off for the original problem, I was under the impression (read somewhere) where you either supply a value or you do not, if you supply a value, one of 0 means windowed, if you do not supply a value it is full screen, and it did work like that for a while, now it won't. I don't recal ever reading what values it needed, as in 32 / 16.

If you highlight the word Graphics in your clode, then click F1, you will see, that it is:
Graphics:TGraphics(width, height, depth=0, hertz=60, flags=0)

That should read, based on this conversation,
depth=[0,16,32]

Atleast that is friendlier.

As far as the second question that I crept into this, and sorry about that, but the waittimer name is also misleading, if it determines the number of times a second your loop runs, it makes sense that a higher number chews up more cpu and a lower number slows down the loop which free's up more cpu, I don't know yet, because frankly I haven't tried, if BlitzMax is multi-threadable, if it is, then that WaitTimer has alot of uses, a thread per heartbeat for levels and spawning, etc.

I am slowly getting the hang of all of this, just seems odd the way things are laid out sometimes.


tonyg(Posted 2006) [#14]
My doc states...

The depth parameter selects a pixel bit depth. This value can be 0, 16, 24 or 32 depending on the graphics modes available. A depth of 0 can be used to select 'windowed mode' graphics, while non-0 depths select 'fullscreen' graphics.




kronholm(Posted 2006) [#15]
Graphics 800,600,32,60 ' 60 fps, 32 bit depth, fullscreen



Dreamora(Posted 2006) [#16]
BM is single threaded and not even multithread safe in case you think about adding multithreading.


Zumwalt(Posted 2006) [#17]
Well now, thats a bummer, can't do apartment threading. That limits a few things.