-
Notifications
You must be signed in to change notification settings - Fork 68
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
Debug screen is black "in front of" the beam #274
Comments
@richtw1 quite likes this: maybe it should be configurable? or the "remaining" screen should be like 30% faded out or something? |
I don't think I'd bother keeping it TBH. If it's more useful to see the entire screen then that's what it should do. Sometimes a million configurable options just needlessly complicates! |
That said, this isn't obviously easy to fix, because it's an inevitable consequence of clearing the texture at the start, instead of blanking scanlines as they're rasterised. This gave a reasonable performance gain, so it would be a shame to put it back. Other possibilities:
|
Agreed it's not an easy fix. Just taking these comments:
Keeping the "old" screen around in a debug mode might be an option. I already have some (expensive) debugging things knocking around that are disabled by default, and so "keep old screen around when debugging" might be an option. So long as I can put ?debug or something in the URL I'll be happy :) |
(that said the "old" screen around could be used to e.g. do phosphor simulation) |
Hitting a breakpoint or ctrl-HOME now yields a black screen post-the virtual CRTC beam. To repro:
I think this is probably a result of the improvements to the CRTC emulation, but it's convenient to see the screen when debugging :)
The text was updated successfully, but these errors were encountered: