Pages: 1 2 »
  Print  
Author Topic: window_handle() is messed up  (Read 4719 times)
Offline (Male) time-killer-games
Posted on: September 15, 2014, 01:26:11 PM

Contributor
Location: Virginia Beach
Joined: Jan 2013
Posts: 1166

View Profile Email
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..


This is what it should do, which is what it does in GameMaker 8.1 (and GMStudio with barely any code changed)..


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
« Last Edit: September 16, 2014, 04:07:41 PM by time-killer-games » Logged
Offline (Male) Goombert
Reply #1 Posted on: September 15, 2014, 03:24:16 PM

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

View Profile
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.
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 (Male) time-killer-games
Reply #2 Posted on: September 15, 2014, 03:29:25 PM

Contributor
Location: Virginia Beach
Joined: Jan 2013
Posts: 1166

View Profile Email
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!
Logged
Offline (Male) Goombert
Reply #3 Posted on: September 15, 2014, 03:42:11 PM

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

View Profile
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.
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 (Male) time-killer-games
Reply #4 Posted on: September 15, 2014, 03:46:46 PM

Contributor
Location: Virginia Beach
Joined: Jan 2013
Posts: 1166

View Profile Email
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...
« Last Edit: September 15, 2014, 04:03:15 PM by time-killer-games » Logged
Offline (Unknown gender) Darkstar2
Reply #5 Posted on: September 15, 2014, 08:07:36 PM
Member
Joined: Jan 2014
Posts: 1244

View Profile Email
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.

Logged
Offline (Male) time-killer-games
Reply #6 Posted on: September 15, 2014, 08:49:29 PM

Contributor
Location: Virginia Beach
Joined: Jan 2013
Posts: 1166

View Profile Email
Which is exactly why I said what I did in my post above yours, Darkstar2...
Logged
Offline (Male) Goombert
Reply #7 Posted on: September 15, 2014, 10:36:16 PM

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

View Profile
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.
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) sorlok_reaves
Reply #8 Posted on: September 15, 2014, 10:52:49 PM
Contributor
Joined: Dec 2013
Posts: 261

View Profile
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.
}
Logged
Offline (Male) time-killer-games
Reply #9 Posted on: September 16, 2014, 02:54:25 PM

Contributor
Location: Virginia Beach
Joined: Jan 2013
Posts: 1166

View Profile Email
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.
« Last Edit: September 16, 2014, 02:57:14 PM by time-killer-games » Logged
Offline (Unknown gender) Darkstar2
Reply #10 Posted on: September 16, 2014, 10:09:06 PM
Member
Joined: Jan 2014
Posts: 1244

View Profile Email
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 ????

Logged
Offline (Male) Goombert
Reply #11 Posted on: September 16, 2014, 10:17:26 PM

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

View Profile
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.
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 #12 Posted on: September 17, 2014, 01:09:54 AM
Member
Joined: Jan 2014
Posts: 1244

View Profile Email
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.
Logged
Offline (Unknown gender) TheExDeus
Reply #13 Posted on: September 17, 2014, 02:59:01 AM

Developer
Joined: Apr 2008
Posts: 1872

View Profile
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.
« Last Edit: September 17, 2014, 03:00:32 AM by TheExDeus » Logged
Offline (Unknown gender) Darkstar2
Reply #14 Posted on: September 17, 2014, 06:17:42 PM
Member
Joined: Jan 2014
Posts: 1244

View Profile Email
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 ?
Logged
Pages: 1 2 »
  Print