0.4.0/screenshot: composite the hardware cursor into /screenshot issue #2
open andymccall opened this · 0 comments
andymccall
Raising as a consumer (rstar-api), and following up on Andys note that the
emulator can help here.
The gap
On the Neo6502 emulator the firmware display cursor is drawn as an SDL overlay
on the window, not into the framebuffer that /screenshot reads
(RNDGetRGBFrame reads videoRAM; the cursor is blitted separately in
sys_debugger.cpp). So a headless capture never shows the cursor — a UI toolkit
cannot screenshot-test its own pointer, and cursor-appearance work (rstar-api
#31) cannot be iterated headlessly at all.
The X16 emulator does NOT have this problem: its KERNAL mouse sprite is a VERA
sprite and composites into the captured frame, so /screenshot shows it.
Ask
Make /screenshot return what the user actually sees, cursor included — i.e.
composite the hardware/display cursor into the captured RGB frame on the Neo
(and any platform where the cursor is a separate overlay), at the position
MSEGetCursorDrawInformation reports, using CURGetCurrent.
That is most of the code already present in sys_debugger.cpps window-draw
path; it just needs to also run into the RGB buffer /screenshot returns.
Why it matters now
Two rstar-api features are blocked on it for automated verification:
#31 a custom cursor image (small red/black/white) — cannot confirm it
renders or looks right without eyeballing hardware.
General cursor regression tests — position, visibility, hotspot.
Pairs naturally with the 0.4.0 pointer-injection work (issue #1): inject a pointer,
step a frame, and /screenshot should show the cursor where it was put.
Imported from GitHub #3, opened by andymccall on 2026-07-22.
andymccall referenced by change f2dd3b3ac5ad on main ·
Raising as a consumer (rstar-api), and following up on Andys note that the emulator can help here.
The gap
On the Neo6502 emulator the firmware display cursor is drawn as an SDL overlay on the window, not into the framebuffer that
/screenshotreads (RNDGetRGBFramereads videoRAM; the cursor is blitted separately insys_debugger.cpp). So a headless capture never shows the cursor — a UI toolkit cannot screenshot-test its own pointer, and cursor-appearance work (rstar-api #31) cannot be iterated headlessly at all.The X16 emulator does NOT have this problem: its KERNAL mouse sprite is a VERA sprite and composites into the captured frame, so
/screenshotshows it.Ask
Make
/screenshotreturn what the user actually sees, cursor included — i.e. composite the hardware/display cursor into the captured RGB frame on the Neo (and any platform where the cursor is a separate overlay), at the positionMSEGetCursorDrawInformationreports, usingCURGetCurrent.That is most of the code already present in
sys_debugger.cpps window-draw path; it just needs to also run into the RGB buffer/screenshotreturns.Why it matters now
Two rstar-api features are blocked on it for automated verification:
Pairs naturally with the 0.4.0 pointer-injection work (issue #1): inject a pointer, step a frame, and
/screenshotshould show the cursor where it was put.Imported from GitHub #3, opened by andymccall on 2026-07-22.