Archive

Posts Tagged ‘Programming’

Codepaste 2 and Google Chrome: friends at last?

May 14th, 2010

Codepaste2 displays correctly in Chrome! Finally!

In Opera, Safari, Firefox, and IE everything was great; in Chrome things went so very wrong: lines would wrap, lose opacity, and display behind themselves. Code was super difficult to read.

But now it works! And, to be honest, I’m not sure why. I updated the version of EditArea it uses, and didn’t see a change. When I switched its allow_resize option from both to y everything magically got better. I was pretty happy. But then I changed y back to both and things didn’t get worse, which left me confused and a little scared.

I hope the issue was resolved by updating EditArea, and all the confusion was caused by some weird caching issue. Or maybe I forgot to refresh?

Codepaste v1 still gets heavier use than Codepaste v2. I wonder if that is by conscious decision, or if people just don’t know about Codepaste v2 and how much better it is.

Codepaste, Dev ,

Tic Tac Whatsit

December 8th, 2009

Long days ago I spoke with a dentist of game demos, and of a festival dedicated to those. We talked of Ticktacktoe, a classic game of boxes and shapes – a boring, beatable game, but an easy one to program.
It’d be easy to program, right? We could probably make one with flash in less than thirty minutes, couldn’t we? At least one way to find out!

Yup. Sure could!

Ticktacwhatsit is made up of nine (9) blocks, and each can be either blank, an X, or an O. That’s so easy to represent in flash!

I started by making a symbol called called block which had two layers and three keyframes on one layer: blank, X, and O. On the other layer, i added the action stop(); to prevent it from flipping through the frames.

I dragged 9 instances of block onto the stage, and arranged them into a game board (named them in sequence) – and drew some lines between them.

And then I wrote the game code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
var boxes:Array = [ b0, b1, b2, b3, b4, b5, b6, b7, b8 ];
var nextSymbol:int = 0;
 
removeChild( done );
done.addEventListener( 'go_again', restart );
 
function restart( e:Event ) : void {
	nextSymbol = 0;
	for( var i:int=0; i < boxes.length; i++ ) 
		boxes[i].gotoAndStop( 1 );
	removeChild( done );
}
 
for( var i:int=0; i < boxes.length; i++ ) {
	boxes[i].addEventListener( MouseEvent.CLICK, onClick );
	boxes[i].buttonMode = true;
}
 
 
function onClick( e:MouseEvent ) : void {
	if ( e.currentTarget.currentFrame == 1 ) {
		e.currentTarget.gotoAndStop( nextSymbol+2 );
		if ( checkGame() ) {
			trace( 'won!' );
			done.gotoAndStop( nextSymbol + 1 );
			addChild( done );
		}
		nextSymbol = (nextSymbol+1)%2;
	}
}
 
function checkGame() {
	for( var t:int=0; t < possible.length; t++ ) {
		var val:int = boxes[possible[t][0]].currentFrame;
		for( var i:int=0; i < possible[t].length; i++ ) {
			if ( boxes[possible[t][i]].currentFrame != val || val == 1 )
				break;
			else if ( i == 2 )
				return true;
		}
	}
	return false;
}
 
 
var possible:Array = [
		[ 0, 1, 2 ],
		[ 3, 4, 5 ],
		[ 6, 7, 8 ],
 
		[ 0, 3, 6 ],
		[ 1, 4, 7 ],
		[ 2, 5, 8 ],
 
		[ 0, 4, 8 ],
		[ 2, 4, 6 ]
	];

So the main idea is that we have a bunch of boxes and whenever one of them gets clicked, we may have to do something. I added each of the boxes to an array (line 1), so I could easily loop through them all (line 14), and set the buttonMode and add an onClick event handler to each. A true buttonMode tells flash to display the little hand when you mouseover the object.

The main processing is done whenever you click a block, and the onClick event handler starts on line 20. That’s really all there is to the game, the rest of the stuff are just extras.

The mouse event is passed as a param to the event handler. Its currentTarget property represents the object clicked, which in this case is one of the blocks.
The first test to do on that block is see if it’s empty. If it’s not empty, there’s nothing for us to do.
A block is empty if it is still on its first frame, which is where currentFrame comes in. If it’s not on its first frame it’s either an X (frame 2) or an O (frame 3).

If it is empty, I need to either fill it with an X or an O, whichever wasn’t used last. For this, I have the nextSymbol variable, which is only ever either a 0(X) or a 1(O). I set the block using its gotoAndStop function, passing it the frame we wish it to change to.

After that, I just check if a player has won!
I was pretty lazy about checking; I made a list of every possible victory combination (line 46), and check each of those (line 32) to ensure all the squares in each aren’t on the same frame, or on frame 1 (line 36).

Done!

Line 28: I wonder why I did nextSymbol = ( nextSymbol + 1 ) % 2; instead of nextSymbol ^= 1; Laziness?

Dev, Uncategorized, being helpful to people less experienced than myself in the ways of the world; mostly in the ways of the web actually , , ,

function race 001!

September 28th, 2009

One day for fun, Karl and I thought up few different ways to accomplish the same thing. That sort of thing is fun. No, it’s fun.

I decided to compare two of them for speed. The range and domain of both functions are {1,2,3}.

Method A
Based on a table.
function( a:int, b:int ) : int {
   var c:int = a^b;
   return c ? c : a;
};

Mathod B
Based on the same table, but karnaugh-mapped, circuit-design style.
function( a:int, b:int ) : int {
   var a0:int = a&1;
   var a1:int = (a&2)>>1;
   var b0:int = b&1;
   var b1:int = (b&2)>>1;
   return ((( a0&~b0 | (~a0)&b0 | a1&b1&b0 )<<1 ) | ( b1&~a1 | a1&~b1 | a1&a0&b0 | (~b0)&~a0 ))&3;
};

Method A is always faster than Method B (except sometimes in firefox for some reason) on my computer, but the difference is minimal (like .5%). There are obviously little ways in which we can tweak the algorithms. For example: we could not declare a0, a1, b0, and b1 every single time.

Function Racer
Click on it to start the race. Click off of it to stop the race.
The number below each method is the number of milliseconds consumed for the total operations performed (above the methods).
The operation size (at the top) is scaled to keep the framerate between 29 and 32.

Uncategorized , ,

brackets or whatever you call them

August 31st, 2009

At first I was all how am i going to deal with the order of operations? and I thought about maybe creating a parse tree. That seemed excessive, especially when I thought about how simple calculators usually work (from a usage standpoint). Which was okay, even good, but how to account for brackets. Or better, nested brackets?

There’s probably a real name for this method, but I don’t know it. Karl will definitely know? And if he doesn’t he’s lying.

So we have the screen, which I will call B and a stack of registers which I will call An. Each register has a value and an operator.

What happens usually is you type a bunch of literals, and then an operator. When you type an operator it checks if there is data in the nearest register, and if so combines the two values using the operator stored in the register and moves the new value and operator into the register. There are only binary operators at the moment, but unary operators would be easy to implement.

When you open a bracket, a new register is pushed onto the stack and the system makes use of that one from now on. When you close a bracket, the operation of the last register is performed with B, and the last register is popped off the stack – its value stored in B.
In this way the calculator supports nested brackets.

12 + 5 =

12
A0 = null
B = 12

+
A0 = {12,+}
B = <empty>

5
A0 = {12,+}
B = 5

=
A0 = null
B = 17

 

5 * ( 1 + 1 ) =

5
A0 = null
B = 5

*
A0 = {5, *}
B = <empty>

(
A0 = {5, *}
A1 = null
B = <empty>

1
A0 = {5, *}
A1 = null
B = 1;

+
A0 = {5, *}
A1 = {1, +}
B = <empty>

1
A0 = {5, *}
A1 = {1, +}
B = 1;

)
A0 = {5, *}
B = 2;

=
A0 = null
B = 10;

Thoughts? Potential bugs?

Dev ,