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,474 @@
|
||||
<!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>Troubleshooting Snake</h1>
|
||||
|
||||
<p>In this file I have a list of a number of possible problems that could show up
|
||||
under some situations as well as some things that might appear to be happening
|
||||
or be a problem but actually are not. For each one I have included a summary, a
|
||||
more thorough description and any resolutions (from easiest to hardest). For
|
||||
anything that can cause more than one issue I will list those separately to keep
|
||||
it as structured as possible/easiest to find.</p>
|
||||
|
||||
<p><a name="toc"></a>
|
||||
- <a href="#topwall">The top wall isn’t (all/some of the time) visible!</a>
|
||||
- <a href="#notmoving">The snake isn’t moving!</a>
|
||||
- <a href="#invisiblehead">I can’t see the snake head (or other part of the snake)!</a>
|
||||
- <a href="#invisiblebug">I can’t see the bug!</a>
|
||||
- <a href="#froze">The game froze!</a>
|
||||
- <a href="#bigsnake">The game gets slower as the snake gets bigger!</a>
|
||||
- <a href="#headonly">I set SIZE=0 GROW=1, ate a bug but still only the head was visible! Why?</a>
|
||||
- <a href="#monochrome">I like black text on a white background but even with a white background terminal it ends up black!</a>
|
||||
- <a href="#toodark">The text is hard to see (not bright enough)!</a>
|
||||
- <a href="#movefaster">Can I move the snake faster temporarily without having to modify the wait time?</a>
|
||||
- <a href="#envvars">On environmental variables more generally and string to int conversions</a>
|
||||
- <a href="#errors">Errors and error reporting</a></p>
|
||||
|
||||
<h2><a name="topwall" href="#toc">The top wall isn’t (all/some of the time) visible!</a></h2>
|
||||
|
||||
<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">HACKING</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>
|
||||
|
||||
<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="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>
|
||||
|
||||
<p> Recompile and try again. That will then show only the number of bugs eaten. See
|
||||
the HACKING file for other data you can include (though there are some
|
||||
discrepancies here and there as you’ll see).</p></li>
|
||||
</ul>
|
||||
|
||||
|
||||
<h2><a name="notmoving" href="#toc">The snake isn’t moving!</a></h2>
|
||||
|
||||
<p>Unless the game is paused this should not be happening. It can appear sometimes
|
||||
that there isn’t movement and sometimes it might have to take a moment to
|
||||
‘unwind’ but as long as the head is moving then everything is fine.</p>
|
||||
|
||||
<p>The tail might not always be moving which could make it seem like the snake
|
||||
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
|
||||
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>
|
||||
|
||||
<p> If you want to see this in action try:</p>
|
||||
|
||||
<pre><code> SIZE=150 SHEDS=10 SHED=1 ./prog
|
||||
</code></pre>
|
||||
|
||||
<p> Once you start moving you’ll see that the tail stays still for a while and
|
||||
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.markdown">bugs.markdown</a> file.</p></li>
|
||||
</ul>
|
||||
|
||||
|
||||
<h2><a name="invisiblehead" href="#toc">I can’t see the snake head (or other part of the snake)!</a></h2>
|
||||
|
||||
<p>Possibly this could happen with too long a score line which I already discussed.
|
||||
It also used to be possible during cannibal mode whilst cannibalising: you would
|
||||
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
|
||||
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
|
||||
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>
|
||||
|
||||
|
||||
<h2><a name="invisiblebug" href="#toc">I can’t see the bug!</a></h2>
|
||||
|
||||
<p>This has happened to me a number of times and early in development there were
|
||||
times that I could swear I even saw it beyond the walls but this should not be a
|
||||
problem now if it ever was.</p>
|
||||
|
||||
<p>However I have made a lot of effort to think of situations that might make the
|
||||
bug location calculation and placement be a problem and even did some debug
|
||||
output and wrote another test program to calculate the maximum number of places
|
||||
the bug could be put etc.</p>
|
||||
|
||||
<p>One of the reasons I have the terminal dimensions have a minimum and also a
|
||||
maximum has to do with the way the bug placement and max size of the snake (and
|
||||
so arrays) are calculated: it could happen that because of it being unsigned
|
||||
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
|
||||
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
|
||||
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.
|
||||
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
|
||||
<a href="snake-colours">snake-colours</a> script to select a different colour scheme.</p></li>
|
||||
</ul>
|
||||
|
||||
|
||||
<h2><a name="froze" href="#toc">The game froze!</a></h2>
|
||||
|
||||
<p>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).</p>
|
||||
|
||||
<ul>
|
||||
<li><p>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.</p></li>
|
||||
<li><p>RESOLUTION #1: 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
|
||||
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.
|
||||
ctrl-c. Try increasing the screen size and/or decreasing the max size of the
|
||||
snake. See below for some tests.</p>
|
||||
|
||||
<p> I removed caps in a test and then:</p>
|
||||
|
||||
<pre><code> GROW=1 COLUMNS=30 LINES=10 CANNIBAL=1 MAXSIZE=10000 ./prog
|
||||
</code></pre>
|
||||
|
||||
<p> It froze at this point:</p>
|
||||
|
||||
<pre><code> X:14/29 Y:5/9 S:323/10000 B:318
|
||||
</code></pre>
|
||||
|
||||
<p> This is because there was only one place for the bug - where the snake head
|
||||
was to be. With these parameters the limit is actually 189! This could
|
||||
perhaps be increased but the calculation I have used is easy and although I
|
||||
certainly could make it so it’s one less than the max that takes more bytes
|
||||
and I don’t see it actually mattering.</p>
|
||||
|
||||
<p> Another time I tried:</p>
|
||||
|
||||
<pre><code> LINES=6 COLUMNS=6
|
||||
</code></pre>
|
||||
|
||||
<p> And it also froze (as noted I impose a minimum of >= 10 for both LINES and
|
||||
COLUMNS).</p>
|
||||
|
||||
<p> Ultimately I had to kill the program due to the game being stuck in the bug
|
||||
placement routine. I could have put in a maximum number of loops but what
|
||||
good would that do? It would use more bytes and what would it do anyway,
|
||||
win? Well that’s what the max size is for.</p></li>
|
||||
<li><p>TERMINAL SIZE TO MAX SNAKE SIZE CALCULATION ETC.</p>
|
||||
|
||||
<p> For this information and more use the termcaps utility:</p>
|
||||
|
||||
<pre><code> make test
|
||||
</code></pre>
|
||||
|
||||
<p> An example:</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> Why are there only 39 playable lines for 42 rows? The first row is the score
|
||||
line, the second is the top wall, the last is the bottom wall. For columns
|
||||
you have the left and rightmost columns for the walls.</p>
|
||||
|
||||
<p> The calculation for max size takes place after decrementing the max y/x;
|
||||
then it’s <code>(maxy - 2) * (maxx - 2)</code>; above that would be:</p>
|
||||
|
||||
<pre><code> (41 - 2) * (156 - 2) == 6006
|
||||
</code></pre>
|
||||
|
||||
<p> If for some reason the game were to stall for this purpose you would have to
|
||||
kill the game by e.g. ctrl-c since the bug placement is stuck in a loop.
|
||||
This shouldn’t happen though.</p></li>
|
||||
</ul>
|
||||
|
||||
|
||||
<h2><a name="bigsnake" href="#toc">The game gets slower as the snake gets bigger!</a></h2>
|
||||
|
||||
<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
|
||||
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
|
||||
bigger.</p></li>
|
||||
<li><p>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?
|
||||
Or is the system rather busy?</p></li>
|
||||
</ul>
|
||||
|
||||
|
||||
<h2><a name="headonly" href="#toc">I set <code>SIZE=0 GROW=1</code>, ate a bug but still only the head was visible! Why?</a></h2>
|
||||
|
||||
<ul>
|
||||
<li><p>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:</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
|
||||
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>
|
||||
</ul>
|
||||
|
||||
|
||||
<h2><a name="monochrome" href="#toc">I like black text on a white background but even with a white background terminal it ends up black!</a></h2>
|
||||
|
||||
<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
|
||||
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
|
||||
recall having to install it under macOS nor Fedora but those systems have GUIs
|
||||
so that’s probably why; in CentOS I did have to install it specially.</p>
|
||||
|
||||
<p> The <code>-m</code> suffix to terminal names means monochrome. Under Linux this
|
||||
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>.</p></li>
|
||||
<li><p>BOTTOM LINE: 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
|
||||
no colour but unfortunately changing the background colour of curses would
|
||||
eat too many bytes in the entry (I cite the functions in the HACKING file).</p>
|
||||
|
||||
<p> I discuss colours and terminals in much more detail in
|
||||
<a href="terminals.markdown">terminals.markdown</a> (<a href="terminals.html">terminals.html</a>).</p></li>
|
||||
</ul>
|
||||
|
||||
|
||||
<h2><a name="toodark" href="#toc">The text is hard to see (not bright enough)!</a></h2>
|
||||
|
||||
<ul>
|
||||
<li><p>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.</p>
|
||||
|
||||
<p> If it’s already set at brighter colours I do not know what to say. Try
|
||||
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>
|
||||
</ul>
|
||||
|
||||
|
||||
<h2><a name="movefaster" href="#toc">Can I move the snake faster temporarily without having to modify the wait time?</a></h2>
|
||||
|
||||
<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
|
||||
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
|
||||
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>
|
||||
</ul>
|
||||
|
||||
|
||||
<h2><a name="envvars" href="#toc">On environmental variables more generally and string to int conversions</a></h2>
|
||||
|
||||
<p>What happens if you do:</p>
|
||||
|
||||
<pre><code> WALLS= ./prog
|
||||
</code></pre>
|
||||
|
||||
<p>Can you run into the wall since you didn’t specify a value and the default is 1?
|
||||
No. That’s not the way it works. By saying WALLS= you have told the system that
|
||||
there is that environmental variable. However the way the <code>strtoul()</code> functions
|
||||
work is that if there’s no valid input it returns 0. This can be detected but
|
||||
it’s wasteful (iocccsize wise) and I have never felt that having invalid input
|
||||
for a number could have a better value than 0.</p>
|
||||
|
||||
<p>If however you were to give valid input followed by invalid input the valid
|
||||
input would be parsed. For example:</p>
|
||||
|
||||
<pre><code> WALLS=1test ./prog
|
||||
</code></pre>
|
||||
|
||||
<p>Would let you go through the walls. On the other hand</p>
|
||||
|
||||
<pre><code> WALLS=test1 ./prog
|
||||
</code></pre>
|
||||
|
||||
<p>Would not. Furthermore if you specify the same variable more than once it’s the
|
||||
last one that counts. For example:</p>
|
||||
|
||||
<pre><code> WALLS=0 WALLS=1 CANNIBAL=1 CANNIBAL=0 ./prog
|
||||
</code></pre>
|
||||
|
||||
<p>Would allow you to go through walls but you could not cannibalise.</p>
|
||||
|
||||
<p>Also note that I specify base 0 which means that you can also have it in hex and
|
||||
octal. These are all the same:</p>
|
||||
|
||||
<pre><code> SIZE=0x3
|
||||
SIZE=3
|
||||
SIZE=03
|
||||
</code></pre>
|
||||
|
||||
<p>The way the functions work is if 0x (or 0X) it’s considered hex; if prefixed
|
||||
with a 0 it’s octal and otherwise it’s decimal. If you specify invalid data
|
||||
(even if only at the beginning of the string) the functions return 0. For
|
||||
example</p>
|
||||
|
||||
<pre><code> SIZE=0
|
||||
SIZE=f
|
||||
SIZE=-
|
||||
SIZE=f1
|
||||
</code></pre>
|
||||
|
||||
<p>Are all equivalent.</p>
|
||||
|
||||
<p>Observe that</p>
|
||||
|
||||
<pre><code> SIZE=08
|
||||
</code></pre>
|
||||
|
||||
<p>Is invalid input because octal only has digits 0 - 7: the resulting size will be
|
||||
0.</p>
|
||||
|
||||
<p>I discuss the signed/unsigned issue to do with curses and sizes in C being
|
||||
unsigned in <a href="bugs.markdown">bugs.markdown</a> but probably there isn’t anything more to say here.</p>
|
||||
|
||||
<h2><a name="errors" href="#toc">Errors and error reporting</a></h2>
|
||||
|
||||
<p>If curses fails to initialise you should get an error that says ‘curses error’
|
||||
and you have every right to curse it to hell if that’s what you so wish.
|
||||
Apparently curses will report an error itself if that function fails but that
|
||||
escaped my notice until later on so you might get two errors in that case.</p>
|
||||
|
||||
<p>Assuming it succeeds the game obtains the maximum y/x of the terminal. The
|
||||
screen size must be at least 10 lines/columns (though in code the number will
|
||||
not be 10); if either is smaller you will get ‘screen too small’ and the game
|
||||
will end (yes things that haven’t begun can be ended).</p>
|
||||
|
||||
<p>If calloc() fails to obtain the needed memory you’ll see something like (here it
|
||||
was before I added proper - to make the perfect and obvious pun - capsizing
|
||||
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>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
|
||||
the snake size will be >= that max anyway. But here’s a curious output:</p>
|
||||
|
||||
<pre><code> SIZE=1 MAXSIZE=0 ./prog
|
||||
YOU WIN!
|
||||
X:78/156 Y:20/41 S:0/0 B:0
|
||||
</code></pre>
|
||||
|
||||
<p>Why does it show snake size as 0 when I specified 1? It’s because the max size
|
||||
is 0 and I limit the size to be no bigger than the max size.</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