Can I change/set resolution etc at runtime?

Monkey Targets Forums/Desktop/Can I change/set resolution etc at runtime?

GfK(Posted 2014) [#1]
Is there a way I can change the screen resolution and switch from windowed/fullscreen at runtime?

(by the way - really don't like the search feature here- it only seems to be showing me one single post from a thread, which isn't an awful lot of use).


MikeHart(Posted 2014) [#2]
Doesn't SetDeviceWindow work for you?

When you get the search result, click on the title so you see the full topic once you had read that single post.


GfK(Posted 2014) [#3]
Doesn't SetDeviceWindow work for you?
Don't know. Probably. I didn't even know about it.

The last time I did a complete project with Monkey (three years ago), it was for iOS, but AFAIK SetDeviceWindow didn't even exist as there was a lot of fuss about the issue at the time as it was one of the glaring shortcomings of the desktop target.


MikeHart(Posted 2014) [#4]
Then it is time to study at the least the version.txt file that come with Monkey. All the changes are mentioned there.


Soap(Posted 2014) [#5]
The answer is yes by the way we allow user to change resolution at runtime. Our config screens allows user to pick any resolution in their list of options and defaults to their native. It allows switching from full/windowed without closing the executable.


ImmutableOctet(SKNG)(Posted 2014) [#6]
You have three options:

* Mojo's target-agnostic wrappers (The 'SetDeviceWindow' command): Available for GLFW and XNA, and it works well enough.
* Manually using the GLFW target's commands ('SetGlfwWindow'): Obviously, only available for GLFW, but it gives you lower-level control when needed.
* Or something a little unorthodox like making your own. Or even using someone else's module, like my 'screen' module, which wraps the standard GLFW and Mojo commands. Though, I wouldn't really recommend that one, as it's really just something I developed for my own use, and is a bit hack-ish.

Mojo's implementation is just backed with Mark's GLFW and XNA specific code. Which is rather basic to begin with. Well, at least on XNA it is. That being said, this functionality is only available on those two desktop targets (Currently).


GfK(Posted 2014) [#7]
Changing the res at runtime is only really relevant for desktop targets anyway, so that's fine.

Just one Q, though - after calling SetDeviceWindow, how are existing resources handled? Do I need to reload everything manually?


ImmutableOctet(SKNG)(Posted 2014) [#8]
When Mark wrote his display-mode code for GLFW, he made sure to do it right. Your resources do not need to be reloaded, it's not like the way it used to be with BlitzMax and BlitzBasic. All you have to do is call it, and you'll be good. The XNA target should work the same way, though that's really just something XNA has in general.

And as I said before, the Mojo-based implementation just uses Mark's platform specific code anyway, so you'll get most of the benefits of that.


EdzUp(Posted 2014) [#9]
Is it just me or when calling SetDeviceWindow( 1024, 768, 1 ) on a screen with a resolution thats bigger than that it gets squashed in the bottom left or am I missing something?

At the moment all my full screen displays are squashed in the bottom left of the screen which is a pain, I wanted fullscreen to use 'the entire screen' or its next to useless.


GfK(Posted 2014) [#10]
Just playing around with this myself... not getting the same problem as you but I've noticed that when I launch a fullscreen app, if I press Alt+F4 to quit out of it, it doesn't work UNLESS I first click the mouse on the game window. Yet it seems to be catching keyboard input fine, otherwise.

Strict
Import mojo

Function Main:Int()
	New Game()
	Return 0
End

Class Game Extends App
	Field r:Int
	Field g:Int
	Field b:Int
	
	Method OnCreate:Int()	
		'Set how many times per second the game should update and render itself
		SetUpdateRate(60)
		SetDeviceWindow(800, 600, 1)
		Self.randomColor()
		Return 0
	End
	
	Method OnUpdate:Int()
		If KeyHit(KEY_SPACE)
			Self.randomColor()
		EndIf
		Return 0
	End
	
	Method OnRender:Int()
		Cls(r, g, b)
		DrawText(Millisecs(), 50, 50)
		
		Return 0
	End	
	
	Method randomColor:Void()
		Self.r = Rnd(0, 255)
		Self.g = Rnd(0, 255)
		Self.b = Rnd(0, 255)
	End

End



ImmutableOctet(SKNG)(Posted 2014) [#11]
@GfK: Your situation with the keyboard input is probably a weird GLFW bug. You're supposed to have the window selected in order to use 'ALT+F4' (In addition, the close system-message isn't dealt with if you overload 'OnClose' without calling the 'App' class's implementation). It probably is some kind of GLFW or Windows bug, because I get the same thing. That being said, I can setup my own key for it, and it works fine.

And just a side note, but you should be dealing with colors as floats, not integers, you just end up with unneeded overhead. And on some targets (Specifically older hardware on platforms like Android), this makes a big difference after a while. (Although, you could make the same argument against using floats, but that's how Monkey does it)

@EdzUp[GD]: That's really strange, but if it's a fullscreen issue, it might just be a driver or monitor issue. Have you tried other OpenGL-based games/programs in fullscreen at a lower resolution than your monitor was built for? You may just have some kind of scaling problem with your drivers. Well, either that or you need to change settings in your monitor, because I've never had this issue.

For me, it just stretches it, but I also have "Wide Mode" set to "Full" for my monitor. And if I set "Wide Mode" to "Aspect", it keeps the aspect-ratio, and gives me blanks space. I don't think your problem is related to Monkey.

When I try the following demo in fullscreen, I get this:


That's basically GfK's demo, just with a few small additions. The image I uploaded (1024x768) simply gets stretched by my monitor, which is what's intended.