switch GLFW_WINDOW_RESIZABLE setting at runtime
Monkey Targets Forums/Desktop/switch GLFW_WINDOW_RESIZABLE setting at runtime
| ||
| Is it possible to turn on GLFW_WINDOW_RESIZABLE parameter during the actual game? I want to allow user to change it in options menu. |
| ||
| This is a bit odd, as I don't see why it should be an option like that. Why should the user even have this option? Sure it'd be nice, but it's not like allowing the window to resize does anything negative (Assuming you support it already; and if you don't, what's the point of this?). GLFW has a window hint system. This is used when creating a window, it can't be done on an already created window. Because of this, you'll have to recreate the window. And since we can't call the standard implementations due to their use of the preprocessor variable, we'll need to make our own versions. Here's the thing, though; the 'BBGlfwGame' class(es) hold(s) several settings you generally want to restore. The issue? They're private, so we can't actually restore them ourselves. On top of that GLFW's window functionality is a lot nicer with GLFW3. But this also means if you want to do this for both GLFW targets, you'll need to effectively write two versions (Or at least use the C++ preprocessor). So, effectively, you can't write this properly. You can get the window and such, but you don't have access to everything. There is the option of simply modifying the target, however. I mean really, making another command for this is overkill. That would be the simpler option, but I think you might just want to ask Mark to add this (Or do it yourself and make a pull request). Again, it's not exactly something you can do without either some odd code changes to your own project, or some relatively small modifications to the target. I was originally going to post some code as an example, but without being able to restore things properly, it's really not worth it. Here's the exact line which is stopping you from doing this. And here's the GLFW3 version. As you can see, this is using the preprocessor variable Mark set up. If it were an argument for the command, and that command was public, we'd be able to do what you wanted. However, Mark does it manually based on the preprocessor, and I honestly don't mind that. That being said, one of the nice things in GLFW3 specifically is the new window-hint defaults system. You might be able to work around this whole thing with that, then use 'glfwWindowHint' manually. But, you'd still need to modify the target. The fact is, most people don't actually care about doing this on runtime. Sure, it'd be nice, but it's not like something more serious, like not being able to change the resolution at all on runtime (Which used to be a problem; obviously, this isn't an issue anymore). Was there a particular reason you wanted this changed on runtime, or were you just trying to give the user as many options as possible? I'd say you should just enable it and be done with it. Anyway, you really can't do this without making modifications to the target(s). |
| ||
| ImmutableOctet(SKNG) Thank you for detailed explanation! I wanted to add this as an extra option to allow user to stretch the game window as he wants. Now I see that it's very complicated and I guess I should pass on this :) By the way, is it possible to turn on MOJO_IMAGE_FILTERING_ENABLED at runtime? I found a topic: http://www.monkey-x.com/Community/posts.php?topic=993 but it's 3 years old. I guess it requires some mojo hacking. I really wanted to add this option |
| ||
| Well, stretching/resizing the window isn't the issue here, it's a matter of having the user change this on runtime. As I said before, it's preprocessor based, so you'll need to pick a setting for it on compile-time and stick to it. As for 'MOJO_IMAGE_FILTERING_ENABLED', I'm not really the right guy to ask about this. The most I know about handling this on runtime is to just use proper AA instead of the usual filtering scheme. Here's my old 'screen' module for example. I'm sure it's been done, but I don't even bother with image filtering to begin with, I always have it off; looks nicer overall. It can be useful, though. I just tend to not bother. Sorry I couldn't help you with that one. |
| ||
| ImmutableOctet(SKNG) Thanks, I'll try to figure this out. |
| ||
| Very simple solution: add a file like "glfw.cpp" in the folder "EXTERN" (choose whatever name you want. Just make sure to import it later), content: class external
{
public:
static void setGraphics(int w, int h)
{
glfwSetWindowSize(w, h);
GLFWvidmode desktopMode;
glfwGetDesktopMode( &desktopMode );
glfwSetWindowPos( (desktopMode.Width-w)/2,(desktopMode.Height-h)/2 );
}
};
and add something like that to your main code: #IF TARGET="glfw" Import "EXTERN/glfw.cpp" Extern Function _SetGraphics:Void(w:Int, h:Int) = "external::setGraphics" #end Public Function SetGraphcis:Void(w:Int, h:Int) #IF TARGET="glfw" _SetGraphics(w, y) #end End You can now call "SetGraphics(w,h)" whenever you want. Ps: this is a code snippet of a Monkey75d project. Dunno if something has changed since then :) |
| ||
| @PhillipK: That's not what we were talking about. Also, you don't need external code for this anymore. Mojo should be used for less target-specific display-mode handling. On top of that, target-specific options are already available through Monkey without direct native-language usage (Not available with GLFW3, weirdly enough; you'll have to use Mojo). What he wanted was to change the resize option on runtime. In other words, he wants to make it so you can toggle the ability to drag to make the window bigger. Monkey only offers the ability to toggle on compile-time. The only way to do this on runtime is by giving GLFW the proper window-hint when creating it. The problem? Monkey uses the preprocessor for this; this means it's always being set to the option specific with the Monkey/C++ preprocessor. Overall, the idea is a bit ridiculous, but I don't see why we can't at least ask Mark about it. After all, it's not like GLFW doesn't support this, it's just a bit strange. |
| ||
| I don't see why this would be an option for a user. As far as I know a window doesn't usually "become resizable", it either is, or it isn't. If you think the user will want to resize the window, ever, then set it to resizable. :) |
| ||
| If you think the user will want to resize the window, ever, then set it to resizable. :) The problem is that I wanted to switch between resizable window and fixed size window at runtime. Anyway, I decided to pass on this one. Now my biggest concern is to achieve switching image filter (MOJO_IMAGE_FILTERING_ENABLED) parameter at runtime. |
   |