ENIGMA Forums

Outsourcing saves money => Issues Help Desk => Topic started by: time-killer-games on September 15, 2014, 01:26:11 pm

Title: window_handle() is messed up
Post by: time-killer-games on September 15, 2014, 01:26:11 pm
I created 3 extensions for the GameMaker:Marketplace, all of which work for Windows in GameMaker:Studio and GameMaker 8.1. I tried them in ENIGMA and they all share the same problem - window_handle() is not doing what it should. Instead of it being used to get the handle of the main game window, it's getting the window handle of the embedded viewport window.

DLL#1 - WindowStyler.dll - https://dl.dropboxusercontent.com/u/79893663/dll's/windowstyler/Downloads/WindowStyler.zip
My WindowStyler extension for example should change the window border to the style of choice, and this is what I get in ENIGMA..
(https://dl.dropboxusercontent.com/u/79893663/dll's/windowstyler/Screenshots/Screenshot%201.png)

This is what it should do, which is what it does in GameMaker 8.1 (and GMStudio with barely any code changed)..
(https://marketplacecdn.yoyogames.com/images/assets/655/screenshots/1746_original.png?1410562054)

Unfortunately due to how my other two extensions work, they rely on WindowStyler in order to function properly..
DLL#2 - WebBrowser.dll - https://dl.dropboxusercontent.com/u/79893663/DLL%27s/WebBrowser/downloads/WebBrowser.zip
DLL#3 - HostExe.dll - https://dl.dropboxusercontent.com/u/79893663/DLL%27s/HostExe/downloads/HostExe.zip

If you try either of those two extensions in 8.1 or Studio, they run in fake fullscreen, which is required because true fullscreen won't allow the external windows (browsers, exes, etc) to embed. In ENIGMA, even though they are set to be in fake fullscreen, they are in regular windowed mode. This is because WindowStyler is changing the window border style of ENIGMA's embedded view window, not the actual game window.

Please fix this. A bug report has been submitted - http://enigma-dev.org/tracker/index.php?id=820
The download links to my 3 extensions in this topic were written specifically to work in 8.1 & ENIGMA.
To download the GMStudio-specific versions, look for them at the GMMarketplace..
https://marketplace.yoyogames.com/publishers/225/samuel-venable
Title: Re: window_handle() is messed up
Post by: Goombert on September 15, 2014, 03:24:16 pm
Please see my comments on GitHub.
https://github.com/enigma-dev/enigma-dev/issues/820

What we need to do is remove the child window and only have 1 window, but this will temporarily remove scaling options. Josh approves of removing the duplicate window.

Additionally this issue is not as bad as it looks, it is good news that extensions themselves do in fact work.
Title: Re: window_handle() is messed up
Post by: time-killer-games on September 15, 2014, 03:29:25 pm
Thanks. I read about this second window thingy before and I was certain that was the problem, and I was right. Whenever this gets fixed I'd love to be informed of the update.

Robert, just let me know preferably on Facebook, that'd be great!
Title: Re: window_handle() is messed up
Post by: Goombert on September 15, 2014, 03:42:11 pm
I just want you to know a couple of things.

1) I am making this the first thing I do when I have free time.
2) If you wrote this extension for say Mac or Linux it would actually work because those platforms use 1 window and do not have scaling options implemented.
3) This will remove the scaling options from Win32 but fix several other window issues as a result, I can guarantee.
4) This will mean no platform will have scaling options, they will all behave as if set to "Full Scale", and a long discussion regarding their reimplementation will have to take place, eg. application_surface

And I will send you a message on Facebook when I send the pull request and this is fixed. I've wanted to remove the 2nd window for some time, I actually had a pull request for it before but turned back at the last minute from having it merged.
Title: Re: window_handle() is messed up
Post by: time-killer-games on September 15, 2014, 03:46:46 pm
A better temporary fix IMHO, if you could tell me how to edit the return value of window_handle() myself?

My extensions are windows only.

I could simply do...
Code: [Select]
double window_handle()
{
     return (HWND)(DWORD)FindWindow("TMain",NULL);
}
...but I don't know where to put that, I search all the code in the enigma-dev directory with only one reference found for "window_handle".

This is what that reference says...
Code: [Select]
unsigned long long window_handle();
...that is not how to declare a new function at all. There's no braces {} nor anything to put between them. It's confusing.

Changes I make I don't want merged/public. I'm just gonna do this until we find a better alternative than multiple windows on Windows...
Title: Re: window_handle() is messed up
Post by: Darkstar2 on September 15, 2014, 08:07:36 pm
Please see my comments on GitHub.
https://github.com/enigma-dev/enigma-dev/issues/820

What we need to do is remove the child window and only have 1 window, but this will temporarily remove scaling options. Josh approves of removing the duplicate window.

Additionally this issue is not as bad as it looks, it is good news that extensions themselves do in fact work.

Why the hell would you want to fix a problem to create a new one, scaling is important.  This creates a mess.  You would want games to scale to whatever resolution the person is using, for instances where you do not want to force people to use a given resolution.

You should weigh how more important scaling is vs. this function which most people don't even use.

Title: Re: window_handle() is messed up
Post by: time-killer-games on September 15, 2014, 08:49:29 pm
Which is exactly why I said what I did in my post above yours, Darkstar2...
Title: Re: window_handle() is messed up
Post by: Goombert on September 15, 2014, 10:36:16 pm
Yes one thing at a time, scaling is currently implemented improperly this is why there are also so many other window issues. It has nothing to do with whether I want to remove scaling or not, the basic barebones of the window system is broke.
Title: Re: window_handle() is messed up
Post by: sorlok_reaves on September 15, 2014, 10:52:49 pm
I can confirm that scaling (+views) sometimes behaves badly only on the Windows backend. I've been trying to fix this problem for Iji beta 2, but if the secondary window is removed, that will actually make my fix much, much easier.

As a workaround for those who need scaling, you can always just fake it with views. This is what I use:

Code: [Select]
window_set_fullscreen(true);
 
  //Constants for the view you want to change.
  rmId = 1; //Can't be the current room.
  vInd = 0; //View to change
  dW = display_get_width();
  dH = display_get_height();
  vW = 800;
  vH = 600;
  sH = -1; //Speed
  sV = -1;
  vX = 32;
  vY = 32;
  bH = 400; //Border
  bV = 300;
  objTrk = -1;

  //Different scaling modes
  mode = 1;
 
  if (mode==3) {
    //Stretch it across the entire display (leads to distortions).
    dW2 = dW;
    dH2 = dH;
  } else {
    //Ensure no stretching, center.
    scl = min(dW/vW, dH/vH);
    if (mode==2) {
      //Forces perfect scaling.
      scl = floor(scl);
    }
    dW2 = scl * vW;
    dH2 = scl * vH;
  }
 
  //Now actually set it.
  room_set_view(rmId, vInd, true,
    vX, vY, vW, vH,
    floor((dW-dW2)/2), floor((dH-dH2)/2), dW2, dH2,
    bH, bV, sH, sV, objTrk
  );

  //You will need to switch to the new room to see the effect.
}
Title: Re: window_handle() is messed up
Post by: time-killer-games on September 16, 2014, 02:54:25 pm
Wouldn't rendering to a surface like YYG be the easiest short term fix for everyone? That's not good for performance but it's better than keeping what we have now which is completely broken.
Title: Re: window_handle() is messed up
Post by: Darkstar2 on September 16, 2014, 10:09:06 pm
Wouldn't rendering to a surface like YYG be the easiest short term fix for everyone? That's not good for performance but it's better than keeping what we have now which is completely broken.

I'd trade temporary scaling issues over performance anytime TKG, let's not emulate YYG's incompetence by any means, we want to be faster than YYG not emulate their stupidity.  I'm sure if they ran a poll most people would not accept this if it meant a trade-off in performance.

If I understood correctly the removal of child window would affect proportional scaling right but not the full scale stretch to screen resolution right ????

Title: Re: window_handle() is messed up
Post by: Goombert on September 16, 2014, 10:17:26 pm
Guys let's not overtrivialize this, it takes about an hour of work to fix this I just don't have the time right at the moment. Clearly we should not be using two windows, when the child window is removed all games will behave as if the scaling option is set to "Full Scale". Then we reimplement the options with application_surface and provide an option to completely disable generation of application_surface altogether, and in the event of the hardware not supporting surfaces it will resort to "Full Scale" mode and leave a message in the debug log. First I must test though if the "Full Scale" option in Studio does still generate the application_surface or not, correct me if I am wrong but I believe it always does, though in ENIGMA I may just make that point to the default framebuffer since with "Full Scale" mode there is no real need to generate a surface you already have that behavior with the default framebuffer.
Title: Re: window_handle() is messed up
Post by: Darkstar2 on September 17, 2014, 01:09:54 am
Robert I remember when we were working on the font glitch fix and you stumbled upon this child window thing, I also found some bugs in relation to improper window drag/scaling, will the removal of child window fix this bug as well?

I guess full scale is better than nothing, though for people who want fixed or proportional there will have to be an alternative.  And yes YYG now uses surfaces now for everything.  But once these changes are made, LGM will have to be changed to temporarily grey out the other scaling option and leave only full scale option active or no scaling options.
Title: Re: window_handle() is messed up
Post by: TheExDeus on September 17, 2014, 02:59:01 am
Fullscreen - with stretching and without - has always worked in ENIGMA when using view functions. I think after the removal of the second window it will still work. The bugs, as far as I am aware, are in the way we set the whole thing up, where can't use view functions because of some chicken and the egg problem. After the game is started, I think you can get all the different behaviors you want using the available functions, just like sorlok posted.
Also, using application_surface will have negligible performance hit. It involves 1 FBO (so video memory consumed equals to the size of the framebuffer, which for 32bit 1920x1080 is about 7.9mb of VRAM, but it will be slightly more because of depthbuffer, alpha and things like that) and drawing two triangles (the quad for the surface itself). But it will allow not only different scaling options, but also things like post-processing effects a lot easier.
Title: Re: window_handle() is messed up
Post by: Darkstar2 on September 17, 2014, 06:17:42 pm
Yes Harri but in terms of FPS, what the hit in performance - can you estimate what the performance loss would be like  ? for more complex games does that mean bigger performance loss?

Do we want to emulate GameMaker's performance or  do we want to be faster and better ?
Title: Re: window_handle() is messed up
Post by: TheExDeus on September 18, 2014, 06:43:39 am
In terms of FPS, it probably would be 0. Could depend on the hardware, because on older PC's rendering to FBO is a little slower than rendering on main framebuffer directly. But on any decent hardware there should be 0 difference in performance. You can actually try it yourself by drawing on a surface and then drawing the surface on the screen. I just tried on my very old laptop with ATI card, and when I draw 10000 objects with sprites, I get 7fps without surfaces, and 7fps when drawing on a surface. If I draw 1000 object with sprites, I get 71fps without surfaces, and 68fps when drawing with surfaces. As I said, the difference is negligible. The only performance hit I can imagine is switching between render targets. On any newer hardware the difference should be even smaller or 0. I will try on my home PC as well.

Even if it had a minor speed impact, application_surface is a feature I very much would like. It allows for post-process effects (you know, like bloom, color changes, motion blur etc.) without the need of managing the rendering on a surface yourself.
Title: Re: window_handle() is messed up
Post by: time-killer-games on September 18, 2014, 11:46:47 am
That's really good news HaRRi! It's good to know. I don't know where I got the idea it would make games slower, I'm glad I was wrong. :D
Title: Re: window_handle() is messed up
Post by: Goombert on September 19, 2014, 03:09:38 pm
Ok well I've got nothing but good news, the implementation is working great and fixes numerous bugs.
https://github.com/enigma-dev/enigma-dev/pull/821

Some of our basic window functions were also break, for instance window_get_width() was reporting the minimized window size when in fullscreen. I have to run through and fix a lot of this for XLIB as well. All the scaling is now implemented through our viewports.
Title: Re: window_handle() is messed up
Post by: sorlok_reaves on September 19, 2014, 03:42:16 pm
for instance window_get_width() was reporting the minimized window size when in fullscreen

Ah, that might explain another bug I was running into. I'll test this later this weekend. Thanks!
Title: Re: window_handle() is messed up
Post by: Darkstar2 on September 19, 2014, 07:50:19 pm
Thanks Robert, really good stuff happening with ENIGMA.

Cheers
Title: Re: window_handle() is messed up
Post by: time-killer-games on September 19, 2014, 09:55:45 pm
Holy pussy-dick hybrid! Fuck yeah, son!!!
Title: Re: window_handle() is messed up
Post by: Goombert on September 21, 2014, 08:57:09 pm
Alright everyone sorlok offered some testing for other platforms and I have decided to merge the pull request. Please fetch the changes and test them TKG and everyone!
https://github.com/enigma-dev/enigma-dev/pull/821
Title: Re: window_handle() is messed up
Post by: sorlok_reaves on September 21, 2014, 09:07:29 pm
You might want to wait 2 minutes on that; I just found a tiny bug in the Windows backend (forgot to re-introduce extern int windowColor). I'll issue a pull request as soon as this test build completes.
Title: Re: window_handle() is messed up
Post by: sorlok_reaves on September 21, 2014, 11:20:44 pm
Ok, the fix has been merged. Feel free to test now.

FYI, there's a small regression on OS-X, whereby the background color does not display properly for windows that have out-of-bounds regions (usually only happens when views force a smaller region).

I can probably fix this (related to windowColor), and I don't think it should hold up the merge.
Title: Re: window_handle() is messed up
Post by: Goombert on September 21, 2014, 11:47:10 pm
That's actually not a regression sorlok, we now like Studio and GM8.1< create the backbuffer for the whole window, since well we only have 1 window. So we have to clear the window when it is resized with the window color, and we also need the native implementation for window color so that it shows while resizing the window. You just have to copy it to the graphics bridges for Cocoa, I can't test so that is why I haven't.

https://github.com/RobertBColton/enigma-dev/blob/master/ENIGMAsystem/SHELL/Bridges/xlib-OpenGL1/graphics_bridge.cpp#L72
Title: Re: window_handle() is messed up
Post by: sorlok_reaves on September 22, 2014, 12:39:22 pm
Shouldn't be too hard; I'll have a look.