Add another alt version to 1993/rince + formatting
The formatting of the README.md file has been completed. Typos were also fixed. The formatting of the design.md has been completed. Typos were also fixed. The second alt version makes movement for the default game (which is in the source code itself) more familiar to vi users. It is an exercise for others to change the somewhat awkward keys for other games. Looking at design.md might be of help there. The bugs.md has been updated with a set of features, not bugs, that should no be fixed.
This commit is contained in:
1 parent
a28bd67968
commit
0cc4ba7313
5 files changed
+57
-58
No files matched your search
+2
-2
@@ -115,8 +115,8 @@ OBJ= ${PROG}.o
|
||||
DATA=
|
||||
TARGET= ${PROG}
|
||||
#
|
||||
ALT_OBJ= ${PROG}.alt.o
|
||||
ALT_TARGET= ${PROG}.alt
|
||||
ALT_OBJ= ${PROG}.alt.o ${PROG}.alt2.o
|
||||
ALT_TARGET= ${PROG}.alt ${PROG}.alt2
|
||||
|
||||
|
||||
#################
|
||||
|
||||
+32
-45
@@ -4,8 +4,22 @@
|
||||
make all
|
||||
```
|
||||
|
||||
NOTE: there is an alternate version of this program that allows one to slow down
|
||||
the game. See the [Alternate code](#alternate-code) section below.
|
||||
NOTE: there are two alternate versions of this program, both allowing one to
|
||||
slow down the game and the second one with movements more familiar to vi users.
|
||||
See the [Alternate code](#alternate-code) section below.
|
||||
|
||||
|
||||
### Bugs and (Mis)features:
|
||||
|
||||
The current status of this entry is:
|
||||
|
||||
```
|
||||
STATUS: INABIAF - please **DO NOT** fix
|
||||
```
|
||||
|
||||
For more detailed information see [1993 rince in bugs.md](/bugs.md#1993-rince).
|
||||
|
||||
|
||||
|
||||
|
||||
## To use:
|
||||
@@ -37,6 +51,11 @@ refresh(),c=select(k,&y,0,0,(v.tv_usec=1<<17,&v))?getch():0;
|
||||
|
||||
to another value like 18 or 19 which you can do with the alternate code.
|
||||
|
||||
In the case of [rince.alt2.c](rince.alt2.c) the movement keys for the default
|
||||
game are slightly different and will feel more familiar to vi users: `h` for
|
||||
left, `l` for right (that was not changed) and `k` for fire (that was also not
|
||||
changed).
|
||||
|
||||
|
||||
### Alternate build:
|
||||
|
||||
@@ -50,7 +69,7 @@ Replace 18 with whatever number you wish.
|
||||
|
||||
### Alternate use:
|
||||
|
||||
Use `rince.alt` as you would `rince` above.
|
||||
Use `rince.alt` or `rince.alt2` as you would `rince` above.
|
||||
|
||||
|
||||
## Judges' remarks:
|
||||
@@ -72,38 +91,6 @@ considered finished when all the `m`s are then `M`s.
|
||||
|
||||
For a brief design description, see [design.md](design.md).
|
||||
|
||||
The `select(2)` from SunOS says:
|
||||
|
||||
```
|
||||
BUGS
|
||||
|
||||
...
|
||||
|
||||
select() should probably return the time remaining from the
|
||||
original timeout, if any, by modifying the time value in
|
||||
place. This may be implemented in future versions of the
|
||||
system. Thus, it is unwise to assume that the timeout
|
||||
pointer will be unmodified by the select() call.
|
||||
```
|
||||
|
||||
Systems such as Linux do return the remaining time in timeout
|
||||
field (0 if no keys were pressed), but `rince` assumes that
|
||||
timeout remains unmodified.
|
||||
|
||||
It has been suggested that:
|
||||
|
||||
```c
|
||||
select(k,&y,0,0,&v)
|
||||
```
|
||||
|
||||
should be replaced with:
|
||||
|
||||
```c
|
||||
select(k,&y,0,0,(v.tv_usec=1<<whatever_you_want,&v))
|
||||
```
|
||||
|
||||
where `whatever_you_want` is some integer such as 17 or 19.
|
||||
|
||||
|
||||
### WARNING for SunOS 4.1.x:
|
||||
|
||||
@@ -112,6 +99,7 @@ compiler in the first place), this program may be used to log
|
||||
out very quickly. Unfortunately, you can't do anything else
|
||||
with it.
|
||||
|
||||
|
||||
### Additional notes
|
||||
|
||||
Some people report that `rince` dumps core on their system.
|
||||
@@ -154,11 +142,11 @@ Levels : Ahh well... it's not *totally* generic.
|
||||
|
||||
The proper definition for usage would be: `./rince [data_filename]`
|
||||
|
||||
|
||||
### Portability
|
||||
|
||||
I have compiled in on the following systems:
|
||||
|
||||
---
|
||||
```
|
||||
System OS Compiler (and flags)
|
||||
DECstation 5000/240 Ultrix 4.2A c89 -std
|
||||
@@ -168,21 +156,20 @@ DECAlpha 3000/500 OSF/1 V1.2 c89 -std
|
||||
SGI Indigo (R4000) IRIX 4.0.5F cc -ansi
|
||||
Alliant FX2800 Conentrix 3.0.0 fxc
|
||||
```
|
||||
---
|
||||
|
||||
\* I never said it worked! The guidelines state that you dislike programs that
|
||||
won't *compile* under both BSD or SysV `Unix`. This compiles, and indeed runs
|
||||
on all the others (both BSD and SysV) correctly.
|
||||
|
||||
Alas, on Solaris it compiles, but mysteriously stops displaying output
|
||||
after a while until you quit with control C, when it all catches up again.
|
||||
I think the problem may lie in either select(), or curses, (or perhaps
|
||||
after a while until you quit with control-c, when it all catches up again.
|
||||
I think the problem may lie in either `select(2)`, or curses, (or perhaps
|
||||
conflict of the two).
|
||||
|
||||
The use of `select()` no doubt makes it less portable to STRICT SysV
|
||||
machines. However I have tested this on several so-called SysV
|
||||
machines, and all of them support `select()`. In fact, the `select()` they
|
||||
support appears to be more portable between them than their `poll()` call.
|
||||
The use of `select(2)` no doubt makes it less portable to STRICT SysV machines.
|
||||
However I have tested this on several so-called SysV machines, and all of them
|
||||
support `select(2)`. In fact, the `select(2)` they support appears to be more
|
||||
portable between them than their `poll()` call.
|
||||
|
||||
|
||||
### Obfuscation
|
||||
@@ -206,7 +193,7 @@ Of course, all the usual obfuscation lurks within, such as combining
|
||||
multiple for loops into single ones; warped and twisted logic; plus a
|
||||
plethora of other minor oddities. It's up to you to discover some of them
|
||||
of course... Sometimes I have sacrificed length for obfuscation. It is all
|
||||
too easy to change the arguments in main to one character identifiers, but
|
||||
too easy to change the arguments in `main()` to one character identifiers, but
|
||||
in my opinion they add to obfuscation in this case by being longer.
|
||||
|
||||
`lint` complains about lots of things. Firstly the use of curses immediately
|
||||
@@ -223,7 +210,7 @@ insufficient memory) is performed.
|
||||
|
||||
There is no 'end of game' checking method. Hence games like Sokoban rely
|
||||
on the user to decide when they have had enough. Also, there is no quit
|
||||
mechanism other than control C.
|
||||
mechanism other than control-c.
|
||||
|
||||
|
||||
## Copyright and CC BY-SA 4.0 License:
|
||||
|
||||
@@ -26,12 +26,11 @@ Hence:
|
||||
... ...
|
||||
```
|
||||
|
||||
This does of course have the odd problem with clashes. What if we want to
|
||||
roll two down boulders down simultaneously towards the same square.
|
||||
I perform no buffering, and so this situation is just a 'fight it out' and
|
||||
let which ever transition has priority win. Such a case may produce the
|
||||
following change of maps (depending on which 'roll' transition is used
|
||||
first).
|
||||
This does of course have the odd problem with clashes. What if we want to roll
|
||||
two boulders down simultaneously towards the same square. I perform no
|
||||
buffering, and so this situation is just a 'fight it out' and let which ever
|
||||
transition has priority win. Such a case may produce the following change of
|
||||
maps (depending on which 'roll' transition is used first).
|
||||
|
||||
```
|
||||
o.o ..o o..
|
||||
@@ -40,7 +39,7 @@ first).
|
||||
```
|
||||
|
||||
I claim that it is possible to perform all of the 3x3 to 1x1 transitions in a
|
||||
3x3 to 3x3 based system. One other feature added in is a work around for the 'no
|
||||
3x3 to 3x3 based system. One other feature added in is a workaround for the 'no
|
||||
buffering' problem. If we define a space ship (as in the [Space
|
||||
Invaders](https://en.wikipedia.org/wiki/Space_Invaders) example) to fly right,
|
||||
and we are 'walking through' our map from top-left to bottom-right, then it is
|
||||
@@ -84,7 +83,7 @@ is written as: `eabcdfghi512346789K`.
|
||||
|
||||
If there are no keys needed for this transition, the character `*1` should
|
||||
be used instead. Now the format of the game description file is now
|
||||
the following: (angle brackets denote an 'entity' to be defined).
|
||||
the following (angle brackets denote an 'entity' to be defined):
|
||||
|
||||
|
||||
```
|
||||
|
||||
Reference in new issue
Block a user