Merge pull request #2401 from xexyl/ferguson12020-troubleshooting
Fixes in 2020/ferguson1/troubleshooting.{md,html}
This commit is contained in:
2 files changed
+60
-54
No files matched your search
@@ -411,16 +411,16 @@ it as structured as possible/easiest to find.</p>
|
||||
</div>
|
||||
<p>Because the score line is dynamic in length depending on the terminal size it
|
||||
can happen that the score/status wraps to the next line(s). This can be fixed by
|
||||
modifying the status line (see <a href="HACKING.html">HACKING.html</a> but
|
||||
modifying the status line (see <a href="HACKING.html">HACKING.html</a>) but
|
||||
you shouldn’t need it to be very wide.</p>
|
||||
<ul>
|
||||
<li><p>RESOLUTION #0: Use a bigger screen (it doesn’t take that many columns)</p>
|
||||
<li><p><strong>RESOLUTION #0</strong>: use a bigger screen (it doesn’t take that many columns)</p>
|
||||
<p><strong>Tip:</strong> try running <code>make test</code> to get an estimate of the minimum number of columns
|
||||
needed. This won’t work right if you change the score line!</p>
|
||||
<p>Note that this utility is not perfect; I describe this elsewhere. Either way a
|
||||
small screen will make it harder to play esp without the cheat modes enabled
|
||||
(but they can still be fun with large screens).</p></li>
|
||||
<li><p>RESOLUTION #1: Open the <a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2020/ferguson1/prog.c">prog.c</a> and change the line</p>
|
||||
<li><p><strong>RESOLUTION #1</strong>: open the <a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2020/ferguson1/prog.c">prog.c</a> and change the line</p>
|
||||
<pre><code> #define J Z(X:%d/%d Y:%d/%d S:%zu/%zu B:%zu\n),Y,y[-2],X, *y, A, g, c );</code></pre>
|
||||
<p>To be something like:</p>
|
||||
<pre><code> #define J Z(B:%zu\n), c);</code></pre>
|
||||
@@ -439,7 +439,7 @@ that there isn’t movement and sometimes it might have to take a moment to
|
||||
isn’t moving but as long as the head is moving then the snake can be assumed to
|
||||
be moving.</p>
|
||||
<ul>
|
||||
<li><p>RESOLUTION #0: Unless the game is paused as long as the snake head is moving
|
||||
<li><p><strong>RESOLUTION #0</strong>: unless the game is paused as long as the snake head is moving
|
||||
everything is fine even if it seems sometimes that the snake tail is still: this
|
||||
is normal and there are a few conditions that this might especially show itself
|
||||
e.g. when the snake is growing.</p>
|
||||
@@ -450,7 +450,7 @@ when it does move you’ll see it doesn’t move for long.</p>
|
||||
<p>Sometimes also it might appear that the movement is delayed but there are
|
||||
numerous causes for this some of which are a busy computer but ultimately
|
||||
it’ll catch up; just give it the time it needs.</p></li>
|
||||
<li><p>BOTTOM LINE: If you want more information then see the <a href="bugs.html">bugs.html</a>
|
||||
<li><p><strong>BOTTOM LINE</strong>: if you want more information then see the <a href="bugs.html">bugs.html</a>
|
||||
file.</p></li>
|
||||
</ul>
|
||||
<div id="invisiblehead">
|
||||
@@ -462,10 +462,10 @@ just have to continue moving on and you’d eventually find your head (assuming
|
||||
the rest of the screen isn’t covered with your body!). And what else could you
|
||||
expect if you decided to shove your head up your …. ? :))</p>
|
||||
<ul>
|
||||
<li><p>RESOLUTION #0: Actually I thought it would look better that you could see the
|
||||
<li><p><strong>RESOLUTION #0</strong>: actually I thought it would look better that you could see the
|
||||
head even when cannibalising so you should be able to lose your head and at the
|
||||
same time see it!</p></li>
|
||||
<li><p>RESOLUTION #1: If the terminal width is too small then it could be that the
|
||||
<li><p><strong>RESOLUTION #1</strong>: if the terminal width is too small then it could be that the
|
||||
score line is covering the wall, snake and even bug; I gave two resolutions to
|
||||
that earlier in this file. To get a recommended number of columns use <code>make test</code>.</p></li>
|
||||
</ul>
|
||||
@@ -486,19 +486,19 @@ without there being restrictions it could end up being a bad value that causes
|
||||
the bug placement loop to never end (in this case the snake would also stop
|
||||
moving).</p>
|
||||
<ul>
|
||||
<li><p>RESOLUTION #0: If evasion mode is enabled (default after 300 moves) just wait
|
||||
<li><p><strong>RESOLUTION #0</strong>: if evasion mode is enabled (default after 300 moves) just wait
|
||||
it out and the bug will move to a new place and it might be easier to see in the
|
||||
new place.</p></li>
|
||||
<li><p>RESOLUTION #1: The terminal size is too small for the score line. See the
|
||||
<li><p><strong>RESOLUTION #1</strong>: the terminal size is too small for the score line. See the
|
||||
earlier problem for how to resolve this if that’s the case.</p></li>
|
||||
<li><p>RESOLUTION #2: Sometimes you have to look closely for it can be easy to miss.
|
||||
<li><p><strong>RESOLUTION #2</strong>: sometimes you have to look closely for it can be easy to miss.
|
||||
If it’s against the wall and the screen is <a href="https://www.hp-lexicon.org/character/gaunt-family/morfin-gaunt/">Snakey</a> or you’re tired or the colour
|
||||
contrast isn’t right for you or something like that it might be harder to see.
|
||||
Try pausing the game (space) and scan the screen for it. If you really are
|
||||
desperate copy and paste the entire file into a document and search for the bug
|
||||
char (if it’s an editor like vi/vim you will have to be sure to escape the char
|
||||
since <code>*</code> is a regexp metacharacter). This has happened to me numerous times.</p></li>
|
||||
<li><p>RESOLUTION #3: If the colour contrast is not good for your eyes use the
|
||||
<li><p><strong>RESOLUTION #3</strong>: if the colour contrast is not good for your eyes use the
|
||||
<a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2020/ferguson1/snake-colours.sh">snake-colours.sh</a> script to select a different colour scheme.</p></li>
|
||||
</ul>
|
||||
<div id="froze">
|
||||
@@ -508,14 +508,14 @@ since <code>*</code> is a regexp metacharacter). This has happened to me numerou
|
||||
have caused this (and I did this deliberately in development to find all the
|
||||
conditions I could to resolve them).</p>
|
||||
<ul>
|
||||
<li><p>RESOLUTION #0: If this does happen it likely is to do with placement of the
|
||||
<li><p><strong>RESOLUTION #0</strong>: if this does happen it likely is to do with placement of the
|
||||
bug; that is why I have the max size of the snake capped a fair bit below the
|
||||
maximum number of coordinates in the game field: because the bug isn’t to be at
|
||||
a place the snake already occupies.</p></li>
|
||||
<li><p>RESOLUTION #1: If the system <code>rand()</code> implementation is really bad maybe it’s
|
||||
<li><p><strong>RESOLUTION #1</strong>: if the system <code>rand()</code> implementation is really bad maybe it’s
|
||||
having a problem finding a location to place the bug. The best I can think of is
|
||||
to try increasing the screen size or decrease the max size of the snake.</p></li>
|
||||
<li><p>BOTTOM LINE: If the bug cannot find a place to be this will likely cause the
|
||||
<li><p><strong>BOTTOM LINE</strong>: if the bug cannot find a place to be this will likely cause the
|
||||
game to freeze because the game loops until it finds an available place for the
|
||||
bug to be; if the pRNG is so bad wrt where the snake occupies it could
|
||||
theoretically happen. If this happens you will have to kill the game by e.g.
|
||||
@@ -573,11 +573,11 @@ This shouldn’t happen though.</p></li>
|
||||
<p>Realistically the game shouldn’t take that much memory but maybe in some very
|
||||
busy systems it would have a problem.</p>
|
||||
<ul>
|
||||
<li><p>RESOLUTION #0: If the rand() implementation is particularly poor then it might
|
||||
<li><p><strong>RESOLUTION #0</strong>: if the <code>rand(3)</code> implementation is particularly poor then it might
|
||||
be that the bug placement is taking more time.</p></li>
|
||||
<li><p>RESOLUTION #1: It could also be the arrays being updated as the snake gets
|
||||
<li><p><strong>RESOLUTION #1</strong>: it could also be the arrays being updated as the snake gets
|
||||
bigger.</p></li>
|
||||
<li><p>BOTTOM LINE: I find it unlikely that either of these happen and I don’t know
|
||||
<li><p><strong>BOTTOM LINE</strong>: I find it unlikely that either of these happen and I don’t know
|
||||
what to say; you can try decreasing the max size to see if it doesn’t reach this
|
||||
problem. Otherwise it would be good to see if you can find a pattern: is it when
|
||||
the snake is bigger i.e. the screen is rather fuller than when you first begin?
|
||||
@@ -587,25 +587,25 @@ Or is the system rather busy?</p></li>
|
||||
<h2 id="i-set-size0-grow1-ate-a-bug-but-still-only-the-head-was-visible-why"><a href="#toc">I set <code>SIZE=0 GROW=1</code>, ate a bug but still only the head was visible! Why?</a></h2>
|
||||
</div>
|
||||
<ul>
|
||||
<li><p>RESOLUTION #0: The size includes the head but what should it show if the size
|
||||
<li><p><strong>RESOLUTION #0</strong>: the size includes the head but what should it show if the size
|
||||
is 0? The head is the obvious choice so once you do get to size 1 you will still
|
||||
only have the head. When you get to size 2 you’ll have part of the body too.
|
||||
Try:</p>
|
||||
<pre><code> SIZE=1 GROW=1</code></pre>
|
||||
<p>And you will see that at one bug you’ll have size two and just as if you had
|
||||
two bugs with the previous invocation.</p>
|
||||
<p>BTW: When you are size 1 you can go back on yourself even if cannibalism is
|
||||
<p>BTW: when you are size 1 you can go back on yourself even if cannibalism is
|
||||
disabled because there really isn’t anything to go back through: it’s just
|
||||
you moving the head until you find a body to use! Once you have size >= 2
|
||||
then cannibalism mode counts.</p></li>
|
||||
<li><p>BOTTOM LINE: In some senses SIZE=0 and SIZE=1 are the same thing.</p></li>
|
||||
<li><p><strong>BOTTOM LINE</strong>: in some senses <code>SIZE=0</code> and <code>SIZE=1</code> are the same thing.</p></li>
|
||||
</ul>
|
||||
<div id="monochrome">
|
||||
<h2 id="i-like-black-text-on-a-white-background-but-even-with-a-white-background-terminal-it-ends-up-black"><a href="#toc">I like black text on a white background but even with a white background terminal it ends up black!</a></h2>
|
||||
</div>
|
||||
<p>This is a curses thing but fortunately it should be easy enough to solve.</p>
|
||||
<ul>
|
||||
<li><p>RESOLUTION #0: Try setting the terminal to monochrome for the invocation of
|
||||
<li><p><strong>RESOLUTION #0</strong>: try setting the terminal to monochrome for the invocation of
|
||||
the game. Depending on what is installed on your system you might not have a
|
||||
monochrome terminal but you can certainly get them. In Red Hat systems these can
|
||||
be found in the package ncurses-term but maybe that will vary on others. I don’t
|
||||
@@ -615,7 +615,7 @@ so that’s probably why; in CentOS I did have to install it specially.</p>
|
||||
terminal is under <code>/usr/share/terminfo/l/linux-m</code> and under macOS (Catalina
|
||||
at least) it’s at <code>/usr/share/terminfo/6c/linux-m</code> (for macOS Ventura it’s
|
||||
<code>/usr/share/terminfo/6c/linux-m</code>).</p></li>
|
||||
<li><p>BOTTOM LINE: Try using a monochrome terminal for the game by e.g.:</p>
|
||||
<li><p><strong>BOTTOM LINE</strong>: try using a monochrome terminal for the game by e.g.:</p>
|
||||
<pre><code> TERM=linux-m ./prog</code></pre>
|
||||
<p>And then on your white background terminal the game should keep the
|
||||
background white and the foreground black. This will of course mean you have
|
||||
@@ -629,7 +629,7 @@ eat too many bytes in the entry (I cite the functions in the
|
||||
<h2 id="the-text-is-hard-to-see-not-bright-enough"><a href="#toc">The text is hard to see (not bright enough)!</a></h2>
|
||||
</div>
|
||||
<ul>
|
||||
<li><p>RESOLUTION #0: Make sure that your terminal settings have for bold text a
|
||||
<li><p><strong>RESOLUTION #0</strong>: make sure that your terminal settings have for bold text a
|
||||
brighter font. The way I have my terminal profiles set up is to use bright
|
||||
colours for bold text. I specifically enable bold in the program so try and find
|
||||
out if enabling brighter colours is possible.</p>
|
||||
@@ -638,7 +638,10 @@ playing with the colours in your terminal, maybe the font size or various
|
||||
other settings. Probably better to make a new profile for this first in case
|
||||
you mess up your old one. FWIW I haven’t had this problem on consoles only
|
||||
and in my systems I have the option to enable brighter colours for bold - it
|
||||
was only in testing that I came across this problem.</p></li>
|
||||
was only in testing that I came across this problem. Of course you might
|
||||
also try changing the colours of the game. For that see
|
||||
<a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2020/ferguson1/snake-colours.sh">snake-colours.sh</a> and
|
||||
<a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2020/ferguson1/play.sh">play.sh</a>.</p></li>
|
||||
</ul>
|
||||
<div id="movefaster">
|
||||
<h2 id="can-i-move-the-snake-faster-temporarily-without-having-to-modify-the-wait-time"><a href="#toc">Can I move the snake faster temporarily without having to modify the wait time?</a></h2>
|
||||
@@ -646,10 +649,10 @@ was only in testing that I came across this problem.</p></li>
|
||||
<p>Yes. The <code>getch()</code> call is non-blocking when the timeout value is positive so
|
||||
it’s up to that number of milliseconds.</p>
|
||||
<ul>
|
||||
<li><p>RESOLUTION #0: All you need to do then is hold down the direction key (or for
|
||||
<li><p><strong>RESOLUTION #0</strong>: all you need to do then is hold down the direction key (or for
|
||||
that matter any other key that <code>getch()</code> will pick up on). You can also rapidly
|
||||
push the key instead of holding it down.</p></li>
|
||||
<li><p>BOTTOM LINE: Depending on the key repeat rate and/or how fast you repeatedly
|
||||
<li><p><strong>BOTTOM LINE</strong>: depending on the key repeat rate and/or how fast you repeatedly
|
||||
hit the key you can have more control over the speed - as long as it is quicker
|
||||
than the regular wait time. For negative wait time (drawing mode) you have to
|
||||
hit a key every time to move because it is blocking.</p></li>
|
||||
@@ -712,7 +715,7 @@ so that by setting the size to -1 it went to the max unsigned value):</p>
|
||||
<pre><code> $ MAXSIZE=-1 ./prog
|
||||
memory error
|
||||
X:0/157 Y:0/42 S:3/18446744073709551614 B:0</code></pre>
|
||||
<p>BTW: There are two arrays that have to be <strong>MAXSIZE</strong> (technically + 1).</p>
|
||||
<p>BTW: there are two arrays that have to be <strong>MAXSIZE</strong> (technically + 1).</p>
|
||||
<p>Is it possible that some value specified by the user could mess this up? I do
|
||||
not know but what I do know is that because it’s unsigned it can’t be negative;
|
||||
if the max size is 0 then the array size will be 1 but it won’t matter because
|
||||
|
||||
@@ -29,10 +29,10 @@ it as structured as possible/easiest to find.
|
||||
|
||||
Because the score line is dynamic in length depending on the terminal size it
|
||||
can happen that the score/status wraps to the next line(s). This can be fixed by
|
||||
modifying the status line (see [HACKING.html][] but
|
||||
modifying the status line (see [HACKING.html][]) but
|
||||
you shouldn't need it to be very wide.
|
||||
|
||||
* RESOLUTION #0: Use a bigger screen (it doesn't take that many columns)
|
||||
* **RESOLUTION #0**: use a bigger screen (it doesn't take that many columns)
|
||||
|
||||
**Tip:** try running `make test` to get an estimate of the minimum number of columns
|
||||
needed. This won't work right if you change the score line!
|
||||
@@ -42,7 +42,7 @@ you shouldn't need it to be very wide.
|
||||
(but they can still be fun with large screens).
|
||||
|
||||
|
||||
* RESOLUTION #1: Open the [prog.c][] and change the line
|
||||
* **RESOLUTION #1**: open the [prog.c][] and change the line
|
||||
|
||||
#define J Z(X:%d/%d Y:%d/%d S:%zu/%zu B:%zu\n),Y,y[-2],X, *y, A, g, c );
|
||||
|
||||
@@ -69,7 +69,7 @@ isn't moving but as long as the head is moving then the snake can be assumed to
|
||||
be moving.
|
||||
|
||||
|
||||
* RESOLUTION #0: Unless the game is paused as long as the snake head is moving
|
||||
* **RESOLUTION #0**: unless the game is paused as long as the snake head is moving
|
||||
everything is fine even if it seems sometimes that the snake tail is still: this
|
||||
is normal and there are a few conditions that this might especially show itself
|
||||
e.g. when the snake is growing.
|
||||
@@ -85,7 +85,7 @@ e.g. when the snake is growing.
|
||||
numerous causes for this some of which are a busy computer but ultimately
|
||||
it'll catch up; just give it the time it needs.
|
||||
|
||||
* BOTTOM LINE: If you want more information then see the [bugs.html][]
|
||||
* **BOTTOM LINE**: if you want more information then see the [bugs.html][]
|
||||
file.
|
||||
|
||||
|
||||
@@ -99,11 +99,11 @@ just have to continue moving on and you'd eventually find your head (assuming
|
||||
the rest of the screen isn't covered with your body!). And what else could you
|
||||
expect if you decided to shove your head up your .... ? :))
|
||||
|
||||
* RESOLUTION #0: Actually I thought it would look better that you could see the
|
||||
* **RESOLUTION #0**: actually I thought it would look better that you could see the
|
||||
head even when cannibalising so you should be able to lose your head and at the
|
||||
same time see it!
|
||||
|
||||
* RESOLUTION #1: If the terminal width is too small then it could be that the
|
||||
* **RESOLUTION #1**: if the terminal width is too small then it could be that the
|
||||
score line is covering the wall, snake and even bug; I gave two resolutions to
|
||||
that earlier in this file. To get a recommended number of columns use `make
|
||||
test`.
|
||||
@@ -129,14 +129,14 @@ without there being restrictions it could end up being a bad value that causes
|
||||
the bug placement loop to never end (in this case the snake would also stop
|
||||
moving).
|
||||
|
||||
* RESOLUTION #0: If evasion mode is enabled (default after 300 moves) just wait
|
||||
* **RESOLUTION #0**: if evasion mode is enabled (default after 300 moves) just wait
|
||||
it out and the bug will move to a new place and it might be easier to see in the
|
||||
new place.
|
||||
|
||||
* RESOLUTION #1: The terminal size is too small for the score line. See the
|
||||
* **RESOLUTION #1**: the terminal size is too small for the score line. See the
|
||||
earlier problem for how to resolve this if that's the case.
|
||||
|
||||
* RESOLUTION #2: Sometimes you have to look closely for it can be easy to miss.
|
||||
* **RESOLUTION #2**: sometimes you have to look closely for it can be easy to miss.
|
||||
If it's against the wall and the screen is [Snakey][] or you're tired or the colour
|
||||
contrast isn't right for you or something like that it might be harder to see.
|
||||
Try pausing the game (space) and scan the screen for it. If you really are
|
||||
@@ -144,7 +144,7 @@ desperate copy and paste the entire file into a document and search for the bug
|
||||
char (if it's an editor like vi/vim you will have to be sure to escape the char
|
||||
since `*` is a regexp metacharacter). This has happened to me numerous times.
|
||||
|
||||
* RESOLUTION #3: If the colour contrast is not good for your eyes use the
|
||||
* **RESOLUTION #3**: if the colour contrast is not good for your eyes use the
|
||||
[snake-colours.sh][] script to select a different colour scheme.
|
||||
|
||||
|
||||
@@ -156,16 +156,16 @@ This should not be possible either but without certain safety checks in place I
|
||||
have caused this (and I did this deliberately in development to find all the
|
||||
conditions I could to resolve them).
|
||||
|
||||
* RESOLUTION #0: If this does happen it likely is to do with placement of the
|
||||
* **RESOLUTION #0**: if this does happen it likely is to do with placement of the
|
||||
bug; that is why I have the max size of the snake capped a fair bit below the
|
||||
maximum number of coordinates in the game field: because the bug isn't to be at
|
||||
a place the snake already occupies.
|
||||
|
||||
* RESOLUTION #1: If the system `rand()` implementation is really bad maybe it's
|
||||
* **RESOLUTION #1**: if the system `rand()` implementation is really bad maybe it's
|
||||
having a problem finding a location to place the bug. The best I can think of is
|
||||
to try increasing the screen size or decrease the max size of the snake.
|
||||
|
||||
* BOTTOM LINE: If the bug cannot find a place to be this will likely cause the
|
||||
* **BOTTOM LINE**: if the bug cannot find a place to be this will likely cause the
|
||||
game to freeze because the game loops until it finds an available place for the
|
||||
bug to be; if the pRNG is so bad wrt where the snake occupies it could
|
||||
theoretically happen. If this happens you will have to kill the game by e.g.
|
||||
@@ -244,13 +244,13 @@ snake. See below for some tests.
|
||||
Realistically the game shouldn't take that much memory but maybe in some very
|
||||
busy systems it would have a problem.
|
||||
|
||||
* RESOLUTION #0: If the rand() implementation is particularly poor then it might
|
||||
* **RESOLUTION #0**: if the `rand(3)` implementation is particularly poor then it might
|
||||
be that the bug placement is taking more time.
|
||||
|
||||
* RESOLUTION #1: It could also be the arrays being updated as the snake gets
|
||||
* **RESOLUTION #1**: it could also be the arrays being updated as the snake gets
|
||||
bigger.
|
||||
|
||||
* BOTTOM LINE: I find it unlikely that either of these happen and I don't know
|
||||
* **BOTTOM LINE**: I find it unlikely that either of these happen and I don't know
|
||||
what to say; you can try decreasing the max size to see if it doesn't reach this
|
||||
problem. Otherwise it would be good to see if you can find a pattern: is it when
|
||||
the snake is bigger i.e. the screen is rather fuller than when you first begin?
|
||||
@@ -261,7 +261,7 @@ Or is the system rather busy?
|
||||
## <a href="#toc">I set `SIZE=0 GROW=1`, ate a bug but still only the head was visible! Why?</a>
|
||||
</div>
|
||||
|
||||
* RESOLUTION #0: The size includes the head but what should it show if the size
|
||||
* **RESOLUTION #0**: the size includes the head but what should it show if the size
|
||||
is 0? The head is the obvious choice so once you do get to size 1 you will still
|
||||
only have the head. When you get to size 2 you'll have part of the body too.
|
||||
Try:
|
||||
@@ -271,12 +271,12 @@ Try:
|
||||
And you will see that at one bug you'll have size two and just as if you had
|
||||
two bugs with the previous invocation.
|
||||
|
||||
BTW: When you are size 1 you can go back on yourself even if cannibalism is
|
||||
BTW: when you are size 1 you can go back on yourself even if cannibalism is
|
||||
disabled because there really isn't anything to go back through: it's just
|
||||
you moving the head until you find a body to use! Once you have size >= 2
|
||||
then cannibalism mode counts.
|
||||
|
||||
* BOTTOM LINE: In some senses SIZE=0 and SIZE=1 are the same thing.
|
||||
* **BOTTOM LINE**: in some senses `SIZE=0` and `SIZE=1` are the same thing.
|
||||
|
||||
|
||||
<div id="monochrome">
|
||||
@@ -285,7 +285,7 @@ Try:
|
||||
|
||||
This is a curses thing but fortunately it should be easy enough to solve.
|
||||
|
||||
* RESOLUTION #0: Try setting the terminal to monochrome for the invocation of
|
||||
* **RESOLUTION #0**: try setting the terminal to monochrome for the invocation of
|
||||
the game. Depending on what is installed on your system you might not have a
|
||||
monochrome terminal but you can certainly get them. In Red Hat systems these can
|
||||
be found in the package ncurses-term but maybe that will vary on others. I don't
|
||||
@@ -297,7 +297,7 @@ so that's probably why; in CentOS I did have to install it specially.
|
||||
at least) it's at `/usr/share/terminfo/6c/linux-m` (for macOS Ventura it's
|
||||
`/usr/share/terminfo/6c/linux-m`).
|
||||
|
||||
* BOTTOM LINE: Try using a monochrome terminal for the game by e.g.:
|
||||
* **BOTTOM LINE**: try using a monochrome terminal for the game by e.g.:
|
||||
|
||||
TERM=linux-m ./prog
|
||||
|
||||
@@ -315,7 +315,7 @@ so that's probably why; in CentOS I did have to install it specially.
|
||||
## <a href="#toc">The text is hard to see (not bright enough)!</a>
|
||||
</div>
|
||||
|
||||
* RESOLUTION #0: Make sure that your terminal settings have for bold text a
|
||||
* **RESOLUTION #0**: make sure that your terminal settings have for bold text a
|
||||
brighter font. The way I have my terminal profiles set up is to use bright
|
||||
colours for bold text. I specifically enable bold in the program so try and find
|
||||
out if enabling brighter colours is possible.
|
||||
@@ -325,7 +325,10 @@ out if enabling brighter colours is possible.
|
||||
other settings. Probably better to make a new profile for this first in case
|
||||
you mess up your old one. FWIW I haven't had this problem on consoles only
|
||||
and in my systems I have the option to enable brighter colours for bold - it
|
||||
was only in testing that I came across this problem.
|
||||
was only in testing that I came across this problem. Of course you might
|
||||
also try changing the colours of the game. For that see
|
||||
[snake-colours.sh](%%REPO_URL%%/2020/ferguson1/snake-colours.sh) and
|
||||
[play.sh](%%REPO_URL%%/2020/ferguson1/play.sh).
|
||||
|
||||
|
||||
<div id="movefaster">
|
||||
@@ -335,11 +338,11 @@ out if enabling brighter colours is possible.
|
||||
Yes. The `getch()` call is non-blocking when the timeout value is positive so
|
||||
it's up to that number of milliseconds.
|
||||
|
||||
* RESOLUTION #0: All you need to do then is hold down the direction key (or for
|
||||
* **RESOLUTION #0**: all you need to do then is hold down the direction key (or for
|
||||
that matter any other key that `getch()` will pick up on). You can also rapidly
|
||||
push the key instead of holding it down.
|
||||
|
||||
* BOTTOM LINE: Depending on the key repeat rate and/or how fast you repeatedly
|
||||
* **BOTTOM LINE**: depending on the key repeat rate and/or how fast you repeatedly
|
||||
hit the key you can have more control over the speed - as long as it is quicker
|
||||
than the regular wait time. For negative wait time (drawing mode) you have to
|
||||
hit a key every time to move because it is blocking.
|
||||
@@ -447,7 +450,7 @@ so that by setting the size to -1 it went to the max unsigned value):
|
||||
```
|
||||
|
||||
|
||||
BTW: There are two arrays that have to be **MAXSIZE** (technically + 1).
|
||||
BTW: there are two arrays that have to be **MAXSIZE** (technically + 1).
|
||||
|
||||
Is it possible that some value specified by the user could mess this up? I do
|
||||
not know but what I do know is that because it's unsigned it can't be negative;
|
||||
|
||||
Reference in new issue
Block a user