Jump to content

Photo

Menu and overlay optimizations in alpha 103?


  • Please log in to reply
5 replies to this topic

#1 BFeely

BFeely

    Newbie

  • Members

Posted 19 February 2022 - 10:49 AM

I noticed in A103 menus are no longer slow when using DXGL, and the FPS overlay is no longer buggy.

 

Please note that for the menus you are actually working around a bug in DXGL with multiple writes to the primary buffer, and may be doing so with the overlay too.
 

Also, framerates do not appear to be stable.

 

Using both included DXGL and my current dev snapshot, Windows 11 build 22000, and NVIDIA driver 511.72.  60Hz G-Sync Compatible display, Fraps showing 60 frames a second in OpenGL.

 

Alpha 102 has stable framerates.

 

I'll be keeping Alpha 102 in a separate folder for further development of DXGL as the menus and overlays represent real-life usage of DirectDraw.



#2 Emily

Emily

    Scripter / Dev

  • ZC Developers

Posted 20 February 2022 - 04:05 AM

One write per frame occurs in the primary buffer. ZQuest was ALWAYS set up that way, ZC now just mimics it.

The FPS overlay was never buggy; drawing it every frame was causing large amounts of lag, so it was made to flicker to prevent the lag. With the optimizations made by only writing to the primary buffer once per frame, the FPS counter draw is less of a lag-causer, so I removed the flicker.

 

If you have framerate issues, do check the `frame_rest_suggest` option in `zc.cfg`; the best value is different per-system. Valid options are `0,1,2`. Though, 60fps is the expected framerate, so if that's what Fraps is showing you, that would indicate running correctly. If it's lower, something is causing lag; if it's ever higher than 61 (sometimes it rounds up on the frame counter oddly) then you have disabled the framerate cap; pressing 'F1' will toggle it.


  • ShadowTiger and Jared like this

#3 BFeely

BFeely

    Newbie

  • Members

Posted 23 February 2022 - 08:55 PM

I didn't change that between either build; A102 and below are working fine for me but it seems almost as if frames are getting duplicated seeing as the in-game FPS counter is showing lower than Fraps.

 

Turning off the FPS throttle causes the game to run smooth, until the game is restarted at which point the framerate shoots through the roof.

 

I did notice that A103 did fix screen shake events in the "Panoply of Calatia" quest.

 

As for the slowdowns due to the old method of writing to the screen for menus, that is currently a bug in DXGL and it will in the future be rewritten.


Edited by BFeely, 23 February 2022 - 09:14 PM.


#4 Emily

Emily

    Scripter / Dev

  • ZC Developers

Posted 24 February 2022 - 10:58 AM

With frame cap off, I get thousands of FPS. With it on, I get a smooth 60 at all times.

 

Could it be that fraps itself is causing issues? That isn't exactly the best software...



#5 Timelord

Timelord

    The Timelord

  • Banned
  • Location:Prydon Academy

Posted 28 February 2022 - 08:59 AM

One write per frame occurs in the primary buffer. ZQuest was ALWAYS set up that way, ZC now just mimics it.
The FPS overlay was never buggy; drawing it every frame was causing large amounts of lag, so it was made to flicker to prevent the lag. With the optimizations made by only writing to the primary buffer once per frame, the FPS counter draw is less of a lag-causer, so I removed the flicker.
 
If you have framerate issues, do check the `frame_rest_suggest` option in `zc.cfg`; the best value is different per-system. Valid options are `0,1,2`. Though, 60fps is the expected framerate, so if that's what Fraps is showing you, that would indicate running correctly. If it's lower, something is causing lag; if it's ever higher than 61 (sometimes it rounds up on the frame counter oddly) then you have disabled the framerate cap; pressing 'F1' will toggle it.


By default AG4 is multibuffered. Good to see that framerate is solid now, but it is wise to project that double buffer should always be enabled, and if needed, tripplebuffer is available.

Without double buffer, you'd have pixel tearing, or worse.

#6 BFeely

BFeely

    Newbie

  • Members

Posted 28 February 2022 - 08:32 PM

Looking at an API log generated by my in-development version of DXGL, it appears WaitForVerticalBlank is being called after changing palette entries.  This has exposed a bug in DXGL, which I have pushed a quick and dirty fix to the DXGL GitHub.

 

The version of DXGL from the Git repository should be stable enough to run ZC alpha 103, but please be aware I have only tested it on the nvoglv32.dll (NVIDIA WDDM) driver so far since it is in the middle of a development cycle.

 

I have made a pre-compiled DXGL DLL from this commit to replace the one bundled with ZC right now at https://www.dropbox....v/dxgl.dll?dl=0using the same MSVC2010 compiler as the bundled version if you'd like to put it in to future alphas.

 

Behavior seems to be about the same as Windows 11's own ddraw.dll after this revision, and the smoothest performance seems to come from setting vsync in zc.cfg to off (throttlefps on of course) and setting FullscreenWindowMode in dxgl.cfg to 1 or 5, or better yet force vsync in the graphics control panel.

 

Not sure why Allegro isn't double-buffering the DirectDraw (locking/unlocking the front buffer instead of making a flipped primary and writing to the backbuffer) however.


Edited by BFeely, 28 February 2022 - 09:27 PM.



1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users