Author Topic: Migration to FBO  (Read 29392 times)

Patrice Terrier

  • Administrator
  • *****
  • Posts: 1983
    • zapsolution
Re: Migration to FBO
« Reply #60 on: June 02, 2018, 09:26:12 am »
Quote
Do you think we really should bother?
Good question  ;D

On my gamer computer i had to restore the initial computation of 13 ms, because your last change ( -2) was too small, and produces a 77 / 78 FPS by me.

...
 
Patrice
(Always working with the latest Windows version available...)

Michael Lobko-Lobanovsky

  • Administrator
  • *****
  • Posts: 1481
Re: Migration to FBO
« Reply #61 on: June 02, 2018, 10:07:10 am »
Patrice,

Before you change the gP.sync_delay msec code again, please check what your concurrent Fraps reading is like I did in my former screenshots (and preferably post your Tron screenshot here for me to see too). If the FPS and Fraps readings are comparable, then it isn't the gP.sync_delay msec code that yields too high rates but probably some voluntaristic setting in your nVidia Control Center that won't permit the user application to set VSYNC programmatically while the Control Center system-wide setting is in effect. Wherever possible, your nVidia Control Center policies should be set to "Application Defined"!

When wglSwapIntervalEXT(1) is called, the OpenGL viewport refresh rate cannot go higher than the monitor refresh rate (75Hz in your case) regardless of how fast our new "timer" ticks. FWIW it may tick at 7 - 2 = 5 ms (= 200 Hz/FPS --> that's for a 144Hz monitor) but your OpenGL refresh rate will still be 75FPS because your monitor delivers 75Hz only. That's what the whole VSYNC idea is all about.
Mike
(3.6GHz Intel Core i5 Quad w/ 16GB RAM, nVidia GTX 1060Ti w/ 6GB VRAM, Windows 7 Ultimate Sp1)

Patrice Terrier

  • Administrator
  • *****
  • Posts: 1983
    • zapsolution
Re: Migration to FBO
« Reply #62 on: June 02, 2018, 02:30:41 pm »
Here is the screen shot.

Note: Fraps oscille between 75 and 76 hz
and ObjReader between 76 and 77 hz.

With this value
gP.sync_delay = (long)(1000.0f / gP.sync_rate) - 1;
i got a fixed 75 hz in Fraps.

« Last Edit: June 02, 2018, 02:43:17 pm by Patrice Terrier »
Patrice
(Always working with the latest Windows version available...)

Patrice Terrier

  • Administrator
  • *****
  • Posts: 1983
    • zapsolution
Re: Migration to FBO
« Reply #63 on: June 02, 2018, 06:37:45 pm »
Mike

I am switching everything to TURBO mode (aka the default setting).
And making the corresponding cleaning/optimisation of the code, i may even remove the matching overlay switch, moving at the same location the rotation icon that becomes a switch (see below).
Patrice
(Always working with the latest Windows version available...)

Michael Lobko-Lobanovsky

  • Administrator
  • *****
  • Posts: 1481
Re: Migration to FBO
« Reply #64 on: June 02, 2018, 06:48:41 pm »
Thank you, Patrice.

Yes, the FPS counter tends to display a ca. +1 FPS higher rate than Fraps for me too. I think I'll fix this nuisance as soon as I find what's causing it. It eludes me at the moment.

I changed my code to gP.sync_delay = (long)(1000.0f / gP.sync_rate) - 1; too to be consistent with yours. Let's wait and see if such a narrow margin of extra FPS proves sufficient for reliable VSYNC over time. (I hope your nVidia Control Center's Image Settings policy is set as in the snapshot below.)

BTW have you been able to make the lighting panel's scroll more responsive to the mouse wheel when in animation mode?

I am switching everything to TURBO mode (aka the default setting).
... i may even remove the matching overlay switch

OK let turbo be our default setting but please don't remove the half-rate option entirely. It may be useful for extremely high polygon counts on low-VRAM video cards.
Mike
(3.6GHz Intel Core i5 Quad w/ 16GB RAM, nVidia GTX 1060Ti w/ 6GB VRAM, Windows 7 Ultimate Sp1)

Patrice Terrier

  • Administrator
  • *****
  • Posts: 1983
    • zapsolution
Re: Migration to FBO
« Reply #65 on: June 02, 2018, 07:35:19 pm »
Ok, i shall keep the TURBO On/Off, while switching the default mode to ON.

Quote
BTW have you been able to make the lighting panel's scroll more responsive to the mouse wheel when in animation mode?
Nope, i did try a few things but nothing perfect, however on my computer it mostly depend of the size of the model.

See attached my nVIDIA setting.

Patrice
(Always working with the latest Windows version available...)

Michael Lobko-Lobanovsky

  • Administrator
  • *****
  • Posts: 1481
Re: Migration to FBO
« Reply #66 on: June 02, 2018, 07:55:04 pm »
Thank you, the settings seem acceptable in this particular case.

BTW I think Qualité isn't very useful for you because you aren't playing games. Note that it overrides application-wide settings that you might try to change programmatically in your code. So when active, Qualité will not allow the application e.g. to switch off its VSYNC. Performances seems more reasonable because programming OpenGL, you're sometimes supposed to run benchmark tests, in which case the faster means the better.
Mike
(3.6GHz Intel Core i5 Quad w/ 16GB RAM, nVidia GTX 1060Ti w/ 6GB VRAM, Windows 7 Ultimate Sp1)

Patrice Terrier

  • Administrator
  • *****
  • Posts: 1983
    • zapsolution
Re: Migration to FBO
« Reply #67 on: June 03, 2018, 11:49:18 am »
Mike

I am using a G-SYNC config, thus using performance or quality makes no difference by me, as long as OR is concerned.

I have attached the latest code i am using, with TURBO being the default mode (this one runs my FPS very close to FRAPS)

Added:
FPS should be always drawn in textured mode, try with wireframe and/or point cloud.
Ideally the FPS should be drawn in composited mode, rather than inside gl_DrawScene.
« Last Edit: June 03, 2018, 04:06:59 pm by Patrice Terrier »
Patrice
(Always working with the latest Windows version available...)

Michael Lobko-Lobanovsky

  • Administrator
  • *****
  • Posts: 1481
Re: Migration to FBO
« Reply #68 on: June 03, 2018, 05:42:12 pm »
Patrice,

Quote
FPS should be always drawn in textured mode, try with wireframe and/or point cloud.

Ah yes, that's a good catch! Please use this in mobj.h:
Code: [Select]
void printFPS(int x, char* str) {
    static bool fpsInited = false;
    char* s = str;
    int i, j, idx = 0;

    if (!fpsInited)
        fpsInit(&fpsInited);

    glMatrixMode(GL_MODELVIEW);
    glPushMatrix();
    glLoadIdentity();
    glTranslatef(0.0f, gP.glHeight - 1.0f, 0.0f);
    glScalef(1.0f, -1.0f, 1.0f);
    glMatrixMode(GL_PROJECTION);
    glPushMatrix();
    glLoadIdentity();
    glOrtho(0.0, gP.glWidth, 0.0, gP.glHeight, -1.0, 1.0);
    glMatrixMode(GL_TEXTURE);
    glPushMatrix();
    glScalef(1.0f / float(g_digitW * 10), 1.0f / float(g_digitH), 1.0f);
    glMatrixMode(GL_MODELVIEW);

    glPushAttrib(GL_ENABLE_BIT | GL_POLYGON_MODE);

    glEnable(GL_BLEND);
    glDisable(GL_LIGHTING);
    glDisable(GL_DEPTH_TEST);
    glPolygonMode(GL_FRONT_AND_BACK, GL_FILL);

    glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);
    glBindTexture(GL_TEXTURE_2D, gM.glFpsTexture);

    x += 1;
    while (*s) {
        i = x + g_digitW;
        idx = (*s++) - 48;
        j = idx * g_digitW;//(idx << 5) / 2;

        glBegin(GL_QUADS);
        glTexCoord2i(j, 0); glVertex2i(x, g_digitH);
        glTexCoord2i(j + g_digitW, 0); glVertex2i(i, g_digitH);
        glTexCoord2i(j + g_digitW, g_digitH); glVertex2i(i, 0);
        glTexCoord2i(j, g_digitH); glVertex2i(x, 0);
        glEnd();

        x += g_digitW;
    }

    glBindTexture(GL_TEXTURE_2D, 0);
    glPopAttrib();

    glMatrixMode(GL_TEXTURE);
    glPopMatrix();
    glMatrixMode(GL_PROJECTION);
    glPopMatrix();
    glMatrixMode(GL_MODELVIEW);
    glPopMatrix();
}

Quote
... this one runs my FPS very close to FRAPS ...

I hope you understand that you're using some obscure side effect of Sleep(1) because strictly speaking, without timeBegin|EndPeriod(1) your Sleep(1) is effectively the same as Sleep(USER_TIMER_MINIMUM), or Sleep(15.6).

Contrary to their deceptive names, the matching timeBeginPeriod() and timeEndPeriod() APIs set/reset the minimum resolution not of timers but rather of process wait state timeouts, like e.g. WaitForSingleObject() or WaitOnAddress(), and of the Sleep() API.

In fact, what you're doing is forcing the process to sleep some extra ticks in addition to the "timer" loop delay. But what I'd rather like to do is understand why such extra sleep is needed at all, because your funny 998+1+1 ticks jugglery seems logical (though somewhat weird) to me.

But OK, let's stick to your solution temporarily until the logically correct solution dawns on us sooner or later. :)

Quote
Ideally the FPS should be drawn in composited mode...

I'd rather see everything drawn in gl_DrawScene() than buried somewhere in your GDImage I have no access to, Patrice. ;) Ideally, the printFPS() routine should be reduced to a glCallList() call but that requires some experimentation to avoid yet more rather than less stress on the renderer.

Mike
(3.6GHz Intel Core i5 Quad w/ 16GB RAM, nVidia GTX 1060Ti w/ 6GB VRAM, Windows 7 Ultimate Sp1)

Patrice Terrier

  • Administrator
  • *****
  • Posts: 1983
    • zapsolution
Re: Migration to FBO
« Reply #69 on: June 03, 2018, 06:04:45 pm »
Quote
BTW have you been able to make the lighting panel's scroll more responsive to the mouse wheel when in animation mode?

Please try this, and tell me what is the best value for you (see the red code)

void ScrollContent(IN HWND hWnd, IN long nScroll) {
    go.mousewheel = -1;
    long nStep = 0, nID = 0, nBottom = 0;
    static long wasDelta;
    long nSpeed = gP.AniTick - wasDelta;
    long one = 1; if (nScroll < 0) { one = -1; }

    if (nSpeed > 30) {
        nStep = 1;
    } else if (nSpeed) {
        nStep = 8;
        one *= 2;
    } else {
        if (gP.nGiration) { nStep = 16; } else { nStep = 8; }
        one *= 4;
    }

    if (gP.nGiration || gP.nUseFPS) { one *= 2; }

    ZOBJECT zObj;


About GDImage, did you looked at the GDplus (a limited GDImage subset) project  ?

It should give you a better understanding on how the whole engine works (everything being based on sprite object).
The great strength of GDImage is that it can also work in zoom mode, just like with Google map (see the Gmap64 project http://www.objreader.com/index.php?topic=106.0).
And who knows, may be one day i will give you more for the posterity...  8)
« Last Edit: June 03, 2018, 06:29:29 pm by Patrice Terrier »
Patrice
(Always working with the latest Windows version available...)

Michael Lobko-Lobanovsky

  • Administrator
  • *****
  • Posts: 1481
Re: Migration to FBO
« Reply #70 on: June 03, 2018, 06:44:58 pm »
if (gP.nGiration || gP.nUseFPS) { one *= 2; } seems to work pretty nicely for me, thanks! I've added it to my code.

Quote
About GDImage, did you looked at the GDplus (a limited GDImage subset) project  ?

I did. That's a pretty solid piece of work, and I imagine GDImage must be a real piece of art. :)

Quote
And who knows, may be one day i will give you more for the posterity...  8)

Alas my friend, I am too old myself to be anyone's happy inheritor. ;D
Mike
(3.6GHz Intel Core i5 Quad w/ 16GB RAM, nVidia GTX 1060Ti w/ 6GB VRAM, Windows 7 Ultimate Sp1)