Schwarze Katze Project

Apple vrs Windows - Genau!

2009-11-07T18:45:00.000-05:00

That is all.

Wine blogging - Shotfire barosa Shiraz 2007

2009-11-01T17:10:00.001-05:00

Classic style shiraz.

Baguala Torrontes 2007

2009-10-14T22:38:00.000-05:00

A light white wine. Floral notes on the nose. Tastes of stone fruit, possibly apricot. A bit of musk on the finish.

Wine Blogging - Kung Fu Girl Riesling 2008 Washington

2009-10-07T22:27:00.002-05:00

A halb-trocken white wine, very fruity. Think somewhere between peaches and lychees.

Playing D&D was being Goth in the '80s

2009-10-04T21:51:00.002-05:00

Something I found while digging through mu old papers.

To speak of old gods and ancient time, of both joy and sorrow, is in itself a mystery.

One hears of Poseidon and Atlantis, of Yahweh and the Twelve Tribes. One listens to tales of Lucifer and the drowned city of Ys, of Solomon and this mines.

History is half deaf and half blind. For history is written by the winners and the voices of the losers are still.

Who sings of the the Sidhe that fair Avalon had forgotten? Who can speak to me of the little people who laid gifts to lost gods, of the folk of bronze and flint?

Having won so often, when have we lost so much? Having enjoyed victory, where did we lose?

Who can show me the first forests of the dryads, of beasts unseen, of spirits unknown? Who can show me the arts of people the vanquished had conquered?
Where can I find the temples and palaces of gods who came before the gods? the toys and games of forgotten children?

Having won so often, when have we lost so much? Having enjoyed victory, where did we lose?

Where can I hear the old songs of life or paens of praise, the cries pf the buried city, or the silence of the forgotten groves? Where can I learn the old rituals of life and darkness, the rites of spring or a dying sun?

History is half deaf and half blind. For history is written by the winners and the voices of the losers are still.

La Sauvageonne, Les Ruffes 2007

2008-11-17T21:29:00.000-05:00

The label is from a different vintage but still.

MTV Video - A Public Service Announcement

2008-11-09T13:36:00.000-05:00

Jackson Browne |MTV Music

Vina Godeval 2006

2008-04-05T17:44:00.003-05:00

A variatel wine rescued by a Spanish nunnery.

OK, is it just me, or did that just sound like a used car dealership?

Image test

2008-04-05T17:41:00.002-05:00

This has been an image test. We now return you to your normal ration of silence.

Wine Blogging - Show

2008-01-20T21:58:00.000-05:00

Excellent Wine. From VintageSpec;

Unlike most inexpensive Cabernet Sauvignon on the market, this one is friendly to the palate. It is full of ripe juicy dark berry fruit layered with vanilla, clove, and allspice. It is not extremely complex, but it is good! A touch of Merlot, Cabernet Franc, Petite Verdot, and Petite Syrah are incorporated to round out the boldness of the Cabernet Sauvignon grape.

Wine Blogging - 2006 Moschofilero Boutari

2008-01-05T17:13:00.000-05:00

A solid dry white wine. Lots of fruit, both for the palate and the nose. There is a bit of minerality to refresh.

Wine Blogging - Belle Glos Meiomi

2007-11-19T21:03:00.000-05:00

A 2006 pinot noir from Sonoma, this is nice warm red wine. Full-bodied, but still light. Lots of fruit for the palate. (Think peaches and a hint of vanilla.) Has a bit of chocolate for the finish.

Wine Blogging - Pirramimma petit verdot

2007-11-03T17:36:00.001-05:00

A good fall red wine. The nose shows grilled pineapple (smell the caramel!)
There is plenty of summer fruits like peaches in the palate and the is full bodied enough to keep one warm on those crisp autumn evenings.

Wine Post - Teusner Jousha 2005

2007-08-14T19:24:00.001-05:00

What can I say but rant and rave, rant and rave?
An extraordinary red wine. The nose is a little sharp (can I say spicy?) with a lot berry and some vanilla. The taste of the wine fills the mouth with lots of fruit (I just cannot identify it). And while it does have some eucalyptus, among other things) at the back of the mouth, there is a very long finish of vanilla.

Since the vineyard is marketing the Joshua 2006 vintage, I'd better grab the '05 while I can

Ed: Raspberries, red Raspberries!! That was the fruit that I was tasting!

Wine of the Day - Ciro, Rosso Classico

2007-08-05T17:05:00.000-05:00

A dark red wine, Ciro starts off with caramel and fig overtones and has a nice warm finish. One point of interest, the grape used in this wine also made the wine that Greece imported way, way, WAY back when Greece was establishing colonies on the Italian peninsula.
Still a very good, solid table red.

PS. Cherry. Did I mention cherry in the finish? There is a taste of cherries (dark cherries) in the finish that lingers a bit.

Wine of the Day - Palazzo Della Torre

2007-08-01T19:17:00.000-05:00

A dry red wine, light enough for the heat of summer but has enough body to hold its own with grilled or braised meals. Lots of woody aromas for the nose with floral notes, the taste is more a blend between herbs and currants with some oak coming out at the back of the tongue.

This wine is unusual in that some of the grapes used are dried for three months before blended with the rest of the harvest.

Wine Blogging: Spier Pinotage, 2005

2007-06-23T09:53:00.000-05:00

Spier 2005 Pinotage

A ruby red Shiraz. Jammy, but not overly sweet. More to the herbal / woodsy end of red wines.

ToDo list

2007-05-24T17:58:00.000-05:00

What I need to do ...
1) I had to re-create my Poggle game program, so I should do a write-up of what I changed.
2) A study of my Concentration game program, with respect to unit and regression tests.
3) Re-create my Kono game program.
4) Go over game position evaluation, a la Conway.

Wine Blogging: The Pretty Miss, Creed of Barossa

2007-05-22T21:38:00.000-05:00

A very good blended red wine. Warm with lots of fruit in the palate, somewhere between cherry and plum. Recommended meal would be grilled porterhouse steak that was rested on a mix of chopped rosemary and thyme with a drizzle of olive oil.

Programming Mephistopheles' Computer

2007-05-21T23:10:00.000-05:00

In terms of paranoia, there are three ways to look at computers;
Naive - Once a program compiles and is debugged successfully, there will be no problems with the program. Apart from the user of course.
Murphy's Computer - Programs will fail fail at random. Usually at the worst moment for the user.
Mephistopheles' Computer - Programs will not just fail, they will fail in a manner to cause the most pain for the user.

While it is a good idea to lock down the program's input so that a "clueless user" (translation: some one who can find an undocumented feature) cannot break a program, there are are other ways that inputs can mess up a system. For instance between threads, between processes, or between function calls. In many cases, the programmer must add reality checks to any input from any source, "trusted" or not, in order to keep problem at a minimum.

For instance, reading and writing to the Windows registry. The cases a program will access the registry can be summed into three; when the program starts, when the program stops, and when the program's parameters change.
When the program starts, either the registry entries are there or they are not, as in starting the program for the first time. Plus, just because the root entry is there for the program, does not mean that the sub-entries are there as well.
All a quitting program wants is to write what ever values it has into the registry. If the entry is not there the entry can be created for the value to be stored..
When the program changes parameters, all that it needs is to store the old value and read the new value. While if the entry for the old value does not exist and can be created, a non-existent new value means that the program must recreated this new value with the programmed defaults.

Note that with multiple choices, the program does not have to check those choices not wanted. When done properly, this can be done on-the-fly.

Just remember, "The devil is in the detail."

Today's Wine Domaine du Loou, Espirit de Blancs

2007-05-20T19:54:00.000-05:00

Domaine du Loou, Espirit de Blancs is a nice crisp wine from Provence. Its taste of green apple will complement curries and satay dishes. The residual sugars will go nicely with any spicy dish, but don't serve this wine with intense tomato based chilies.

Recommended meal: Fine Cooking's Best of issue, Spring/Summer 2007's Thai Marinated Roast Chicken with Lemongrass-Peanut Pan Sauce with Bon Appetit's June 2007 issue's Strawberry-Blueberry Summer Pudding for dessert. In order to get more sauce for the chicken recipe, I would recommend that a quarter cup of chicken broth be added to the roasting pan, either for the basting for just for scrapping up the drippings.

Today's Wine, Joel Gott Cabernet Sauvignon 2005

2007-05-20T15:18:00.000-05:00

(Actually yesterday's wine.)
Joel Gott Cabernet Sauvignon 2005, Blend 815 is a big fruity wine. About 17.00 USD. It goes well with grilled foods. Think sirloin burgers topped with roasted onions and bleu cheese.

I had this with skirt steak simmered in chili sauce (cooked ancho and jalapeno peppers pureed with garlic, salt, anise seed and tomatillos, then strained) and served with guacamole.

Testing, Testing .. 1, 2, 3

2007-05-20T10:58:00.000-05:00

Is this Mic still open?

Kono: the Board class (again)

2006-06-28T20:26:00.000-05:00

Actually a bit more than a variable move made it necessary to refoactor every thing.

O.K., the CBoard class is purely about the playing field. The reason why earlier versions placed movement functionality here was confusion about the similarity between checking for possible movement paths and checking for neighbouring regions.

So, the minimum required for the CBoard class is (ignoring Singleton issues) drawing the board and retrieving board and region information. The functions about neighbourhoods can be skipped as there is no special or missing neighbouring cells to be concerned with.

The named constants:
Private;
drawing constants for the playing field, and
number of cells
Public:
OFF_BOARD.

Variables:
Private;
array of regions for selecting pieces, and
array of regiond for selecting playing regions.

Static Functions (no need to create or release instances to call these):
Public;
retrieve dimensions of layout (number of cells for each direction), and
check that location (x,y) is in bounds.

Functions:
Public;
retrieve the region for location (x,y),
match location (x,y) to point,
drawing,
retrieving the size of the playing field (in pixels), and
Singleton functionality.

The Scoring System, Nimbers III

2006-06-17T12:27:00.000-05:00

Once Nimber arithmetic is explained with 3 stacks, there is no need to go any further. The value of four or more stacks can be determined as combinations of 1, 2 and/or 3 stacks.

The starting point here is to use 3 stacks containing 1, 2 and 3 counters. These 3 stacks (1* + 2* + 3*) have the combined value of 0. If the first person removes one of the stacks, the second person can then equalize the remaining stacks and leave the Game with a value of 0 again. Alternatively if the first person equalizes two of the three stacks, then the second person can remove the un-equal third stack and leave the game with 2 equal stacks again.
So the first set of equivalences in Nimber Addition are;

1* + 2* + 3* = 0
1* + 2* = 3*
1* + 3* = 2*
2* + 3* = 1*

The next triplet of Nimbers in Winning Ways, Vol. 1 that equal 0 can be played out in much the same manner. In addition to the moves mentioned before (first player: removes a stack, second player: equalizes the remaining stacks and first player: equalizes 2 stacks, second player: removes the un-equal stack), the second player also has the following strategy. If the first player reduces one of the bigger stacks to either 2* or 3*, the second player can remove counters from the other large stack to give it a value of 3* or 2* respectively. The game now has the value of 1* + 2* + 3* or, as previously determined, 0.

Evaluating any random set of 3 stacks is not terribly difficult. One just has to find the Nimber value of two smaller stacks. If this value equals the third stack, the total value of the triplet is 0 and the first person to play loses. If the combined Nimber value of the smaller stack does NOT equal the third stack, all the first player needs to do to win is to reduce the third stack to the value calculated and leave the Game with the value of 0.

Further examples of Nimber addition can be found in Berkamp, Conway and Guy's "Winning Ways, Vol. 1", pages 42 and 59 - 59.

The Scoring System, Nimbers II

2006-06-17T12:11:00.000-05:00

Beginning with two stacks, the properties of Nimbers start appearing.

Two stacks of equal height (with equal Nimber values) turns out to have a total value of 0 (the first person to move loses). If the first person takes an entire stack, the second person take the second stack and the first person is left without a move. On the other hand if the first person takes only part of a stack, the second person takes the same amount from the other stack and leaves the total value 0 as before.
Thus the first property of Nimbers is that two Nimbers of equal value total to 0 (n* + n* = 0). In other words, a Nimber is its own negative.

Two stacks of unequal value mean that the first person wins, of course. The best strategy is for the first person to equalize the stacks leaving a Game with the value of 0 for the second player.

The Scoring System II, Nimbers

2006-06-13T20:32:00.000-05:00

Now consider Lucy and Robert with a single stack of cookies. They take turns eating one or more cookies from the stack. The loser in this game is the one that cannot get any more cookies to eat from the stack.

The best strategy for either player is to grab the entire stack.

Here the first person to play wins.

The Scoring System I

2006-06-13T20:18:00.000-05:00

Skipping over fractional game values for the time being, let us talk whole numbers.

We will start off considering games blocking games where the first person without a move loses. By convention, the Left player (which I'll name Lucy) will win if the game's value is positive, >0, or, in other words, has move moves than the opposing side. And the right player (Robert) will win if the game's value is less than 0, more moves than Lucy.
If the game has a value of 0 (think of a game board without pieces), then the first person to move is the loser (no piece to move).

Follow along with Berlekamp, Conway, and Guy in "Winning Ways".

scheduling

2006-06-13T16:12:00.000-05:00

One of the problems I am having is that when I built up my collection of programs I tended to skip around, going from one program to another, to avoid burning out. This tends to make for long development times.

I will try to blog on a regular basis, once I get my scheduling together. Until then, all I can do is random posts.

Kono: regarding Rules class

2006-06-09T19:17:00.000-05:00

Applying rules of the game without specifiing who is in that location just dose not make sense. About the only way that one can apply a movement rule and not care about ownership is with non-partisan (pieces can be moved by anyone) games or games that have both partisan and non-partisan pieces.

Happy 6/6/6

2006-06-06T20:08:00.000-05:00

Kono, re-going over the go-over

2006-06-04T20:38:00.000-05:00

It is rather embassasing to re-do teh rules class in order to get it to check that the piece moved is actually owned, much less owned by the proper side. I.e., Pre-Condition from point is playerX.

More Books II

2006-05-31T21:19:00.000-05:00

More Books

2006-05-31T21:16:00.000-05:00

Gotta collect them all!

An Edward Gorey Death

2006-05-28T13:07:00.000-05:00

What horrible Edward Gorey Death will you die?

You will swallow some tacks. You are a little weird, maybe not so much in a good way. Buy a yellow tie and wear it on your head.
Take this quiz!

Quizilla |
Join

| Make A Quiz | More Quizzes | Grab Code

Kono: the beginning

2006-05-26T19:59:00.000-05:00

The two classes that are essentially remain the same (expect for the Microsoft supplied classes) are the CStone and the CBoard classes. And about the ONLY thing that changes for the CBoard class is 1) the movement functions are moved the CRule class, 2) the named constant for the size of the playing area becomes private, and 3) that a new public function is added to indicate whether or not a given point is indeed on the playing area.

PS. I will start commenting on the COwner class when I finished refactoring it. The only other bit than needs to be mentioned is that the stored piece arrays are combined within a CPoint array in order to keep the location values together. (Saves on mental sweat.)

Kono: Today's post is brought to you by the letter R

2006-05-24T21:50:00.000-05:00

R for ARRRRRGH!

And here is my book recommendation;

Kono: Refactoring

2006-05-23T19:33:00.000-05:00

If I ever compile these posts, I will include my old code so programmers can have something to point to and snicker.

1) The first part that gets changed is to place every function that reflects / models / or is based on a rule of the game into the Rules class.

2) Hide as much as possible. While the signels enumerated constants need to remain exposed, there are others that do not. The size of the board (CBoard::DX) is one.

3) Even if copying data in two classes is faster, don't. Better to 'waste' computer cycles in function calls that to miss synchronizing the data and causing odd results. (The exapmle here is the COwner::Player ownership array in the CGame class.)

4) Right now the only other bit that I can see is to minimize the amount of data that goes into the Undo and the MoveGenerator classes. (Note: Optimize was not mentioned.)

Poggle: more solutions

2006-05-22T19:57:00.000-05:00

5-by-5

Black and White
1	0	1	1	0
0	1	1	1	0
1	1	1	0	0
1	1	0	1	1
0	0	0	1	1

3 Colours
0	1	1	0	2
1	0	0	2	0
1	0	2	0	1
0	2	0	0	1
2	0	1	1	0

4 Colours
3	2	1	1	0
2	1	3	1	2
1	3	1	0	0
1	1	0	1	1
0	2	0	1	1

5 Colours
3	3	4	0	1
3	4	2	4	3
4	2	0	0	1
0	4	0	4	0
1	3	1	0	4

6-by-6

Black and White
1	0	1	1	0	1
0	1	1	1	1	0
1	1	1	1	1	1
1	1	1	1	1	1
0	1	1	1	1	0
1	0	1	1	0	1

3 Colours
0	1	0	0	1	0
1	1	1	1	1	1
0	1	2	2	1	0
0	1	2	2	1	0
1	1	1	1	1	1
0	1	0	0	1	0

4 Colours
3	2	1	1	2	3
2	1	3	3	1	2
1	3	3	3	3	1
1	3	3	3	3	1
2	1	3	3	1	2
3	2	1	1	2	3

5 Colours
2	1	4	4	1	2
1	2	0	0	2	1
4	0	3	3	0	4
4	0	3	3	0	4
1	2	0	0	2	1
2	1	4	4	1	2

7-by-7

Black and White
1	1	0	1	0	1	1
1	1	1	0	1	1	1
0	1	1	0	1	1	0
1	0	0	1	0	0	1
0	1	1	0	1	1	0
1	1	1	0	1	1	1
1	1	0	1	0	1	1

3 Colours
0	1	2	0	2	1	0
1	2	2	1	2	2	1
2	2	1	0	1	2	2
0	1	0	2	0	1	0
2	2	1	0	1	2	2
1	2	2	1	2	2	1
0	1	2	0	2	1	0

4 Colours
1	1	2	3	2	1	1
1	3	1	0	1	3	1
2	1	1	2	1	1	2
3	0	2	3	2	0	3
2	1	1	2	1	1	2
1	3	1	0	1	3	1
1	1	2	3	2	1	1

5 Colours
1	4	4	3	4	4	1
4	0	3	3	3	0	4
4	3	4	2	4	3	4
3	3	2	1	2	3	3
4	3	4	2	4	3	4
4	0	3	3	3	0	4
1	4	4	3	4	4	1

Poggle, the solutions

2006-05-20T15:14:00.000-05:00

One interesting point is that there is only ONE solution for each of the 3-by-3 Poggle variants. For the 4-by-4 Poggle versions, quite a few more.
The 4-by-4 Poggle game's linear algebra solutions required that two or more buttons be completely specified before the entire solution could be show. I did re-discover a solution for this version that I had first found back when I was first putting this program together. (A "d'oh!" type solution you will see when it is described.)

For the 3-by-3 Poggle puzzles;

2 Colours
1	0	1
0	1	0
1	0	1

3 Colours
0	1	0
1	1	1
0	1	0

4 Colours
3	2	3
2	3	2
3	2	3

5 Colours
1	4	1
4	3	4
1	4	1

For the 4-by-4 Poggle version, consider the following. There are location on any Poggle board that toggle EXACTLY 4 buttons. Given that the 4-by-4 Poggle board has 16 button, only 4 buttons should be pressed to cover the entire Poggle board. And here they are.

0	0	X	0
X	0	0	0
0	0	0	X
0	X	0	0

and its mirror image

0	X	0	0
0	0	0	X
X	0	0	0
0	0	X	0

. See what was meant by this solution being a 'kick yourself' moment for not seeing it immediately?

Poggle, Revisited II

2006-05-18T19:50:00.000-05:00

You know you're in trouble when one find statements similar to "... which proves that some initial states are insolvable." (My emphasis.) The question becomes, how does one find out this difference?

In "Adventures in Groups Theory", David Joyner points to a post by D. Rusin. In it, one Carsten Haese lays out the solution to a similar game that can be applied to Poggle. I will attempt to reproduce it in this post.

Short form: convert the game to linear algebraic form and solve. Not-so short form: stock up on asprin.

Think of Poggle as a state machine with; a internal state (here, the buttons that are light), an input alphabet (the buttons), an output alphabet (the lights), an internal trasition table (the new internal state, given a specified internal state and the input), and an output table (given an internal state and an input, the output). As the output, input and internal state can be folded into one set and the tables can be considered as one, there are only two items that need to be looked at.

The state can be represented by a one-dimensional vector that is n-squared elements long. Think of this vector representing the Poggle board's display layed out row by row (from top to bottom).

Now to build the transition table. The size of the table will be n-squared by n-squared elements. The building blocks cosist of;
the Identity Matrix (size n-by-n),
the Zero Matrix (size n-by-n), and

1	1	0	..	0	0
1	1	1	..	0	0
0	1	1	..	0	0
..
0	0	0	..	1	1

(size n-by-n).
The construction of the B matrix is placing 1's in the main diagonal of the n-by-n matrix and in the diagonals above and below it. 0's are placed every where else.

The transition matrix is formed

B	1	0	..	0	0
1	B	1	..	0	0
0	1	B	..	0	0
..
0	0	0	..	1	B

For instance the 3-by-3 Poggle board's transition matrix is;

1	1	0	1	0	0	0	0	0
1	1	1	0	1	0	0	0	0
0	1	1	0	0	1	0	0	0
1	0	0	1	1	0	1	0	0
0	1	0	1	1	1	0	1	0
0	0	1	0	1	1	0	0	1
0	0	0	1	0	0	1	1	0
0	0	0	0	1	0	1	1	1
0	0	0	0	0	1	0	1	1

For Poggle the solution can be foudn with the linear equation;
(A x = s0) mod y.
where s0 is the starting vector (a 1 dimensional vector containing n-squared 1's for Poggle), and x is the vector containing the buttons to input. The modulus y is simply the total number of colours that the program cycles through.

Using {a,b,c,d,e,f,g,h,i} to denote the solution vector, the 3-by-3 Pobble board can be solved with the solution of;
a + b + d = 1 mod y,
a + b + c + e = 1 mod y,
b + c + f = 1 mod y,
a + d + e + g = 1 mod y,
b + d + e + f + h = 1 mod y,
c + e + f + i = 1 mod y,
d + g + h = 1 mod y,
e + g + h + i = 1 mod y,
f + h + i = 1 mod y.

For y=2 it is easy to see that {1,0,1,0,1,0,1,0,1} is the solution.

Programming Query

2006-05-17T22:04:00.000-05:00

When programming (and this is top-down, caller-to-callee programming) does one; program a function call before writting the function? program a function stub with a bogus and/or error return so that the program compiles? or, write a function stub and include an assert or otherwise alert the person running the program of the missing function?

Kono, some changes

2006-05-16T21:14:00.000-05:00

OK, one added class is a Singleton class to check moves against rules of the game. This will (not in this game but in others) reduce the CBoard class to checking if cell X and cell Y are, in fact, neighbours.
The other class that will be added is a display class that will show either al possible moves or possible moves that were graded into best to worst.

One big change in this program is that the game can be saved. A short-cut toward this is to derive the CGame and the COwner classes from CObject to take advantage of the Serialize function.

Kono, the rule of the game

2006-05-15T22:02:00.000-05:00

The playing field is a 4 by 4 square. Each player has 8 pieces starting on opposing halves of the playing field.

Pieces can move one place either vertically or horizontally.

Pieces capture by jumping over one friendly piece onto an opposing piece, again either vertically or horizontally.

One side wins when the other side cannot move, either by blocking the other side's pieces or by capturing all of the opposing pieces.

The next game

2006-05-14T00:00:00.000-05:00

One can almost flip a coin between Alquerque and 'Four Field' Kono, remove all the opposing pieces or keep the pieces from moving. Well, considering that the popular game to program is Alquerqeu, I will go with Kono. The mechanism is pretty much the same if one elides past the huff rule and the capture method.
I could have gone with Alquerque's cousin, Fanorona. But the capture rules are not exactly clear.

I will present 'Fox and Geese' and Four Handed Shaturanga (an early form of chess) later.

Mu Torere, Improvements

2006-05-13T23:40:00.000-05:00

Step 21.

Well one thing that can be added is accessibility, again. In other words, adjusting the colours and enabling keybourd-only input.

Another improvement is to change the art-work. As was said earlier another background that can be used is an eight spoked wheel, with or without the rim. A bitmap can be used for the background too. Use your imagination, is the playing field scratched on stone? scribbled into sand? or in-laid in wood? 3-D sprites can also be used for the playing pieces.

Other improvements range from optimizing the program to adding more moves to the 'AI's' look-ahead.

Good Luck.

Mu Torere, the Final test

2006-05-11T16:50:00.000-05:00

Step 19.
Like last time, the program needs to be checked for syntax errors at each of the previous steps.

For Q & A (re-test all the steps each time corrections are needed);

A - Run the 'Mu Torere' program. Examine the menu, but do not try anything. Then exit the program.
Did it start cleanly? Was the menu correct? Was the program displaying correctly? Did the program exit cleanly?

B - Run the program. Select and then re-select the Colour Legend menu item. Select the 'Change User Colour' menu item and change the colour. Do the same with the 'Change Computer Colour' menu item. Select each of the pre-set AI level of effort menu items. Select the Custom AI Level menu item and change the value to the neighbourhood ( + / - the EPSILON that you picked ) of each pre-set level, selecting 'OK' each time and re-selecting the Custom AI Level dialog to select the next value. Exit the program and then re-start it. Examine the menu items again.
Did the Colour Legend display toggle (appear / disappear) along with the selection? Was the Colour Legend menu item checked at the same time as the Legend was displayed and unchecked when the Legend was NOT displayed? Did the colours of the proper pieces change as new colours were selected and were those colours the ones selected? Did the Colour Legend change as well and show the right colours?
Did the AI Level menu items check and uncheck as different levels were selected? Did the check mark follow the selection? Did the changing the AI Level with the Custom AI Level dialog do anything? Did the checkmark show when the custom value was in the neighbourhood?
When re-starting the program, did the colours match those selected during the last run? Does the Custom AI value match that from the last run?
And does the program start and exit cleanly?

C - Run the program. Set the AI level of effort to 'Off' or set the Custom AI Level to 0. Select points on; the Desktop, the program caption, the program's background, the program's empty location, all pieces owned by the Computer, each of the User owned pieces that CANNOT be moved legally (one of the middle ones), a User piece that CAN be moved legally. After the Computer moves, select points on; the program's background, the program's new empty location, all of the Computer's pieces, all of the User pieces that CANNOT legally move, and then the User piece that CAN legally move. Select the 'New' menu item and then exit the program.

Did the program move the expected legal pieces as expected and ONLY when a legal USER piece was selected? Was this behaviour repeated with the new positions? Did selecting 'New' reset the program to the initial positions?
Again, did the program start and exit cleanly?

D - Start the program again and play a few rounds. If the choice was made to NOT let the AI level of effort change after starting play, test that this is so. Continue until one side or the other wins. Try selected various points on the program to see if the program continues to move pieces. Select 'New' and continue playing with the AI 'Off' until the side that did not win, wins.

Did selecting a new AI level work? Did the winning side messages display correctly? Did the program stop playing at this point?
Again, did the program start and exit cleanly?

Step 20.
Re compile the program as 'Release'. Make sure that all options that appear under 'Debug' compiling are no longer availible.

Mu Torere, the rest of the story

2006-05-10T20:20:00.000-05:00

Step 17.
Not much else to do at this point.

Just add the event handlers for the AI menu items, and code the relevant values into them. The only vit that I would recommend is to use some sort of variance value when coding the OnUpdateXXX() handlers. This way when the user pick a custom AI level-of-effort that is in the neighbourhood of the program's idea of the level, the right menu item is checked. For example;

pCmdUI->SetCheck(abs(((CMuTorereApp*)AfxGetApp())->getAI() - CAILevel::LOW) < CAILevel::EPSILON ? 1 : 0);

I used CAILevel::EPSILON with the value of 3 to determine how close user chosen values had to be.

Step 18.
The registry stuff was much the same as that for the Poggle project. So go to this page to review.

Mu Torere, setting the AI

2006-05-09T21:32:00.000-05:00

Step 16.
The dialog for the custom AI 'Level-of-Effort' is fairly simple. All the special functionality works on a dialog box that contains a horizontal scrollbar, a couple of static texts to mark the high and low end of the scrollbar, an edit box and the 'OK' and 'Cancel' buttons. The only functions that need to be explained are the InitDialog(), the OnHScroll() and the OnEnChangeEdit1() (or what ever the edit box is id'ed in your program) functions.
Using MS's IDE one should associate a variable with the edit box.

Oh yes, there are a few named constants to specify the AI levels for the program. As long as 0 is used for the Off end of the scale and around 95 for High, it really does not matter what value is used for the Low and Middle of the scale (example, 25 and 66 respectively). Remember that the program uses the randomMove() function whenever the random value (mod 100) is GREATER than the AI level choosen.

On dialog initialization;

BOOL CAILevel::OnInitDialog()

Get a CEdit pointer the the dialog's Edit box.
Get a CScrollbar pointer to the dialog's horizontal scrollbar.

Get the text associated with the edit box. (Part of the Data Exchange process.)
Re-format the text as integer. (Use _tstoi() for the UNICODE enabled programs.)

Set the lower and upper limits of the scrollbar to 0 and 100 resp.
Set the scrollbar position to the integer value retrieved from the edit box. (As this is an initialization, the scrollbar will not need redrawing.)

On changes of the edit box;

void CAILevel::OnEnChangeEdit1()

Get a CEdit pointer the the dialog's Edit box.
Get a CScrollbar pointer to the dialog's horizontal scrollbar.

Get the text associated with the edit box. (Part of the Data Exchange process.)
Re-format the text as integer. (Use _tstoi() for the UNICODE enabled programs.)

Set the scrollbar position to the integer value retrieved from the edit box.

to reflect the changes of the scrollbar in the edit bxo (and the variable that is retrievable);

void CAILevel::OnHScroll(UINT nSBCode, UINT nPos, CScrollBar* pScrollBar)

Get the lowest limit, the highest limit and the current position of the scrollbar.

Given how the scrollbar position is changing (given by nSBCode),change the scrollbar position as appropriate.

Get the CEdit pointer the edit box.
Set the edit box's text to the value of the scrollbar's current position.

Mu Torere AI II

2006-05-07T19:59:00.000-05:00

Step 15.

Two new steps and a modification for the Move Generator class and a new function and a modification for the Game class.

The modification is for the CMoveGenerator's getMove function;

int CMoveGenerator::getMove(const int& aiL)

Pre-Condition:
That aiL is between 0% and 100%, inclusive.

If a random value (mod 100) is greater than aiL, use the randomMove(COwner::playC) function.
Otherwise use the aiMove(COwner::playC) function.

(The move returned should NOT equal CBoard::OFF_BOARD.)

Return the move.

Instead of constructing the class instance with the value to use for the AI effort, we are just going to submit the value when getting the Computer's move. No need to store anything that way.

The 'AI';

int CMoveGenerator::aiMove(const COwner::Player& tag)

Pre-Condition:
That tag is either COwner::playC or COwner::playU.

Create two COwner::NUM_PIECES-sized integer arrays.

Initialize both arrays with the MoveGenerator's thisGame's buildMove() for player tag.
(The returned caount should be within limits.)

Use evaluateMoves() to assign values.
(The returned array should NOT equal NULL.)

Return a move given that;
If any move was assigned a 1 (the player tag won) has the highest priority.
Otherwise, pick a random move with the value of 0 (no-one won).
Any moves assigned -1 are to be ignored.

And, yes, only one array to store the moves could be used here. The thought in my so-called mind was that the issue was where the next move needs to be considered as well, needing a spare array.

Evaluating the move;

void CMoveGenerator::evaluateMoves(const COwner::Player& forTag, const CGame& startG, int* moves)

Pre-Condition:
That tag is either COwner::playC or COwner::playU.
That moves is NOT NULL.

Create an integer array with COwner::NUM_PIECES with elements.
Assign a COwner::Player variable to the opposing player.

For each move in moves;
{
If move equals CBoard::OFF_BOARD,
Re-assign element to and go to next element.

Create a temporary CGame variable with thisGame's values.
Apply this move to the temporary CGame.

Did forTag win?
{
Assign +1 to the element.
}
Else,
{
Use the created move array to store the opponent's moves given the applied move. (The program has already tested the applied move to see if forTag won, now check the opposing side.)

If any of the opposing move is a winner,
{
Assign -1 to this moves element.
}
Else,
{
Assign 0 to this moves element.
}
}
}

Creating the move array before the loop gets the possible error condition out of the way.

The new function in CGame is;

bool CGame::applyMove(const COwner::Player& tag, const int& moveFrom)

Pre-Condition:
That tag is either COwner::playC or COwner::playU.
That moveFrom is with CBoard bounds.
That moveFrom is NOT equals emptyLoc.

Pre-Condition:

Apply Move(tag,moveTag)

The modification in CGame is in the computerMove() function, one just needs to give the CMoveGenerator's getMove() function the specified AI level.

Mu Torere, Undo II

2006-05-05T15:07:00.000-05:00

Step 14.
All of the functions in CUndoQueue are pass-through. One way looking at this is to consider the Interface - Implementation Pattern. One class to give the using program something to handle, and the other class actually does the work but is 'hidden' from the program. One distinct advantage is that once the Interface part is stable, any functional changes in the Implementation will not cause the rest of the program to be re-compiled.

Step 15.
There are only a few places that need changing in the Document class to add the undo interface. Of course the menu item 'Undo' needs to have event handlers for the OnUndo and the OnUpdateUndo events. OnUndo just calls the undo() function of the queue, apply it to the game and update the program's view. The OnUpdateUndo calls the queue's canUndo() function and uses it to enable or disable the 'Undo' menu item.

The undo queue, a pointer, is created in the Document's constructor using the value stored in the App class to determine the number of element in the queue.
The queue is initialized then in the Document's OnNewDocument. At the risk of being obvious, this means that each new game starts with an empty undo queue.

As for the mechanism of storing the game in the queue, it will proceed along the following lines;

The current game is stored in a temporary CGame variable.
The move function of CGame, selectMove() is called.
ONLY IF a valid move was done is the CGame value in the temporary variable stored in the queue. Note that valid move will include cases were the Computer or the User won.

Mu Torere, Undo

2006-05-03T14:23:00.000-05:00

Disclaimer: Before going on to describing the Undo functionality, here is the reason for the program using a base and derived class and for storing the old information as a CGame object.
It looked like a good idea at the time, OK?
Seriously though, the reasoning for the Queue class from the undo calls was to allow updating the Queue class for further functionality in the future and to avoid the temptation of putting queue functionality in the undo calls.
As for using an entire CGame object, well consider that a placeholder. To minimize the run-time footprint one can extract the bare minimum data needed to represent the game and then apply this data later. But that can be left for future updates.

Step 13.
The Base Queue.
The CCircleQueue class uses several named constants to improve program readability.
First off are the upper and lower limits to size of the queue. Now it seems to make very little sense to worry about limits while talking about a static queue. Except, suppose the decision on the queue size was re-considered and a change was requested. In this program the change can be implemented in the registry and avoids the re-compiling that a hard-coded number would need.
While the upper limit is pretty much arbitrary, the lower limit of 2 was chosen with the view to keep the special cases within reason.

The data structure is relatively simple; one pointer going forward (into the future), one pointer going back (back to the past), and one pointer to the data. The class uses two pointers to this data structure for its purposes.

The constructor simply sets the structure pointers, topPoint and stopPoint, to NULL and sets the bookkeeping integer, qSize, to 0. The queue will be created seperately. The destructor uses a seperate function to actually de-allocate the queue.

void CCircleQueue::Release(void)

Pre-Conditions:
That topPoint is NOT NULL.
That topPoint->forward is NOT NULL.

While a temp pointer is NOT equal to topPoint AND is NOT NULL,
{
Copy the temp pointer to another pointer for deletion.
Move the temp pointer over to temp->forward.

Process the copied pointer by deleting its data pointer if NOT NULL and by deleting this pointer.
}

Delete topPoint->data, if NOT NULL.
Delete topPoint.

Finally, set stopPoint to NULL

The Queue creation begins with;

bool CCircleQueue::newQueue(const int& levels)

Pre-Conditions:
That levels is between CCircleQueue::Q_LLIMIT and CCircleQueue::Q_ULIMIT inclusively.

Assign an integer variable, counter, to levels (or the value of levels that is within bounds).

Create 2 elements for the initial Queue using topPoint and a temporary pointer. If this allocation fails, return false.
Assign the forward and back pointers.

Assign CCircleQueue::Q_LLIMIT to qSize.
While qSize is less than counter AND less than or equal to CCircleQueue::Q_ULIMIT,
Add a queue element using growOne(). If this fails at any point( NOT equal to CCircleQueue::QGROW_GOOD), break out of loop. (qSize is incremented within growOne().)

In any case, return true.

The function used for growing the Queue builds on an already initialized queue. At this time the only point at which the queue will grow is from topPoint (which is known) and will only use the forward structure pointer. This means that (if the queue is already in use and has data) the historical data structure can still be reached.

CCircleQueue::qReport CCircleQueue::growOne(const CCircleQueue::qPoint& addTo)

Pre-Conditions:
That topPoint is NOT NULL.
That topPoint->forward is NOT NULL.
That addTo equals CCircleQueue::QPOINT_FIRST.

Attempt to allocate a queue element. Set its data pointer to NULL.

Insert this element into the queue forward of topPoint.

Return CCircle::QGROW_GOOD.

There are two distinct error returns from this function. CCircleQueue::Q_ERROR is used on the event of a mal-formed queue, while CCircleQueue::QGROW_FAIL reports a failure (possible memory shortage) in adding additional queue elements.

The queue resetting function is as follows;

void CCircleQueue::resetQueue(void)

Pre-Conditions:
That topPoint is NOT NULL.
That qSize is between CCircleQueue::Q_LLIMIT and CCircleQueue::Q_ULIMIT inclusive.

A while loop is used to visit each element in the queue, delete any allocated CGame pointer and set those pointers to NULL.
NOTE:If the loop eve finds that the next element in the queue is missing (NULL), the program SHOULD exit.

Finally, stopPoint is set to NULL.

The program does use a 'called-out-of-order' condition statment before the preconditions, if qSize is less than CCircleQueue::Q_LLIMIT then the create Queue function is called with the specification of CCircleQueue::Q_LLIMIT.

Both the push() and the pop() functions are overloaded. But the basic push() function is;

bool CCircleQueue::push(const CGame& data, const CCircleQueue::qPoint& addTo)

Pre-Conditions:
That topPoint is NOT NULL.
That qSize is between CCircleQueue::Q_LLIMIT and CCircleQueue::Q_ULIMIT inclusive.
That addTo equals CCircleQueue::QPOINT_FIRST.

Again a 'called-out-of-order' condition statment before the preconditions, if qSize is less than CCircleQueue::Q_LLIMIT then the create Queue function is called with the specification of CCircleQueue::Q_LLIMIT.

Attempt to allocate a new CGame pointer for the queue. Set this allocation to data.

If this is the very first data pointer for the queue (topPoint->data == NULL),
{
(stopPoint should be NULL at this time.)

Set topPoint->data to the new CGame allocated pointer.
Set stopPoint to topPoint.
}
Else if the queue is full up (the pointer forward of topPoint is stopPoint),
{
(There is a valid pointer for stopPoint->forward.)

Set topPoint to stopPoint.
Move stopPoint to stopPoint->forward.

Delete the CGame allocation (if it exists) in the current topPoint->data.
Set topPoint->data to the new CGame allocated pointer.
}
Otherwise,
{
(stopPoint should be a valid pointer.)
(topPoint->forward should exist.)

Move topPoint to topPoint->forward.
Delete the CGame allocation (if it exists) in the current topPoint->data.
Set topPoint->data to the new CGame allocated pointer.
}
After all that return true.

And the pop() function is;

void CCircleQueue::pop(CGame& data, const CCircleQueue::qPoint& getFrom)

Pre-Conditions:
That topPoint is NOT NULL.
That qSize is between CCircleQueue::Q_LLIMIT and CCircleQueue::Q_ULIMIT inclusive.
That getFrom equals CCircleQueue::QPOINT_FIRST.

If stopPoint is NULL, there is nothing left to pop.

If this is the last one in the queue (topPoint == stopPoint),
{
(topPoint->data should exist.)

Set returned data to topPoint->data.
Delete topPoint->data and set it to NULL.

Set stopPoint to NULL.
}
Else,
{
(topPoint->data should exist.)
(topPoint->back should exist.)

Set returned data to topPoint->data.
Delete topPoint->data and set it to NULL.

Move topPoint to topPoint->back.
}

The test for popping data is check if topPoint is NOT NULL AND that stopPoint is NOT NULL.

Mu Torere, a digression

2006-04-30T17:10:00.000-05:00

In this entry the number of possible combinations of playing pieces will be determined. What will be done is to find the Generating Function given by Burnside's Lemma, which is a special case of Polya's enumeration theorem. Before anyone asks, the only thing that I could determine about Generating Functions is that they are a way to encode sequences (and not a decent how-to in the description either.) Examples are better.

First off, Permutation Groups are collection of permutaion operations (element swapping) on the elements of a set. They can be denoted by cycle decompositions of the swaps being made. For instance;

A 2-element swap on a 6 element Set
123456
153426
=
(1)(3)(4)(6)(25)

has 4 1-element cycles and 1 2-element cycle
While

Rotation on the same 6 element Set
123456
234561
=
(123456)

ha only 1 cycle of 6 elements.

Polya's enumeration theorem uses equivalent decompositions, i.e. (1)(2)(3)(4)(56) and (1)(3)(4)(5)(26) having 4 1 elements cycles and 1 2 element cycles are equivalent, to
create the generating function. Each permutation operation is weighted according to the number of equivalents and then the average is taken.
As an example the number of distinct ways to add edges to a 3 vertice graph can be found as follows. The permutations on a 3 element set is (second example);
[1 2 3] = (1)(2)(3)
[1 3 2] = (1)(2 3)
[2 1 3] = (1 2)(3)
[2 3 1] = (1 2 3)
[3 1 2] = (1 3 2)
[3 2 1] = (1 3)(2)
Which creates the function; 1/6 ( x1^3 + 3 a1 a2 + 2 a3 ). The translation is that there is one equivalent of 1-cycle * 1-cycle * 1-cycle plus three equivalents of 1-cycle * 2-cycle plus two of 3-cycle operations.
The generating function is then created using (z+1), where z denotes an edge and 1 denotes no edge. This produces ((z+1)^3 +3 (z+1)(z^2+1)+(z^3+1))/6.
Or rather, z^3 + z^2 + z^1 + 1. Which can be read as there is only one way to add three edges to the graph, only one way to add 2 edges, only one way to add 1 edge and only one way to add no edges. Only considering rotations will procude the same results.

For Mu Torere, only the rotation permutations will be used. This allows us to equate, for instance, all swaps that are 2 places apart. Ignoring teh central location, means that only 8 locations need be considered. From this, the permutaion groups are;
[12345678] = (1)(2)(3)(4)(5)(6)(7)(8)
[23456781] = (12345678)
[34567812] = (1357)(2468)
[45678123] = (14725836)
[56781234] = (15)(26)(37)(48)
[67812345] = (16385274)
[78123456] = (1753)(1864)
[81234567] = (18765432)
Being 4 permutations 8-element cycles, 1 permutation group of 1-element cycles, 1 permutation group of 2-element cycles, and 2 groups of 4-element cycles. This gives the preliminary function of 1/8 (g1^8 + g2^4 + 2 g4^2 + 4 g8).
For the generating function, we will use (c+u+1) where c will denote a piece owned by the Computer, u will denote one owned by the User, and 1 will be a empty location. This creates the generating function ((c+u+1)^8 + (c^2+u^2+1)^4 + 2 (c^4+u^4+1)^2 + 4(c^8+u^8+1))/8.

HomeWork: What terms will we need to examine? And what will be final number?

Update:
The terms to examine are C^4 U^4, C^4 U^3, and C^3 U^4.
The numbers are 10, 35, and 35, which totals 80.

Mu Torere AI

2006-04-29T16:31:00.000-05:00

While I recover the Undo functionality, I will go over the background of the program's AI in the meanwhile.

Essentially, the program can use one of 3 kinds of decision making routines to simulate a proper AI. (This is in addition to the random move routine.)
The first is the basic tree graph to layout what move lead to which moves and an evaluation of that move. For this version I will only evaluate the NEXT Computer's move and the following User's move (one ply each) for the winning move.
Another is to use pattern recognition. The program can check the current positions of the playing pieces and find out if a winning move is possible.
The related routine (the third one) is to use a state machine. The program will not need to decipher the game to find the proper state, but the current state of the game will need to be stored to determine the next game state. The trade-offs are pretty much obvious, program complexity (deciphering the game to a state value) versus footprint (storing the current state and the next-state table.)

The pattern matching and the state machine routines are possible because of the limited distinct positions of the playing pieces. (At least the computer can calculate them).

Poggle update

2006-04-29T15:59:00.000-05:00

OK, I found the references I wanted to prove that Poggle can be solved. It seems that this game was marketed under the name Merlin's Machine, Lights Out and Orbix. The obly difference it seems is that the neighbourhood of cells along the edge and corners of the game wrapp around to the other side. (Which should suggest ideas.)
The only issue is that this kind of problem has only been looked at using wrap-around neighbourhoods.

SoI need to apply a little mental knuckle-work.

Now I just need to read the chapter.

Mu Torere, the AI II

2006-04-28T12:04:00.000-05:00

Step 12.
Given all the de-allocation problems with CMoveGenerator as a Singleton, I decided to toss it over and just use a pointer within the Computer's move function (see update in last step.)

So there are only three functions that need to be constructed at this time, in addition to the constructor (which preps the RNG.) The public functions are the getMove(void) returning the CBoard location the Computer moves to and setGame(const CGame* data). The private function, randomMove(const COwner::Player& tag), just grabs an availible move at random. The decision tree part for the AI will be added later. This is enough to start play testing the program.

The only thing really unusual about the comstructor is that it requires an integer. This will be for the AI part.

The Constructor
CMoveGenerator::CMoveGenerator(const int& aiL)
Enforce limits on the chosen AI level. If debugging, seed Random Number Generator with specific value. Otherwise, use the value returned from time() as the seed.

In case this is new, the standard headers for doing this are time.h, math.h, and stdlib.h.

Updating the CMoveGenerator instance with the current game is straight forward.

void CMoveGenerator::setGame(const CGame* aGame)

Pre-Condition:
That aGame is valid.

Set private CGame variable to COPY aGame.

This point is one that is debatable. Just how much data is needed to determine the next move? Here the costs on system resources from multiple copies of the CGame object were balanced against the straight-forwardness of only one operation needed to list the possible moves.

The interface of getMove() allows the program to hide all the messy details of actually determing the next move.

int CMoveGenerator::getMove(void)

Call the private move generator for the Computer's move.

Post-Condition:
That the returned move is valid.

The only move generator right now is purely random (as much as a ccomputer can get anyway.)

int CMoveGenerator::randomMove(const COwner::Player& tag)

Allocate memory to store the possible moves.

Get the possible moves based on the store data.
Perform reality checks on data. (Not much to this one. The only biggie is the possiblity that this function is called when there are no moves left.)

Get a random possible move. I used a while loop (with an emergency limiter) to extract a non-CBoard::OFF_BOARD value.

Clean-up and return the move.

Complaint, MS de-allocation.

2006-04-24T20:36:00.000-05:00

Every once in a while the Microsoft compiler will complain when de-allocating memory. It seems that the guard space allocated along with that allocated by new has been altered. From comments within the provided code, the only other explaination for this is that the de-allocation is being done on the 'wrong' heap.

Solution? If your program breaks when de-allocating the same bit of memory over and over again (And I am NOT talking memory leaks.), the best work-around that I have found is to allocate an extra amount of memory for that 'problem' allocation to keep everyone happy.

Mu Torere, moving the pieces II

2006-04-23T20:47:00.000-05:00

Step 11.
Now the User and the Computer needs to move. An enumerated type lSelection needs to be created with Invalid, Valid, ComputerWon, and UserWon as values to allow for CGame to signal the Document.
AND, might as well do this now, a boolean flag needs to be added to the CGame class to denote that there are no more moves to do. This flag will need to be added to the various copying functions.

For the User the CGame adds the function

CGame::lSelection CGame::selectMove(const CPoint& point)

If the finished flag is true, then return a CGame::Invalid signal.

Get a pointer to the CBoard instance.
If this pointer is NULL, return CGame::Invalid.

If there is no valid selection from CBoard's whatIndex(), return CGame Invalid.
Otherwise,
Test the move. If not possible to move, return CGame::Invalid.
If moving is not possible, return CGame::Invalid.

If the User won, set the finished flag to true and return CGame::UserWon.

Get the move from the computer Move function.
ASSERT that this move is not CBoard::OFF_BOARD.

Move the Computer's piece.
ASSERT that this Move was possible.

If the Computer won, set the finished flag to true and return CGame::ComputerWon.

If nothing else, CGame::Valid.

I should point out the issue with the move. (As if you had not noticed.) If the User's move work but the Computer's did not, at this poin the only reasonable action is to exit the program, preffereably with some message to the user. Even then there must be a better way to handle this situation.
The only thing that I can think of is to use the Undo functionality to restore the game, and try again. (Either ask the user to re-do the move, or to loop a few times and THEN ask the user.)

The function for testing who won;

COwner::Player CGame::whoWon(void) const

If the emptyLoc is the center location (8), return COwner::playN.

Get the COwner::Player value of the side that owns the center.

Switch on the value in emptyLoc,
{
If either neighbouring array element (element 7 is next to element 0) is owned by the same side of the center, return that COwner::Player value.
}

Otherwise, just return COnwer::playN.

The function for testing the move;

bool CGame::canMove(const COwner::Player& tag, const int& fromLoc)const

Get the pointer to the CBoard instance.
Pre-Conditions:
That tag is either COwner::playC or COwner::playU.
That fromLoc is greater than or equal to 0 and less than CBoard::NUM_PLACES.
And that fromLoc is NOT equal to emptyLoc.

Get a pointer to the CBoard instance.

If the move from fromLoc to emptyLoc is NOT possible, return false.

Get the COwner::Player value of the opposing side.

If emptyLoc is the center location, test to see if one and / or the other neighbour of fromLoc is owned by the opposing side.
If this is the case, return true.
Otherwise, return false.

And if emptyLoc is NOT the center, return true.

And the function for the computer's move;

int CGame::computerMove(void) const

~~Get a pointer to the CMoveGenerator instance.~~
Allocate a CMoveGenerator instance.
Test pointer to see if it is valid.

Setup the MoveGenerator instance with the current CGame.

Get the move.
ASSERT that the move will not be CBoard::OFF_BOARD. (Actually done AFTER releasing the CMoveGenerator instance.)

~~Release~~ Delete the CMoveGenerator instance.

Return the move

Update: Changed CMoveGenerator instance from Singleton instance to straight pointer allocation.

Mu Torere, moving the pieces

2006-04-22T20:01:00.000-05:00

(I neglected to post this before going on about the AI.)

There are two classes that have information that changes because pieces move. I will cover the user interaction part in the next post.

For the COwner class;

bool COwner::Move(const int& fromL, const int& toL)

Pre-Conditions:
That fromL is greater than 0 and less than CBoard::NUM_PLACES.
That toL is greater than 0 and less than CBoard::NUM_PLACES.
And that fromL is NOT equal to toL.

Get the element in Board's loc array that has the same value as fromL. Return false if this fails.

Then assign toL to this element.
Return true.

And for the CGame class;

bool CGame::Move(const COwner::Player& tag, const int& fromLoc)

Pre-Conditions:
That tag is either COwner::playC or COwner::playU.
That fromLoc is greater than 0 and less than CBoard::NUM_PLACES.
And that fromLoc is NOT equal to emptyLoc.

If tag was COwner::playC
{
If the Computer's Move routine succeeds
{
Change the owned array as appropriate.
Assign fromLoc to emptyLoc.

return true.
}
}
else
{
If the User's Move routine succeeds
{
Change the owned array as appropriate.
Assign fromLoc to emptyLoc.

return true.
}
}

If the program gets this far return false.

Mu Torere, the AI!

2006-04-20T19:32:00.000-05:00

Now we are cooking with gas! The only thing is that this will not be that elaborate, and for that matter the AI will not much more that an Random Number Generator in order to check the rest of hte system. But here goes.

First a few functions are needed to establish the ground work, specifically copy contructors and the like.
While 'friend' classes and functions could have been used, adding a CGame object or pointer directly to the CMoveGenerator allows for the contruction of building hypothetical moves, e.g. 'What Computer moves are availible if the User moved this way?' (And yeah, I do hear the eye-balls rolling at this point.)

So, for the COwner and CGame class the copy constructor looks like;

The Copy Constructor
CXxxxx::CXxxxx(const CXxxxx& obj) : Copy initialization list
For each element in array, copy obj.array[element]

The '=' operator function works as follows;

The Equal Operator
const CXxxxx& CXxxxx::operator =(const CXxxxx &obj)
If this is NOT equal the address of obj (&obj)then { Copy obj's data members. For each element in array, copy obj.array[element] } In anycase, return the object reffered to by this. (*this)

I really recommend reading a good book on C++ to find out WHY operator=() is declared in this manner.

And finally, a kluge to copy from pointers to objects for the CGame class. I went through a bit of hoop-jumping and pointer manipulation and massaging before settling on this to extract pointer data members to copy to temporary objects. (But then I do not know the complete ins-and-outs of C++.) Much like the operator=() function the only difference is that there is no need to return the object to which this reffers;

void setGame(CGame* aGame);
void setGame(const CGame* aGame); // overloaded to copy-from this

If this is NOT equal the address of aGame (&aGame)then
{
Copy aGame's data members.

For each element in array, copy aGame->array[element]
}

Note: that there is NO data validation. While this can be added, it might be better to do that in a separate step.

Mu Torere, the Stone Singleton

2006-04-19T21:19:00.000-05:00

Step 8.
A basic Singleton instance, all that is required of this class is to draw the playing pieces.
Why isn't this folded in with one of the other classes? The basic reason is that this class can be considered a working stub class. If need be, a different drawing routine can be substituted to draw 3-D playing pieces. Or a Sprite class can be used instead. Or the user can decide.

For drawing;

void CStone::Draw(CDC* pDC, const COLORREF& res, const CRect& rect)

Create a 2-pixel wide pen with the colour of the menu text, usu. black.
Create a solid bruch with the provided colour, res.

Select the pen and the brush into the drawing context.
Draw an Ellipse contained by rect.
Select the old pen and old brush back into the drawing context.

Note that all the needed information for drawing the piece is provided. Nothing is stored in the CStone instance.

Mu Torere, the Owner class

2006-04-19T20:54:00.000-05:00

Step 9.
The COwner class has only 3 variable to track, and a couple of named constants. One variable res holds the colour for the pieces it manages, an integer array loc (with named constant NUM_PIECES) to store the location on the board, and a variable tagP indicating which side the object is on (using COwner's enumerated Player type).
A couple of in-line functions to get the CBoard and CStone instance are useful. The only in-line function that could be added is one setting the COwner object's colour. Just remember to check that the object has actually been set-up by looking for a proper value in tagP. (No need to colour an un-assigned COwner object.)

Aside from the drawing function, the only thing that needs adding is the set-up function for initalization and the reset function for new games.

The COwner constructor just initializes the class's variables to what are essentially don't-care / error values that will be corrected when the COwner objects are properly initialized. In this case, res and tagP are set to RGB(255,0,0) and COwner::playN, while all elements in loc are set to CBoard::OFF_BOARD.
All the destructor needs to do is to Release any CBoard and CStone instances.

The bare-bones void COwner::setUp(const COwner::Player& tag) just sets the COwner object's tagP variable (only if tag is COwner::playC or COwner::playU) and then calls the reSet() function.

The void COwner::reSet(void) initialization function does have a Pre-condition that the only tagP values are COwner::playC or COwner::playU. Aside from that, the loc array is now initalized for each side. As long as all pieces from the same side are adjoining, placement does not matter. In my program I initialized the User and Computer arrays so that the User had the two places on the left and the two places on the top of the playing field. (From all the examples that I have seen.) The center playing location remains empty.

For drawing;

void COwner::Draw(CDC* pDC)

PreConditions:
That pDC is not-NULL.
That the COwner object's tagP equals COwner::playC or COwner::playU.
That there is a valid (not-NULL) CBoard instance.
That there is a valid (not-NULL) CStone instance.

For each location in loc,
{
Get the board location's CRect.
DEBUG: Is the CRect not-empty (0,0,0,0)?
If the returned CRect is empty, skip this location.

Draw the CStone instance with the returned CRect and the COwner's res colour.
}

Step 10.
All that needs to be done to display the playing pieces is to;

A - Create private COwner objects in CGame for the Computer and the User.
B - Use the setUp() function for each object with the proper COwner::Player value for each.
C - Create an in-line function for CGame to set the colours for the COwner objects. My program set the colours for both COwner objects at the same time. You can try a different approach if you wish.
D - The CGame setColours() is called in the Document's constructor for the initial colour. The function is also called in each of the 'Change Colour' menu item actions.
E - Each COwner object is drawn after the CBoard instance in the CGame's drawing function.
F - (Optional.) A reset funtion can also be added to the CGame at this time, calling each of the COwner objects. This reset function is used in the Document's OnNewDocument(0 function.

Try running the program. The playing pieces should be of the colour that were specified, e.g. they should match the colours displayed in the CInfoDisplay legend. Also the pieces should be in the playing location that were programming in to the COwner reSet() function.

Mu Torere, changing colours

2006-04-18T21:27:00.000-05:00

Step 6.
Given that the program can display colours, might as well go ahead and show how to change those colours. But first, the menu

File	Settings		Help
New game	Undo		About Mu Torere...

Exit	Show Colour Legend

	Change Computer Colour...
	Change User Colour...

	AI Level	Off

		Low
		Medium
		High

		Custom AI Level...

Step 7.
On changing the colour in the Document;

void CMuTorereDoc::OnSettingsChangeXxxx()

Create CColorDialog object.

Set dialog flags.

dlg.m_cc.Flags |= CC_FULLOPEN | CC_RGBINIT;
dlg.m_cc.rgbResult = ((CMuTorereApp*)AfxGetApp())->getColourXxxx();

If the colour dialog returns IDOK.
{
Set the game's colours.
Set the application's Xxxx colour.

Update View with colour hint.
}

In the View, the Update View function is as follows;

void CMuTorereView::OnUpdate(CView* /*pSender*/, LPARAM lHint, CObject* /*pHint*/)

If lHint equals the Document's colour hint.
{
Set the colours in the CInfoDisplay instance.
}

In all cases, Invalidate the window to re-draw.

In my program I set both the User and the Computer colours at the same time. For efficiency, a different hint from the Document should be used for each colour change.

The addition to the View's Draw function is minor (done after the game is drawn);
If the application's m_Display is true, draw the CInfoDisplay instance.

The CinfoDisplay is set up in the View constructor;

Go to the first element in the CInfoDisplay instance.

Add _T("Computer") and the application's computer colour to the first element.
Add _T("User") and the application's user colour the next element.

Mu Torere, the Legend

2006-04-17T20:24:00.000-05:00

The sole reason for the InfoDisplay class is to show to the user which colour belongs to which player. In this program, the class is draw directly on the window, over-lapping the playing field. If I ever figure out a way to allow a program to close a child modeless window, I'll post it but for now this is it.

A Singleton class, CInfoDisplay contains the following as variables;

variable	inital value	comment
static CString *labels	NULL
static COLORREF *colours	NULL
static CPoint topLeft	CPoint(0,0)	for positioning
static int counter	0	for the iterator
static int numLabel	0

There are some named constants used for spacing included as well as a limit to the number of array elements.

The functions that will be used are static CInfoDisplay* getInstance(const int& count) and static void Release(void) for the pattern (Note that getInstance requires a parameter), void Draw(CDC* pDC), CSize getLabelSize(CDC* pDC) const, static void First(void) (to reset counter to 0), bool setInfo(const CString& sLabel, const COLORREF& rgbColour), and bool setRGB(const int& index, const COLORREF& rgb). Also note that the setRGB() function requires a index. I would have been better not to depend on such things for synchronization.

Since the labels and the colours are in dynamic arrays, the destructor can be used for the clean-up.

destructor
CInfoDisplay::~CInfoDisplay(void)
If labels is not-NULL, delete it. If colours is not-NULL, delete it.

The additional code in this class's getInstance involves creating the labels and colours arrays;

CInfoDisplay* CInfoDisplay::getInstance(const int& count)

Pre-condition;
That count is greater than 0.

If instance is NULL and count greater than 0
{
Create new CInfoDisplay and assign to instance.
(Strictly speaking if this fails, the function should return NULL.)

If count is greater than CInfoDisplay::MAX_LABELS, use CInfoDisplay::MAX_LABELS instead.

Try allocating CString[count] memory and assigning it to labels.

Try allocating COLORREF[count] memory and assigning it to colours.

If labels is not-NULL, assign _T(" ") to each element.
If colours is not_NULL, assign RGB(255,0,0), i.e. red, to each element.

Assign (0,0) to topLeft.
}

Return instance.

Note the use of _T() for the CString elements. This Microsoft macro handles the difference between UNICODE and ANSCII at compile-time.

For the iterator function;

bool CInfoDisplay::setInfo(const CString& sLabel, const COLORREF& rgbColour)

Pre-condition;
That instance is not-NULL.
That counter is greater or equal to 0 and less than numLabel.
That labels is not_NULL.
That colours is not-NULL.

If counter equals numLabel, then return false. // no more can be entered

Assign sLabel to labels[counter].
Assign rgbColour to colours[counter].

Increment counter.

Return true.

The index-based colour-setting function works as follows;

bool CInfoDisplay::setRGB(const int& index, const COLORREF& rgb)

Pre-condition;
That instance is not-NULL.
That colours is not-NULL.
That index is greater than or equal to 0 and less than numLabel.

Assign rgb to colours[index].

Return true.

The following function helps the program determine the size of all the text that will be drawn. For now mostly redundant, but if positioning the CInfoDisplay instance is being done it will allow the programmer to compensate for weirdness.

CSize CInfoDisplay::getLabelSize(CDC* pDC) const

Pre-condition;
That instance is not-NULL.
That numLabel is greater or equal to 0 and less than numLabel.
That labels is not_NULL.
That pDC is not-NULL.

Initialize the x and y values to return.

For each label,
{
Get the size of the text of the label. (via GetTextExtent())

If the label's x-extent is greater, assign the value to x.

If the label's y-extent is smaller than the rectangle used to display the colour (CInfoDisplay::CELL_SIZE)
{
Increment y by CInfoDisplay::CELL_SIZE.
}
else
{
Increment y by the label's y-extent.
}

If not at the last label
{
Increment y by CInfoDisplay::SPACING.
}

Return CSize(x,y).

Finally, for drawing the instance;

void CInfoDisplay::Draw(CDC* pDC)

Pre-condition;
That instance is not-NULL.
That labels is not_NULL.
That pDC is not-NULL.

Get the size of the text from getLabelSize().

Create a solid pen with the colour of the menu text.

Initialize dy with the BORDER value + PADDING value + topLeft.y.
For each label,
{
Draw the label.

Get the size of the label.
Adjust like the gatLabelSize() function.

Set up a square CELL_SIZE-by-CELL_SIZE separated from the label by SPACING.
Create a solid brush with the appropriate colour.
Draw the square.

Increment dv by the label height and by the SPACING.
}

Now draw the enclosing box. Remember that the box is reduced by the BORDER value, that topLeft positions the box, and that the box's width is expanded by SPACING and the colour display.

Mu Torere, the Playing Board II

2006-04-16T14:28:00.000-05:00

Step 4.
Once the Board class has been set-up, all that needs to be done is to pass the right values to the right functions in the View class. For the moment, create a Game class and two pass-through function for Draw(CDC* pDC) and getSize(void).
Note; if interested here are the in-line functions to specifically catch allocation errors wrt. Board class.

CBoard* getBoard(void)

Get pointer to CBoard instance.

ASSERT that pointer is not-NULL.

Return pointer.

All the second version of the getBoard() function is defined using const to allow the CGame's getSize() function to use it.

Step 5.
It is preferred to use similar pass-through functionality in the program's Document class. (With a private CGame variable.)

Step 6.
Since the View class's onDraw(CDC *pDC) only has one statement to be added, pDoc->Draw(pDC), we will go onto the OnInitialUpdate() function.

void CMuTorereView::OnInitialUpdate(void)

// from the development's' function wizard
Call CView::OnInitialUpdate().

Get the Board class's CSize from the Document.

Increase the retrieved size in the X direction by twice the window's frame.
Increase the retrieved size in the Y direction by the Window's frame + the height of the menu and the height of the titlebar.

Get the width of the desktop.
If the retrieved size is wider than the desktop, then limit the retrieved size's width.

Get the height of the desktop.
If the retrieved size is taller than the desktop, then limit the retrieved size's height.

AfxGetMainWnd()->SetWindowPos(NULL, 0, 0, tSz.cx, tSz.cy, SWP_NOMOVE |
SWP_NOZORDER);

Mu Torere, the Playing Board

2006-04-16T08:20:00.000-05:00

Step 3,
As a starting point, the Board class is a good one. Once this class is set-up, the View can be set to right size and to draw. There are two of the class's functions right there, getSize(void) const const and Draw(CDC *pDC).

The Board class will use the Singleton pattern, so getInstance(void) and Release(void) will need to be added.
Other functions needed for the game are getPlace(const int&) const to return a rectangle for drawing playing pieces, whatIndex(const CPoint&) const for determining valid mouse clicks, and canMove(const int& from, const int& to) const for checking for valid neighbours.

In addition to the Singleton's instance, the Board class also needs an array for the program's playable CRect's, places[CBoard::NUM_PLACES].
The named constants are OFF_BOARD = -1 (a public constant, not really needed in the Board class but a habit), NUM_PLACES = 9 (private, used for readability), and BORDER = 20 (private).

Now all of the numbers used in this class were determined by hand because of the general awkwardness of calculating the positions of the 8 points of the star plus the indents. (Actually I use a positioning kluge to come up with the right numbers, but I will not subject the readers to that mess.)

Constructor
CBoard::CBoard(void)
places[0].SetRect(80,20,130,70); places[1].SetRect(160,20,210,70); places[2].SetRect(220,95,270,145); places[3].SetRect(220,180,270,230); places[4].SetRect(160,250,210,300); places[5].SetRect(80,250,130,300); places[6].SetRect(20,180,70,230); places[7].SetRect(20,95,70,145); places[8].SetRect(120,130,175,185);

For the Singleton pattern;

CBoard* CBoard::getInstance(void)

Is instance NULL?
{
Try allocating new CBoard instance.

If allocation fails, set instance to NULL.
}
Return instance.

void CBoard::Release(void)

Is instance not-NULL?
{
Delete instance.

Set instance to NULL.
}

For the View;

CSize CBoard::getSize(void) const

Pre-Condition:
instance is not-NULL.

Is Return CSize(right-most point+CBoard::BORDER,bottom-most point+CBoard::BORDER)

void CBoard::Draw(CDC* pDC)

Pre-Condition:
instance is not-NULL.

Create a solid brush with the colour of the window's background.
Create a pen with the colour of the menu's text.
(This should provide enough contrast.)

Select into drawing context the pen and brush.

Draw a circle in the rectangle given by place[8].

Move to center of place[0].
Draw line to (145,95).
Draw line to center of places[1].
Draw line to (185,120).
Draw line to center of places[2].
Draw line to (205,160).
Draw line to center of places[3].
Draw line to (185,205).
Draw line to center of places[4]
Draw line to (145,230).
Draw line to center of places[5].
Draw line to (105,205).
Draw line to center of places[6].
Draw line to (90,160).
Draw line to center of places[7].
Draw line to (105,120).
Draw line to center of places[0].

Select into drawing context the old pen and brush.

Note: As an alternative playing field, a 8-spoked wheel can also be draw. Just draw the center last to keep it from being over-drawn.

Mu Torere, the Application I

2006-04-15T23:05:00.000-05:00

Step 2.
Again the Application class will be used for storing the session values. The values stored, private, will be 'int m_AI' for the AI level, 'int m_Undo' for the number of Undo's, 'COLORREF m_Computer', 'COLORREF m_User', and 'bool m_Display' for showing the playing piece display.
Since these are private variables, you will need to add get/set accessor functions (inline) to the Application classes. The only exception would be for the m_Undo variable, only a get function is needed as the user will NOT be able to adjust this during the game. (If the user is feeling ambitious, he/she can go into the registry to change this value.)

Mu Torere, the Set Up

2006-04-15T22:51:00.000-05:00

The basic set-up of this program will be Microsoft's View-Document model, as I wrote earlier.

Not much in the way a frills are needed, though I would recommend using the static MFC libraries. After all, passing on your program to friends only to find out it woun't run from the lack of the proper libraries is not a good thing. (This will also happen as your developement libraries become outdated.)

Again, in the Mainframe class's PreCreateWindow(), the 'FWS_ADDTOTITLE' style needs removal.

PS. There was an additional class I neglected to mention last time, CInfoDisplay. This class is more an aid to memory for the user as there is no easy way to tell the playing pieces apart except for the colour. If you prefer you can mark the playing pieces appropriately, but follow along for now.

Allocating memory and further thoughts on the Singleton Pattern

2006-04-13T17:07:00.000-05:00

In all earnest, allocating memory is a prime case of "Damn'd if you do, and damn'd if you do not." On one hand, you spend time programming allocation checking for a 200 K-byte utility that will be the only thing running on a system with 2 G-bytes of RAM. On the other hand, you find out the hard way about the lack such checks when the utility recursively takes over the system's memory during the demo before the boss and very important clients 2 and 3.

The current standards for C++ require that the new operator throws a bad_alloc exception when things go wrong during memory allocation. Compilers can be made aware of this exception by including the 'new' header file while 'using namespace std;' (Sorry, angle brackets are still awkward under Blogger.)
Thus;

bool Setup(void)
{
int *fields;

try{

fields = new int[NUM_RECORDS];

}
catch(bad_alloc e){

return false;

}

// do something

return true;

}

This will allow the program to fail nicely and handle the situation, without crashing the system.

PS. C++ also allows new NOT to throw an exception, but the only reason I can see for this is to allow new to be used in constructors. But I could be wrong.

With respect to Singletons, this means that the Singleton instance can be allowed to fail (return NULL) in case of memory issues. The other side to this is that these kind of memory failures need to be handled as well.Take a look at how Microsoft handles the situation in its View-Documents architecture.
In Release executables, the View uses an inline GetDocument() function that returns a Document pointer that is re-cast into a pointer of the program's specific Document class. In Debug executables, this GetDocument() function first ASSERTs that the program's Document is correctly derived before returning the pointer.

The only cause for concern that might spring up is that when using a Singleton instance in serveral different classes, what happens to version control?

Smeg. Smeg. Smeg!

2006-04-12T19:07:00.000-05:00

My Tablet PC is screwing up. Which should not be an issue except for the fact that I have all my projects stored on it.

I really hope that all that needs doing is to update a driver.

Mu Torere Steps

2006-04-11T21:29:00.000-05:00

Next Game
Mu Torere Classes
Mu Torere, the Set Up
Mu Torere, the Application I
Mu Torere, the Playing Board
Mu Torere, the Playing Board II
Mu Torere, the Legend
Mu Torere, changing colours
Mu Torere, the Owner class
Mu Torere, the Stone Singleton
Mu Torere, the AI!
Mu Torere, moving the pieces
Mu Torere, moving the pieces II
Mu Torere, the AI II
Mu Torere AI, again.
Mu Torere, a digression
Mu Torere, Undo
Mu Torere, Undo II
Mu Torere AI II
Mu Torere, setting the AI
Mu Torere, the rest of the story
Mu Torere, the Final test
Mu Torere, Improvements

I see that I will need to go back and re-do the titles.

Mu Torere Classes

2006-04-11T21:05:00.000-05:00

A quick run down of the classes

Microsoft classes
	View class (Drawing the game)
	Application class (Storing the session values in the registry)
	Document class (Managing the game)
Game class (Bookkeeping for the game and its sub-components)
	Board class (Singleton instance of the playing field)
	Owner class (Bookkeeping for the players)
		Stone class (Singleton instance for the playing pieces)
	Undo class (Derived from)
		Circular Queue class
	Move Generator class (Singleton, Determines the next move)
		k-Tree class (Helper class for the program's best move tree)

Simple Blocking Game

2006-04-10T20:21:00.000-05:00

The game with a solid lock on being the simplest game in history is widespread though out Asia. A sample of the names by which it is known (from Parlett); Do-guti (India), Pong Hau K'i (China), On-moul-ko-no (Korea), Sua tok (Thailand).

The playing field can be thought of as a diagonally crossed square with one side removed. Movement is along the lines as show in the figure. (At the risk of pointing out the obvious, the playable locations are the four corners of the square and the center.)

Pong Hau K'i

Players move their pieces alternately to the empty point until one player cannot move. The player that cannot move loses.

An alternate way to start that is mentioned by R.C. Bell is that the players alternate placing their pieces onto the field before starting to move.

Next Game

2006-04-09T14:10:00.000-05:00

The next game that will be made in to a program is Mu Torere, a straight forward blocking game played by the Maori of New Zealand.

It is played on a eight pointed star with the star's center as the ninth playable location. Each player has four pieces and the movement rules are simple enough.
- a Piece can move from the center to an empty star point.
- a Piece can move from a star point to a neighbouring start point.
- a Piece can move from a star point to the empty star center ONLY IF one or both of the neighboouring points are occupied by Pieces belonging to the opposing player.
- in the program, the User will go first. Letting the Computer play first is an option.

A Player loses if there is no possible move availible.

on Poggle

2006-04-09T13:58:00.000-05:00

First Example
The Name of the Game is Poggle
Poggle Patterns
After adding the Board Class
What type data members for static instance?
On Menu actions
View Class Update I
View Class Update II
Clicking on Poggle
The Big part of Poggle
Drawing Re-visited
Poggle, Is this thing on?
Poggle, Working with the Registry
Final Exam for Poggle
Some ideas for upgrading Poggle

Now all I need to do is to go back and gammar check my posts.

Some ideas for upgrading the Poggle executable.

2006-04-07T15:31:00.000-05:00

Idea 1:
Localization for other languages.

There are only two places where this would need to be done. The menu is one, the other is the Message to the user annoucing that the puzzle is solved. Most of the material that I have read on the subject recommend to use the String table in the resources to store the message and menu strings the user will read, one String table per language.
One solution that came up is to use resource DLLs. See the following page at CodeGuru for further information.

Idea 2:
Accessibility.

First off, what changes would need to be made where the mouse cannot be used? The program then needs to handle keyboard input. Which keys will be used for pointing? for selecting the pointed to cell? Can the User change these input keys?
Also, how will the selection be highlighted? One way would be to manipulate the cursor so that it will point to the proper cell as the user uses the keyboard. Another would be to change the display to make the selected cell stand out.

As this program is visual in nature, how can vision issues be addressed. In addition to blindness, there is colour-blindness. Should the user be allowed to adjust the colours? make them mono-chrome?

Idea 3:
Solutions.

There is a very good chance that users will complain about the puzzles being impossible to solve. So the solutions need to be documented. How about automating the process?

Final Exam for Poggle

2006-04-05T17:05:00.000-05:00

Now that the program was coded and all the syntax errors have been fixed, the time has come to do all the finishing touches for the program.

A formal and complete test schedule will not be described. This would mean listing out ALL the "if .. [else if ..] then" staments in all coded routines and creating scenerios to trigger them. The test set that will be described should be inclusive enough.

Note all of the following should be done using the Debug version of the program. This will allow the compiler's debugger to display the proper information.

Round 1.
- Does the program start?
- Are all expected menu item accessible?
- Does the Help menu work?
- Does the program exit cleanly?

For the first round that is all that is needed. The user interface and starting/stopping the program is checked at this point.
If the Program does not start, the initialization need to be checked. If a three finger salute is needed to halt the program, the clean-up needs to be examined. And the program's resources need to be examined if the menu is not correct.

One final point to make here is that now is the time to start looking for memory leaks. If one is found, it needs addressing immediately. Usually, this will also get a majority of the memory problems that would otherwise pop up later.

Round 2.
- Using the basic options, does the game detect mouse clicks? valid ones? invalid ones?
- Using the basic options, does the game process the user's selections properly? Click each cell twice to address the following questions.
- - Using the basic options, do the cells switch colours (black and white here) correctly?
- - Using the basic options, do the correct neighbouring cells change state?
- Using the basic options, does the game detect the winning condition? What happends when the program gets mouse clicks after this point?
- Finally, using the basic options, does the 'New Game' menu item return the game to its starting position?
- Exit and look for memory leaks again.

Round 3 through N.
Much of the same questions are asked for each game option. Additionally;
- Do the game settings menu items change the game?
- - Is the number of cells correct? Is it drawn correctly?
- - Do the cells cycle through the correct colours? Every time?

Now once the winning condition has been tested for the basic game, I did not test for it to happen with the other versions. If you get a win, more power to ya.

Once the program was tested, memory leaks fixed, and debugged, the program can be compiled again for Release, i.e. optimized.

Cheers

How about that.

2006-04-03T15:12:00.000-05:00

I am 9% Idiot.

I am not annoying at all. In fact most people come to me for advice. Of course they annoy the hell out of me. But what can I do? I am smarter than most people.

Take the
Idiot Test
@ FualiDotCom

Officially ...

2006-04-03T15:10:00.000-05:00

I did not want to get caught up in all the 'April Fools' posting.

Unofficially, I was too bleep-ing lazy to actually log on.

Poggle: Working with the Registry

2006-03-31T20:34:00.000-05:00

The program will access the registry in two places in Poggle's Application class. One is the ExitInstance() where the menu options the user has picked are stored until the next session. The other is the InitInstance() (of course). It goes without saying that the standard warnings about working in the registry are in full force even when doing entry change programmatically.
Not only that, for more involved programs, the programmer has to keep the registry structure for the program in mind. Will the structure need updating when the program changes? (I am doing this for my Concentration program, and it is an iron-casted pain.) How will changes in the registry (from the user or otherwise) be handled?

Step 15: I put the following after the program's initialization executes LoadStdProfileSettings(0), which loads the .INI file stuff.

Using the RegCreateKeyEx() function is a two-fer operation. If the key does not exit, the operation creates it. Otherwise, the key is opened for further work. The key returned from this function can be used in the following functions to point to the proper registry entry.
For the root registry key of the program the following options were used;
The Registry Key to be worked on was the hive, HKEY_CURRENT_USER (wait for it) to keep the user's choices personnal.
The SubKey used is "Software\\Your Company\\Poggle". (Thought I was going to work on the hive root, didn't you.) Note the escaped slashes.
The registry option used was REG_OPTION_NON_VOLATILE to keep the entries between sessions.
The Security option used was KEY_ALL_ACCESS. Used appropriately, this parameter allows the programmer to tailor the program's functionality to the best (lowest) security settings needed. Done wrong, only the Administrator will be able to run the program.

The returned value from this function is asserted to be equal to ERROR_SUCCESS.
The results value (what went on) is asserted NOT to be NULL.

If the results value is REG_CREATED_NEW_KEY then the program's session values for size and colour cycles need to be created, via RegSetValueEx().
Otherwise the values for this sessions can be retrieved with RegQueryValueEx(). Mind the results value of NULL (error from the registry key creation/open) should be handled as well.

Step 16: In the ExitInstance() function all that needs to be done is to use the RegSetValueEx() function to enter the session values before the program exits.

Quick aside: A comment on 'Magic Numbers'.

2006-03-29T19:59:00.000-05:00

First off, avoid 'Magic numbers' at all times in your program! It is extremely rare for a single use of a fudge factor in any program. Honestly, these adjustment numbers will, not might, WILL pop-up elsewhere as the program grows.
The only instances where such a number is used, that I can think of, would be in a mathematical equation (which really should be in its own routine anyways) or as a throw-away value only needed for debugging, e.g. the actual value does not matter just as long it is the same for each debugging session.

If a number is needed, consider making it a user defined value instead of a named constant. Many times the user will have a better idea as to the preffered value than the developer. (And many times the user will be a gormless git that will make a complete hash of things. But that is another rant.)
Case in point is the colour of the playing pieces. Now Black and White are considered traditional. But earlier, before mono-chrome displays, red was often used as the second colour in a number of games, i.e. Black and Red for backgammon and less commonly White and Red for chess. And what about adding an additional player? That third colour should be used?

Poggle: Is this thing on?

2006-03-29T19:49:00.000-05:00

Step 14: The routine, bool finishedTest(void) the Board will use to find that the user has completed the challenge is fairly straight forward.

Pre-conditions:
- Is the Board instance valid? Actually this would be unneccessary as the routine is private and will not be call via the Singleton interface.
- Is the Board's states array valid?

Loop through the states array
- - (Note: I made an assumption here that I could have Assert'ed, that all states values are greater than or equal to 0.)
- - Is this element less than Board's cycle variable -1?
- - - If so then return false.

Return true.

Drawing, Re-visited

2006-03-28T21:21:00.000-05:00

Step 13: Now that the Board's states array is being used I can describe the void Draw(CDC* pDC) function in better detail.

In the constructor create and specify 5 solid CBrush objects (Yes, they are variables of the Board class). Using black for all off and white for all one, the three other CBrush object's colours are red, green and blue.

Preconditions:
- Is the Board instance still valid?
- Is the supplied pDC valid?
- Is the states array still valid?
- Is the places array still valid?

For each cell of the Board,
- - if the state of that cell is the Board's cycle -1 (all on), select the white CBrush
- - else if the state of that cell is 3, select a colour CBrush.
- - else if the state of that cell is 2, select a colour CBrush.
- - else if the state of that cell is 1, select a colour CBrush.
- - else the state of that cell is 0 (all off), select the black CBrush.

- - Draw the cell. Note, not specifying the CPen of the current drawing area (the pDC) will cause an 1 pixel black outline to be drawn. It would have been better to assume that the user would have chosen the window background and a contrasting text colour and gone with that text colour to outline the cells.

Post conditions:
- The Board instance is still valid.
- The same can be assumed about the places and states arrays.

The big part of Poggle

2006-03-28T00:12:00.000-05:00

At least the part that I consider the MAIN part, everything else is secondary.

Step 13: Firat of, the mod portion of the program, int changeState(const int& state), the only thing that this routine does is to return the next integet in the current cycle.

The pre-condition is that the current Board instance is valid.

If the state parameter of the function is equal to the Board class's cycle variable -1, then return 0 (the starting point).

Otherwise, return the state +1.

Step 14: For void toggleCells(const int& index);
The pre-conditions are tha the Board instance is valid (again).
That the the place index is within bounds. (Release, otherwise just return.)
And that the states array is not NULL

First off, the clicked CRect element. Use the changeState() function on the state for the clicked CRect.

If the index is greater than the Board's size-1 (top row), then apply changeState() to the CRect above the current cell. (index - Board's size)
If the index is less than or equal to Board's size * (Board's size) (bottom row), than apply changeState() to the CRect below the current cell. (index +Board's size).
If the index mod() with the Board's size is NOT equal to 0 ( left side), apply changeState() to index -1.
If the index mod() the Board's size is NOT equal to the Board's size -1 (right side), then apply changeState() to index +1.

Clicking on Poggle

2006-03-26T12:49:00.000-05:00

In the View-Document model, only the View class processes mouse clicks. Which means that the program needs to jump through a couple of routines to detect and react to the user's mouse.

After adding the OnLButtonDown(UINT flags, CPoint point) handler to the View class, similar functions need to be added to the Document and the Board. The View calls the Document and the Document calls the Board.

Step 11: In the Document's mouse handler, void onClick(const CPoint& point), there are only three statements that need to be taken.

Assert that there is an instance of the Board class. (CBoard::getInstance() != NULL)

Call the Board's mouse handler.

Update view. Here the programmer will use UpdateAllViews(NULL). As only one View is associated with the Document, it does not matter if one goes through the effort to find the pointer this single View or just uses NULL for all (meaning one) Views. The other bit is that with only one parameter used, no hint value is passed and the OnUpdate routine will just Invalidate() the drawing area.

Note: I used a const reference for the click point as I did not see any need to manipulate the mouse.

Step 12: There are more things to process in the Board class's mouse handler, void onClick(const CPoint& point).

Check pre-conditions. (Is there a valid instance? Is places valid?)

Is the game over? (I tested a boolean variable to avoid calling a routine.) If finished, congratulate the user again and return.

Find the CRect object in places that contains the CPoint object point. It is highly recommended not to use the loop variable as the record holder for this. Currently C++ standards mean that this variable is likely to be out-of-scope outside of the loop. Most compilers will enforce this, although there are reportedly some that will keep the loop variable visible outside of the loop.

Ignoring out-of-bounds index values (less than 0 and greater than or equal to the Board's size variable squared), process the relevant state value and test for completion. If complete, congratulate the user and set the boolean finished variable for future reference.

Process post-conditions. (Is the Board instance still valid?)

Concentration: Reinventing the wheel

2006-03-26T00:14:00.000-05:00

Specifically Object Oriented Programming.

Originally, I was accessing the specific advanced/medium/beginner variables directly. Actually there was every reason to leave the decision tree at the Application (with the Application) and just ask for the output variables.

Now that I have changed the options, not only do I have the normal beginner/medium/ advanced playing fields, I have the same variables for the 'Blink' (show cards before play), the 'Challenge' (change timer as player progresses), and 'Master' (hide matched cards) variants. I have to add specific registry keys for each combination of variant and still deliver them to the User with the same function call.

View Updates II

2006-03-23T22:53:00.000-05:00

Most of the Desktop checks would really not be an issue with regards to Poggle, but it is best to get into the habit of checking anyways.

The maximum width bounded by the desktop is found by using GetSystemMetrics(SM_CXMAXTRACK).

On the other hand, the height of the desktop is found using a different systems function. This is found using the function SystemParametersInfo() with the action SPI_GETWORKAREA. This will get the Rect denoting all the desktop that is NOT covered by the taskbar or by any application desktop toolbar. The function will need a temporary CRect object to store the retrieved value.

Finally, the function SetWindowPos() needs to be called to set the program's dimensions. This function can be used via the Windows pointer from AfxGetMainWnd(). There are some differences using SetWindowPos() between the initial update and the user demanded updates that will be explained below.

Step 9: The Initial Update.

Call the View class's CView::OnInitialUpdate() function.

Get and adjust the size of the Board object as mentioned earlier.

Set the Window size with AfxGetMainWnd()->SetWindowPos(NULL, 0, 0, adjustedSize.cx, adjustedSize.cy, SWP_NOMOVE | SWP_NOZORDER).

Step 10: The On-Demand Updates.

void CPoggleView::OnUpdate(CView* , LPARAM lHint, CObject*)
{
The only function parameter we are interested in the lParam lHint for communication between the Document and View.

Test lHint for the value specifying that the View needs resizing. (I used an enum to create a named constant in Poggle's Document class for this.) If so, then
{
Get and adjust the size of the Board object as mentioned earlier.

Set the Window size with AfxGetMainWnd()->SetWindowPos(NULL, 0, 0, adjustedSize.cx, adjustedSize.cy, SWP_NOMOVE | SWP_NOZORDER | SWP_NOCOPYBITS).
}

In any case Invalidate() and redraw everything.
}

Note: The flags in SetWindowPos (last parameter) specify the following:
SWP_NOZORDER - Leaves the program in the z-order it currently is placed, If top-most it stays top-most. This flag causes the function to ignore the first parameter (pointer to reference Window pointer, here NULL.
SWP_NOMOVE - Keep position. (Actually leave top-left corner of window in same position.) This flag causes function to ignore the second and third parameters (here 0 and 0).
SWP_NOCOPYBITS - Discards everything within the GUI. The program MUST redraw itself to show any changes.

View Updates

2006-03-22T17:48:00.000-05:00

Under Microsoft's View-Document model there are a few places that the programmer can change the size of the program's interface.

The common one given as an example is to use the Mainframe class's PreCreateWindow function and alter the CREATESTRUCT variable's cx and cy parameters. The problem is that this is only good for program where the height and width are already known.

While I am talking about the CMainFrame::PreCreateWindow function;
Step 8: Remove the style FWS_ADDTOTITLE from the cs.style parameter. This style adds the filename of the saved file the program is displaying or 'Untitled' when starting afresh.

The other place to re-size a program is in the View class's OnInitialUpdate and OnUpdate functions using Window's SetWindowPos(). OnInitialUpdate() is called between the time the Document first connects with the View but before the View is first displayed. OnUpdate() is called by the Document's UpdateAllView() function, which allows the programmer an opportunity to refresh the View on demand.

While there are some differences between the initial and on-demand updates, the bare bones is as follows;

Get the size of the Board. A pass-through function in the Document class should do this as there could be additional information in the Document to be added (not in this case). Reminder, this will be the right-most and bottom-most values, plus the BORDER value in each direction.

Example: The getSize() function from CBoard

CSize CBoard::getSize(void) const
{
Assert that this instance is not NULL.

Assert that Board's places is not NULL.
If Board's places is NULL, then return an empty CSize value, i.e. CSize(0,0).

Return Size with the right-most value of places[BoardSize-1]+BORDER and the bottom-most value of places[BoardSize * (BoardSize-1)]+BORDER.
}

The returned size is then adjusted for the GUI.
(For Microsoft) In the X direction this is given by GetSystemMetrics(SM_CXFIXEDFRAME) which is the width of the GUI frame for the thin frame style. (I did say to create the program with the thin frame didn't I?)
The Y direction adjustment is given by the GetSystemMetrics(SM_CYFIXEDFRAME) PLUS GetSystemMetrics(SM_CYCAPTION) (for the caption) PLUS GetSystemMetrics(SM_CYMENU) (for the menu bar). Please Note that this last metric is for single line menus only. (I am still working on multiple line menus.)

Next up, Desktop checks.

Marks, and Revisions, and Versions, oh my!

2006-03-21T11:48:00.000-05:00

I have not seen any sort of 'rules of thumb' for coming up with version numbers. So here is mine.

The Version (or Major Version) Number; This increments only when the User experience with the program will change in a new and major way or when the program design changes in a manner that the entire program has to be re-engineered from soup to nuts.
Simply extending the program's functionality, e.g. additional file types, would not make the cut. The extention would have to involve new capabilities for the user, not just additional capabilities much like ones that user had before.
For instance, adding a move hint capability would justify a change in version as this would involve multiple changes in multiple areas in the program to implement.
N.B. Zero in this position, by convention, is reserved for works in progress, alpha and beta programs.

The Mark (or Minor Version) Number; This increments when the user's experience is modified or when a major portion of the program needs changing, like when a class withing the program needs refactoring.
For instance, instead of just showing the best move, the program could indicate which moves are better than others. The only major changes are done in a very small set of classes, usually one, and minimal changes (if any) are needed elsewhere.

The Revision Number; Capabilities and user experience remains the same but how they are implemented changes. Usually the changes involve one, maybe two, functions.

The Build Number; Increments per build cycle. Setting this to zero would basically depend on the developer.

Sometimes Build number and Revision numbers are swapped.

On Menu actions

2006-03-21T10:30:00.000-05:00

Step 7: All of the menu items concerned with changing the game (its size or colour cycle) can be written the same way.

Example;
on selecting size X by X
{
Set Document's changed size flag to true.

Set Application's size variable to X.

Call OnNewDocument() to recreate Board.

Update View.
}

on updating size X by X menu item
{
Set check if Application's size variable == X.
}

Note 1: Accessing the Application class's members is not hard but there is one trick to remember. AfxGetApp() returns a pointer to the CWinApp base class, not a pointer to the Application class. You will need to cast the pointer in order to get to the Application's class members, i.e. (CPoggle*)AfxGetApp().
And yes it would be better to use dynamic_cast to recast the pointer. Just remember use a try and catch structure for possible mis-casting.
[UPDATE] Standard OO mistake here. Directly accessing the Application's variables is not good form. It would be much better to use Set / Get functions.

Note 2: Changing the Board's size and the Board's colour cycle really do not need to be handled in the same manner as only changing the size means re-allocating memory. So this is another item that can be improved later on.

State-ful variables

2006-03-19T21:04:00.000-05:00

Step 6: The Document-View model that Mircosoft uses has a central application class that manages the WinMain portion of the program. Later on the registry founctions will ba added, but for now just the size of the playing field and the number of colours vaeiables need be created. Note: It would be a good idea that the limits of the Board class be enforced at this point but this can be compensated for at the game set up. (It is still a possible problem but only if the limits are not enforced constantly.)

The Set-up functions

2006-03-16T21:19:00.000-05:00

Step 3: The first set-up function is used to allocate the Rectangle array places and the int array states. It is only called when the size of the playing area or of the color cycle needs changing. of course the program start up calls this function as well.

boolean setUp(void)

// preconditions
Assert that the Board instance pointer is not NULL. ( redundant, but just in case )
Assert that the Board size value is within specified limits

If the places array exists, delete it.
If the states array exists, delete it.

Create the new Rectangle array using the Board's size value (squared) and asign it to places
Create the new Rectangle array using the Board's size value (squared) and asign it to states

Assert that places is not NULL. (Debug)
If places is NULL, return failed. (Release)

Using the constant values for the border, cell spacing and cell size, create in places an x-by-x square of Rectangles.

// post conditions
Assert that the Board instance is still not NULL.

Return success.

Step 4: The other set-up function is a reset or initialization function for new games. As everything else is set up all this function needs to do is to set the values in the states array to 0 (Black) and initialize any other game values in the Board instance.
The pre-conditions are that the Board instance exists, and that there is a valide states pointer.
The post-condition is that the Board instance still exists.

Step 5: Of course a function is needed to set the Board instance's field size and number of colours variables.

Step 6: As I am using the Microsoft View-Document model, I put the set-up calls in the Document class's OnNewDocument function.

// the variables denoting a change in the Board instance were set to true in the Document's constructor
If there was a change in the size or number of colours do{

Set the Board instance's size and number of colours.

CBoard::getInstance()->setUp();

Set the Documents variables for a changed Board to false.
}

Reset the Board instance to game starting values.

Of course, if the Board instance's setUp() failed, this will have to be passed on to the Document's base class for handling as an error.

Changing the game: I

2006-03-15T22:54:00.000-05:00

Step 1: First I enumerated the various constants (enum), the upper and lower limits to the size of the board and some delimiters for drawing the board (border, rectangle size, and space between). The lowest limit I chose for the board size was 3 (for a 3-by-3 cell board) and the upper was 7. At this time the constants for the upper and lower limits for the colours the game uses can also be added.
I would recommend using the lower limit to initialize the board size's static variable.

Step 2: Add the appropriate menu items. I went for 'Preferences'->'Size' ->[ 3x3,4x4,5x5,6x6,7x7]. Then the event handlers and update handlers can be added to the Document class for these menu items. The update handlers will allow the program to checkmark the right menu item. (I will go into this later.) The menu items for the number of colours can also be dealt with at this point.

Constant for large values of X

2006-03-14T23:02:00.000-05:00

No doubt you have started out creating constant values using the statement '#define VALUE=5'. The problem with this is that most debuggers will not be able to report this constant value. The fact that the preprocessor has processed this statement before the debug symbols are gathered is one reason for this.

A better way to represent constant values is to use the const keyword. (Final in Java.) One advantage is that any type of variable can be called constant, and this includes user defined structures.

If you would rather have the constant value have class scope, using the enum keyword is the way to go. You cannot use a variable type other than integer, but you can reference the value through the containing class, e.g. myClass::constVal.

A Variation on Concentration

2006-03-13T14:28:00.000-05:00

After reading about memory tests, I thought up a variant for my Concentration game. The user first sees the card layout. When ready, the user clicks on the 'Blink' menu item or button. The program then displays the card pairs for X seconds and then only shows the card backs. In order to rely on memory only, the program only indicates match success or failure by changing the colors of the card backs.

A couple of options to make the game even more sadistic. One, if the user can match cards in under an arbitrary number of attempts, the program automatically shortens the time that the cards are displayed when the user clicks 'Blink'.
The second, and worse, is to have the computer revert the display of the successful matches to 'un-played' after a short time. Not only would the user have to memorize the card positions, but the successful matches as well. Of course matching a pair of cards the second or more time would not go to the score.

This observation / memory training game is not a new idea. I have come accross it elsewhere, but the only place that I definitly remember it is in Heinlein's "Citizen of the Galaxy". Here a bunch of odds-and-ends are thrown on the ground / a tray / the table and then covered after a short time. Not only must the player remember what objects were thrown, the position and orientation (if possible) has to be remembered as well.

What type data members for a static instance?

2006-03-13T13:54:00.000-05:00

In Poggle, I am using static for all data members in the Singleton opbject. In other program, the only static data member is the instance variable.

About the only advantage I can think of for all data variable to be declared static is to allow the calling classes to access them, directly or throught accessor functions, without going through the Singleton instance. The disadvantage is this will break the expected behavior of the Singleton as well as having potential syncronization issues.

After adding the Board class

2006-03-10T20:32:00.000-05:00

As the starting point one should start with four functions; one to draw, one to get the size of the field, and two to initialize the data. The first initialization function is for new games. The second is for those times the playing field changes. (Actually for non-solitare games, the Board class only needs to initialized once in its lifetime.)

The data variable that the Board class will start with is a pointer to a Rectangle class, *places. (CRect in Microsoft IDE.) Since the Board will be re-sized when different game playing options are selected, pointers will allow the board information to be destroyed and recreated on the fly. Clean-up is nothing out of the ordinary, so the Board class's destructor can be in charge of that.
The other starting variable is a integer to hold the size information. This is to avoid all the sizeof()/sizeof(Rectangle) hoops to jump through to get pointer array information. I recommend just storing the length of the side.

For right now, the drawing function for the class just can draw the rectangles that places point to. This will suffice as a place-holder until the rest of the game's variables are added. A single loop will be all that is required. Just assert() that there is a valid pointer before drawing random pointers.

The Singleton: One More Time

2006-03-08T21:17:00.000-05:00

What was the bit from the Highlander series? "There can be only one!"

The Singleton pattern enforces this idea. Hiding the details of creating the object from the calling class, a Singleton object forces the caller to access its functionality through a specialized interface. One advantage of this approach is that the caller will not need to track multiple objects over different calling objects.

While, supposedly, a Singleton object in C++ can be constructed in the manner as those in Java, I will be using a point to implement Singleton objects. The only disadvantage is that the user must manage the destruction of the object, and not depend on the scope of the Singleton.

Header File:

class Singleton
{
private:
     Singleton(void);
     ~Singleton(void);

     static Singleton *instance;

public:
     static Singleton* getInstance(void);
     static void Release(void);
};

Source:

#include "Singleton.h"

Singleton* Singleton::instance=NULL;

Singleton::Singleton(void)
{
     //do stuff here
}

~Singleton::Singleton(void)
{
     // clean up
}

Singleton* Singleton::getInstance(void)
{
     if(instance == NULL){
          instance = new Singleton();
     }

     return instance;
}

void Singleton::Release(void)
{
     if(instance != NULL){
          delete instance;
          instance = NULL;
     }
}

Apologies

2006-03-07T22:40:00.000-05:00

Given the lame fashion blogger renders HTML I will have to use psuedo-code to describe my code and not write about specific dependencies.

PS. Boolean tests for less than X and greater than Y are going to really be a pain.

Excuse the delay

2006-03-02T21:35:00.000-05:00

I need to find out post angle brackets.

1	1	0	1	0	0	0	0	0
1	1	1	0	1	0	0	0	0
0	1	1	0	0	1	0	0	0
1	0	0	1	1	0	1	0	0
0	1	0	1	1	1	0	1	0
0	0	1	0	1	1	0	0	1
0	0	0	1	0	0	1	1	0
0	0	0	0	1	0	1	1	1
0	0	0	0	0	1	0	1	1

1	1	0	1	0	0	0	0	0
1	1	1	0	1	0	0	0	0
0	1	1	0	0	1	0	0	0
1	0	0	1	1	0	1	0	0
0	1	0	1	1	1	0	1	0
0	0	1	0	1	1	0	0	1
0	0	0	1	0	0	1	1	0
0	0	0	0	1	0	1	1	1
0	0	0	0	0	1	0	1	1

1	1	0	1	0	0	0	0	0
1	1	1	0	1	0	0	0	0
0	1	1	0	0	1	0	0	0
1	0	0	1	1	0	1	0	0
0	1	0	1	1	1	0	1	0
0	0	1	0	1	1	0	0	1
0	0	0	1	0	0	1	1	0
0	0	0	0	1	0	1	1	1
0	0	0	0	0	1	0	1	1