美味すぎ。カウンターに座ったら目の前でタマネギ切ってるんだもん。反則だよ。
美味すぎ。カウンターに座ったら目の前でタマネギ切ってるんだもん。反則だよ。
式の変形途中で記号を間違えるので、Maximaの力を借りることにした。こういうのは本当は手を動かした方が良いんだろうけどね。
W32TeXとGhostScript、imaximaを導入。imaxima-image-typeがpng'だと画像は出るが何も見えなかったので'jpegにした。背景が黒いから見えないだけかなと思ったんだけど、imaxima-bg-color、imaxima-equation-color、imaxima-fg-colorを指定しても変わらず。'jpegにしたら黒地に白文字で表示されるようになった。
ああ、行列のかけ算はピリオドなのね。*だと思ってはまった。
迷路を文字列で記述して、それを読み込みたい。例えば、次のような記述。
...#####....... ...# #....... .### #######. .# @ #. .## ## # ###. ..# # #... ..# #### #... ..# #... ..##########...
'.'は部屋の外、'#'は壁、' 'は床、'@'はプレイヤー。
読み込み関数へ渡すとき、一つの文字列で渡すか、文字列の配列で渡すか。
一つの文字列で渡す場合、行毎の区切り文字を決めるか、別途迷路の幅(桁数)を指定する必要がある。
var maze = loadMaze("
|...#####.......
|...# #.......
|.### #######.
|.# @ #.
|.## ## # ###.
|..# # #...
|..# #### #...
|..# #...
|..##########...");
文字列の配列で渡す場合、ちょっと記述量が増える。メモリ効率も悪い。
var maze = loadMaze( ["...#####.......", "...# #.......", ".### #######.", ".# @ #.", ".## ## # ###.", "..# # #...", "..# #### #...", "..# #...", "..##########..."]);
古い人間なのでついつい上を考えてしまうのだけど、上の方法は区切り文字を入れ忘れたり、幅の指定を間違えたりといったミスを誘いやすい。効率が問題となる場面ではないのだから、後者を選んだ方が無難だと思う。
1行の文字数が一定ではない場合があり得る。例えば、次のように指定したって良いじゃないか、という話だ。
var maze = loadMaze( ["...#####", "...# #", ".### #######.", ".# @ #", ".## ## # ###", "..# # #", "..# #### #", "..# #", "..##########"]);
これについては、読み込むときに最大の幅で揃えても良いし、揃えずに読み込んで、アクセスするときにチェックしても良い。詳しくは後で考えることにする。
Cell = {
OUTSIDE: 0,
FLOOR: 1,
WALL: 2
};
function loadMaze(strs)
{
var assert = function(cond) { if(!cond){ throw "Failed to load maze.";}};
var player = null;
var cells = [];
for(var y in strs){
var cellsRow = [];
for(var x = 0; x < strs[y].length; ++x){ // for/inではダメだった。Firefoxは動いたけど。
switch(strs[y].charAt(x)){ //strs[y][x]と書いたらIEで動かなかった。
case '#': cellsRow.push(Cell.WALL); break;
case '@': cellsRow.push(Cell.FLOOR); assert(!player); player = {x:x, y:y}; break;
case ' ': cellsRow.push(Cell.FLOOR); break;
default: cellsRow.push(Cell.OUTSIDE); break;
}
}
cells.push(cellsRow);
}
return {cells:cells, player:player};
}
出来るだけ平易に書いてみた。以下言い訳。
とりあえず読んだ結果をテキストで出してみる。
// 読んでみるのコード
...
// どう指定するかの2番目のコード
...
document.open();
document.write("<pre>");
for(var y in maze.cells){
var line = "";
for(var x in maze.cells[y]){
switch(maze.cells[y][x]){
case Cell.OUTSIDE: line += '.'; break;
case Cell.FLOOR: line += ' '; break;
case Cell.WALL: line += '#'; break;
}
}
document.writeln(line);
}
document.writeln("player:(" + maze.player.x + "," + maze.player.y + ")");
document.write("</pre>");
document.close();
次はグラフィカルに表示してみたい。
今夜も月が綺麗である。
ああ、発売延期するのか。まあ、ゆっくり作ればいいんじゃね？ くらいに思っていたのだが、なにやら変な話が流れているようだ。
個人的には、体験会で触ったくらいの出来であれば、多少不具合があっても発売すればいいんじゃね？ と思っている。出たら買うけど、出なかったらそれはそれで困らないというのがなんとも。
演算子を多重定義できないとどう組んで良いのか分からないよー(泣)
長いこと目をつぶってきたんだけど、そろそろちゃんと調べてみますかね、ということで。
それにしても256×256は迫力だよね。でも、高精細用だからあまり描き込んだ物は良くないのかな。
へー、Ctrl+ホイールで変えられたんだ。
リサイズ対応。全画面化周辺のクラス群が複雑すぎて死ねる。思わずvisioでクラス図を書いてしまった。複雑さの原因は、pimpl、誰が全画面化をするのかという問題、画面の抽象化と実装の切り替え、入力系の分離。たぶん色々やり過ぎなんだと思う。でもそのあたりの全体的な設計は変えずに、細かい部分の追加と修正で対応。
「(昔の)小学生向けcanvas要素入門」というのを書いてみた。昔子供の頃にBASICで育った今おっさんたちに捧げる。これで昔BASICを触ったことのあるおっさんなら、現代でも同等のことくらいは出来るようになるはずである。
現代の小学生はどうやってプログラムの世界へ入っていくのだろう、という疑問のこれがその答えだ！……と言いたいところであるが、現代の小学生は先にお絵かきソフトに触れると思うので、こんなのが出来ても全く嬉しくないだろう。
普段そんなにJavaScriptに触れる機会が持てないでいるのだけど、前々から色々遊んでみたいとは思っていた。
それを阻むのは何かと考えると、いちいちテキストファイルを作らなきゃいけないことなんじゃないかと思ったので、ファイルを作らなくても良い環境を用意した。
JavaScriptコンソール。別フレームでevalするだけ。Firefox、Operaでは動いたけど、IEでは動かなかった。top.フレーム名.evalが使えないみたい。IEで別フレームで評価するにはどうしたらいいんだろ。まあ、IEで使わないからいいけど。
さて、試しのコード。
document.open();
document.write("<html><body>");
var i;
for(i = 0; i < 10; ++i){
document.write("hello<br>");
}
document.write("</body></html>");
document.close();
これをソース欄に貼り付けて、実行すると、helloが10回出力される。
canvas要素もテスト。
var cv = document.createElement("canvas");
cv.setAttribute("width", "640");
cv.setAttribute("height", "480");
cv.style.cssText = "border: solid;";
document.body.appendChild(cv);
var ctx = cv.getContext("2d");
ctx.beginPath();
ctx.moveTo(320,240);
var i;
for(i = 0; i <= 360*3; i+=10){
var rad = Math.PI*i/180.0;
var x = 320+Math.cos(rad) * i*0.2;
var y = 240+Math.sin(rad) * i*0.2;
ctx.lineTo(x, y);
}
ctx.stroke();
ちょっとしたグラフをプログラムでちゃちゃっと書くのには便利かもしれない。