add rules, guidelines, fix HTML code, move compressed tarball in inventory
By changing the _inventory_order_ of the compressed tarball from
**100000** to **1415926535**, the compressed tarball will land at
the top of the secondary file list and remain still easy to find.
Updated the `manifest.numbers` spreadsheet and rebuilt
the `.entry.json` files.
Added `next/` directory to hold the next IOCCC rules and guidelines.
Added `next/README.md` that `bin/gen-top-html.sh` uses to form
the `next/index.html` file.
Added _Rules and Guidelines_ link to the sidenav bar to link to the
`next/index.html` file.
Added _IOCCC Rules_ as `next/rules.md` that `bin/gen-top-html.sh`
uses to form the `next/rules.html` file.
Added _IOCCC Guidelines_ as `next/guidelines.md` that `bin/gen-top-html.sh`
uses to form the `next/guidelines.html` file.
Changed `bin/gen-top-html.sh` VERSION from "1.2.4 2024-04-13"
to "1.3 2024-04-14".
Prevent `pandoc(1)` from interpreting the commented out language
of a markdown code block as a code class. So a markdown such as:
````
``` <!---sh-->
...
```
````
that produced HTML of the form:
```html
<pre class="<!---sh-->"><code>...</code></pre>
```
will now produce HTML of the form:
```html
<pre><code>...</code></pre>
```
NOTE: Before when the language of a markdown code block
was not commented, the HTML produced by `pandoc(1)` was
oddly indented with extra whitespace on the first line
of the code block. While commenting out the language
of the code block removed some of the odd intending,
it left a weird class in the HTML pre block that
surrounded the HTML code block. This hack prevents
`pandoc(1)` from assigning a class to the HTML pre block.
Changed `in/md2html.sh` VERSION from "1.2.1 2024-04-13"
to "1.3 2024-04-14".
Added `make gen_sitemap` to end of both `make www` and `make
quick_www` in top level Makefile.
Ram `make www` to test under macOS and to perform the above.
**IMPORTANT NOTE**: The current `next/rules.md` and `next/guidelines.md`
are simply the 2020 IOCCC Rules and Guidelines converted into
markdown form. There are **NOT** the Rules and Guidelines that
will be used the IOCCC MOCK, nor the next IOCCC.
TODO: Improve the `bin/gen-status.sh` tool to modify the top of the
`next/rules.md` and `next/guidelines.md` files to keep them
in sync with the _contest_status_ as found in `status.json`.
TODO: Improve the look and feel of the `next/rules.md` and
`next/guidelines.md` markdown files.
This commit is contained in:
Landon Curt Noll committed
1 parent
a672335d2d
commit
518a6336d0
734 files changed
+7919
-4119
No files matched your search
+14
-13
@@ -83,6 +83,7 @@
|
||||
<div class="sidenav">
|
||||
<a href="../../news.html">IOCCC News</a>
|
||||
<a href="../../status.html">Contest status</a>
|
||||
<a href="../../next/index.html">Rules and Guidelines</a>
|
||||
<a href="../../faq.html#submit">How to enter the IOCCC</a>
|
||||
<a href="../../faq.html">FAQ</a>
|
||||
</div>
|
||||
@@ -192,12 +193,12 @@ defaults if you don’t want to change the colour.</p>
|
||||
initialise a pair (make it 5 so as to not interfere with the script
|
||||
customisability) and then you use the bkgd() function with the colour pair.
|
||||
Something like this:</p>
|
||||
<pre class="<!---c-->"><code> init_pair(5, COLOR_BLACK, COLOR_WHITE);
|
||||
<pre><code> init_pair(5, COLOR_BLACK, COLOR_WHITE);
|
||||
bkgd(COLOR_PAIR(5));</code></pre>
|
||||
<p>I played with this after winning and I came across some problems with colours
|
||||
but that changes the background of the program anyway.</p>
|
||||
<p>The standard colour identifiers are:</p>
|
||||
<pre class="<!---c-->"><code> COLOR_BLACK
|
||||
<pre><code> COLOR_BLACK
|
||||
COLOR_RED
|
||||
COLOR_GREEN
|
||||
COLOR_YELLOW
|
||||
@@ -220,16 +221,16 @@ source code (<strong>include the single quotes!</strong>) respectively:</p>
|
||||
<p>Let’s say you don’t want to use arrow keys or you don’t have arrow keys. Instead
|
||||
you might want the keys <code>l</code>, <code>r</code>, <code>u</code> and <code>d</code> for the directions. Find the case
|
||||
statements:</p>
|
||||
<pre class="<!---c-->"><code> case KEY_LEFT:
|
||||
<pre><code> case KEY_LEFT:
|
||||
case KEY_RIGHT:
|
||||
case KEY_UP:
|
||||
case KEY_DOWN:</code></pre>
|
||||
<p>Replace <code>KEY_LEFT</code> with:</p>
|
||||
<pre class="<!---c-->"><code> 'l'</code></pre>
|
||||
<pre><code> 'l'</code></pre>
|
||||
<p>and do the same thing for the other directions too. If you want more than one
|
||||
key e.g. the arrow keys and the letters just add another case statement e.g. for
|
||||
left it might be:</p>
|
||||
<pre class="<!---c-->"><code> case KEY_LEFT: case 'l':</code></pre>
|
||||
<pre><code> case KEY_LEFT: case 'l':</code></pre>
|
||||
<p>Yes the single quotes matter. You can do similar for the other input keys.
|
||||
Please note that modifier keys like ctrl aren’t detectable or at least I’m
|
||||
unaware of how to do so.</p>
|
||||
@@ -245,9 +246,9 @@ end of the game; I leave that as an exercise to the reader to implement two
|
||||
different sets. Please also be aware that if you don’t want any information you
|
||||
must set it to the below at the very least; defining it without a value is not
|
||||
enough (it amounts to the parameters to a printf call):</p>
|
||||
<pre class="<!---c-->"><code> #define J " " );</code></pre>
|
||||
<pre><code> #define J " " );</code></pre>
|
||||
<p>If you don’t care about brief displays of ‘o’ at 0,0 you can just have:</p>
|
||||
<pre class="<!---c-->"><code> #define J "");</code></pre>
|
||||
<pre><code> #define J "");</code></pre>
|
||||
<p>That’s the bare minimum. Notice also that it’s been a long while since I’ve
|
||||
tested this part but I think this is right.</p>
|
||||
<p>Anyway as I said the score line has basic statistics that’s relatively easy to
|
||||
@@ -262,7 +263,7 @@ bug. This however was something I didn’t quite like: I like having the
|
||||
coordinates of where the snake is plus the other things that are there (a number
|
||||
of which were added over time). Obviously this would take many bug sized bytes
|
||||
(bites) even once let alone twice! Thus I made it into a define:</p>
|
||||
<pre class="<!---c-->"><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>
|
||||
<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>With the table below you can show a variety of other variables/statistics.</p>
|
||||
<p>There’s another reason for changing this line though: depending on the terminal
|
||||
width the line could cover the top wall; this can even happen only part of the
|
||||
@@ -280,7 +281,7 @@ so if this line wasn’t there it would require changes to make it work right.</
|
||||
<p>For an example this would only include the size of the snake and the number of
|
||||
bugs eaten (I think I have this correct; I’ve made many changes to the point of
|
||||
not wanting to mess with anything that’s unnecessary):</p>
|
||||
<pre class="<!---c-->"><code> #define J Z(SIZE: %zu BUGS: %zu\n), A, c);</code></pre>
|
||||
<pre><code> #define J Z(SIZE: %zu BUGS: %zu\n), A, c);</code></pre>
|
||||
<p>More generally the following expressions and data types (with format specifiers)
|
||||
come to mind as information that might be of interest.</p>
|
||||
<pre><code> DESCRIPTION EXPRESSION TYPE FORMAT SPECIFIER
|
||||
@@ -307,9 +308,9 @@ come to mind as information that might be of interest.</p>
|
||||
bug)</code></pre>
|
||||
<h2 id="make-it-so-the-snake-starts-at-a-random-location">Make it so the snake starts at a random location</h2>
|
||||
<p>Quite simply change:</p>
|
||||
<pre class="<!---c-->"><code> X = H / 2; Y = *x / 2;</code></pre>
|
||||
<pre><code> X = H / 2; Y = *x / 2;</code></pre>
|
||||
<p>To be something like:</p>
|
||||
<pre class="<!---c-->"><code> X = R(1,H-1);
|
||||
<pre><code> X = R(1,H-1);
|
||||
Y = R(2,*x-1);</code></pre>
|
||||
<p>Or whatever you might want it to be… (question to answer: will this work at
|
||||
all? You decide!)</p>
|
||||
@@ -407,7 +408,7 @@ their ruddy phone instead of where they’re walking (even when crossing a busy
|
||||
street!).</p>
|
||||
<p>If you look at the walls code you will see a ternary operator for both <code>X</code> and <code>Y</code>
|
||||
coordinates. This of course is very different now but the idea remains the same:</p>
|
||||
<pre class="<!---c-->"><code> if (p && !(*O>=O[1]||H>=M(1)))
|
||||
<pre><code> if (p && !(*O>=O[1]||H>=M(1)))
|
||||
{
|
||||
if (X<1||X>=H)
|
||||
X = X<1?H-1:1;
|
||||
@@ -420,7 +421,7 @@ the walls (off screen). Depending on where the snake is it will set the
|
||||
coordinates to the correct new location.</p>
|
||||
<p>If however you wanted the walls to act as a barrier you could do something like
|
||||
this instead (omitting the inner if statements here):</p>
|
||||
<pre class="<!---c-->"><code> X=X<1?1:*H-1;
|
||||
<pre><code> X=X<1?1:*H-1;
|
||||
|
||||
Y=Y<2?2:*O-1;</code></pre>
|
||||
<p>Again though that’s just the idea; the code is dramatically different. The above
|
||||
|
||||
Reference in new issue
Block a user