Switch renderer from OpenGL to ANGLE#35
Conversation
The naive implementation only supported `*`, `*.*` and `*.ext` type patterns. This improves the matching mechanism by mechanically rewriting the file part of the pattern into a regular expression. Do not pass untrusted paths into this as it doesn't guard against expressions of high complexity.
commit 4fdaf05 Author: Lars Viklund <zao@zao.se> Date: Mon Aug 22 19:27:01 2022 +0200 Bump vcpkg to one with working LuaJIT, disable x64 builds commit c5a1278 Author: Lars Viklund <zao@zao.se> Date: Sun Aug 14 23:55:56 2022 +0200 Specify vcpkg.json path explicitly to avoid conflicts with registry commit 601ea2c Author: Lars Viklund <zao@zao.se> Date: Sun Aug 14 23:52:16 2022 +0200 Add vcpkg registry for own LuaJIT build
There's plenty of optimization possible when drawing UI primitives where primitives related by texture or colour can be merged into composite GPU draw calls. This optimization can currently not be enabled wholesale as much of the Lua code has hardcoded assumptions about draw order within layers being preserved. In order to more clearly manifest such order dependencies there's also an entertaining option to completely shuffle the draw order of primitives within each layer. These new variables are `r_layerOptimize` and `r_layerShuffle`, both defaulting to 0 (off).
It's possible that a legacy version of `cldapi.dll` is present on older systems where it's not officially supported, which may have a different set of exports. Guard against this by explicitly checking if the export we desire is present.
Between no merging of draw calls at all and aggressively merging draw commands in a way that the draw order differs from the submission order, there's the possibility of a conservative order-preserving optimization. This merges any contiguous sequence of draw calls that have the same batch key into a single vertex buffer and drawing them together. This reduces the number of GPU draw calls submitted, yielding decent frame rate gains.
We can detect if nothing has changed from the previous frame by computing a cheap hash of the draw command stream and if it matches we reuse the previous contents of the render target we prepare anyway for resolution scaling.
Historically we broke up draw batches by texture, viewport or blend mode. If any of those changed, a new batch was opened and the previous one was submitted to the GPU as it could no longer be appended to without violating ordering constraints. This commit adds a vertex attribute used to select among a set of textures, limited by the maximum texture sampler count the OpenGL ES implementation supports. As long as no more than that many textures are used in adjacent draw calls they can all be merged into a single draw call. With an implementation that supports 16 texture samplers, a typical passive skill tree can be drawn in around six draw calls with correct draw ordering.
Viewport clipping can be emulated in shaders by passing in the viewport extents via primitive attributes and discarding fragments in the fragment shader with `discard` statements. This allows us to merge more draw calls across previously uncrossable batch boundaries that arose from viewport changes as those caused GPU state changes that must be between draw calls.
Some views in the application can have a lot of geometry outside of the viewports, particularly the passive skill tree. We can save a lot of GPU work and emit fewer batch boundaries if we conservatively cull out quads that are entirely outside of their viewports by testing axis-aligned bounding boxes. This greatly speeds up the skill tree when partially zoomed, which tends to be a common case. This has benefits in reducing the amount of batch boundary cuts by not having to consider the render states of unseen geometry, especially texture changes.
There was a problem hiding this comment.
Do we still need this file now that we have vcpkg.json?
There was a problem hiding this comment.
The vcpkg.txt files are indeed superfluous now in manifest mode as we have it all declared in vcpkg.json.
Wires77
left a comment
There was a problem hiding this comment.
We don't need the vcpkg-ports folder anymore, right? Didn't they add a luajit version upstream we can use?
The local ports tree is currently unused, we are currently using a LuaJIT port from vcpkg upstream as we define which baseline vcpkg commit and what overlay ports to use in |
Wires77
left a comment
There was a problem hiding this comment.
I saw some support for other OSes in here, is the only thing unsupported opening URLs?
| glLoadIdentity(); | ||
| nextViewport_ = cmd->viewport; | ||
| if (showStats_) { | ||
| // ImGui::Text("VIEWPORT: %dx%d @ %d,%d", cmd->viewport.width, cmd->viewport.height, cmd->viewport.x, cmd->viewport.y); |
There was a problem hiding this comment.
Guessing these commented lines can be uncommented or removed?
| r_layerOptimize = sys->con->Cvar_Add("r_layerOptimize", CV_ARCHIVE | CV_CLAMP, "1", 0, 1); | ||
| r_layerShuffle = sys->con->Cvar_Add("r_layerShuffle", CV_ARCHIVE | CV_CLAMP, "0", 0, 1); | ||
| r_elideFrames = sys->con->Cvar_Add("r_elideFrames", CV_ARCHIVE | CV_CLAMP, "1", 0, 1); | ||
| r_drawCull = sys->con->Cvar_Add("r_drawCull", CV_ARCHIVE | CV_CLAMP, "1", 0, 1); |
There was a problem hiding this comment.
Cool, was going to ask if these were defaulted properly, as they weren't last time I tested.
| @@ -0,0 +1,158 @@ | |||
| // SimpleGraphic Engine | |||
| // (c) David Gowor, 2014 | |||
There was a problem hiding this comment.
Technically this isn't their work ;)
There was a problem hiding this comment.
Wow, surprised that most of this isn't necessary with GLFW
| wrec.right = wrec.left + cur.mode[0]; | ||
| wrec.bottom = wrec.top + cur.mode[1]; | ||
| AdjustWindowRectEx(&wrec, style, FALSE, exStyle); | ||
| // TODO(LV): Verify that stored coordinates are aligned right. |
There was a problem hiding this comment.
Showstopping TODO or nice-to-have?
|
So one big issue I'm finding is that if I try and attach a debugger on the Lua side via PyCharm, PoB doesn't open and also doesn't kill the process. That invocation looks like this in Launch.lua:OnInit(): package.cpath = package.cpath .. ';C:/Users/trevo/AppData/Roaming/JetBrains/PyCharmCE2021.1/plugins/EmmyLua/debugger/emmy/windows/x86/?.dll'
local dbg = require('emmy_core')
dbg.tcpListen('localhost', 9966)
dbg.waitIDE()I tried to use For running on wine (Running in an Ubuntu VM) it looks like we will need to also build Finally, we need to hide the ImGUI UI by default. |
|
On the debugger - you seem to use the The cloud state is more about the provider as a whole rather than individual files as it queries the state of the sync root that contains the path. I couldn't find any conclusive state to query for whether a file could be successfully obtained apart from attempting to actually read it. We should never have a dependency on the Debug runtime in a shipping situation and custom is to not ever deploy it outside of a development machine as the license doesn't allow redistribution. To run a Debug build on a machine that doesn't have a dev environment you need to privately deploy those non-redist files - were you running a Debug build or has aspects of it crept into the release? ImGui - yep. |
Doh, I just kept using my existing debug lines, forgetting they would have different DLLs. Works fine now as well.
It's better than nothing, we can see what kind of things we can do with that information at least.
I found it easiest to pull the built binaries onto my VM via this PR: PathOfBuildingCommunity/PathOfBuilding#6705 They were built with these commands: cmake -A x64 -G "Visual Studio 17 2022" --toolchain .\vcpkg\scripts\buildsystems\vcpkg.cmake -B build-output -DCMAKE_INSTALL_PREFIX=runtime
cmake --build build-output --config RelWithDebInfo -t INSTALL |
To be done before merging:
Nice-to-haves for later PRs: