Closing a Window

About Monkey 2 Forums Monkey 2 Programming Help Closing a Window

This topic contains 10 replies, has 5 voices, and was last updated by  Mark Sibly 2 years ago.

Viewing 11 posts - 1 through 11 (of 11 total)
  • Author
    Posts
  • #7750

    sicilica
    Participant

    Is there no way to close a Window without killing the AppInstance? There don’t seem to be any SDL_DestroyWindow calls anywhere that I can find, even.

    Or maybe I’m just going about things the wrong way. How is everyone handling changing resolutions? At this point, the only thing I can think of would be to have a persistent “game state” object that you create in Main, then create an AppInstance and Window within some loop, and then call Terminate on that app and make a new one that uses the same state object if you even need to change resolution, switch windowed/fullscreen, etc. But… that seems like a pretty bizarre way to handle things, and I question whether that will be sanitary for things like std.time.Millisecs and so on.

    Edit: Actually, that doesn’t even work, since Terminate calls libc.exit instead of continuing after the blocking App.Run call. Is this just impossible because Mark didn’t get around to writing SDL cleanup code? I guess none of this would work at all outside of desktop, but is noone trying to develop something commercial?

    #7755

    DaY
    Participant

    you could run in console mode and use createwindow function in mojo module just use global pointers to store the new window hwnd and then terminate the global appInstance and as its console it should not close the full app just the hwnd.

    #7756

    nerobot
    Participant

    How is everyone handling changing resolutions?

    You can change window size on the fly, but with some extra code right now (it’s easy to make it a part of Window class).

    Code:

    Additional import is required:

    Usage:

     

    Also there is a SDL_HideWindow() method inside of sdl2 module.

    Maybe it’s that you are searching for (instead of DestroyWindow).

    #7763

    sicilica
    Participant

    Running in console mode – wouldn’t that not get you access to SDL, though? Still would like to be using SDL for input and rendering and everything. Maybe I’m wrong here, but getting the WinAPI handle of a manually created window seems like the wrong approach.

    SDL_HideWindow and SDL_DestroyWindow aren’t quite the same, no.

    It looks like the sdl2 module exports SDL_SetWindowBordered and SDL_SetWindowFullscreen, among others, so maybe the solution is just to run SDL commands manually. In that case I would have to hack mojo though – mojo.app.Window._sdlWindow is private. While I’ve posted quite a bit in the past about wanting more direct access to OpenGL/SDL directly, in this case for simple 2D I do plan on actually using mojo, is all. Oh, there is actually a getter for the SDL window, nevermind. I should’ve read your code more carefully.

    Is there a reason that more of this functionality isn’t already exposed by the Window class? This was all so easy by the time I started using monkey1, and I don’t think I was super late to the party. Maybe the worst part is that 90% of the methods on these classes are hidden. I get that Mark wants to wait to expose stuff that isn’t finalized, but it means I have to spend a lot of time looking through the actual source for all these modules in order to be able to actually do anything productive with them at all. It was all I could do to figure out how to get an actual timestamp for SeedRnd:

    All of the time_t and tm_t structs, and all of libc, aren’t even documented – but from the looks of things it would’ve been really hard to get an actual timestamp from std.time.Time even after calling std.time.Time.Now to get the system time in the first place.

    #7766

    DaY
    Participant
    [/crayon]

    as you can see you can create instances and multi windows from the console its the route im trying to pass instance to a externel lib. its a bit hackish but mx2 is still being developed.

    #7767

    sicilica
    Participant

    The fact that you have two AppInstance’s isn’t doing anything for you here, unless I’m crazy. When you call App.Run(), it’s executing on pAppinstance2, which starts an SDL event loop. Both windows work because they aren’t tied directly to the AppInstance; both pAppinstance1 and pAppinstance2 should have access to both windows when they call Window.VisibleWindows().

    I don’t know what you’re trying to do here, but I have a lot of trouble believing that that could possibly help anything, and it certainly doesn’t give you any extra ability to close windows individually or to exit that SDL event loop and re-enter a new one (via App.Terminate or whatever).

    I’m reasonably confident that using SDL commands directly is the only solution right now.

    #7768

    DaY
    Participant

    i used app.run to show that you can create instance in console mode obv you would need to overide the window attributes you just create ur own app.run not the default.

    the other way would be to create a cpp class that handles the SYS WINDOW directly so you just hook into the window exteranly.

    could you not extend the app.cpp in mojo?

    #7779

    nerobot
    Participant

    Is there a reason that more of this functionality isn’t already exposed by the Window class?

    The main idea here is to extend base minimal functionality by real needs – to minimize overcoding.

    Also don’t forget that mx2 is very newly language. Our real using and reature requesting make it better and better. 🙂

    —————————————–

    Not need to create many app instances, but create a few windows.

    And create many windows isn’t a problem – it works.

    The problem is terminating whole app when closing any window.

    I looked into sources of Window class and found that (private method):

    As you can see, there is

    that doesn’t check windows count, and terminate app by closing any window.

    I added that as issue: https://github.com/blitz-research/monkey2/issues/163

    #7826

    Mark Sibly
    Keymaster

    Currently, mojo is designed very much around ‘one permanent window’ style game coding. Multiple windows are very untested (although the basic framework for support is in there and they will eventually happen) and yes, closing window=closing app, something that will also change in future.

    handling changing resolutions?

    The Window.BeginFullscreen() and Window.EndFullscreen() methods allow you to dynamically enter/leave fullscreen mode at runtime. With no params, BeginFullscreen enters ‘desktop mode’ fullscreen, or you can specify width,height,hertz to actually change display mode. Note you can also provide a virtual resolution via OnMeasure:Vec2i() so desktop mode fullscreen is often fine.

    See bananas/spacehimps for a demo of Alt-Enter fullscreen toggling. See bananas/viewlayout for a demo of virtual resolution.

    There’s still no way to enum display modes cleanly though (excluding SDL) – coming soon-ish.

    To manually change position/size of a window (in ‘desktop’ coords) use the Window.Frame property.

    In general, avoid using SDL_* calls if there’s a ‘mojo’ way to do something. SDL_Resize will probably work, but only because mojo currently polls window size for the sake of some platforms. I’d rather not expose this level of mesiness though (ie: In future it may not, or it may not on some platforms etc) so if there’s mojo way to do something, please use that as it should be ‘just work’. And if it doesn’t, or mojo doesn’t have some feature you’re having to resort to SDL for, let me know or better, post an issue at github.

    #7833

    impixi
    Participant

    There’s a bug in the Window.BeginFullscreen method. I posted an issue on Github…

    When it’s fixed the following *rough* example should work. It gets your primary display’s supported modes and allows you to switch through them at run time:

    [/crayon]
    #7834

    Mark Sibly
    Keymaster

    …thanks for that Impixi, fixing now.

    And BeginFullscreen isn’t even docced yet! Fixing that too…in general, if you notice something @hidden in the docs that looks like it shouldn’t be, please let me know.

Viewing 11 posts - 1 through 11 (of 11 total)

You must be logged in to reply to this topic.