Terminal version requires X server running

[jwt27]

Hey, just discovered this project accidentally by googling "jatgnas.8ys". Turns out, this is exactly what I was looking for. Thanks!

I got it running on my Debian machine but for some reason it needs an X server present, or else I get this:

With vcxsrv running it all works, but the game plays quite slowly. Is that intentional?

[MestreLion]

Hi! Thanks for being interested and testing my humble restoration project!

No, roguepc does not require an X Server. It's a "pure text" game, it only uses ncurses library for cursor positioning, character colors and printing. I can play it fine on the Linux Console and on remote servers via SSH.

The issue you're seeing seems to be some mis-configuration between PuTTY and the remote Debian server. Curses is very picky about its environment, it requires a properly installed/configured terminal database and vars such as $TERM to be properly set by PuTTY. Also, PuTTY seems to be trying X11 forwarding, and it shouldn't/doesn't need to, as roguepc is not an X11 application.. What happens when you try similar "ncurses-based-text-only" software such as nano or aptitude?

[jwt27]

That's the thing, I've never seen this issue with other curses applications. This message normally only comes up if I start an X11 application, eg. glxgears. It seems something in roguepc is trying to communicate with the X server, for some reason. Also, it only happens during gameplay, and not on the title screen or key-bindings screen.

I have TERM=putty-256color, if it matters. I tried TERM=xterm (should be roughly compatible) and it did the same thing.

edit: When I unset DISPLAY, the game works and plays at full speed (with the X server active, it runs much like on an 8088).

If I run DISPLAY='' ./rogue, this happens: Looks like the game is repeatedly calling xset.

[MestreLion]

googling "jatgnas.8ys"

Btw, why were you googling for this? This "jatgnas.8ys" always puzzled me, and I have no idea what it means. the .8ys makes me suspect an OCR error when converting from image to text (.8YS is similar to .SYS, specially in DOS Fonts), but I wish I knew what the original was. This for me is one of the unsolved mysteries of Rogue

[jwt27]

Initially I went looking for a port of Rogue that uses the CP437 characters, being dissatisfied with the ugly BSD version that comes with Debian. I couldn't find any so I assumed no one had done it before, and I set out to see if I could do it myself. When I disassembled rogue.exe I found this cryptic file name, and googling that led me here :)

What it means, I have no idea. Maybe the presence of this file would enable a debug/cheat mode in earlier versions? That could explain why it's such a garbled name, it doesn't immediately stand out when you view the executable in a hex editor.

I have a (partial) fix for the issue described here, by the way. Will send a PR soon!

[MestreLion]

It seems something in roguepc is trying to communicate with the X server, for some reason.

I would suspect it's the splash screen, it's a separate executable that requires SDL, and that (usually) requires X. But...

Also, it only happens during gameplay, and not on the title screen or key-bindings screen.

... this rules out the splash. It's also very puzzling that it does not happen on the title screen.

I have TERM=putty-256color, if it matters. I tried TERM=xterm (should be roughly compatible) and it did the same thing.

Seems correct for curses. That enables 256 colors and allows unicode chars to display properly

When I unset DISPLAY, the game works and plays at full speed (with the X server active, it runs much like on an 8088).

DISPLAY is used by X Server (and its applications) to know which display/virtual TTY to use. It is also commonly used by applications to know if they're running under X or not. I'm almost sure ./src/rogue (the C compiled binary, not the shell script launcher) does not use it. Which leads me to...

Looks like the game is repeatedly calling xset.

humm... that leads me to believe the culprit is...

[MestreLion]

How are you invoking RoguePC? Are you using the ./roguepc shell script in the project root? If so, it might be launching xterm or gnome-terminal and then running ./src/rogue in them. And they are X applications. Ruuning XTerm or Gnome Terminal through PuTTY would most likely create a mess like you were describing.

Care to try simply running ./src/roguepc directly via PuTTY to see what happens?

[jwt27]

Yes, I'm running the game via ./src/rogue. The problem is that PuTTY always sets DISPLAY even when no X server is running, so that is not a reliable method to determine if the game is running in an X window. Hold on, I have a solution but I need to test it on a desktop Linux machine first.

[MestreLion]

Yes, I'm running the game via ./src/rogue.

So it looks like ncurses (the C library) is the one using DISPLAY. Which is really weird, as by itself it really shouldn't care about X, and it would also affect other software such as nano or aptitude (which I guess use ncurses, but I might be wrong)

The problem is that PuTTY always sets DISPLAY even when no X server is running

This is not good behavior... it would confuse X apps into thinking PuTTY is an X Server display, which I believe it isn't (it's merely an SSH terminal, right?). Is this at least configurable?

Hold on, I have a solution

Care to share what is your idea? I could work on it too, test a few things, and maybe create a launcher for PuTTY (similar to what ./roguepc does when deciding when/if invoke xterm or gnome terminal)

[jwt27]

The problem is in md_keyboard_leds(), where xset is used to read the keyboard LED status if DISPLAY is set. https://github.com/MestreLion/roguepc/blob/39531cd7b84abba5b8f43e18df707358999625a2/src/mach_dep.c#L72

See the pull request I submitted: #17 (I thought github would send you a notification for that)

[jwt27]

This is not good behavior... it would confuse X apps into thinking PuTTY is an X Server display, which I believe it isn't (it's merely an SSH terminal, right?). Is this at least configurable?

X11 forwarding can be disabled, but it's buried in a menu and very inconvenient to toggle on/off for each session. I just leave it enabled, and start the X server only when I need to run a gui application.

[MestreLion]

The problem is in md_keyboard_leds(), where xset is used to read the keyboard LED status if DISPLAY is set.

https://github.com/MestreLion/roguepc/blob/39531cd7b84abba5b8f43e18df707358999625a2/src/mach_dep.c#L72

See the pull request I submitted: #17 (I thought github would send you a notification for that)

Wow, I completely forgot about my md_keyboard_leds() hack! Nice job about the X11 library call!

[MestreLion]

This is not good behavior... it would confuse X apps into thinking PuTTY is an X Server display, which I believe it isn't (it's merely an SSH terminal, right?). Is this at least configurable?

X11 forwarding can be disabled, but it's buried in a menu and very inconvenient to toggle on/off for each session. I just leave it enabled, and start the X server only when I need to run a gui application.

And what values does PuTTY sets DISPLAY when X11 forwarding is enabled?

If it is empty, we might also check for an empty string in md_keyboard_lights() before trying to do X11 calls. But we can discuss that in your PR

[MestreLion]

Fixed by d14665303ba33e117d59929fca8fcba319fa3985

Thanks a LOT for that contribution!