Skip to content
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

Incorrect rendering for Gorched terminal-based game. #6265

Closed
oising opened this issue May 30, 2020 · 5 comments · Fixed by #16825
Closed

Incorrect rendering for Gorched terminal-based game. #6265

oising opened this issue May 30, 2020 · 5 comments · Fixed by #16825
Labels
Area-Rendering Text rendering, emoji, complex glyph & font-fallback issues Area-VT Virtual Terminal sequence support In-PR This issue has a related PR Issue-Bug It either shouldn't be doing this or needs an investigation. Needs-Tag-Fix Doesn't match tag requirements Priority-3 A description (P3) Product-Terminal The new Windows Terminal.
Milestone

Comments

@oising
Copy link
Collaborator

oising commented May 30, 2020

Another render canary for you, @miniksa: Gorched (scorched earth game, terminal version.) It even has a Windows installer, so I'm guessing it was tested on alacritty or something.

From: https://github.com/zladovan/gorched

It should look like:

Attract Screen

But actually looks like (with default options):

image

When I run with "safe" options, gorched --low-color --ascii-only I see:

image

No matter what width I set, I couldn't get it to align. Additionally, it seems there's some persistent glitching after the game is quit (ctrl+c) with margins and wrapping.

@ghost ghost added Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting Needs-Tag-Fix Doesn't match tag requirements labels May 30, 2020
@oising oising added Area-Rendering Text rendering, emoji, complex glyph & font-fallback issues Area-VT Virtual Terminal sequence support Issue-Bug It either shouldn't be doing this or needs an investigation. and removed Needs-Tag-Fix Doesn't match tag requirements labels May 30, 2020
@oising
Copy link
Collaborator Author

oising commented May 30, 2020

I had a look at the underlying go library that the game is built on, termloop. It seems none of the examples there render correctly either, but they are significantly simpler. Maybe that would be easier to debug. I set up the environment like so:

scoop install go
go get -u github.com/JoelOtter/termloop
git clone https://github.com/JoelOtter/termloop

Then I ran some of the examples in: /tree/master/_examples -- they all render messed up, or don't work at all. I wonder what it's doing that's so wacky.

@DHowett
Copy link
Member

DHowett commented May 30, 2020

Termbox, the library Termloop builds on, notoriously (at least, they're notorious to me 😄) tries to be clever about interacting with the Windows console instead of using our VT support. I wonder what they're doing.

This is probably something "conhost recording" would help with. . . 😄

Thanks for looking at this, @oising!

@j4james
Copy link
Collaborator

j4james commented May 30, 2020

This is essentially a duplicate of #4363. The game uses console API calls to write to the screen buffer, and it looks like a lot of the blank areas of the background are actually the zero codepoint. Ideally conpty should be translating those to something like a space or non-breaking space, but it's just passing them through as a null control, which then ends up getting ignored.

@oising
Copy link
Collaborator Author

oising commented May 30, 2020

Oh, lordy. I didn't look that closely. I just presumed it was VT all the way ... look what I've become! Close as a dup if you see fit, guys.

@j4james
Copy link
Collaborator

j4james commented May 30, 2020

I should mention the colors also don't work (i.e. some elements will be invisible) unless you've used the --low-color option, because obviously the console APIs can only handle 16 colors.

That said, you can actually run the Linux build in WSL, and that works perfectly (as far as I can tell), because it's then using actual VT sequences.

@zadjii-msft zadjii-msft removed the Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting label Jun 9, 2020
@ghost ghost added the Needs-Tag-Fix Doesn't match tag requirements label Jun 9, 2020
@zadjii-msft zadjii-msft added the Product-Terminal The new Windows Terminal. label Jun 9, 2020
@ghost ghost removed the Needs-Tag-Fix Doesn't match tag requirements label Jun 9, 2020
@zadjii-msft zadjii-msft added the Priority-3 A description (P3) label Jun 9, 2020
@zadjii-msft zadjii-msft added this to the Terminal v2.0 milestone Jun 9, 2020
@zadjii-msft zadjii-msft modified the milestones: Terminal v2.0, 22H2 Jan 4, 2022
@zadjii-msft zadjii-msft modified the milestones: 22H2, Backlog Jul 5, 2023
@microsoft-github-policy-service microsoft-github-policy-service bot added the In-PR This issue has a related PR label Mar 5, 2024
@DHowett DHowett closed this as completed in 563b731 Mar 6, 2024
@microsoft-github-policy-service microsoft-github-policy-service bot added the Needs-Tag-Fix Doesn't match tag requirements label Mar 6, 2024
DHowett pushed a commit that referenced this issue Mar 8, 2024
When using the legacy console APIs, it's possible to write arbitrary
codepoints into the buffer. If any of those codepoints are in the C0 or
C1 range, and the buffer contents are forwarded over conpty, they can
end up mistakenly interpreted as controls by the connected terminal.

This PR fixes that issue by converting any C0 and C1 codepoints in the
buffer into printable glyphs before forwarding them over conpty. I've
used the C0 glyphs from the DOS 437 codepage and just a `?` for the C1
codepoints, since that's what you would typically have seen in the v1
console with a raster font.

Although this doesn't address the main problem in #16410, it should at
least fix the rendering issues they're seeing when running their app in
Windows Terminal.

I've confirmed that the test case in #4363 now looks the same in Windows
Terminal as it does in conhost, and I've tested the Windows version of
the terminal game [Gorched], and confirmed that it now works correctly
in Window Terminal.

[Gorched]: https://github.com/zladovan/gorched

Closes #4363
Closes #6265

(cherry picked from commit 563b731)
Service-Card-Id: 92001662
Service-Version: 1.20
DHowett pushed a commit that referenced this issue Mar 8, 2024
When using the legacy console APIs, it's possible to write arbitrary
codepoints into the buffer. If any of those codepoints are in the C0 or
C1 range, and the buffer contents are forwarded over conpty, they can
end up mistakenly interpreted as controls by the connected terminal.

This PR fixes that issue by converting any C0 and C1 codepoints in the
buffer into printable glyphs before forwarding them over conpty. I've
used the C0 glyphs from the DOS 437 codepage and just a `?` for the C1
codepoints, since that's what you would typically have seen in the v1
console with a raster font.

Although this doesn't address the main problem in #16410, it should at
least fix the rendering issues they're seeing when running their app in
Windows Terminal.

I've confirmed that the test case in #4363 now looks the same in Windows
Terminal as it does in conhost, and I've tested the Windows version of
the terminal game [Gorched], and confirmed that it now works correctly
in Window Terminal.

[Gorched]: https://github.com/zladovan/gorched

Closes #4363
Closes #6265

(cherry picked from commit 563b731)
Service-Card-Id: 92001661
Service-Version: 1.19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-Rendering Text rendering, emoji, complex glyph & font-fallback issues Area-VT Virtual Terminal sequence support In-PR This issue has a related PR Issue-Bug It either shouldn't be doing this or needs an investigation. Needs-Tag-Fix Doesn't match tag requirements Priority-3 A description (P3) Product-Terminal The new Windows Terminal.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants