mirror/ioccc
1
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Add preview of 1984-2019

Browse Source 
The 2020 winners are hinted it, but the source code is not there,
nor are the hints. Someone could look into the HTML and
see what was commented out, but that is not a problem because
WHO won is known and the name of their AWARD is known already.
Moreover a number of the winners have talked about what their
entirs do, so the commented out spoiler text is not a bit problem.

One will find HTML commented out with:

    <!-- XXX remove when 2020 is ready
    2020 links here
    XXX remove when 2020 is ready -->

The "XXX remove when 2020 is ready" string is found at the
start and end comment blocks.  Again, soneone could read
what was commented out, but that is OK since most of that
information is known or can be known.  The following files
have such HTML comment blocks in them.

    ./winners.html
    ./years-spoiler.html
    ./years.html

In addition, ./all/summary.txt was modified to not
include the 2020 entries for the momemt.

The 2020 winner code AND write-ups are NOT part of this set.

p.s. The all/all.tar.bz2 does not contain the 2020 source code (yet?).
This commit is contained in:
Landon Curt Noll committed 2020-12-30 16:57:03 -08:00
1 parent 28efc67f5d
commit c0663537cb
1683 files changed
+220064
Download Patch File Download Diff File Expand all files Collapse all files

No files matched your search

2015/dogon/Makefile
+262
View File
@@ -0,0 +1,262 @@
#!/usr/bin/env make
#
# 2015 makefile
#
# This work by Landon Curt Noll, Simon Cooper, and Leonid A. Broukhis
# is licensed under:
#
# Creative Commons Attribution-ShareAlike 3.0 Unported License.
#
# See: http://creativecommons.org/licenses/by-sa/3.0/
################
# tool locations
################
#
SHELL= /bin/bash
CP= cp
CPP= cpp
GUNZIP= gunzip
BUNZIP2= bunzip2
LD= ld
MAKE= make
RM= rm
SED= sed
TAR= tar
TRUE= true
MKDIR= mkdir
MV= mv
TR= tr
GREP= grep
SORT= sort
UNIQ= uniq
# Set X11_LIBDIR to the directory where the X11 library resides
#
#X11_LIBDIR= /usr/X11R6/lib
#X11_LIBDIR= /usr/X11/lib
X11_LIBDIR= /opt/X11/lib
# Set X11_INCLUDEDIR to the directory where the X11 include files reside
#
#X11_INCDIR= /usr/X11R6/include
#X11_INCDIR= /usr/X11/include
X11_INCDIR= /opt/X11/include
# Compiler warnings
#
#CWARN=
#CWARN= -Wall
#CWARN= -Wall -Wextra
CWARN= -Wall -Wextra -pedantic ${CSILENCE}
#CWARN= -Wall -Wextra -Weverything
#CWARN= -Wall -Wextra -Weverything -pedantic
#CWARN= -Wall -Wextra -Weverything -pedantic ${CSILENCE}
# Silence warnings that ${CWARN} would normally complain about
#
#CSILENCE=
CSILENCE= -Wno-implicit-int -Wno-variadic-macros -Wno-absolute-value \
-Wno-bitwise-op-parentheses -Wno-char-subscripts -Wno-dangling-else \
-Wno-implicit-function-declaration -Wno-parentheses \
-Wno-shift-op-parentheses -Wno-unsequenced -Wno-conversion \
-Wno-float-conversion -Wno-missing-variable-declarations \
-Wno-reserved-id-macro -Wno-shadow -Wno-shorten-64-to-32 \
-Wno-sign-conversion
# compiler standard
#
#CSTD=
#CSTD= -ansi
CSTD= -std=c11
# compiler bit architecture
#
# Some entries require 32-bitness:
# ARCH= -m32
#
# Some entries require 64-bitess:
# ARCH= -m64
#
# By default we assume nothing:
#
ARCH=
# defines that are needed to compile
#
#CDEFINE=
CDEFINE= -DW=1024 -Dp=800
# include files that are needed to compile
#
#CINCLUDE=
CINCLUDE= -I ${X11_INCDIR} -include stdlib.h
# optimization
#
# Most compiles will safely use -O2. Some can use only -O1 or -O.
# A few compilers have broken optimizers or this entry make break
# under those buggy optimizers and thus you may not want anything.
# Reasonable compilers will allow for -O3.
#
#OPT=
#OPT= -O
#OPT= -O1
#OPT= -O2
OPT= -O3
# default flags for ANSI C compilation
#
CFLAGS= ${CWARN} ${CSTD} ${ARCH} ${CDEFINE} ${CINCLUDE} ${OPT}
# Libraries needed to build
#
#LIBS=
LIBS= -L ${X11_LIBDIR} -lm -lX11
# ANSI compiler
#
# Set CC to the name of your ANSI compiler.
#
# Some entries seem to need gcc. If you have gcc, set
# both CC and MAY_NEED_GCC to gcc.
#
# If you do not have gcc, set CC to the name of your ANSI compiler, and
# set MAY_NEED_GCC to either ${CC} (and hope for the best) or to just :
# to disable such programs.
#
CC= cc
#CC=clang
MAY_NEED_GCC= gcc
##############################
# Special flags for this entry
##############################
#
ENTRY= prog
CSRC= ${ENTRY}.c
OBJ= ${ENTRY}.o
DATA=
ALT_OBJ=
ALT_ENTRY=
TARGET= ${ENTRY}
#################
# build the entry
#################
#
all: ${TARGET} ${DATA}
@${TRUE}
${ENTRY}: ${CSRC}
${CC} ${CFLAGS} $< -o $@ ${LIBS}
# alternative executable
#
alt: ${ALT_ENTRY}
@${TRUE}
# data files
#
data: ${DATA}
@${TRUE}
###############
# utility rules
###############
#
everything: all alt
clean:
${RM} -f ${OBJ} ${ALT_OBJ}
clobber: clean
${RM} -f ${TARGET} ${ALT_ENTRY}
nuke: clobber
@${TRUE}
dist_clean: nuke
@${TRUE}
install:
@echo "Surely we are joking Dr. May!"
@${TRUE}
# backwards compatibility
#
build: all
@${TRUE}
##################
# 133t hacker rulz
##################
#
love:
@echo 'not war?'
@${TRUE}
haste:
$(MAKE) waste
@${TRUE}
waste:
@echo 'haste'
@${TRUE}
make:
@echo 'Attend a maker faire'
@${TRUE}
easter_egg:
@echo you expected to sometimes mis-understand this $${RANDOM} magic
@echo chongo '<was here>' "/\\oo/\\"
@echo Readers shall not be disallowed from not failing to be unable to not partly misunderstand this partocular final echo.
# Understand the history of the Homebrew Computer Club
# as well as the West Coast Computer Faire and
# you might be confused different. :-)
#
supernova: nuke
@-if [ -r .code_anal ]; then \
${RM} -f .code_anal_v5; \
else \
echo "planet deniers, like the IAU, are amusing"; \
fi
@echo A $@ helps ${MAKE} the elements that help form planets
@${TRUE}
deep_magic:
@-if [ -r .code_anal ]; then \
ccode_analysis --deep_magic 2ed3582ec5c094a093fea2a6bcb9f19439892873c9cc45ed1ceaafe08b7d52e1b2c7cd524be3b0b2 --FNV1a_hash_512_bit "${ENTRY}"; \
else \
echo "You are holding it wrong!"; \
fi
@${TRUE}
magic: deep_magic
@-if [ -r .code_anal ]; then \
ccode_analysis --mode 216091 --level 216193 --FNV1a_hash_512_bit "${ENTRY}"; \
else \
echo "These aren't the primes you're looking for Pauline!"; \
fi
@${TRUE}
# The IOCCC resident astronomer states
#
charon: supernova
@echo $@ is a dwarf planet
@echo dwarf is a type of planet
@echo $@ is a planet
pluto: supernova
${MAKE} charon
@echo $@ is a dwarf planet
@echo dwarf is a type of planet
@echo $@ is a planet
@echo get used to having lots of planets because a $< can ${MAKE} a lot of them
2015/dogon/hint.html
+144
View File
@@ -0,0 +1,144 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta name="GENERATOR" content="mkd2html 2.1.5a DL=DISCOUNT">
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=utf-8">
<link rel="stylesheet"
type="text/css"
href="../hint.css">
<title>Most Crafty</title>
</head>
<body>
<h1>Most Crafty</h1>
<p>Gil Dogon<br>
<a href="http://sokoban-gild.com">http://sokoban-gild.com</a></p>
<h2>Judges' comments:</h2>
<h3>To use:</h3>
<pre><code>make
./prog
</code></pre>
<h3>Try:</h3>
<pre><code>./prog
press and hold the Left Arrow key until you turn 90-degrees to the left
when you see a long tunnel, press the function key F2
Use the Up, Down, Left and Right keys to change your path
Press function higher numbered function keys (F3, F4, ...) to go faster
Press F1 to stop
Turn 90-degrees to one side
Press F4 to and drill into some blocks for a bit
Press F1 to stop
Turn 180-degrees to face the way you came
Press F2 and navigate back down the new hole until you reach the long tunnel again
Press F1 to stop
etc.
Press the ESC key
</code></pre>
<h3>Selected Judges Remarks:</h3>
<p>You are in a twisty maze blocks, almost all alike.</p>
<p>Those blocks are generated by twisty maze of code blocks, almost all different.</p>
<p>Can you find your way around either and understand where you are?</p>
<p>How many function keys does your keyboard have? Can you generate very high number function keys such as F30 or F31? :-)</p>
<p><em>Textures? We don&rsquo;t need no stinking textures.</em></p>
<h2>Author&rsquo;s comments:</h2>
<h3>What is it?</h3>
<p>Just run prog with no arguments on an X11-compatible system. The scenery, though pseudo-randomly generated should be strangely familiar, specially to those still in their teen age. You can navigate using the keyboard arrow keys and the function keys. Your speed is a linear function of (n-1) where Fn is the last function key you have pressed, and you always move in the direction you are looking at. Be aware that you are probably some kind of a Creeper as is obvious from looking at the program, hence your movement is destructive to the environment. So after pressing F12 for warp speed, and moving around randomly, you might find yourself in a 3D maze of twisty little passages, from which there is only one Esc(ape) key. Note that in theory if you have a specialty keyboard with 32 function keys you may even press F31 to reach infinite improbability drive speed, though the author had never tested this feature. However a hidden comment in keysymdef.h suggests the existence of a mythical Sun Keyboard with 35 function keys :)</p>
<h3>Full disclosure.</h3>
<p>This entry, tough pretty thoroughly obfuscated, is not entirely original, nor am I Notch. The inspiration for this entry is a demo code written by the Notch himself, which was released with the following license: &ldquo;you may use the code in here for any purpose in any way you want, at your own risk&rdquo;. That version will henceforth be referred to as the original. Though the original in itself was quite nice and rather dense piece of code, it was not written in C, nor entirely and meticulously obfuscated, a state of things I hopefully rectified.</p>
<h3>Some extra features.</h3>
<p>Basing it on the original which already had a wonderful simple and concise ray casting through a generated voxel world rendering, I added a few tweaks of my own device:</p>
<ul>
<li>Two pass optimized rendering. The program first calculates 1/16 of the output image by ray casting, and then, when possible uses texture interpolation on the voxel faces. It speeds up the rendering by at least a factor of 4 on most scenes, but extra care must be taken when passing rays through the leaves voxels &hellip;</li>
<li>Fixed a small omission in the original. When you looked though a transparent leaves voxel, you did not see the leaves at voxel faces that were far from you. In this version the rendering of those (far face leaves) is correct.</li>
<li>Window rendering size specified in Makefile.</li>
<li>Added the keyboard controls for navigation (and destruction).</li>
</ul>
<h3>Portability issues.</h3>
<p>This entry is rather portable I think on modern platforms. It assumes of course basic X-windows availability. There are several other salient assumptions though:</p>
<ul>
<li>The entry assumes sizeof(int)=4. This seems to cover pretty much everything that supports X-windows so would be broken only on quite ancient machines, embedded processors, or some big iron 64 bit system where sizeof(int)=8.</li>
<li>The entry assumes the default visual has 24 bit depth (RGB). This seems to be the case on most X Servers this days.</li>
<li><p>The entry, does a thing which is an absolute No-No for X-windows program, i.e. assuming it knows some numeric values for keysyms defined in keysymdef.h . I have searched far and wide the lord Google&rsquo;s domain, yet was unable to find a version of the file where those assumptions were broken. This enables the important support of up to 32 function keys keyboards without spilling over the size limit, and allows us to use such fun expression for arrow view control as the following:</p>
<pre><code> *(a&amp;1?&amp;C:&amp;B)-=(.05 -a/2%2*.1)*!(a-1&amp;4092^3920)
</code></pre></li>
</ul>
<h3>Precision issues.</h3>
<p>The entry, on purpose, (see the section about SIMD below) does not use enough bits of precision, so some times the ray will miss the intersection of two voxel faces and push on through. That&rsquo;s why you may notice some noise along close up voxel edges. Fixing this issue would have taken the entry over the size limit regrettably.</p>
<h3>Obfuscations.</h3>
<p>Well, of course you have all the usual suspects, used for extreme compression, and such a nice layout: not very informative identifiers, which are being reused all over the place, some rather gruesome looking expressions, a whole load of magic constants with apparently no rhyme nor reason (including a Lagrange polynomial), and a message from our friendly Cetaceans. However it also includes some clever and not so obvious though instructive techniques, to subtly make the code more magical and efficient, at the same time.</p>
<p>Those techniques are about the use of 64 bit integers in order to do SIMD work, in a portable way without ever using any SSE/AVX or other non-portable compiler inline functions! The irony though, is that when compiling the program on modern X86 architectures indeed SSE/AVX is used for the long longs.
Following is some &ldquo;Spoiler&rdquo; information, So if you want to play tough, stop reading at this point.</p>
<h3>Portable SIMD programming.</h3>
<p>So how is this done? Quite simply by using the whole long long arithmetic&rsquo;s capability. I think the C99 standard assures us that long long has at least 64 bits. Most of those bits are unused in normal programs, however here we use them more wisely. For example, in the inner loop of the program you have the innocent looking expression i+=d. What it does in fact, is a SIMD addition of two vectors, each with three signed fixed point coordinates, advancing our ray in 3D space!
To spell it out, the macro producing such vectors is P, and the assignment q=0x820008202625a0 sets our creeper original position to about (32.5, 32.5019, 2441.406) .</p>
<p>Evidently when doing such arithmetics, care must me taken to avoid overflow from one component to the other, but since our voxel world is a torus of size 64 in each dimension this hardly matters. A subtle issue, is how to deal with signed quantities. In the i+=d expression above i has 3 positive components, but d has arbitrary signed components, as our ray may face in any direction. It seems things should not work, specially as we defined both i and d as unsigned! However notice that the T (and P )macro converts float to signed long longs. Once sign is extended from a least component into higher bits, it seems at first to be recipe for disaster, however everything works beautifully, and you get precise component results when the final accumulation components in i are positive. This only gets broken a bit when the final accumulation has a least significant negative component. To see this bug in action change the assignment above to q=0x82000820000000, and look towards the negative direction of the main tunnel.</p>
<p>Similar technique is used on the RGB components so their brightness can be adjusted simultaneously by the expression: o=o*b>>8 . Of course some spare bits are needed between the components, so they are spread in the long long and reordered as RBG.</p>
<hr />
<!--
(c) Copyright 1984-2016, [Leo Broukhis, Simon Cooper, Landon Curt Noll][judges] - All rights reserved
This work is licensed under a [Creative Commons Attribution-ShareAlike 3.0 Unported License][cc].
[judges]: http://www.ioccc.org/judges.html
[cc]: http://creativecommons.org/licenses/by-sa/3.0/
-->
<TABLE><TR>
<TD><a rel="license" href="http://creativecommons.org/licenses/by-sa/3.0/"><img alt="Creative Commons License" style="border-width:0" src="http://i.creativecommons.org/l/by-sa/3.0/88x31.png" /></a></TD>
<TD><P>&copy; Copyright 1984-2016,
<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="http://creativecommons.org/licenses/by-sa/3.0/">Creative Commons Attribution-ShareAlike 3.0 Unported License</a>.</P></TD>
<TD>&nbsp;<!--<a href="http://validator.w3.org/check?uri=referer"><img src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01 Transitional" height="31" width="88"></a>--></TD>
</TR></TABLE>
</body>
</html>
2015/dogon/hint.text
+111
View File
@@ -0,0 +1,111 @@
# Most Crafty
Gil Dogon
<http://sokoban-gild.com>
## Judges' comments:
### To use:
make
./prog
### Try:
./prog
press and hold the Left Arrow key until you turn 90-degrees to the left
when you see a long tunnel, press the function key F2
Use the Up, Down, Left and Right keys to change your path
Press function higher numbered function keys (F3, F4, ...) to go faster
Press F1 to stop
Turn 90-degrees to one side
Press F4 to and drill into some blocks for a bit
Press F1 to stop
Turn 180-degrees to face the way you came
Press F2 and navigate back down the new hole until you reach the long tunnel again
Press F1 to stop
etc.
Press the ESC key
### Selected Judges Remarks:
You are in a twisty maze blocks, almost all alike.
Those blocks are generated by twisty maze of code blocks, almost all different.
Can you find your way around either and understand where you are?
How many function keys does your keyboard have? Can you generate very high number function keys such as F30 or F31? :-)
*Textures? We don't need no stinking textures.*
## Author's comments:
### What is it?
Just run prog with no arguments on an X11-compatible system. The scenery, though pseudo-randomly generated should be strangely familiar, specially to those still in their teen age. You can navigate using the keyboard arrow keys and the function keys. Your speed is a linear function of (n-1) where Fn is the last function key you have pressed, and you always move in the direction you are looking at. Be aware that you are probably some kind of a Creeper as is obvious from looking at the program, hence your movement is destructive to the environment. So after pressing F12 for warp speed, and moving around randomly, you might find yourself in a 3D maze of twisty little passages, from which there is only one Esc(ape) key. Note that in theory if you have a specialty keyboard with 32 function keys you may even press F31 to reach infinite improbability drive speed, though the author had never tested this feature. However a hidden comment in keysymdef.h suggests the existence of a mythical Sun Keyboard with 35 function keys :)
### Full disclosure.
This entry, tough pretty thoroughly obfuscated, is not entirely original, nor am I Notch. The inspiration for this entry is a demo code written by the Notch himself, which was released with the following license: "you may use the code in here for any purpose in any way you want, at your own risk". That version will henceforth be referred to as the original. Though the original in itself was quite nice and rather dense piece of code, it was not written in C, nor entirely and meticulously obfuscated, a state of things I hopefully rectified.
### Some extra features.
Basing it on the original which already had a wonderful simple and concise ray casting through a generated voxel world rendering, I added a few tweaks of my own device:
* Two pass optimized rendering. The program first calculates 1/16 of the output image by ray casting, and then, when possible uses texture interpolation on the voxel faces. It speeds up the rendering by at least a factor of 4 on most scenes, but extra care must be taken when passing rays through the leaves voxels ...
* Fixed a small omission in the original. When you looked though a transparent leaves voxel, you did not see the leaves at voxel faces that were far from you. In this version the rendering of those (far face leaves) is correct.
* Window rendering size specified in Makefile.
* Added the keyboard controls for navigation (and destruction).
### Portability issues.
This entry is rather portable I think on modern platforms. It assumes of course basic X-windows availability. There are several other salient assumptions though:
* The entry assumes sizeof(int)=4. This seems to cover pretty much everything that supports X-windows so would be broken only on quite ancient machines, embedded processors, or some big iron 64 bit system where sizeof(int)=8.
* The entry assumes the default visual has 24 bit depth (RGB). This seems to be the case on most X Servers this days.
* The entry, does a thing which is an absolute No-No for X-windows program, i.e. assuming it knows some numeric values for keysyms defined in keysymdef.h . I have searched far and wide the lord Google's domain, yet was unable to find a version of the file where those assumptions were broken. This enables the important support of up to 32 function keys keyboards without spilling over the size limit, and allows us to use such fun expression for arrow view control as the following:
*(a&1?&C:&B)-=(.05 -a/2%2*.1)*!(a-1&4092^3920)
### Precision issues.
The entry, on purpose, (see the section about SIMD below) does not use enough bits of precision, so some times the ray will miss the intersection of two voxel faces and push on through. That's why you may notice some noise along close up voxel edges. Fixing this issue would have taken the entry over the size limit regrettably.
### Obfuscations.
Well, of course you have all the usual suspects, used for extreme compression, and such a nice layout: not very informative identifiers, which are being reused all over the place, some rather gruesome looking expressions, a whole load of magic constants with apparently no rhyme nor reason (including a Lagrange polynomial), and a message from our friendly Cetaceans. However it also includes some clever and not so obvious though instructive techniques, to subtly make the code more magical and efficient, at the same time.
Those techniques are about the use of 64 bit integers in order to do SIMD work, in a portable way without ever using any SSE/AVX or other non-portable compiler inline functions! The irony though, is that when compiling the program on modern X86 architectures indeed SSE/AVX is used for the long longs.
Following is some "Spoiler" information, So if you want to play tough, stop reading at this point.
### Portable SIMD programming.
So how is this done? Quite simply by using the whole long long arithmetic's capability. I think the C99 standard assures us that long long has at least 64 bits. Most of those bits are unused in normal programs, however here we use them more wisely. For example, in the inner loop of the program you have the innocent looking expression i+=d. What it does in fact, is a SIMD addition of two vectors, each with three signed fixed point coordinates, advancing our ray in 3D space!
To spell it out, the macro producing such vectors is P, and the assignment q=0x820008202625a0 sets our creeper original position to about (32.5, 32.5019, 2441.406) .
Evidently when doing such arithmetics, care must me taken to avoid overflow from one component to the other, but since our voxel world is a torus of size 64 in each dimension this hardly matters. A subtle issue, is how to deal with signed quantities. In the i+=d expression above i has 3 positive components, but d has arbitrary signed components, as our ray may face in any direction. It seems things should not work, specially as we defined both i and d as unsigned! However notice that the T (and P )macro converts float to signed long longs. Once sign is extended from a least component into higher bits, it seems at first to be recipe for disaster, however everything works beautifully, and you get precise component results when the final accumulation components in i are positive. This only gets broken a bit when the final accumulation has a least significant negative component. To see this bug in action change the assignment above to q=0x82000820000000, and look towards the negative direction of the main tunnel.
Similar technique is used on the RGB components so their brightness can be adjusted simultaneously by the expression: o=o*b>>8 . Of course some spare bits are needed between the components, so they are spread in the long long and reordered as RBG.
--------------------------------------------------------------------------------
<!--
(c) Copyright 1984-2016, [Leo Broukhis, Simon Cooper, Landon Curt Noll][judges] - All rights reserved
This work is licensed under a [Creative Commons Attribution-ShareAlike 3.0 Unported License][cc].
[judges]: http://www.ioccc.org/judges.html
[cc]: http://creativecommons.org/licenses/by-sa/3.0/
-->
2015/dogon/prog.c
+56
View File
@@ -0,0 +1,56 @@
#define So long
#define R rand()
#include <math.h>
#include <X11/Xlib.h>
#define T(i,F) ((So long)(i)<<F)
#define O(c,L,i) c*sin(i)+L*cos(i)
#define y(n,L) for(n=0; n<L 3; n++)
#define P(v,L) d=0; y(l,)d+=T(L*l[v],l*20);
#define X(q) q>>10&63|q>>24&4032|q>>38&258048
char J[1<<18]; int G[W*p],_,k,I=W/4+1,w=p/4+1; float C,B,e;
unsigned So long A,n,d, t,h,x, f,o,r,a,l,L,F,i,s,H=1<<18,b=250,D[1<<14],z[W*p],q
=0x820008202625a0;main(){Display *j=XOpenDisplay(0);Window u=XCreateSimpleWindow
(j,RootWindow(j,0),0,0,W,p,1,0,0);XImage *Y=XCreateImage(j,DefaultVisual(j,0),24
,2,0,(char*)G,W,p,32,0); XEvent M; for(XMapWindow(j,u); XSelectInput( j,u,1)&&a-
65307; ){ if(!H){ if(XCheckWindowEvent(j,u,1,&M)){ a=XLookupKeysym(&M.xkey,0);*(
a&1?&C:& B)-=(.05
-a/2% 2* .1)*!(a-
1& 4092^ 3920);a+
2&0xfe0^ 0xfc0||(
s=a+2&31 ); }else
{ y(k,p+ ){ F=k%w* 4|k/w; float a[6],S=(F-p /2.) /p;
y(_,W+){ i=_%I*4|_/I; if( F<p&i<W){ o=1; L= i+F*W;if
(l=i&3); else{ l=F&3; o=W ; } h=z[L-o*l]; f =z[L+(4-
l)*o]; t =F-p/2||i-W/2; r =h^f; if(!l| !t|( int)r|(!
(h- 3&3) &&258063&r>>38)) { float V=(i-W/2. )/p,U=O(
S,1,B),m =32768,Q=m; a[4] =O(-1,S,B); a[3]= O(U,V,C)
; a[5]=O (-V,U,C); P((a+3 ),s*42); t||(A=d) ;f=0;y(n
,){float N=a[n+3], E=1024 /fabs(N); b= N<0; float K=
(((q>>20 *n)^~-b)+!b&1023 )/1024.; y(d,)a[d ]=a[d+3]
*E; a[n] =round(a[n]); P( a,K); i=q+d; P(a, 1); e=E*
K; for(; e<m; i+=d){ l=X(i); t=r=l^(l^l-( 1<<6*n))
&63<<6*n ; if(b){ r=l; l=t; } if(J[r])l=r ; if(t=J
[l]){x=( n-1)?(i|i>>40)&1023|i>>8&4190208 |4194304
:i&1023| i>>28&4190208|(b^l==r)<<23; if(h =D[(x>>6
&0xf|x>> 14&0x3f0)+t*768]){ o=h; f=n|l*4| x<<32; m
=e; } if (t==8&e<Q)Q=e; } e+=E; } }b=(255 -((f&3)+
2)%3*51) *(1-m/32768); o=o*b>>8; G[L]=o>> 32<<8|o&
16711935 ; z[L]=3*(Q<=m)|f|b<<56; } else{ d=l*(f<<
8>>40)+( 4-l)*(h<<8>>40)>>2&16774143; o=D [(d>> 6&
15|d>>14 &1008)+J[(int)h/4]*768]*(b=h>>56 )>>8; G[
L]=o>>32 <<8 | o& 16711935 ; z[L]=(
int) h|d <<32|b<< 56; } }} } q +=A;
XPutImage (j, u+0, DefaultGC (j,J[X(q
)]=0),Y, 0,0,0,0, W,p); }} else{ L=
--H/768; J[H] =R% 16*(R%4< abs((H>>
6&63)-32 )+abs((H
>>12&63) -32)-3);
i=H &15; F=H %768
>>4; if( L<16){if
(L-1|!(R %3))b=R%
96^255; l=i*i*3+i*81/4&3; a=L>3?L-8?L-5?9858122:12365733-488848*((i+F/4*4)%8&&F%
4):R%2*5298487:3352537*L*L-14202379*L+19205553; if(L==4)if(F<l+18)a=6990400;else
if(l>F-19)b*=0.7; if(L==3){ if((i-1&15)<14&(F-1&15)<14&!(F&16)){ a=12359778; _=7
-i; k=7-F%16; _^=_>>31; k^=k>>31; b=196-R%32+(k>_?k:_)%3*42;} else{ b*=1+R%2*(.5
-(i&1)); } } D[H]=(a&16711935|(a&65280)<<24)*(b>>(F>>5))>>8&0xff00ff00ff; } } }}