MagicBeanDev/Longshot
MagicBeanDev/Longshot
Watch
75
97
Fork
You've already forked Longshot
 101
Code Issues 237 Pull requests 244 Projects Releases 9 Packages Wiki Activity Actions 761

WIP: fix(vk): a direct quad draw's BaseVertex is its first vertex, as for every other non-indexed draw #907

Draft
mooki wants to merge 1 commit from mooki/Longshot:fix/direct-quad-basevertex into main
pull from: mooki/Longshot:fix/direct-quad-basevertex
merge into: MagicBeanDev:main
Conversation 0 Commits 1 Files changed 2 +182 -3
mooki commented 2026-11-15 20:05:54 +00:00
Member

Type: fix · Risk: low · Tested on: macOS 26.7.1, Apple M4 Max (game-free checks only, arm64 and x86_64 under Rosetta) · Needs: Windows and Linux, any GPU

Why

Vulkan has no quad topology, so LS draws a direct quad draw as an indexed triangle list it writes into the recording's
stream. For a draw that is not indexed, those indices were the vertex numbers themselves (first vertex + 4q + corner), drawn
with a vertex offset of 0. Vulkan's BaseVertex for an indexed draw is its vertex offset, so a vertex program that reads the
draw's base vertex got 0 in such a quad draw. (A program reads it from the vertex stage's driver bank at 0x640, which LS
reads as BaseVertex.)

Every other non-indexed draw LS makes is a vkCmdDraw. Vulkan gives a non-indexed draw its first vertex as BaseVertex, so
those draws read the first vertex. The indirect quad draws in #851 read it too. Only direct non-indexed quad draws read 0, so
the same program got a different base vertex depending on whether its draw was quads.

Not seen in a game: in the macOS port's game runs no quad was drawn (their quad census line never appeared).
Found while making the indirect quad draws (now in #851), whose non-indexed records carry the first vertex as their vertex offset.
The issue tracker's titles (snapshot of 2026-11-14 20:01) have nothing that fits. See #420.

How to reproduce

Seen on: not seen in a game; shown on main's own quad branch by this PR's game-free test, on macOS 26.7.1, Apple M4 Max, arm64 and x86_64 under Rosetta (the code is the same on every OS)
Settings and switches: none. Any program that reads the base vertex, in a direct quad draw that is not indexed and does not start at vertex 0
Steps: from this branch, run python -I -B tests/test_quad_base_vertex.py --cxx c++ --source <a checkout of main>. In a game: a direct NVN_DRAW_PRIMITIVE_QUADS draw with a first vertex other than 0, whose vertex program reads the base vertex (longshot_log.txt names such programs: vk: program … reads the draw's base vertex)
Expected: BaseVertex is the draw's first vertex, as in every other non-indexed draw LS makes (Vulkan's rule for a non-indexed draw)
Actual: BaseVertex is 0. The test reports FAIL BaseVertex: not indexed count 4 first 1 …: got 0, want 1 (576 failures of 5,936 checks)

What changed

A direct quad draw that is not indexed now writes its triangles counting from 0 (4q + corner) and passes its first vertex
as the indexed draw's vertex offset. Vulkan fetches vertex index + vertex offset, so every vertex fetched is the same as
before. VertexIndex is the same too, and LS reads it as NVN's vertex id. Only BaseVertex changes, from 0 to the first
vertex. Indexed quad draws and every other draw are unchanged.

  • gpu/vk/vk_draw.cpp, draw()'s quad branch (main :7814-7844):
    • the non-indexed corners are 4q + k instead of first + 4q + k (:7833-7834);
    • vkCmdDrawIndexed's vertex offset is d.indexed ? d.base_vertex : d.first (:7840, was … : 0).
    • #851 gives a non-indexed indirect quad record the same form ({6⌊V/4⌋, I, 0, fv, fi} over a pattern of 4q + corner),
      so direct and indirect quads give the same BaseVertex.
  • tests/test_quad_base_vertex.py (new):
    • It cuts draw()'s quad branch out of vk_draw.cpp (and DrawArgs out of vk_draw.h) and runs it on the CPU, with
      stand-ins for the stream, the guest's index buffer and the commands.
    • It reads the recorded draw the way Vulkan reads an indexed draw: vertex = index + vertex offset, BaseVertex = vertex
      offset.
    • 699 draws, not indexed and indexed:
      • not indexed: first vertex 0 to 2^30 + 3, 0 to 4,099 vertices, 0, 1 or 3 instances, two first instances;
      • indexed: 8-, 16- and 32-bit, base vertex −100,000 to 100,000, with each type's largest value among the indices.
    • Each draw checks every vertex fetched, BaseVertex, the instances and the first instance, and that fewer than 4 or more
      than 2^24 vertices draw nothing.
    • --source runs it on another tree.

Measurements

Verdict: nothing to measure. The draw writes the same number of indices into the stream and records the same single command; only the values of the vertex offset and the indices change.

Flags and settings

None

Testing

Tested: game-free, on macOS 26.7.1, Apple M4 Max, at daeb117c on main aa95d35f. This PR's head 98218916 is the same patch rebased onto main 7bacf846 (git range-diff: identical), and its tree is exactly the merge of daeb117c with 7bacf846 on which the new test was run again and passed:

  • tests/test_quad_base_vertex.py (new), arm64 and x86_64 under Rosetta (clang++ -arch x86_64):
    • this PR: 699 draws, 5,936 checks, 0 failures on both;
    • main aa95d35f's vk_draw.cpp (--source): 576 failures on both, every one BaseVertex (0 where the first vertex is not 0); main's vertices are right;
    • two altered copies of this PR's branch fail it too (arm64): the new indices with a vertex offset of 0 (1,152 failures: BaseVertex and the vertices fetched), and the old indices with the first vertex as the offset (576 failures: each vertex fetched with the first vertex added twice).
  • gpu/vk/vk_draw.cpp compiled whole, for arm64 and x86_64, with nx2/build.py's own macOS commands (in a tree with the macOS build, #845's head, whose vk_draw.cpp and vk_draw.h are main's): main's file and this PR's both exit 0 on both. The objects reference and define the same symbols as main's (nm).
  • python -I -B tests/run_all.py --jobs 6 on this Mac, where main's runner takes macOS for Linux: 544 passed, 33 failed, 17 skipped. Main aa95d35f gives 543 passed, 33 failed, 17 skipped, and by name every result is the same apart from the new test (pass). The 33 fail on main on this Mac too: test_appimage_package_retry, test_appimage_player_build, test_collect_wide, test_control, test_cpm_discovery, test_crash_dialog, test_crash_record, test_env_on, test_game_layout, test_lift_cleanup_error, test_linux_preflight, test_longshot_ctl, test_low_memory_notice, test_make_game_cache, test_mem_gate, test_mem_gate_children, test_mirror_trim, test_oot_state_tap, test_options_budget_once, test_options_path, test_pcache_header_read, test_pipeline_cache_file, test_pipeline_cache_save, test_pipeline_play_cache, test_pipeline_tour, test_prof_symbols, test_program_cache_cleanup, test_program_cache_one_variant, test_readback_late, test_report_run, test_split_giants, test_vk_pgo, test_walk_key.
  • Logs of three macOS game runs (integration builds 78ec1c47 and 63fc3d2c, arm64): no vk: quad draws line, which
    appears at the first quad draw. In the scenes played no quad was drawn, so this change draws no pixel differently there.
    These logs can't say whether any program reads the base vertex: vk: program … reads the draw's comes only from programs
    translated during the run, and each run loaded a program cache of 47,798 keys.

Not tested: in the game, on any platform: no scene is known to draw a quad whose program reads the base vertex.
Not built on Windows (llvm-mingw) or Linux: no PC here. The change has no platform branch, so it runs the same on both.

Must be tested:

  • Windows and Linux, any GPU: build this PR (head 98218916) and main (7bacf846) the same way, run python -I -B tests/run_all.py on each, then start each to the title, expecting test_quad_base_vertex to pass, no other check to change status against main, and the same vk: lines in longshot_log.txt as main's (by hand: test request T-P4YP)

Risks

What could break: a program that reads the base vertex in a direct non-indexed quad draw now gets the first vertex
instead of 0, as it already does in every other non-indexed draw. The vertices fetched are the same.

What NVN itself gives a non-indexed draw there is not known, and this PR does not settle it:

  • GL gives gl_BaseVertex 0 to a draw with no base vertex parameter, such as DrawArrays
    (ARB_shader_draw_parameters: "In
    the case where the command has no parameter, the value of <gl_BaseVertexARB> is zero").
  • Eden's HLE of NVN's non-indexed draw macro puts the base instance at 0x640; only the indexed macros put the base vertex
    there (src/video_core/macro.cpp,
    HLE_DrawArraysIndirect, lines 86 and 116).

LS reads 0x640 as BaseVertex in every draw (gpu/vk/vk_shader.cpp:540). If NVN's value for a non-indexed draw is 0 or
the base instance, that is a question about every non-indexed draw LS makes, not only quads. This PR only makes quads give
the same value as the rest.

A first vertex of 2^31 or more (not a real draw) makes the vertex offset negative; on 32-bit arithmetic the vertex index
wraps to the same value as before.

Turning it off: revert the commit

Compatibility: Nothing changes: no cache, save, longshot_options.ini key or vk ABI is touched.

Reviewer notes

  • Conflicts with open PRs (git merge-tree, heads of 13:58 CST), each one hunk in vk_draw.cpp's quad branch:
    • #851 (mac/topic-draw-path-quads-mesh, which carries the indirect quads) and #852 (mac/topic-mac-perf, on top of it)
      write the triangles through quad_draws::triangles(…, [&](uint32_t i) { return d.indexed ? src[i] : first + i; }, out)
      and draw through drawid_direct::indexed(quads * 6, …, d.indexed ? d.base_vertex : 0, …). Resolution:
      d.indexed ? src[i] : i in the lambda (dropping first), and d.first in place of the 0.
    • #850 (mac/topic-draw-path) draws through the same drawid_direct::indexed(…, d.indexed ? d.base_vertex : 0, …). Put
      d.first in place of the 0; its corners merge to this PR's.
    • Whichever lands second also gives tests/test_quad_base_vertex.py stand-ins for the names those branches use in the
      quad branch (quad_draws.h, drawid_direct, drawid_indirect, quad_records, quad_tally, quad_lost,
      quad_rotated, quad_drawn, census_draw, provoking_note, census_fan_draw).
    • #845 to #849 and #853 (fix/quad-stream-grow) merge cleanly. The test passes on the tree merged with #853 (its
      stream_alloc stand-in takes the third argument).
  • Rebased onto main 7bacf846 (head 98218916, the same patch); the test passes on that tree. The whole suite ran at daeb117c on aa95d35f; on 7bacf846 it is queued and this description gets its result.

Issues

See #420

Checklist

Everyone

  • One topic.
  • The title is a Conventional Commit (type(scope): description) of the status line's type.
  • Why gives the reason plainly and links the issues that fit (the tracker searched).
  • Measurements has a verdict, or one line saying why there is nothing to measure.
  • Testing names what was tested, what wasn't, and what must still be tested, where and how. (Test request T-P4YP.)
  • Rebased on current main (7bacf846, head 98218916).
  • python -I -B tests/run_all.py passes (any failure that also fails on main is named).
  • No game files, dumps, build output or generated files.
  • third_party/ untouched (a new folder with a PROVENANCE.md instead).
  • The license is OK: GPL-3.0-or-later, nothing incompatible and nothing decompiled.

When it applies

  • AI assistance recorded with Assisted-by: / Co-Authored-By: trailers.
  • A game-free test added for the fix, failing on main and passing here.
  • A check under tests/ that reads changed source updated in this PR, not weakened. (None needed a change: every check that reads vk_draw.cpp gives the same result as on main; the new test reads the quad branch.)
**Type:** fix · **Risk:** low · **Tested on:** macOS 26.7.1, Apple M4 Max (game-free checks only, arm64 and x86_64 under Rosetta) · **Needs:** Windows and Linux, any GPU ## Why Vulkan has no quad topology, so LS draws a direct quad draw as an indexed triangle list it writes into the recording's stream. For a draw that is not indexed, those indices were the vertex numbers themselves (first vertex + 4q + corner), drawn with a vertex offset of 0. Vulkan's `BaseVertex` for an indexed draw is its vertex offset, so a vertex program that reads the draw's base vertex got 0 in such a quad draw. (A program reads it from the vertex stage's driver bank at `0x640`, which LS reads as `BaseVertex`.) Every other non-indexed draw LS makes is a `vkCmdDraw`. Vulkan gives a non-indexed draw its first vertex as `BaseVertex`, so those draws read the first vertex. The indirect quad draws in #851 read it too. Only direct non-indexed quad draws read 0, so the same program got a different base vertex depending on whether its draw was quads. Not seen in a game: in the macOS port's game runs no quad was drawn (their quad census line never appeared). Found while making the indirect quad draws (now in #851), whose non-indexed records carry the first vertex as their vertex offset. The issue tracker's titles (snapshot of 2026-11-14 20:01) have nothing that fits. See #420. ## How to reproduce **Seen on:** not seen in a game; shown on main's own quad branch by this PR's game-free test, on macOS 26.7.1, Apple M4 Max, arm64 and x86_64 under Rosetta (the code is the same on every OS) **Settings and switches:** none. Any program that reads the base vertex, in a direct quad draw that is not indexed and does not start at vertex 0 **Steps:** from this branch, run `python -I -B tests/test_quad_base_vertex.py --cxx c++ --source <a checkout of main>`. In a game: a direct `NVN_DRAW_PRIMITIVE_QUADS` draw with a first vertex other than 0, whose vertex program reads the base vertex (longshot_log.txt names such programs: `vk: program … reads the draw's base vertex`) **Expected:** `BaseVertex` is the draw's first vertex, as in every other non-indexed draw LS makes (Vulkan's rule for a non-indexed draw) **Actual:** `BaseVertex` is 0. The test reports `FAIL BaseVertex: not indexed count 4 first 1 …: got 0, want 1` (576 failures of 5,936 checks) ## What changed A direct quad draw that is not indexed now writes its triangles counting from 0 (4q + corner) and passes its first vertex as the indexed draw's vertex offset. Vulkan fetches vertex index + vertex offset, so every vertex fetched is the same as before. `VertexIndex` is the same too, and LS reads it as NVN's vertex id. Only `BaseVertex` changes, from 0 to the first vertex. Indexed quad draws and every other draw are unchanged. - `gpu/vk/vk_draw.cpp`, draw()'s quad branch (main `:7814-7844`): - the non-indexed corners are `4q + k` instead of `first + 4q + k` (`:7833-7834`); - `vkCmdDrawIndexed`'s vertex offset is `d.indexed ? d.base_vertex : d.first` (`:7840`, was `… : 0`). - #851 gives a non-indexed indirect quad record the same form (`{6⌊V/4⌋, I, 0, fv, fi}` over a pattern of `4q + corner`), so direct and indirect quads give the same `BaseVertex`. - `tests/test_quad_base_vertex.py` (new): - It cuts draw()'s quad branch out of `vk_draw.cpp` (and `DrawArgs` out of `vk_draw.h`) and runs it on the CPU, with stand-ins for the stream, the guest's index buffer and the commands. - It reads the recorded draw the way Vulkan reads an indexed draw: vertex = index + vertex offset, `BaseVertex` = vertex offset. - 699 draws, not indexed and indexed: - not indexed: first vertex 0 to 2^30 + 3, 0 to 4,099 vertices, 0, 1 or 3 instances, two first instances; - indexed: 8-, 16- and 32-bit, base vertex −100,000 to 100,000, with each type's largest value among the indices. - Each draw checks every vertex fetched, `BaseVertex`, the instances and the first instance, and that fewer than 4 or more than 2^24 vertices draw nothing. - `--source` runs it on another tree. ## Measurements **Verdict:** nothing to measure. The draw writes the same number of indices into the stream and records the same single command; only the values of the vertex offset and the indices change. ### Flags and settings None ## Testing **Tested:** game-free, on macOS 26.7.1, Apple M4 Max, at `daeb117c` on main `aa95d35f`. This PR's head `98218916` is the same patch rebased onto main `7bacf846` (`git range-diff`: identical), and its tree is exactly the merge of `daeb117c` with `7bacf846` on which the new test was run again and passed: - `tests/test_quad_base_vertex.py` (new), arm64 and x86_64 under Rosetta (`clang++ -arch x86_64`): - this PR: 699 draws, 5,936 checks, 0 failures on both; - main `aa95d35f`'s `vk_draw.cpp` (`--source`): 576 failures on both, every one `BaseVertex` (0 where the first vertex is not 0); main's vertices are right; - two altered copies of this PR's branch fail it too (arm64): the new indices with a vertex offset of 0 (1,152 failures: `BaseVertex` and the vertices fetched), and the old indices with the first vertex as the offset (576 failures: each vertex fetched with the first vertex added twice). - `gpu/vk/vk_draw.cpp` compiled whole, for arm64 and x86_64, with nx2/build.py's own macOS commands (in a tree with the macOS build, #845's head, whose `vk_draw.cpp` and `vk_draw.h` are main's): main's file and this PR's both exit 0 on both. The objects reference and define the same symbols as main's (`nm`). - `python -I -B tests/run_all.py --jobs 6` on this Mac, where main's runner takes macOS for Linux: 544 passed, 33 failed, 17 skipped. Main `aa95d35f` gives 543 passed, 33 failed, 17 skipped, and by name every result is the same apart from the new test (pass). The 33 fail on main on this Mac too: test_appimage_package_retry, test_appimage_player_build, test_collect_wide, test_control, test_cpm_discovery, test_crash_dialog, test_crash_record, test_env_on, test_game_layout, test_lift_cleanup_error, test_linux_preflight, test_longshot_ctl, test_low_memory_notice, test_make_game_cache, test_mem_gate, test_mem_gate_children, test_mirror_trim, test_oot_state_tap, test_options_budget_once, test_options_path, test_pcache_header_read, test_pipeline_cache_file, test_pipeline_cache_save, test_pipeline_play_cache, test_pipeline_tour, test_prof_symbols, test_program_cache_cleanup, test_program_cache_one_variant, test_readback_late, test_report_run, test_split_giants, test_vk_pgo, test_walk_key. - Logs of three macOS game runs (integration builds `78ec1c47` and `63fc3d2c`, arm64): no `vk: quad draws` line, which appears at the first quad draw. In the scenes played no quad was drawn, so this change draws no pixel differently there. These logs can't say whether any program reads the base vertex: `vk: program … reads the draw's` comes only from programs translated during the run, and each run loaded a program cache of 47,798 keys. **Not tested:** in the game, on any platform: no scene is known to draw a quad whose program reads the base vertex. Not built on Windows (llvm-mingw) or Linux: no PC here. The change has no platform branch, so it runs the same on both. **Must be tested:** - Windows and Linux, any GPU: build this PR (head `98218916`) and main (`7bacf846`) the same way, run `python -I -B tests/run_all.py` on each, then start each to the title, expecting `test_quad_base_vertex` to pass, no other check to change status against main, and the same `vk:` lines in longshot_log.txt as main's (by hand: test request T-P4YP) ## Risks **What could break:** a program that reads the base vertex in a direct non-indexed quad draw now gets the first vertex instead of 0, as it already does in every other non-indexed draw. The vertices fetched are the same. What NVN itself gives a non-indexed draw there is not known, and this PR does not settle it: - GL gives `gl_BaseVertex` 0 to a draw with no base vertex parameter, such as DrawArrays ([ARB_shader_draw_parameters](https://registry.khronos.org/OpenGL/extensions/ARB/ARB_shader_draw_parameters.txt): "In the case where the command has no <baseVertex> parameter, the value of <gl_BaseVertexARB> is zero"). - Eden's HLE of NVN's non-indexed draw macro puts the base instance at `0x640`; only the indexed macros put the base vertex there ([`src/video_core/macro.cpp`](https://git.eden-emu.dev/eden-emu/eden/src/branch/master/src/video_core/macro.cpp), `HLE_DrawArraysIndirect`, lines 86 and 116). LS reads `0x640` as `BaseVertex` in every draw (`gpu/vk/vk_shader.cpp:540`). If NVN's value for a non-indexed draw is 0 or the base instance, that is a question about every non-indexed draw LS makes, not only quads. This PR only makes quads give the same value as the rest. A first vertex of 2^31 or more (not a real draw) makes the vertex offset negative; on 32-bit arithmetic the vertex index wraps to the same value as before. **Turning it off:** revert the commit **Compatibility:** Nothing changes: no cache, save, `longshot_options.ini` key or vk ABI is touched. ## Reviewer notes - Conflicts with open PRs (`git merge-tree`, heads of 13:58 CST), each one hunk in `vk_draw.cpp`'s quad branch: - #851 (`mac/topic-draw-path-quads-mesh`, which carries the indirect quads) and #852 (`mac/topic-mac-perf`, on top of it) write the triangles through `quad_draws::triangles(…, [&](uint32_t i) { return d.indexed ? src[i] : first + i; }, out)` and draw through `drawid_direct::indexed(quads * 6, …, d.indexed ? d.base_vertex : 0, …)`. Resolution: `d.indexed ? src[i] : i` in the lambda (dropping `first`), and `d.first` in place of the `0`. - #850 (`mac/topic-draw-path`) draws through the same `drawid_direct::indexed(…, d.indexed ? d.base_vertex : 0, …)`. Put `d.first` in place of the `0`; its corners merge to this PR's. - Whichever lands second also gives `tests/test_quad_base_vertex.py` stand-ins for the names those branches use in the quad branch (`quad_draws.h`, `drawid_direct`, `drawid_indirect`, `quad_records`, `quad_tally`, `quad_lost`, `quad_rotated`, `quad_drawn`, `census_draw`, `provoking_note`, `census_fan_draw`). - #845 to #849 and #853 (`fix/quad-stream-grow`) merge cleanly. The test passes on the tree merged with #853 (its `stream_alloc` stand-in takes the third argument). - Rebased onto main `7bacf846` (head `98218916`, the same patch); the test passes on that tree. The whole suite ran at `daeb117c` on `aa95d35f`; on `7bacf846` it is queued and this description gets its result. ## Issues See #420 ## Checklist ### Everyone - [x] One topic. - [x] The title is a Conventional Commit (`type(scope): description`) of the status line's type. - [x] Why gives the reason plainly and links the issues that fit (the tracker searched). - [x] Measurements has a verdict, or one line saying why there is nothing to measure. - [x] Testing names what was tested, what wasn't, and what must still be tested, where and how. (Test request T-P4YP.) - [x] Rebased on current `main` (`7bacf846`, head `98218916`). - [x] `python -I -B tests/run_all.py` passes (any failure that also fails on `main` is named). - [x] No game files, dumps, build output or generated files. - [x] `third_party/` untouched (a new folder with a `PROVENANCE.md` instead). - [x] The license is OK: GPL-3.0-or-later, nothing incompatible and nothing decompiled. ### When it applies - [x] AI assistance recorded with `Assisted-by:` / `Co-Authored-By:` trailers. - [x] A game-free test added for the fix, failing on `main` and passing here. - [x] A check under `tests/` that reads changed source updated in this PR, not weakened. (None needed a change: every check that reads `vk_draw.cpp` gives the same result as on main; the new test reads the quad branch.)
fix(vk): a direct quad draw's BaseVertex is its first vertex, as for every other non-indexed draw
Some checks failed
CI / Python source checks (ubuntu-24.04, part 1/2) (pull_request) Has been skipped
Details
CI / Python source checks (ubuntu-24.04, part 2/2) (pull_request) Has been skipped
Details
CI / SPIR-V fixtures (global narrow load/store, direct surface atomics, F2I immediate) (pull_request) Has been skipped
Details
Third-party parts / The same as upstream (pull_request) Has been skipped
Details
Website / Website on Cloudflare (pull_request_target) Has been skipped
Details
CI / Conventional Commit title (pull_request) Successful in 3s
Details
CI / Workflow lint (actionlint) (pull_request) Successful in 6s
Details
Guide screenshots / Guide images and local UI source review (pull_request) Failing after 5s
Details
Third-party parts / As their notes say (pull_request) Successful in 10s
Details
PR description / Description follows the template (pull_request_target) Successful in 4s
Details
9821891689 
A direct non-indexed quad draw made its triangles from the vertex numbers
first + 4q + corner and drew them with vkCmdDrawIndexed(..., vertexOffset 0).
Vulkan's BaseVertex for an indexed draw is its vertexOffset, so a program
that reads the draw's base vertex (the vertex stage's driver bank at 0x640,
which LS reads as BaseVertex) got 0 in such a draw. Every other non-indexed
draw LS makes is a vkCmdDraw, and Vulkan gives a non-indexed draw its first
vertex as BaseVertex. The indirect quad path (#851) gives it too.

The triangles now count from 0 (4q + corner), and the first vertex is the
vertexOffset. The vertices fetched are the same (index + vertexOffset =
first + 4q + corner). VertexIndex, which LS reads as NVN's VertexId, is the
same. BaseVertex is now the first vertex. Indexed quad draws, and every
other draw, are as before.

What NVN itself puts at 0x640 for a non-indexed draw is not known. GL gives
gl_BaseVertex 0 to a draw with no base vertex, and Eden's HLE of NVN's
non-indexed draw macro puts the base instance there. That question covers
every non-indexed draw LS makes, not only quads, and this commit does not
change it.

tests/test_quad_base_vertex.py runs draw()'s quad branch on the CPU and
reads its draw the way Vulkan does. On main it fails with 576 failures,
each a BaseVertex of 0 where the first vertex is not 0. Here it passes
(699 draws, 5,936 checks).

Assisted-by: Claude Opus 5.5
Co-Authored-By: Claude Opus 5.5 <[email protected]>
Some checks failed
CI / Python source checks (ubuntu-24.04, part 1/2) (pull_request) Has been skipped
Details
CI / Python source checks (ubuntu-24.04, part 2/2) (pull_request) Has been skipped
Details
CI / SPIR-V fixtures (global narrow load/store, direct surface atomics, F2I immediate) (pull_request) Has been skipped
Details
Third-party parts / The same as upstream (pull_request) Has been skipped
Details
Website / Website on Cloudflare (pull_request_target) Has been skipped
Details
CI / Conventional Commit title (pull_request) Successful in 3s
Details
CI / Workflow lint (actionlint) (pull_request) Successful in 6s
Details
Guide screenshots / Guide images and local UI source review (pull_request) Failing after 5s
Details
Third-party parts / As their notes say (pull_request) Successful in 10s
Details
PR description / Description follows the template (pull_request_target) Successful in 4s
Details
This pull request is marked as a work in progress.
This branch is out-of-date with the base branch
View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.
git fetch -u 'fix/direct-quad-basevertex:mooki-fix/direct-quad-basevertex'
git switch 'mooki-fix/direct-quad-basevertex'
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels   
area/accessibility
Barriers for people with disabilities

  
area/audio
Sound and music

  
area/input
Controllers, keyboard, mouse

  
area/install
Installing, updating, building from your game

  
area/menu
In-game menu and settings

  
area/renderer
Vulkan renderer, shaders, effects

  
area/saves
Save files

  
area/tooling
Developer tools: scripts, CI, build and release tooling

  
area/upscaling
DLSS, FSR, frame generation

  
beanstalk: approved @ 1697603
Set by Beanstalk for show; the farm's database is what counts

  
beanstalk: approved @ 2c5a62e
Set by Beanstalk for show; the farm's database is what counts

  
beanstalk: approved @ 4fd82b7
Set by Beanstalk for show; the farm's database is what counts

  
beanstalk: approved @ 64d6d09
Set by Beanstalk for show; the farm's database is what counts

  
beanstalk: approved @ 6f91fae
Set by Beanstalk for show; the farm's database is what counts

  
beanstalk: approved @ 70a78f9
Set by Beanstalk for show; the farm's database is what counts

  
beanstalk: approved @ 8015c9a
Set by Beanstalk for show; the farm's database is what counts

  
beanstalk: approved @ 8d361dc
Set by Beanstalk for show; the farm's database is what counts

  
beanstalk: approved @ 9d8356e
Set by Beanstalk for show; the farm's database is what counts

  
beanstalk: approved @ abf2227
Set by Beanstalk for show; the farm's database is what counts

  
beanstalk: approved @ d82f202
Set by Beanstalk for show; the farm's database is what counts

  
beanstalk: approved @ e5f1e40
Set by Beanstalk for show; the farm's database is what counts

  
beanstalk: approved @ ee8ab5f
Set by Beanstalk for show; the farm's database is what counts

  
ci: approved
A maintainer approved CircleCI for this fork PR (sticky; removed after 14 quiet days)

  
good first issue
A good start for a new contributor

  
gpu/amd
AMD GPUs

  
gpu/igpu
Integrated GPUs

  
gpu/intel
Intel GPUs

  
gpu/nvidia
NVIDIA GPUs

  
help wanted
Extra hands or knowledge wanted

  
kind
bug
 Something doesn't work as it should

  
kind
chore
 Build, CI, dependencies, tidying

  
kind
docs
 Documentation

  
kind
feature
 A new feature or an improvement

  
kind
performance
 Frame rate, frame time, loading, memory

  
kind
question
 A question rather than a change

  
needs measurements
Waiting for before/after measurements

  
platform/linux
Affects Linux (a change for every system carries both Windows and Linux)

  
platform/macos
macOS (Apple silicon or Intel Macs)

  
platform/steam-deck
Steam Deck

  
platform/windows
Affects Windows (a change for every system carries both Windows and Linux)

  
preview
Maintainers: deploy a preview of this PR's website (read its changes first). Removed after the run.

  
priority
critical
 Crashes, data loss, or blocks most players

  
priority
high
 Important: next in line

  
priority
low
 Nice to have

  
regression
Worked in an earlier build, broken in a newer one: highest priority, above other bugs

  
risk
high
 Broad or core change: the renderer, defaults on many systems, saves, installs, security

  
risk
low
 Small, contained change: little can break

  
risk
medium
 Changes behaviour in one area, or a default on some systems

  
status
blocked
 Waits on something else first

  
status
confirmed
 Reproduced or agreed on

  
status
duplicate
 Already reported or proposed

  
status
invalid
 Not a problem in this project

  
status
needs-info
 Waiting for more information from the reporter

  
status
wontfix
 Will not be worked on

  
testing wanted
Wanted: a test on other hardware (posts a test request in #test-requests)

  
ci: approved
No labels
area/accessibility
area/audio
area/input
area/install
area/menu
area/renderer
area/saves
area/tooling
area/upscaling
beanstalk: approved @ 1697603
beanstalk: approved @ 2c5a62e
beanstalk: approved @ 4fd82b7
beanstalk: approved @ 64d6d09
beanstalk: approved @ 6f91fae
beanstalk: approved @ 70a78f9
beanstalk: approved @ 8015c9a
beanstalk: approved @ 8d361dc
beanstalk: approved @ 9d8356e
beanstalk: approved @ abf2227
beanstalk: approved @ d82f202
beanstalk: approved @ e5f1e40
beanstalk: approved @ ee8ab5f
ci: approved
good first issue
gpu/amd
gpu/igpu
gpu/intel
gpu/nvidia
help wanted
kind
bug
kind
chore
kind
docs
kind
feature
kind
performance
kind
question
needs measurements
platform/linux
platform/macos
platform/steam-deck
platform/windows
preview
priority
critical
priority
high
priority
low
regression
risk
high
risk
low
risk
medium
status
blocked
status
confirmed
status
duplicate
status
invalid
status
needs-info
status
wontfix
testing wanted
ci: approved
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
MagicBeanDev/Longshot!907
No description provided.