今日はマリオカートをやりました。
昔からグランプリで総合4位以下になったらどうなるのか気になっていたのですがサントラのそのバージョンの曲を聴いてしまって、何が何でもやりたくなってしまいまして。
個別のコースでは必ず4位以内に入らねばならず、それにより最低4点は手に入ってしまうので順位調整が大変でした。
でもその甲斐あって見事4位にはいることに成功！
爆弾ミニカーが慰めてくれました。
チャット、多重入室、というのはよくないと思っていたけど、一人二役できて面白いじゃないかという指摘を受けてそれ対応のための方法を考案中です。
まあ今回はそんな難しいことは抜きにしてとりあえず単純な入退室処理だけを作りました。
今日はふにゃの絵でも。
楕円ツール使ってる時点でダメダメだわ。
ふにゃさんのナビゲーションバーの背景は木目模様にしようと思ったんだけど何度も描こうとして挫折。
結局どうしたのかというと、VBで適当な模様を作ってそれを縮小してそれらしいものに仕立て上げました。
それに伴いギヤバネ君にも木目模様を施しました。
アキタラヤメル企画にもスタイルシートを施してみました。
GChat、発言処理ができるようになりました。
人工無能ちゃんとの相性も考えて普通のチャットプログラムではまずやらないようなことをしています。
それが、発言の時系列ソートと未来の発言を表示しない機能。
人工無能ちゃんは人間様の発言を受けてから即座に返答するしか能がないので、人間様によくある入力時間を擬似的に再現するために表示だけ遅らせるという手法をとったのです。
とりあえずテスト書き込みできる状態にはあるのでぜひ見ていってください～。
FFCCの「哀しい怪物」を大雑把に耳コピしてみました。
う～ん、SFX音を使うと音源依存が激しくなるなぁ…。
ま、そんなこと知ったこっちゃないけど。
チャットを作っていました。
入室フォームと発言フォームができました。
ほとんど何もありませんが、一応最低限の機能だけで。
そもそも多機能だったら使う人がもてあましちゃうか、乱用して悪い雰囲気になっちゃうかになりそうだし。
入室せずに発言しようとしたり、退室後に発言しようとしたり、極端に長いROMは不正行為として処理するつもりです。
まず、前2つは、過去ログを参照して、その人の最後の発言が退室メッセージでなかったらメッセージを受理します。
3番目のは、一定時間以上アクセスがないと自動退室。これでウィンドウを閉じちゃっても退室メッセージが出せるはずです。
表示処理については、読み込みが書き込みより圧倒的に多いと仮定して、表示を軽くするため極力ログ整形処理をしないよう整形済みHTMLファイルを用意し、発言→ログ書き込み→HTMLファイル書き込み→HTMLファイルを読み込んで表示、という流れで発言処理を行います。
ログ表示件数はいっそのこと固定。ほとんどの人はめいっぱいたくさんか初期設定だけでしょう。
ウィルスに感染していました。
今日午前0時半過ぎに症状が現れ、おかげで睡眠時間がかなり削られました。
おかげで睡眠時間がかなり削られました。
http://d.hatena.ne.jp/mifumi323/20050714
今日は人の顔。
小学生の頃から人、特に顔を描くのを頑なに拒み続けて今に至るのですが、さすがにこれではいけないと思い、描くことにしました。
思えば覚えているうちで一番最後に描いたのが小学三年生の頃に描いたリコーダーを吹く友達。
あのとき目がおかしいといわれたのを覚えています。
とりあえず必要なところはCGameObjectBaseから抜いてきて、一応Cf3MapObjectBase完成。
さらにこれを派生させて主人公クラス作成。
グラフィックはstaticメンバにして無駄なメモリ消費を減らす。
主人公は一体だけだから関係ないはずだけど。
ちなみにグラフィックはGIF画像で用意されていて、透過情報はGIF側で持っています。
一応表示までできるようにはなってます。
やっぱり目に見えるところから作ると作ってるって感じがしていいねぇ。
気まぐれ人工無能、そろそろ作り出そうかなと考えていたり。
正規表現にマッチする応答を返す方式、マルコフ連鎖、人対人の会話から自動学習、呼ばれて出てきて落ちたら消える。
散発に行ってきました。
この季節は髪が乾きにくいのでかなり短くしてもらいました。
とりあえず提出期限を一番大きく過ぎてるレポートを完成。
何度も再提出させられて、今度こそ完璧だと思うのですが…。
「甲骨文字から楷書に至るまでの漢字の変遷について」を書き直したものを学習帳にアップしました。
元々学校にレポートして出したものをHTMLに編集したものなので、「引用のないレポートは自分勝手な思い込みだから信用できない。必ず引用と引用元を記載すること」という先生様の有難いお言葉のため、半分以上が引用で成り立っています。
キ番復活しました。
統合の影響で2000以上すっ飛ばされていますが、一応今のこの値で運用再開です。
ミディビの具体的な仕様について考えてみます。
まず、掲示板と連携しなければいけないので、アプレットからCGIへとデータの受け渡しをしなければならないのです。
しかし、ブラウザの不調などで、アップロードはできたけど文章の記入ができないなどのトラブルが出てきそうです。
作品投稿→コメント記入→コメント投稿、という流れになるのですが、この途中で終わっちゃったりすることがお絵描き掲示板でも結構あるようなので、アップロードされたMIDIから、この流れを再開できるようにするのが必須だと思うのです。
お絵描き掲示板ではこのあたりどうやっているのかは知らないけど、今回はMIDIの中にパスワードを暗号化して埋め込むという方式を採用しようかと考えています。
自分用のリンク集プログラムを改良してみたら登録していたデータが半分吹っ飛びました。
レポートは今日中には終わらせるつもりです。
日記と掲示板のプログラムをちょっと改良しました。
いずれもメンテナンス部門の変更なのでユーザーが使える部分では変更ありません。
FFCCでは、ちょっと気まずい手紙を拾って受け取ってしまったためリセット。
結構アイテム手に入ってたんだけどな。
ByteEditでも改良してみようかと思ったのですが、どうも今日中には間に合いそうにないです。
ファイルとの比較を作れば解析が簡単になるかなぁと思ってたり。
もとのGBBSとあまり変えていませんが、掲示板を設置してみました。
一応専用アイコンにも対応したりエラー時の処理を改良したりもしています。
アイコンは今のところユーザーで利用できるのが１種類しかありませんが、順次増やしていく予定です。
予定ついでに今後の方針を言っておくと、自己紹介は統合してひとつに、ランキングやその他もろもろのCGIは多分そのまま、アンケートは削除するかも。
HPMもそのまま移転しない予定。パーミッションやら.htaccessの再設定が面倒くさいので。
リンク集は相互リンク以外は順次移転。相互リンクのほうは向こうから張り替えてくれたらこっちもTGWSのほうのリンクに移動。どことどこの相互かははっきりさせておきます。
チャットはその内気が向いた来店します。
ルールを ”タイム制” から ”ストック制” に変え、1回ブレイクしたら負け、というルールで挑みます。
ひとことでいうと、 [ジャゴンボ] は好戦的な惑星で、 [コロニオン] も好戦的な惑星。
７分近くにおよぶ、とんでもないデッドヒートの中、とあるラインがピンチになって白く点滅するたびに「あぶない！あぶない！」と白熱するギャラリーがいないのが残念です。
正直、私はこの程度のデッドヒートは何度も見ました！
６分５３秒、あるラインがどうしようもない状態になり、戦意にぎらついていたジャゴンボ星人の目に諦めの色が翳ったとき、「燃え尽きたぜ…真っ白にな」とでもいわんばかりに唐突にコロニオンがブレイク。
何とか勝ちました。
Gのほうのアップロードをとりあえず移転。
掲示板もGBBSを基に新しく作っています。
はい。トップがPHPになっているのにお気づきでしょうか。
そんなもん知ったこっちゃありませんね。
以前はSSIからカウンタCGIを呼び出していたのでPerlとCGIの2つのファイルの呼び出しがあったのですが、PHPにしてひとつのファイルにまとめたためかなり軽くなっているはずです。
ミディビ、更新しました。
プログラムには触れてませんけど、手がかりにはなるはずです。
やっぱ2ヶ月もあいてるんでそろそろ更新しとかないとなーということで。
CGI作ってたりしてました。
ん～。アクセス解析もしてみたけど特に際立った変化はなし。
とりあえず次の更新は次の水曜日までになるだろうな。
メールフォームを改良してみたい今日この頃です。
JavaScriptを使って、ボタンを押すとアンケートフォーム作動、さらに「ブラウザ情報を送信」のチェックを入れるとアクセスログからは解らない、画面サイズなどの閲覧状況なども送信できるように。
バージョン情報については解決。
データの大きさが可変であるためか構造体が用意されていない！
そのためポインタをゴリゴリになっちゃいまして。
実際可変長のところは肝心のバージョン番号がある場所の後ろからなので、バージョン番号のある場所は計算で正確に求められたりします。
よしよし、これで今後のバージョンアップがやりやすくなった。
ぃやったあああああああっ！！！！100万点！！！100万点ですよっ！！
メテオスチャレンジダウナスで100万点突破しました！
そんでもって、CGI作りました。
http://tgws.fromc.jp/akiyame/index.php?id=meteos
に設置。
ドラクエ5、あの腹の立つカボチのイベントを無視して勝手にキラーパンサーを仲間にしちゃいました。
カカシとメダルはちょっと惜しいけどメダルはエスタークから無限に取れるらしいし、名産品はもう既にどうでもよくなってきちゃったし、娘エリーさえ元気に育ってくれればそれでいいんだし…
放置気味のTscript、そもそも完全オリジナルにする意味はあるのか、と考えてしまう今日この頃。
いろんなサイトで配布されている掲示板スクリプトは何から何までお膳立てしてくれてるものが多いけど、掲示板のコアとなる、記事の読み書きのみを提供したライブラリは少ないのではないか。
いやいやいや、あったらほしいのだ！
それも著作権フリーで、一部流用許可、パクリ上等、みたいなのを。
いやまて、自分で作って配布してみるのはどうか。
とりあえず考えておこう。
パネルγ、特にゲーム的に変更した部分はなし。
計算すると、連鎖で作ったHUGEが730点、smallによる17連鎖が765点、作る手間はそう変わらないので得点バランスとしては悪くない。
ただ、自由度が非常に高いので、できる人はどこまで行くか皆目見当も付かない。
1万点前後で終わるといいんだけど…
エンドレスのほかの、タイムアタックやプレスブレーカーやプラクティスやらのシステムもある程度構想ができたので、エンドレスの部分から、共通化できそうな部分をこれから探していこうと思います。
MIDIB、できるのできないの言ってるばっかりじゃなんにもできないので、Javaの練習も兼ねて、この製作過程をプログラミングコーナーのネタにしてしまおうかと考えております。
で、動きそうになったらためしに設置してみる、と。
レポート早めに終わらせました。
これで遊べ…いや、テスト勉強に集中できる。
掲示板でよく「一行書き込みはやめてください」という記述を見かけます。
別に禁止するほどのことでもないと思うのだが、たった一行のために書き込み一つのスペースと容量を使われるのがもったいないのでしょう。
そのために、一言掲示板なるものを用意するというのもひとつですが、書き込みが分散して全体としては減るまいかと思うんですね。
掲示板なら同じ掲示板として利用したい。でも書き込みひとつに一行というのは…
そこで考えたのが、複数の一行を着込みをひとつの書き込み(スレッド)の中に詰め込むシステム。
例えば、10行の書き込みが普通のところに1行の書き込みが来ると100行が一気に流れてしまいますが、1行書き込みを自動判別してひとつの書き込みに追加という形で投稿すれば流れるのは10行に過ぎないのです。
また、一行でもかまわないという気軽さから、書き込みが増える期待も。
Tscript、どうしようか…
既にあるCGIを使って9割変更するくらいならいっそのこと1から全部作ろうと思って作り始めたのですが、どうも最近はかどらない。
横の繋がりなんて弱いものさ。ちょっとしたことですぐ崩れてしまう。
だけどいざというときに頼りになるのは縦じゃなく横の繋がりだぜ。
灰色の高のぼり。はい、そーゆーわけで、パネルが逃げるプログラム、そしてゲームオーバーを作りましたよ。
いやむしろ、灰色よ高のぼれ！
悪あがきしないとみっともないぜ。はい、もう最後まで何が起こるかわかりません。
変えられる運命をそっくり受け入れるなんて、気が早くないか？
で、ゲームオーバーになるまで一度やってみました。
3987点。
4000点に後一歩及ばず。惜しいっ！
最初にHUGEを２個作って後はLARGE狙いで。
隙間が残り２マス分を切ってもまだ悪あがき。
さすがに逆転ができないことはもうわかってたけど１点でも多くとりたいので。
隙間が残り２ドットになってもまだ色はわかります。
最後の最後の最後の最後まで粘りましょう。
個人的リンク集に暗号機能を搭載してみました。
まあ暗号とはいってもとても実用には耐えない代物なんですけどね。
まあ家族の好奇から逃れるためならばこの程度で充分ということで。
暗号化と同じ秘密鍵で復号化します。
MIDIを作るアプレットMIDIAを作成中です。
とりあえずEclipseインストールしてアプレットクラスを継承するところまで。
プレス機をちょっと改良しました。
グラフィックの変化と、ピンチ時遅くなる処理(ただし、ピンチになるスイッチが働かないのでノンストップ)。
たくさん同時消ししてもプレス機を押し返せるようにはしたけどあまり当てにはならない。
パネルγの色パレットの設定を作りました。
ウィンドウモードでパレットが指定できないのは多分サーフェスがパレットモードじゃないから。
となれば正式版ではフルスクリーンモードだけにするか…？
それともウィンドウモードではパレットアニメーションを使わないことにするか…？
いっそのこと3Dをもう一度やり直すか…？
実際に使ってみたら良い点悪い点がよくわかりますのー。
12月も終わりというこのころになってやっと「冬の寒さ」がやってきて、思い出したように雪が降り出しました。
昨日までの寒さは秋の肌寒さ。
雪は地面で速やかに融けてしまいましたが。
最近キリ番とかにあまりこだわらなくなってきたのでカウンターの文字の大きさを普通の大きさで統一するようにしました。
以前のように大きさが変わるバージョンがいいという人がいたら戻しますが。
サーバーのOSはRedHatLinuxだ。
Linux系はマルチタスクOSであり、複数のユーザーが同時に利用する。
だから、あまり高負荷なCGIは設置できない。
私自身のためでも訪問者のためでもない、サーバーを共有するほかのユーザーのためだ。
しかし、時としてCGI上で重い処理を実行しなければならないときがある。
もちろん一番手っ取り早い解決方法は処理を軽くすることであるが、理論的にも現実的にも限界というものがある。
例えば、N個のデータに対して処理を行いたい場合は、どんな場合でも最低N回の処理が必要になる。
また、実行しないという方法もある。
つまり、データをローカル環境にダウンロードしてそこで処理をすればサーバーに負荷はかからないという計算だ。
しかしそれには時間も手間も余計にかかる。
そこで、原点に立ち返って考えてみる。
なぜ高負荷の処理をしてはいけないのか。
マルチタスクの動作原理からわかるとおり、実際の処理は１つのCPUがこなしており、単純計算すれば、２人が同時に処理を行えば処理速度はそれぞれ半分になるということだ。
低負荷の処理であれば処理は瞬時に終わるため、２人が同時に、ということは少なく、仮にあったとして処理速度が半分になる期間はごく短いということになる。
そしてもうひとつ考えてみる。
高負荷とは何なのか。
言うまでもなく負荷が高いことである。
負荷が高いとはどういうことを言うのか。
非常に多くの処理を行う場合であろう。
しかし、その非常に多くのそれぞれひとつは実は軽い処理なのである。
例えば、同じ処理でも、10倍の時間を掛けて処理すれば単位時間当たりの負荷は10分の1に減るだろう。
つまり、常にほんの少し重い状態をキープすれば一見重さを感じないのではないか。
ということで、日記の左側メニューを生成する処理を作りました。
ローカルテストではこの機能は一回約0.17秒かかるようで、実際に使うのは数日に一回程度だから多少重くても気にしない。
逆にチャットのようなものだと一回一回が軽くても呼び出し回数が馬鹿にならなかったりしますけどね。
