Add 2020 source files for real
This commit is contained in:
Landon Curt Noll committed
1 parent
a3c1748648
commit
9d61fc0fb4
147 files changed
+32101
No files matched your search
@@ -0,0 +1,383 @@
|
||||
<!doctype html public "-//W3C//DTD HTML 4.0 Transitional //EN">
|
||||
<html>
|
||||
<head>
|
||||
<meta name="GENERATOR" content="mkd2html 2.2.2">
|
||||
<meta http-equiv="Content-Type"
|
||||
content="text/html; charset=utf-8"> <link rel="stylesheet"
|
||||
type="text/css"
|
||||
href="../hint.css" />
|
||||
<title></title>
|
||||
</head>
|
||||
<body>
|
||||
<CENTER>
|
||||
<IMG SRC="/png/ioccc.png" ALT="IOCCC" height=78 width=267>
|
||||
<P><FONT size="6"><I>The International Obfuscated C Code Contest</I></FONT></P>
|
||||
<div id="bar">
|
||||
<ul>
|
||||
<li><a href="../index.html">About the 27th IOCCC</a></li>
|
||||
<li><a href="../whowon.html">27th IOCCC Winners</a></li>
|
||||
<li><a href="/index.html">IOCCC home</a></li>
|
||||
<li><a href="/winners.html">List of All Winners</a></li>
|
||||
<li><a href="/judges.html">The Judges</a></li>
|
||||
</ul>
|
||||
</div>
|
||||
<P><FONT size="6"><B>Supplemental Info</B></FONT></P>
|
||||
</CENTER>
|
||||
|
||||
|
||||
<h1>Terminals</h1>
|
||||
|
||||
<p>Terminals are very easy to mess up and for that reason they deserve their own
|
||||
file. I discuss terminal capabilities, dimensions (setting and how to restore
|
||||
sanity if it causes any problems) as well as colours (limitations etc.).</p>
|
||||
|
||||
<p><a name="toc"></a>
|
||||
- <a href="#termcaps">Capabilities support testing program</a>
|
||||
- <a href="#dimensions">Setting the game dimensions</a>
|
||||
* <a href="#linescolumns">The LINES and COLUMNS environmental variables</a>
|
||||
* <a href="#insanity">Terminal insanity</a>
|
||||
* <a href="#restore">Restoring the terminal</a>
|
||||
* <a href="#abuse">Terminal size abuse</a>
|
||||
- <a href="#termlimitations">Terminal limitations</a>
|
||||
- <a href="#colours">Terminal colours</a>
|
||||
* <a href="#background">Curses background</a>
|
||||
* <a href="#monochrome">Monochrome terminals</a>
|
||||
* <a href="#colourlimitations">Colour limitations</a>
|
||||
* <a href="#disablecolour">Disabling colour</a></p>
|
||||
|
||||
<h1><a name="termcaps" href="#toc">Capabilities support testing program</a></h1>
|
||||
|
||||
<p>Although it should be playable without the features I use (except that cursor
|
||||
movement is required) I have provided a source file that can test your terminal
|
||||
for the capabilities I use in the entry.</p>
|
||||
|
||||
<p>It also tries to determine the minimum number of columns to play without the
|
||||
status line overflowing - even with the dynamic length. Try:</p>
|
||||
|
||||
<pre><code> $ make test
|
||||
</code></pre>
|
||||
|
||||
<p>This compiles the program and runs it; you should see something like:</p>
|
||||
|
||||
<pre><code> terminal supports cursor movement
|
||||
terminal supports making cursor invisible
|
||||
terminal supports bold
|
||||
terminal supports colours
|
||||
|
||||
terminal rows 42 (39 playable)
|
||||
terminal cols 157 (155 playable)
|
||||
|
||||
snake size: 997 (max size: 6006)
|
||||
bugs: 199 (max size: 1201)
|
||||
|
||||
at least 34 columns recommended for snake size 997 (is 157)
|
||||
at least 37 columns recommended for snake size 6006 (is 157)
|
||||
|
||||
No problems detected.
|
||||
</code></pre>
|
||||
|
||||
<p>If I pass in any of the variables <strong>GROW</strong>, <strong>MAXSIZE</strong>, <strong>SIZE</strong> and/or
|
||||
<strong>LINES</strong> or <strong>COLUMNS</strong> it bases its calculations on those variables. For
|
||||
example:</p>
|
||||
|
||||
<pre><code> $ MAXSIZE=-1 GROW=1 make test
|
||||
terminal supports cursor movement
|
||||
terminal supports making cursor invisible
|
||||
terminal supports bold
|
||||
terminal supports colours
|
||||
|
||||
terminal rows 42 (39 playable)
|
||||
terminal cols 157 (155 playable)
|
||||
|
||||
snake size: 6006 (max size: 6006)
|
||||
bugs: 6001 (max size: 6001)
|
||||
|
||||
at least 37 columns recommended for snake size 6006 (is 157)
|
||||
at least 37 columns recommended for snake size 6006 (is 157)
|
||||
|
||||
No problems detected.
|
||||
</code></pre>
|
||||
|
||||
<p>As you can see it tells you the max size (the ‘capsized’ snake) as well as
|
||||
the requested max size (if the requested size is bigger than the capsize then it
|
||||
will be set to that value instead) of the snake. The capped size is like in the
|
||||
Snake game itself but the suggested minimum number of columns is based on a
|
||||
number of variables.</p>
|
||||
|
||||
<p>If I were to do the above but set columns to less < 35 then there would be a
|
||||
problem. But why if the utility recommends at least 37? This is because the
|
||||
max size of the snake also depends on the terminal size. This utility is not
|
||||
perfect: I don’t consider shedding; I set growth to 5 if it’s 0 (since it would
|
||||
be indeterminate how many bugs are possible before ‘winning’ since there would
|
||||
be no ‘winning’); and there are probably other things too.</p>
|
||||
|
||||
<p>As for capabilities: besides cursor movement the others are just nice to have.
|
||||
From my tests keeping the cursor visible doesn’t ruin gameplay but it is less
|
||||
distracting if nothing else to have it invisible (in fact due to the sequence of
|
||||
function calls the cursor would mostly appear to be not in the game field itself -
|
||||
from memory at least).</p>
|
||||
|
||||
<p>Maybe there are other capabilities I should check for that I’m unaware of but
|
||||
this should give you an idea.</p>
|
||||
|
||||
<p>If there are any problems it will say how many (fatal and otherwise). The fatal
|
||||
problems are if curses fails to initialise or if movement of cursor cannot be
|
||||
done (both seem odd).</p>
|
||||
|
||||
<p>Both scripts run this utility and prompt if there are any problems;
|
||||
you can continue either way.</p>
|
||||
|
||||
<h1><a name="dimensions" href="#toc">Setting the game dimensions</a></h1>
|
||||
|
||||
<p>There are a number of ways to do this and only one will keep the terminal sane
|
||||
all the time but that’s by running it under a terminal emulator that you can
|
||||
resize the window with first. But what if you want exacts?</p>
|
||||
|
||||
<h2><a name="linescolumns" href="#toc">The LINES and COLUMNS environmental variables</a></h2>
|
||||
|
||||
<p>To specify the lines/columns of curses program per instance use the <code>LINES</code> and
|
||||
<code>COLUMNS</code> environmental variables.</p>
|
||||
|
||||
<p>For demonstration consider the following:</p>
|
||||
|
||||
<pre><code> $ echo $LINES $COLUMNS
|
||||
42 157
|
||||
</code></pre>
|
||||
|
||||
<p>Note: I subtract 1 from the max y/x and the max coords in the game output
|
||||
include the walls and score line but these values are for the terminal itself.</p>
|
||||
|
||||
<p>Say you want 55 columns:</p>
|
||||
|
||||
<pre><code> $ COLUMNS=55 ./prog
|
||||
</code></pre>
|
||||
|
||||
<p>This will force curses to detect the max columns (X) of your terminal (for the
|
||||
game dimensions) - to be 55; it might look like this instead:</p>
|
||||
|
||||
<pre><code> X:27/54 Y:20/41 S:5/997 B:0
|
||||
</code></pre>
|
||||
|
||||
<p>But problems can arise with messing with dimensions: in my tests this held only
|
||||
to lines.</p>
|
||||
|
||||
<h2><a name="insanity" href="#toc">Terminal insanity</a></h2>
|
||||
|
||||
<p>Terminal sanity can be compromised and it can cause all sorts of output
|
||||
problems; it might not appear right away but it will show its ugly head
|
||||
eventually if you use it. For example pager output might be screwy, echo might
|
||||
be turned off, output of commands might overwrite the input of those commands,
|
||||
etc. For the game you might not see the final score.</p>
|
||||
|
||||
<h3><a name="restore" href="#toc">Restoring the terminal</a></h3>
|
||||
|
||||
<p>In my tests there is one thing that at least allows you to see the final score
|
||||
and that is by running <code>clear</code> before running the program. That’s what the
|
||||
prog.alt version does. You might run it as one of:</p>
|
||||
|
||||
<pre><code> LINES=20 ./prog.alt
|
||||
LINES=20 ./snake.alt
|
||||
</code></pre>
|
||||
|
||||
<p>Even if the final score is visible though the terminal may very well still be
|
||||
messed up. There are numerous things you might try but probably the easiest is
|
||||
to run the game again without modifying the dimensions (and then just quit) or
|
||||
even just the <code>reset</code> command.</p>
|
||||
|
||||
<p>The Linux man page says:</p>
|
||||
|
||||
<pre><code>You might have to run the `reset` tool like:
|
||||
|
||||
<LF>reset<LF>
|
||||
|
||||
(the line-feed character is normally control-J) to get the terminal
|
||||
to work, as carriage-return may no longer work in the abnormal state.
|
||||
</code></pre>
|
||||
|
||||
<p>If you don’t have the reset utility you can try:</p>
|
||||
|
||||
<pre><code> echo -e \\033c
|
||||
</code></pre>
|
||||
|
||||
<p>Otherwise try <code>clear; stty sane</code> (that will turn on echo also) or if all else
|
||||
fails log out and back in.</p>
|
||||
|
||||
<p>For more information on this subject generally see the <a href="https://www.tldp.org/HOWTO/Keyboard-and-Console-HOWTO.html">Linux keyboard and
|
||||
console HOWTO</a> (specifically <a href="https://www.tldp.org/HOWTO/Keyboard-and-Console-HOWTO-4.html">Linux keyboard and console HOWTO section 4</a>).
|
||||
Yes this works under macOS (at least it did for me).</p>
|
||||
|
||||
<h3><a name="abuse" href="#toc">Terminal size abuse</a></h3>
|
||||
|
||||
<p>So players 1, 2 and 3 are content with not meddling with the terminal sizes
|
||||
outside what’s actually possible with their screen. But then player 4 comes
|
||||
along and thinks he/she will be clever and mess with the dimensions a bit. Let’s
|
||||
say they have a 13" monitor and they think it’d be funny to see how 997 lines
|
||||
would work; they might try something like:</p>
|
||||
|
||||
<pre><code> LINES=997 ./prog
|
||||
</code></pre>
|
||||
|
||||
<p>What then? Well expect trouble; curses will not know any better and the max
|
||||
number of lines will be 997. If they were to do:</p>
|
||||
|
||||
<pre><code> COLUMNS=997 ./prog
|
||||
</code></pre>
|
||||
|
||||
<p>Then they will see a different effect. Again the same reason: the player trying
|
||||
to be funny.</p>
|
||||
|
||||
<p>The game will try and be funny in return and you can expect it to not function
|
||||
properly. Because that’s what funny means in this context.</p>
|
||||
|
||||
<h1><a name="termlimitations" href="#toc">Terminal limitations</a></h1>
|
||||
|
||||
<p>It’d be nice if curses could detect hitting more than one arrow key at the
|
||||
same time so that diagonal directions would be possible but unfortunately it’s
|
||||
not (<code>cat -v</code> confirms this). Even if I were to define four extra keys what
|
||||
would they be? And what about the head character? The HACKING file has
|
||||
information on this.</p>
|
||||
|
||||
<p>I also limit the terminal size to 10 lines/columns but most likely it would
|
||||
require the cheat modes to win and in any event allowing certain low values
|
||||
causes problems e.g. <strong>LINES=6 COLUMNS=6</strong> and <strong>LINES=3 COLUMNS=3</strong> caused some
|
||||
nasty issues.</p>
|
||||
|
||||
<h1><a name="colours" href="#toc">Terminal colours</a></h1>
|
||||
|
||||
<p>N.B.: If all you’re after is wanting to change the colours see the script
|
||||
<a href="snake-colours.sh">snake-colours.sh</a> instead. The rest of this file was mostly notes for the
|
||||
judges; here I discuss the background, foreground as well as limitations (in
|
||||
particular runtime limitations).</p>
|
||||
|
||||
<h2><a name="background" href="#toc">Curses background</a></h2>
|
||||
|
||||
<p>The documentation I have seen says that the background will always be black and
|
||||
from a quick test this holds even with a terminal that has a white background.
|
||||
There is a way to force the background to remain white though that’s by way of
|
||||
monochrome (so no colours); I discuss that and another related terminal specific
|
||||
in the troubleshooting guide (there’s another way but it would take me over the
|
||||
iocccsize; I talk about it in the HACKING file).</p>
|
||||
|
||||
<h2><a name="monochrome" href="#toc">Monochrome terminals</a></h2>
|
||||
|
||||
<p>According to my tests for monochrome terminals the screen has the white and
|
||||
black background; if terminal is configured to be black background white
|
||||
foreground that is the order it is too. You can try that like:</p>
|
||||
|
||||
<pre><code> TERM=linux-m ./prog
|
||||
</code></pre>
|
||||
|
||||
<p>But I do not specifically check if the terminal has colours. Is there a curses
|
||||
implementation that has a problem here? Below I explain what to comment out
|
||||
should you need colours to be disabled but I personally have not run into any
|
||||
problems even with monochrome terminals. Later I say what to do to remove colour
|
||||
support in the source code itself.</p>
|
||||
|
||||
<h2><a name="colourlimitations" href="#toc">Colour limitations</a></h2>
|
||||
|
||||
<p>According to X/Open Curses, Issue 7 (pg. 57):</p>
|
||||
|
||||
<pre><code>With init_pair() and pair_content(), the value of pair must be in a range
|
||||
from 0 to and including COLOR_PAIRS-1. (There may be an
|
||||
implementation-specific upper limit on the valid value of pair, but any such
|
||||
limit is at least 63.) Valid values for f and b are the range from 0 to and
|
||||
including COLORS-1.
|
||||
</code></pre>
|
||||
|
||||
<p>The manpage for <code>init_pair()</code> says this:</p>
|
||||
|
||||
<pre><code> These limits apply to color values and color pairs. Values outside these limits are not legal, and may result in a runtime error:
|
||||
|
||||
[...]
|
||||
|
||||
COLOR_PAIRS corresponds to the terminal database's max_pairs capability, (see terminfo(5)).
|
||||
</code></pre>
|
||||
|
||||
<p>Based on the two as well as the fact that monochrome terminals (I’ve tried under
|
||||
both Linux and macOS) seem to work fine I believe I am fine here too. And to
|
||||
confirm this I wrote the following code with the output below:</p>
|
||||
|
||||
<pre><code> #include <curses.h>
|
||||
|
||||
int main()
|
||||
{
|
||||
initscr();
|
||||
start_color();
|
||||
printw("COLORS: %d\nCOLOR_PAIRS: %d\n", COLORS, COLOR_PAIRS);
|
||||
getch();
|
||||
endwin();
|
||||
}
|
||||
|
||||
TERM=linux-m ./colour_pairs
|
||||
COLORS: 0
|
||||
COLOR_PAIRS: 0
|
||||
</code></pre>
|
||||
|
||||
<p>Without specifying the TERM I get:</p>
|
||||
|
||||
<pre><code> COLORS: 256
|
||||
COLOR_PAIRS: 32767
|
||||
</code></pre>
|
||||
|
||||
<p>In the case that colour is supported the standard states that there will be more
|
||||
possible colour pairs than I have used so that’s not a problem either. Perhaps
|
||||
even it would only be a runtime error if the colours are supported and the
|
||||
number is out of the range? To try and figure this out I did another test:</p>
|
||||
|
||||
<pre><code> int main()
|
||||
{
|
||||
initscr();
|
||||
start_color();
|
||||
|
||||
init_pair(COLOR_PAIRS+1, COLOR_WHITE, COLOR_GREEN);
|
||||
bkgd(COLOR_PAIR(COLOR_PAIRS+1));
|
||||
init_pair(1, COLOR_WHITE, COLOR_BLACK);
|
||||
attron(COLOR_PAIR(1));
|
||||
printw("COLORS: %d\nCOLOR_PAIRS: %d\n", COLORS, COLOR_PAIRS);
|
||||
|
||||
getch();
|
||||
endwin();
|
||||
}
|
||||
</code></pre>
|
||||
|
||||
<p>Running it like</p>
|
||||
|
||||
<pre><code> TERM=linux-m ./colour_pairs
|
||||
</code></pre>
|
||||
|
||||
<p>I got the output as if colours weren’t used: 0 and 0. With coloured terminals
|
||||
however it was not visible. If I however comment out the call to <code>bkgd()</code> I get
|
||||
instead:</p>
|
||||
|
||||
<pre><code> COLORS: 256
|
||||
COLOR_PAIRS: 32767
|
||||
</code></pre>
|
||||
|
||||
<p>Which leads me to believe that if you try using a value outside the range it
|
||||
won’t work for a colour-capable terminal but it doesn’t matter for monochrome
|
||||
terminals one way or another. And since I don’t go beyond the ranges (as I cited
|
||||
earlier) there shouldn’t be any problem here.</p>
|
||||
|
||||
<h2><a name="disablecolour" href="#toc">Disabling colour</a></h2>
|
||||
|
||||
<p>Nevertheless if it is a problem and you don’t want to use a monochrome terminal
|
||||
(or can’t):</p>
|
||||
|
||||
<p>First comment out the code that has <code>start_color();</code> and then add <code>return;</code> to the
|
||||
top of the <code>C()</code> function (the rest of the code won’t be reached). If necessary
|
||||
you can also comment out the <code>init_pair()</code> calls.</p>
|
||||
|
||||
<p>Perhaps you only need to add the <code>return;</code> to <code>C()</code>. My guess is that’s the case
|
||||
but I do not know for certain.</p>
|
||||
<BR>
|
||||
<HR>
|
||||
<TABLE><TR>
|
||||
<TD><a rel="license" href="https://creativecommons.org/licenses/by-sa/3.0/"><img alt="Creative Commons License" style="border-width:0" src="/png/by-sa-3.0-88x31.png" /></a></TD>
|
||||
<TD><P>© Copyright 1984-2020,
|
||||
<A HREF="/judges.html">Leo Broukhis, Simon Cooper, Landon Curt Noll</A>
|
||||
- All rights reserved<BR>
|
||||
This work is licensed under a <a rel="license" href="https://creativecommons.org/licenses/by-sa/3.0/">Creative Commons Attribution-ShareAlike 3.0 Unported License</a>.</P></TD>
|
||||
<TD> <!--<a href="https://validator.w3.org/check?uri=referer"><img src="https://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01 Transitional" height="31" width="88"></a>--></TD>
|
||||
</TR></TABLE>
|
||||
</body>
|
||||
</html>
|
||||
Reference in new issue
Block a user