Landon Curt Noll
518a6336d0
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.
To build:
make
Bugs and (Mis)features:
The current status of this entry is:
STATUS: INABIAF - please **DO NOT** fix
For more detailed information see 2012 blakely bugs.
To use:
./blakely "RPN formula" resolution > output.gif
Try:
./try.sh
Judges' remarks:
Several IOCCC themes (RPN calculator, animated GIF generator, ray tracing) in one package! Very impressive!
The checkerboard pattern in the output can be broken. Could you figure out how?
Larger GIF files confuse some image viewers.
Author's remarks:
Remarks
This program renders a generic
RPN expression in
ray-traced animated
GIF form. The expression in spatial
variables x and y is specified on the command-line with the required
resolution, and an animated GIF showing a fly-around of the resulting surface is
output to stdout.
Usage
The program should be run as:
./blakely xy* 32 > pic.gif
where the first parameter is a RPN expression, and the second is the width of the required GIF, up to a maximum of 250.
The expressions are written in Reverse Polish Notation with the following characters recognised:
+, -, *, / - usual arithmetic operations
^ - Exponentiation; valid for constant exponent only
s - sin
c - cos
0-9 - single digit integers
d - duplicate number on stack
t - transpose top two elements on stack
x - x coordinate value
y - y coordinate value
NB: all arithmetic is done in double precision, so 23/ is two-thirds, rather
than 0.
The surface plotted corresponds to -1 <= x,y <= 1 and for best results, the
generated z value should lie between -1 and 1.
If there is a division by zero, square-root of a negative number, or similar operation, then the results are undefined.
Examples
For test-runs, use a resolution of 32. For simple expressions, the
GIF generation should take only
a few seconds with a modern processor and full optimization. Runtime scales as
O(N^3) with resolution N,
and more complex expressions take longer to compute. For example, increasing the
resolution of ripple.gif
to 250 took ~35 minutes to render on an i7
processor.
./blakely xy* 32 > saddle.gif
./blakely xx*yy*1++d5*ct/ 64 > ripple.gif
Algorithm
A generic root-finding algorithm to find the point of intersection between a ray
and the surface is done using a simple forward search from the eye. In order to
make the rendering realistic, both the value of the expression, and its
derivative with respect to x and y must be tracked. This is done using an
obvious stack-based approach.
Obfuscations
Much of the obfuscation is achieved through the use of single-letter variables
and #defines. The characters output for the GIF
format are generated in myriad
and wonderful ways, making use of
XOR, return values from
putchar(), and odd expressions. The layout is in the form of X Y Z.
Limitations
ASCII is assumed since many bytes for the
GIF output are generated from characters
given in the source code. On compilation a few warnings about parentheses come
up when using gcc 4.6.3, and one about no return value from main() (who uses
exit codes anyway?), but clang 3.1 emits no warnings.
Questions
- Apart from their appearance when computing the RPN expression, sin and cos are not used. How do we then get the correct angles for rotation?
- Exactly how many times will the animation repeat?
- Why is there an upper limit of 250x250 for the resolution?
- What is the point of
b[0]? - Where are the words
NETSCAPEandGIFhidden in the source?
(Note that the author may or may not be able to answer all of the above questions.)