WireWorld

[Salem]

It's been a good few months since the last competition, so here goes.

Wireworld is a cellular automata using the same ideas as Conway's game of life.

The programming task is to read in a "wireworld" simulation file and run an animated simulation of that world.

Here is an example file.

# Wireworld input file
# A # denotes the start of a comment upto the end of the line
#
# The delay keyword indicates the speed of animation in frames per second.
# a value of 0 means wait for a keypress.
delay=0
#
# The area of play is defined using these 4 letters
# Background    = '.'
# Electron Head = 'E'
# Electron Tail = 'T'
# Wire          = 'W'
# The test area will be no bigger than 80*24
# The test area will always be rectangular (each line the same length)
# No wires will touch the edge of the test area.
...................................
.TEWWWWWWWWWWWWWWWWWWWWWWWWWWWWWW..
................................W..
.........WWWWWWWWWWWWWWWWWWWWWWWW..
.........W......................W..
.........W......................W..
...WWWWWWWWWWWWWWWWWWWWWWWWWWWWWW..
......W............................
......WWWWWWWWWWWWWWWWWWWWWWWWW....
...................................
#
# For each delay period, the program should calculate and display
# the progress of the electrons through the wires.
# So TEWWW becomes WTEWW and WWTEW etc etc.
# End of file.

The task:
Write a program in standard C89 or C++98 (including the STL) to implement a wireworld simulation.
The program will be given a single command line parameter, namely the name of the configuration file in the above format.

The challenge:
Create three separate source files along the lines of
main.c - the portable program.
tty.c - specific functions to "draw" to a simple terminal.
curses.c - specific functions to "draw" to a screen via ncurses.
Other source files can be implemented, but ONLY to support main.c

Create one header file which describes the interface into tty.c AND curses.c which will be included by main.c.

Example

#include "myscreen.h"
int main ( int argc, char *argv[] ) {
    myscreen_open();
    myscreen_print("hello world");
    myscreen_close();
    return 0;
}

The porting modules tty.c and curses.c must only depend on stdio and ncurses respectively.

The example compilation command lines will be
gcc main.c tty.c
gcc main.c curses.c -lncurses

I've used C here, but the same applies to C++ writers, that is main.cpp, tty.cpp and curses.cpp.

The points:
Points will be variously awared for:
- Robustness in handling bad input.
- Does it compile out of the box.
- Consistency of coding style, use of comments.
- Ease of portability, basically the size of tty.c and curses.c.
The smaller these files are, and the narrower the interface, the easier it should be to port to another display (in theory at least).
Careful thought about your interfaces could get you some good points.

Duration:
The competition officially runs from the 1st to 30th September.
The remainder of August is to ask questions about the competition, clarify rules, read up on ncurses, allow people time to decide to join in etc.
Whilst you can start now, there may be changes you have to take account of.

Submissions:
A zip file containing source files and a readme.txt with any specific notes which you think might be considered important.
The name of the zip should be your cprog username (eg. Salem.zip).
To be sent to an email address (to be decided) by Midnight GMT 30/09/06.

The following function can be assumed to exist, to permit easier porting to both platforms.
void wwSleep ( unsigned int milliseconds );

The following two functions will be available to the terminal implementation.
void wwClearScreen ( void );
void wwWaitKey ( void );

The test platform will be cygwin or Linux (those where I know ncurses exists).
I might try the tty based approaches on say dev-c++ or vc++ (time permitting).

Useful links:
http://mathworld.wolfram.com/WireWorld.html
http://en.wikipedia.org/wiki/Ncurses

[Queatrix]

>> The test area will be no bigger than 80*24

Will if be any smaller than 80*24?

If so, than how do we know the size of this 'space'? Will the end of a line after 'code' specify the width?

[zx-1]

Originally Posted by Salem

The following function can be assumed to exist, to permit easier porting to both platforms.
void wwSleep ( unsigned int milliseconds );

The following two functions will be available to the terminal implementation.
void wwClearScreen ( void );
void wwWaitKey ( void );

So, do we just put calls to these functions in our code, and you provide their implementation during testing?

[Sebastiani]

well, I hammered out a solution in under 3 hours.
it doesn't actually meet the requirements (although it is portable), so I won't officially enter the contest (lazy, right?), but I will post it after the winner is announced, just for fun. of course, due to my utter laziness, I haven't rigorously tested it, so I wouldn't be suprised if Salem actually proves that my program is broken (he's quite good at that ).

[Salem]

> Will if be any smaller than 80*24?
The logical inverse of > is <=

> So, do we just put calls to these functions in our code, and you provide their implementation during testing?
Yes, you of course write whatever you like inside them to test on your own system (to call say your own implementation specific delay function).
But you don't need to submit your own versions of these functions as I will have my own, specific of course to my system.

[itsme86]

W00t! Mine's ready for submission.

[Sebastiani]

are there any premade maps available online? I've found plenty of examples in the form of image files, but none in text format.

[Salem]

I'll be creating a few for testing purposes a bit later on.

Though since the area is pretty small, it's not going to be anything exotic like a multiplier.

One of the points of the competition is writing portable code, which would make it easier to scale up to 1000x1000 using openGL for example without having to rewrite huge chunks of code to do it.

[Hunter2]

>>I'll be creating a few for testing purposes a bit later on.
One bonus point for writing an image-processing routine to convert animated GIFs into text format with an appropriate delay field.

Two bonus points for converting a flash animation into an animated GIF first.

[Raven Arkadon]

what happens if there are multiple paths the electron could take? it splits up - does it?

[Raven Arkadon]

also, in case it splits up: what happens if electrons meet each other?

[Sebastiani]

I have a suggestion: instead of requiring the edges in the map data, why not implicitly including them (which would simplify the definition of some circuits)?

>> what happens if there are multiple paths the electron could take? it splits up - does it?

correct.

>> also, in case it splits up: what happens if electrons meet each other?

that depends on the state of the adjacent cells.

[itsme86]

Originally Posted by Raven Arkadon

also, in case it splits up: what happens if electrons meet each other?

Check out the link that Salem provided to the wolfram.com site.

[Raven Arkadon]

well i assume that tails may overlap:

 W
TE
 W

becomes
 E
WT
 E

but a head may never enter an already occupied field - or the inverse: a head may only enter fields with a wire on it.

[itsme86]

You don't need to assume anything. The rules are well-defined by the links that Salem provided.