Open jgabaut opened 8 months ago
Hello, sorry for the lag, but I'm back now! Thanks for raising the issue.
This is the smallest my terminal can be after running the game and getting the display notice without crashing:
I don't think I'll need to error handle the addwstr()
call since most people don't typically open up their terminals this tiny.
...maybe falling back to a minimal size that ensures something is drawn and no crash occurs.
If you mean physically resizing the user's terminal to a minimally accepted size by the program, I don't think there's a way to do that I'm pretty sure?
I will add in your PR #5 as immediately letting the users know of the correct terminal size is a good idea.
No, the fallback idea was something dumb like... A double check on size.
Basically, for the error display, you can know the minimal needed size not to crash (you seems to have found it).
When going to print the error, recheck size can show the error as expected. Otherwise... May as well try to print the error to 0,0
.
In any case, as you have rightly said, this doesn't really seem important or really useful to fix. I mostly wanted to just document this, since after #5, the possible crash would be moved earlier than before in the logic.
At the moment, the error display for too small of a screen is not always drawn correctly.
I think at the moment, the whole thing blows up if the screen's width is less than the error message.
This occurs on
main
branch whenever a call toensure_right_terminal_size()
finds a weird enough screen:When trying to run from patch #5, this error may occur as soon as the game is launched (given a screen size "small enough").
I guess error handling for the
addwstr()
call inself.screen.addstr((x // 2) + 1, submessage_ypos, submessage)
may alleviate this, maybe falling back to a minimal size that ensures something is drawn and no crash occurs.I'm mostly positive this was mostly me messing with the resizing, but I wonder what's the actual condition needed to make the drawing fail.