Migration to FBO

[Michael Lobko-Lobanovsky]

Patrice,

When in full screen, there are two glitches that I think should be corrected in v2.5.

• There is still one wallpaper image line missing at the screen bottom. (see image 1 below) To fix this, goto ToggleFullScreen() in Main.cpp and add as follows:
  
  ........
          // PAT: 02-12-2018
          SetWindowLongPtr(gP.hGL, GWL_STYLE, WS_POPUP | WS_VISIBLE);                                          // PAT: 02-12-2018
          MoveWindow(gP.hGL, 0, 0, screenWidth, screenHeight + 1, FALSE);                                     // PAT: 02-12-2018
          SetWindowPos(gP.hOverlay, HWND_TOPMOST, 0, 0, 0, 0, SWP_NOMOVE | SWP_NOSIZE);                        // PAT: 02-12-2018
          if (IsWindow(go.hTip)) { SetWindowPos(go.hTip, HWND_TOPMOST, 0, 0, 0, 0, SWP_NOMOVE | SWP_NOSIZE); } // PAT: 02-12-2018
  ........
  
  
• When trying to save a screenshot, centering the SaveFile dialog on the screen causes hGL displacement that can't be corrected other than by exiting the full screen mode. (see image 2 below) To fix this, goto gl_TimerView() in Main.cpp and add as follows:
  
  void gl_TimerView() {
      static DWORD AnimDelay, ReportDelay;
      //DWORD AniCount = GetTickCount();
      gP.AniTick = GetTickCount();
      if (gP.openDialog) { // Center OpenDialog
          HWND hWnd = GetForegroundWindow();
          if ((hWnd != gP.hMain) && (hWnd != gP.hGL) && IsWindowVisible(hWnd)) {
              RECT r; GetWindowRect(hWnd, &r);
  ........

[Michael Lobko-Lobanovsky]

Patrice,

Can your skinned controls like e.g. list views change their visible appearance depending on whether they are enabled or disabled?

[Patrice Terrier]

There is still one wallpaper image line missing at the screen bottom.

This seems to occure only with some specific wallpapers.

For example, if you select a white background into Windows, and the Black.png for wallpaper in OR, then in fullscreen mode, you won't see any white line at the bottom, at least by me. Also try using a full HD wallpaper rather than 1024x512.

Can your skinned controls like e.g. list views change their visible appearance depending on whether they are enabled or disabled?

In that case, the best solution would be to paint a disabled window hover the control, this is what i am doing to simulate a popup modal dialog (to see the effect in action, just display the About dialog box, then you won't be able to click outside of the dialog).

[Michael Lobko-Lobanovsky]

This seems to occure only with some specific wallpapers.

For example, if you select a white background into Windows, and the Black.png for wallpaper in OR, then in fullscreen mode, you won't see any white line at the bottom, at least by me. Also try using a full HD wallpaper rather than 1024x512.

Please look at the image below. Anyway, why not just fix that glitch if we can? I'm not seeing any adverse effects of that extra pixel added to the height on my monitors. Do you see any on yours?

In that case, the best solution would be to paint a disabled window hover the control, this is what i am doing to simulate a popup modal dialog (to see the effect in action, just display the About dialog box, then you won't be able to click outside of the dialog).

Got it, thanks for the tip.

[Patrice Terrier]

2.When trying to save a screenshot, centering the SaveFile dialog on the screen causes hGL displacement that can't be corrected other than by exiting the full screen mode. (see image 2 below) To fix this, goto gl_TimerView() in Main.cpp and add as follows:

I am unable to reproduce this behavior on W10.

Does this occures only when you are in full screen mode?

In full screen mode we should consider the size of the gP.hGL window rather than the size of gP.hMain.
Here is what to do:

void gl_TimerView() {
    static DWORD AnimDelay, ReportDelay;
    //DWORD AniCount = GetTickCount();
    gP.AniTick = GetTickCount();
    if (gP.openDialog) { // Center OpenDialog
        HWND hWnd = GetForegroundWindow();
        if ((hWnd != gP.hMain) && IsWindowVisible(hWnd)) {
            RECT r; GetWindowRect(hWnd, &r);
            long w = r.right - r.left;
            long h = r.bottom - r.top;
            if (gP.nIsFullScreen) {          // PAT: 04-11-2018
                GetWindowRect(gP.hGL, &r);
            } else {
                GetWindowRect(gP.hMain, &r);
            }
            r.right = (r.right - r.left - w) / 2;
            r.bottom = (r.bottom - r.top - h) / 2;
            long x = r.left + r.right;
            long y = r.top + r.bottom;
            MoveWindow(hWnd, x, y, w, h, TRUE);
            gP.openDialog = 0;
        }
    }

To create a disabled window use this couple of API:
HWND hGFI = skCreateDW (hWndToDisable);
skDestroyDW (hGFI);
To learn more about it, read this
https://forum.powerbasic.com/forum/user-to-user-discussions/sdk-programming/59770-dim-the-disabled-windows

BTW, i have added the extra pixel for the full screen mode

[Michael Lobko-Lobanovsky]

Patrice,

I am unable to reproduce this behavior on W10.

That's correct, the glitch isn't observed under Win 10 but it is seen Under Win 7 on both nVidia and ATi.

Does this occures only when you are in full screen mode?

Yes, only when in full screen.

Here is what to do:

Sorry but your fix doesn't help under Win 7: although the hGL window doesn't drift away any more but the SaveAs dialog stays off-center in the top left corner of the screen. My fix works under both OSes and doesn't seem to care whether the mode is windowed or full screen, as the full screen size is large enough to make the differences in hMain and hGL, and hence the dialog displacement error relative to the screen center, imperceptible.

Occam's razor, my friend; please follow my earlier suggestion.

To create a disabled window use this couple of API:

Thank you very much for those! The About dialog example didn't help because the actual APIs were hidden in the info box implementation, and re-writing the entire blob of PB code just for one tiny disabled window was too much pain in the back.

BTW, i have added the extra pixel for the full screen mode

Excellent!

[Patrice Terrier]

OK, i followed your advice, because i have no way to check it anymore on W7.

Code: [Select]

    if (gP.openDialog) { // Center OpenDialog
        HWND hWnd = GetForegroundWindow();
        //if ((hWnd != gP.hMain) && IsWindowVisible(hWnd)) {
        if ((hWnd != gP.hMain) && (hWnd != gP.hGL) && IsWindowVisible(hWnd)) {  // MLL: 04-11-2018 (for W7 compatibility)
            RECT r; GetWindowRect(hWnd, &r);
            long w = r.right - r.left;
            long h = r.bottom - r.top;
            if (gP.nIsFullScreen) {          // PAT: 04-11-2018
                GetWindowRect(gP.hGL, &r);
            } else {
                GetWindowRect(gP.hMain, &r);
            }
            r.right = (r.right - r.left - w) / 2;
            r.bottom = (r.bottom - r.top - h) / 2;
            long x = r.left + r.right;
            long y = r.top + r.bottom;
            MoveWindow(hWnd, x, y, w, h, TRUE);
            gP.openDialog = 0;
        }
    }
Note: On W10 because of the border width used by the Windows theme, in full screen mode the displacement error is much more visible.

Here is an example to disable the wallpaper listbox :
HWND hGFI = skCreateDW(GetDlgItem(gP.hMain, IDC_LISTBOX));
it must be done AFTER the skin theme has been applied to the main window

[Michael Lobko-Lobanovsky]

... i have no way to check it anymore on W7.

I have both 64-bit Win 7 and 10 on two different boxes with nVidia geForce video adapters. You can rely on my reports in this regard.

Note: On W10 because of the border width used by the Windows theme, in full screen mode the displacement error is much more visible.

OK OK, your name stays in the list of fixes.

Here is an example to disable the wallpaper listbox :

How did you know it's going to be the wallpaper list box??  

[Patrice Terrier]

How did you know it's going to be the wallpaper list box??

For the purpose of post-processing, we must provide specific materials, and of course avoid the changing of the wallpaper background, just like for my BassBox/MediaBox visual plugins 

I am stamped with a few new models, but because of my foot i have to spend several hours in my bed, far away from my keyboard 

About the disabled window, we will probably need a specific one, to follow the moving of the main window, let me know when you need it, and i shall write it or perhaps make a change into WinLIFT (have to see the easiest one).

[Michael Lobko-Lobanovsky]

I'm sorry for your bad times ... How's your foot doing, my friend?

[Patrice Terrier]

Going slowly better, i can now put again my right foot on the floor, thank you...

[Patrice Terrier]

Mike--

Ok, i am finally asking about Jessica

What FX did you put into FX1 to FX9, and the 3 horizontal sliders ?

...

[Michael Lobko-Lobanovsky]

Oh Patrice, you must be definitely getting better now that you've started to take interest in the opposite sex!

Those are just handlers I might need when experimenting with various post-processing effects and their parameters in real time in any combination. They have no particular bindings yet, hence no meaningful labels. I also hid the topmost mouse label for now to allow for more space on the panel and add yet more controls if needed. Finally, I readjusted the main window's min sizes to be able to see the CPU/GPU meters instantly whenever I open the lighting control panel, and to narrow the viewport horizontally for easier framing depending on the scene content.

Thus, ObjReader with the yellow orb is the experimental sandbox I intend to use for transitioning from the current direct screen buffer writes to the frame buffer object. When tested and proven functional in the sandbox, the individual PP effects may go into standard ObjReader where you'll decide where and how to implement the associated controls.

[Patrice Terrier]

Mike

I plan to work back on ObjReader64, and i would like to add individual mesh rotation along the X, Y, Z axes.
First thing, i want to know if you have worked already on this in the FBO version ?

Indeed it is not related to post processing, but moreover an enhancement of the existing demo mode.

I am thinking also of a new global #animate (with speed parameter for CW or CWW rotation).

Your thought ?

[Michael Lobko-Lobanovsky]

I plan to work back on ObjReader64 ...

That's great news, Patrice! It indicates your foot's finally gotten much much better, n'est-ce pas?

... and i would like to add individual mesh rotation along the X, Y, Z axes.
........
I am thinking also of a new global #animate (with speed parameter for CW or CWW rotation).

Have a look at this article svp. These mass-production low-cost monitors (and competitive notebooks too!) are designed to operate at refresh frequencies of 75 to 144Hz and don't have a 60Hz option at all. Note that ObjReader's current Windows timer-based refresh engine will not be able to deliver such speeds because its fastest theoretical rate is ca. 64FPS (ca. 15,6 msec) only. VSYNC=2 will work regardless as it doesn't care what the refresh rate actually is as long as the renderer is still able to catch up with half the monitor rate, but VSYNC=1 ("turbo") won't because of the timer's too slow pace.

We could use straight-forward timer-less continuous VSYNC'ed rendering but it would be considerably more stressful for the CPU/DWM than the current Windows timer implementation is.

We need another adjustable render clock, probably RDTSC-/high precision Sleep()-based one, which means we'll have to go down to the 64-bit inline assembly level. It is available in GCC and Intel C(++) but is missing entirely in 64-bit MS VC(++).

First thing, i want to know if you have worked already on this in the FBO version ?

No, and now you know why. I imagined you defending your timer implementation and your beloved MS VC too, and felt kinda frustrated...