Pages: 1
  Print  
Author Topic: Win32 Nested Window  (Read 1775 times)
Offline (Male) Goombert
Posted on: May 25, 2014, 12:51:47 AM

Developer
Location: Cappuccino, CA
Joined: Jan 2013
Posts: 3110

View Profile
Well, I didn't realize until recently we are creating two windows on Win32, one is the child window for graphics and the top one is the parent. Our whole system is programmed around this currently by utilizing it to maintain the aspect ratio of the window since we use somewhat fake fullscreen behavior. This does however have its costs, 1 we can't use this solution for XLIB and Cocoa, 2 Win32 is buggy as hell on its own let alone trying to use a parented window device.

A simple solution that I already tested and got working was to remove it completely and handle window adaptation in the screen viewport function. glScissor was needed to stop the window color from becoming the room background color, so you would get black bars, but it did not work in fullscreen, Direct3D did not require any extra functionality because its viewports already treat them as bounds, but like OpenGL it also did not work in fullscreen.

At any rate, the only cross-platform solution is to emulate window adaption for our fake fullscreen behavior in the graphics systems/viewports. I want to know what everyone's opinion on this is.
Logged
I think it was Leonardo da Vinci who once said something along the lines of "If you build the robots, they will make games." or something to that effect.

Offline (Unknown gender) Darkstar2
Reply #1 Posted on: May 25, 2014, 01:58:54 AM
Member
Joined: Jan 2014
Posts: 1244

View Profile Email
Wow this is a real mess.  I really hate to see FAKE and ENIGMA in the same sentence.  It reminds me back in the days of GM8 and older, they used "fake" full screen.  Remember, when there was screen resolution changes done inside a game it would fuck up people's desktop icon ? I was not even aware fake FS was used here, lol!

it's hard to give an opinion without testing anything, what are the implication for windows development, will this affect scrolling games? Will we still be able to use view ports, what other consequences to gaming, performance, etc.  Please provide more info. If this means improving speed and how things are done then no question about it.  What are the implications on the maintain aspect ratio / full scale manual scale in the LGM IDE, will these still function? etc.
Gotta give us more info :D



« Last Edit: May 25, 2014, 02:01:08 AM by Darkstar2 » Logged
Offline (Unknown gender) TheExDeus
Reply #2 Posted on: May 25, 2014, 02:38:49 AM

Developer
Joined: Apr 2008
Posts: 1872

View Profile
I honestly can't tell why two windows were used (maybe because of your mentioned fullscreen problems), but I do know that OGL sometimes require you to make a window twice at startup. That is because if you want to get parameters from GL context, then you need to create it, which you can only do with a window. Then you read the parameters, destroy the context + window and create a new context + window using the parameters you got. I don't think we use for that though. That is required only when you want to change pixel depth or something and see if the user's GPU supports it.
Logged
Offline (Male) Goombert
Reply #3 Posted on: May 25, 2014, 03:35:20 AM

Developer
Location: Cappuccino, CA
Joined: Jan 2013
Posts: 3110

View Profile
Darkstar2, actually it's kind of nice really because it means most GM game don't fuck with your display resolution, it would extremely piss me off if they did. But you can still do real full screen and set the display resolution and let the display handle the black bars if you really want, this is also why I'm suggesting we not worry about the window color becoming the background color.

But the whole point here is that I can emphasize enough, aspect ratio doesn't do shit on XLIB right now, and we can't do this on all platforms, it needs to be more cross-platform so we have consistent behavior. But if we really want I'm sure we could find a way to hack the fuck out of XLIB to do it, but then our code is just shit for every platform instead of simplistic.

Harri, yes that is exactly what Josh said that it was because of OpenGL, but he did not elaborate before leaving. At any rate, my tests worked fine with using only one window and OpenGL, literally everything was working fine, I was just working on fixing it up before I decided to revert it and ask everyone else's opinion.
« Last Edit: May 25, 2014, 03:58:31 AM by Robert B Colton » Logged
I think it was Leonardo da Vinci who once said something along the lines of "If you build the robots, they will make games." or something to that effect.

Offline (Unknown gender) Darkstar2
Reply #4 Posted on: May 25, 2014, 03:54:31 AM
Member
Joined: Jan 2014
Posts: 1244

View Profile Email
Darkstar2, actually it's kind of nice really because it means most GM game don't fuck with your display resolution, it would extremely piss me off if they did. But you

I completely disagree with you.  You'd probably be pissed at most commercial games out there, some impose a minimum resolution others offer you a choice/menu.
Nothing wrong in changing screen res as long as you set it back to its origin once game ends.  Why the HELL would anybody be pissed off if it did not mess with anything else ? In ENIGMA so far I don't see that screen res changing messes anything up.

So which is it now I am confused, does ENIGMA do real FS or fake ? What do you define as "fake" ? is it my understanding that you smply resize the window instead of actually doing a real FS ? that was utter shit, and that was how it was done in older GM.

Quote
But the whole point here is that I can emphasis enough, aspect ratio doesn't do shit on XLIB right now, and we can't do this on all platforms, it needs to be more cross-platform so we have consistent behavior. But if we really want I'm sure we could find a way to hack the fuck out of XLIB to do it, but then our code is just shit for every platform instead of simplistic.

Hmm looks like we are getting into some YYG scenarios here, I guess it's up to developers to decide if they want to sacrifice windows for multi platform (as YYG did) or leave things as they are, working at fixing things separately, or for windows first, etc.) In my opinion, since there are probably more windows users, more emphasis should be placed on platform used the most, for now.

Quote
Harri, yes that is exactly what Josh said that it was because of OpenGL, but he did not elaborate before leaving. At any rate, my tests worked fine with using only one window and OpenGL, literally everything was working fine, I was just working on fixing it up before I decided to revert it and ask everyone else's opinion.

Did you run any bench ? did we gain some performance gains ?

The lack of blanking between room changes could make for some interesting seamless effects.

Logged
Offline (Male) Goombert
Reply #5 Posted on: May 25, 2014, 04:08:16 AM

Developer
Location: Cappuccino, CA
Joined: Jan 2013
Posts: 3110

View Profile
Quote from: Darkstar2
So which is it now I am confused, does ENIGMA do real FS or fake ? What do you define as "fake" ? is it my understanding that you smply resize the window instead of actually doing a real FS ? that was utter shit, and that was how it was done in older GM.
Both GM and ENIGMA use "fake fullscreen" so say you have a room 640x480. When you fullscreen the game the parent window will be 1920x1080 or w/e your display resolution is and stretch the 640x480 child window with the graphics context to fit the area based on your aspect ratio. In any other game it will set your display resolution to 640x480 and just make the 1 window that has a graphics context fill the whole window. The "black bars" are then handled by your display monitor.

What I am saying is this is possible to emulate by filling the whole screen with the window, and using the viewport controls to emulate the aspect ratio. The only problem is OpenGL and Direct3D don't have limits for clearing the backbuffer to a color. So you end up with the whole window being cleared to your background color, whereas you only want the viewport area cleared to the background color, and you want the "black bar" area cleared to the window background color. When not in fullscreen this is not a problem for Direct3D because its view frustum is an actual matrix and is bounded, in OpenGL you have to use glScissor, but both systems will clear outside the viewport for some reason when in fullscreen.
http://www.opengl.org/sdk/docs/man2/xhtml/glClear.xml
https://www.khronos.org/opengles/sdk/docs/man/xhtml/glScissor.xml
http://msdn.microsoft.com/en-us/library/windows/desktop/bb172632%28v=vs.85%29.aspx

Anyway, people like me don't like this, because well, GM games have a tendency to be shit, be fullscreen, not freeze on lose focus, and capture the mouse and force it to the center of the window, so you have absolutely no way of ALT+Tabbing because of the lack of foresight by budding game developers.

Quote from: Darkstar2
Hmm looks like we are getting into some YYG scenarios here, I guess it's up to developers to decide if they want to sacrifice windows for multi platform (as YYG did) or leave things as they are, working at fixing things separately, or for windows first, etc.) In my opinion, since there are probably more windows users, more emphasis should be placed on platform used the most, for now.
What the hell are you talking about? I'm talking about sacrificing 1 uneeded window, there is just no need for our code to be designed around working two window handles. This does not rule out the possibility of a window_create function. I am actually certain GM has been doing it this way since 8.1, I just can't emulate the "black bars" in full screen mode for some odd reason.

Quote from: Darkstar2
Did you run any bench ? did we gain some performance gains ?
No I did not, I doubt it would affect performance much unless you have a really shitty card and it don't like clearing the background of two windows.

Also, Harri, correct me if I've said anything wrong.
« Last Edit: May 25, 2014, 04:12:34 AM by Robert B Colton » Logged
I think it was Leonardo da Vinci who once said something along the lines of "If you build the robots, they will make games." or something to that effect.

Offline (Unknown gender) Darkstar2
Reply #6 Posted on: May 25, 2014, 11:56:40 AM
Member
Joined: Jan 2014
Posts: 1244

View Profile Email
Both GM and ENIGMA use "fake fullscreen" so say you have a room 640x480. When you fullscreen the game the parent window will be 1920x1080 or w/e your display resolution is and stretch the 640x480 child window with the graphics context to fit the area based on your aspect ratio. In any other game it will set your display resolution to 640x480 and just make the 1 window that has a graphics context fill the whole window. The "black bars" are then handled by your display monitor.

Exactly.  In my opinion this the best option, letting your display handling it. Nothing wrong with seeing black bars to the left and right.  If the game sets 16:9 compatible resolutions, the display automatically switches to 16:9, that's how commercial games work.   If I were to now set my monitor to 800x600 I would see black bars left and right.  It's not that bad I mean people were using CRT for years at that ratio :P  and if I revert to my native resolution, the whole screen fills.   I think any emulation / faking is unnecessary.  Most games don't do that.  Also was not aware GMS did that, I thought they had gotten rid of the fake FS shit ages ago.  From what I recall, real FS is faster (rendering, 3D, etc.).  and last time I checked I had no issues alt-tabbing from commercial games.

Now emulating by using viewport etc, this would have you take control over viewport.  What if we make games and we need to manually manipulate viewport etc how will it be possible since it will already be used and locked.

Quote
end up with the whole window being cleared to your background color,

I think that would be quite ugly.  Personally I believe black bars would be a better contrast against any colour.  Personally don't like the idea of filling the entire area with the background colour.....lol that would make it look sort of like Commodore 64 with its foreground/background thingy.

Quote
Anyway, people like me don't like this, because well, GM games have a tendency to be shit, be fullscreen, not freeze on lose focus, and capture the mouse and force it to the center of the window, so you have absolutely no way of ALT+Tabbing because of the lack of foresight by budding game developers.

True :D but that is up to the developer and should always be.  Personally I would have the game automatically go into a pause menu if lost focus and everything paused, AND at the end game I would have it returned to whatever resolution the screen was originally before running the game.  I am aware of certain bad habits people did in GM games.

Also there is one scenario where it is required to manually change screen res within a game in ENIGMA..... One of the changes you made to allow for dual screens, had the side effect that if your viewing area is larger than your display res, the area would be zoomed out - Remember this was seen in TKG's alien game, it scaled fine in GMS but not in ENIGMA, and I later found out that I could fix this problem by either setting my screen resolution = to or greater than the view area of the game.  So this is an example where changing res internally would be critical.

Quote
What the hell are you talking about? I'm talking about sacrificing 1 uneeded window, there is just no need for our code to be designed around working two window handles. This does not rule out the possibility of a window_create function. I am actually certain GM has been doing it this way since 8.1, I just can't emulate the "black bars" in full screen mode for some odd reason.

Sure I mean getting rid of unneeded stuff particularly if it has no impact on other things would be a good thing, however not if it causes issue with the views/ports options in the IDE or functions, allowing a developer to fully control them.  Also I have followed GM since the days of Mark Overmars, until now......and I'm quite sure they did major changes to the display/rendering, one of them now is handling real full screen.  I' quite sure they don't use an extra window.

Quote
No I did not, I doubt it would affect performance much unless you have a really shitty card and it don't like clearing the background of two windows.

I think my GF 660GTXTi SuperClocked handles it fine :P But what about a person running your game using onboard video or an old gfx card. ?  Also what about complex games with lots of rendering ?

I think I remember now reading lots on the topic of real/fake fullscreen think it was mentioned that the real FS have higher priority or some shit related to DX, priority or something like that I can't quite remember, it was so long ago.   I remember on older games when alt-enter to put game in windows mode it would run slower and going back to real fullscreen made it faster again, giving it highest priority as opposed to shared, something along those lines.

I have not had a chance to test the new changes yet.  Will do so later, but I'm really puzzled about Ben's sprite issue, it's mysterious I think that there is something outside ENIGMA/LGM causing his issues.

So maybe TKG will be happy when he comes back in a few months from his trip to the sun lol.
Logged
Offline (Male) Goombert
Reply #7 Posted on: May 25, 2014, 06:46:05 PM

Developer
Location: Cappuccino, CA
Joined: Jan 2013
Posts: 3110

View Profile
Quote from: Darkstar2
Now emulating by using viewport etc, this would have you take control over viewport.  What if we make games and we need to manually manipulate viewport etc how will it be possible since it will already be used and locked.
They theoretically wouldn't be "locked", just leave your aspect ratio to Full Scale, and it won't touch your viewports.

Quote from: Darkstar2
From what I recall, real FS is faster (rendering, 3D, etc.).
Of course it is, because it's lowering the display resolution and not stretching a low resolution picture over a big resolution display.

Quote from: Darkstar2
and last time I checked I had no issues alt-tabbing from commercial games.
Right, commercial games, I'm talking about games made with GM, and made by noobs, so that is a red herring. I do not agree with the level of sandboxing YYG does, but I do agree with some default sandboxing like we saw with the very powerful GM8 and lower.

Quote from: Darkstar2
I think that would be quite ugly.  Personally I believe black bars would be a better contrast against any colour.  Personally don't like the idea of filling the entire area with the background colour.....lol that would make it look sort of like Commodore 64 with its foreground/background thingy.
It doesn't do that in windowed mode, I didn't say it was supposed to do that, in fact, I'm wanting someone else like Harri to weigh in and tell my why or how to fix it.

Quote from: Darkstar2
True :D but that is up to the developer and should always be.
Right, I never once mentioned removing functionality, the developer can just set Full Scale aspect ratio and use the display_* functions if they want to do real fullscreen, just like GM8.

Quote from: Darkstar2
One of the changes you made to allow for dual screens
I didn't make any changes, ENIGMA has always functioned that way, I in fact refused to change anything.

Quote from: Darkstar2
Sure I mean getting rid of unneeded stuff particularly if it has no impact on other things would be a good thing, however not if it causes issue with the views/ports options in the IDE or functions, allowing a developer to fully control them.  Also I have followed GM since the days of Mark Overmars, until now......and I'm quite sure they did major changes to the display/rendering, one of them now is handling real full screen.  I' quite sure they don't use an extra window.
They either use a second window, which for some reason people think you need for OpenGL, or they emulate it in the viewport, you can tell that GM games don't change your display resolution by default.

Quote from: Darkstar2
I think I remember now reading lots on the topic of real/fake fullscreen think it was mentioned that the real FS have higher priority or some shit related to DX, priority or something like that I can't quite remember, it was so long ago.   I remember on older games when alt-enter to put game in windows mode it would run slower and going back to real fullscreen made it faster again, giving it highest priority as opposed to shared, something along those lines.
Yes that would be true for multi-tasking, because guess what, you can't multi-task fullscreen applications, hello Metro!
« Last Edit: May 25, 2014, 06:48:35 PM by Robert B Colton » Logged
I think it was Leonardo da Vinci who once said something along the lines of "If you build the robots, they will make games." or something to that effect.

Pages: 1
  Print