-
Notifications
You must be signed in to change notification settings - Fork 2
+ ghosting from Gamate #14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
DnCraptor
commented
Oct 8, 2025
- bug-fix
Summary of ChangesHello @DnCraptor, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This PR refactors the ghosting implementation in the Gamate emulator, moving the logic into Highlights
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code Review
This pull request introduces a new ghosting effect and refactors how it's applied, which is a great improvement. However, I've found a few critical issues that will prevent the code from compiling or cause incorrect behavior at runtime. Please see my detailed comments below.
supervision_exec_ex((uint8_t *) SCREEN + 240 * 20 + 40, 240, 0, settings.ghosting); | ||
} else { | ||
supervision_exec_ex((uint8_t *) SCREEN, SV_W, 0); | ||
supervision_exec_ex((uint8_t *) SCREEN, SV_W, 0, settings.ghosting); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The function signature for supervision_exec_ex
has been updated to include a ghosting
parameter, but not all call sites have been updated. The call within the #else
block for non-VGA builds is still using the old signature, which will cause a compilation error.
// Around line 1253 in the new file
#else
supervision_exec_ex((uint8_t *) SCREEN + 240 * 20 + 40, 240, 0);
#endif
Please update all calls to supervision_exec_ex
to match the new four-argument signature.
src/potator/watara.c
Outdated
p_exp = expected_screen; | ||
uint8_t* p_out = backbuffer; | ||
uint8_t* p_rich = rich_screen; | ||
for (int i = 0; i < sizeof(rich_screen); ++i) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The loop for applying the ghosting effect has incorrect bounds. It iterates sizeof(rich_screen)
times, which is a fixed 200 * 240 = 48000
.
However, the actual rendered area is SV_H
(160) lines high, and the memory layout of each line is determined by backbufferWidth
. The preceding loop that populates expected_screen
only processes this SV_H
-line area.
This discrepancy will cause the loop to read from uninitialized parts of expected_screen
and write beyond the intended area in backbuffer
, leading to visual artifacts and undefined behavior.
The loop bounds should be based on the actual rendered area, which is SV_H * backbufferWidth
.
for (int i = 0; i < SV_H * backbufferWidth; ++i) {
set(PICO_BOARD "murmulator" CACHE STRING "Board type") | ||
#set(PICO_BOARD "murmulator2" CACHE STRING "Board type") | ||
#set(PICO_BOARD "olimex-pico-pc" CACHE STRING "Board type") | ||
#set(PICO_BOARD "waveshare_rp2040_pizero" CACHE STRING "Board type") | ||
set(PICO_BOARD "waveshare_rp2350_pizero" CACHE STRING "Board type") | ||
#set(PICO_BOARD "waveshare_rp2350_pizero" CACHE STRING "Board type") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These changes to PICO_BOARD
and the HDMI
option (on line 51) appear to be local development configurations. They switch the default target board to murmulator
and disable HDMI output.
Are these changes intended to be part of this pull request? If not, they should be reverted to avoid altering the default build configuration for other developers.