つーさのくーかん

そういえば5月に入ってから日記を書いていないじゃないか。

ブロック崩しを作っている。

作っているといっても、まだ、1文字もコードは書いてないので
作ろうかなぁと考えていると言った方が正しいか。

簡単だと思っていたけど1つわからないことがでてきてしまった。

ボールが長方形であるブロックにぶつかったときに、
X軸速度成分を反転するのか、Y軸速度成分を反転するのか。
これを判定するスマートなアルゴリズムとはなんだろか。

ブロックの縦横の辺の長さの比とatanを使う？
ボールの半径分太らせた長方形を用意して、ボ線分と円の交差ール中心が今どの矩形内に収まっているかを判定する？
ブロックの4辺に対して、線分と円の交差判定を適用する？
いずれの方法でもやればできそうなのだけど、なにぶん面倒くさがりなもので。

それに、ボールは離散時間上を動くわけでブロックや壁にめり込む。
単に衝突を矩形判定してると、2つのブロックに同時にぶつかりうる。
よくよく考えないと2回反射して貫通弾になってしまうだろう。

現フレームで移動するはずのブロックの軌道を線分で表して、
衝突面での反射をシミュレーションするとか。

ブロックを円にするという誰もが思いつきそうなアイディアを採用すると、
当たり判定は円判定になって、反射方向はベクトルを射影して計算するーとか。

でも、よりうまく反射させるには、同じように軌道を線分化、
ボール半径分太らせたブロック円との交差判定、
めり込むはずだった分の距離を、その交点で反射、か……。

とまぁ、改めていろいろ考えてみると、
アクションゲーム作りを学ぶにはブロック崩しはなかなかいい題材なのかも。
そのうちプロジェクト自体放り出しそうだなぁω

「一般の人」にとっては、もうそういう時代、ね。
理解に2秒を要したらその時点でその機能は使ってもらえない。
FAQ、ヘルプが必要なシステムは設計からして間違ってる。
でも、最後に勝つのはマニュアルを事細かに読んだ人間。

昔は、パソコンのマニュアルとか周辺機器のマニュアルとか分厚いのがついてきて、
私はそのほとんどに目を通したもの。だから、所謂普通の人よりはパソコンに詳しかった。
最近、普通の人と自分を差別化するのが難しいと感じるようになってきたのは、
C#とかインテリセンスとか使ってるせいであり、
すっかり「マニュアル」というものを読まなくなってしまったせいであり、
世の中のソフトウェアが親切になってきたせい、なのかもしれない、なぁ。
そんな私は、未だにマニュアルが必要なプログラムを書き続けている、気がする、が。

今日は音を録音して、UDPパケットで、LAN内の他のマシンに送りつけるプログラムを書いた。
これによりLAN内の他のマシンが再生している音が別のマシンで拾えるようになった。
ここに、TCPリスナとICY 200 OK、MP3エンコーダつけたら、
簡易ネトラジ放送ソフトができる。音ゲの中継もなんのその
netmidiの機能縮小版とでも言うか。なんか昔からこんなことばっかやってるなぁ。

using System;
using System.Windows.Forms;
using System.Net.Sockets;
using Tsukikage.WinMM.WaveIO;

namespace WinMMTest
{
    public partial class Form1 : Form
    {
        WaveIn wi = new WaveIn(0, 44100, 16, 2);
        UdpClient udp = new UdpClient(29999);

        public Form1() { InitializeComponent(); }

        private void Form1_Load(object sender, EventArgs e)
        {
            wi.OnData = delegate(byte[] d) { udp.Send(d, d.Length, "192.168.24.95", 29999); };
            wi.Start();
        }

        private void Form1_FormClosing(object sender, FormClosingEventArgs e)
        {
            wi.Close();
            udp.Close();
        }
    }
}

それにしても、言語が高級になりすぎて、俺にはこれをプログラムと呼んでいいのかわからなくなりつつある。それがC#という言語の恐ろしいところだ。

題名の通り。あんまり突っ込んでやるつもりはなかったものの

続きを読む

画面は開発中のものです。

冬コミはアクションRPGを出します。
去年の夏に出したやつの焼き直しと言えばそうなのだけども。
この画面に写り混んでいるものの中に、私の著作物なんか一切ないのだけど、
無断で載せてみる実験。

続きを読む

動的コンパイルした先のコードで例外が発生すると、スタックトレースの行番号が取れない。
場所 にはメソッド名しか表示されない。コンパイル元がファイルでもダメ。

デバッグ情報を残し、かつ一時ファイルを残す設定にして、後からpdbの読み込みを試みる。

えー。

デバッグ出力コンソールくらいしか用意できないのかしら。printfデバッグω
スクリプトととして使うならデバッグ情報が足りねーのは致命的な気がするなぁ。
ある程度、どんなところでバグることが多いかの経験があればまだしも……。
それでもInvalidOperationException とか InvalidCastException だったら目も当てられない。
えーーーー　どこーーー？？？？　になること請け合い。

未解決。

関係ないけど。今日、西条に初雪が降りました。明日はもっと冷えるそうです。正直……

RPGのシナリオスクリプトを、
C#のあるソースファイルのメソッドとして定義し、
C#コンパイラに食わせることを考える。

スクリプトなのだから、スクリプタさんが書く。
文法こそC#だがスクリプトっぽい感覚で書けるように留意する。

RPGなのだから「メッセージを表示してボタン待ち」のような高レベルAPIを用意したい。
スクリプトの実行はそこでブロッキングして、一見処理が止まってるように見せたい。
しかし実際にスレッドまで止めてしまうとゲームが止まってしまう。どうする？

続きを読む

いわゆるIDisposableをつけなきゃいけないクラスについてabstractな基底を作って、メモリ回収はGCに任せようとか思ってたが。Sceneクラス破棄してスコープアウトしてもScene直下で持ってるリソースのデストラクタが呼ばれず、先にDirect3DとかDirectSoundのDisposeが呼ばれて、ストリーム再生中のバッファでAccessViolationがでる。確かにGCがオブジェクトのデストラクタを呼ぶタイミングは予想できないのに、実験的にはちゃんと呼んでくれてたという意味不明な理由で、あほな実装に走った。今振り返ってみれば、どうしてこのような実装にしたのかわからない。これは由々しき事態だ。結局Paneliaみたいに、親子を考えて寿命管理しないといけない。C#になってもリソースの寿命管理からは逃れられないのか。GSDKで文字を書くとPaneliaよりも極端にFPSが落ちる謎の現象も確認。同じ文字列を描いてるのに、ぱねりあでは700FPS、GSDKでは150FPSしかでない。原因がさっぱりわからなくて困っている。PresentParametersやRenderStateはまったく同じ設定のハズなのに、いったいどこが違うんだ？うーーん……。昨日やっと、ひととおり書き終わったつもりになって、初めてビルドして動かしてみたら、でるわでるわ。バグのやま。まぁ当たり前なんだけど。上に書いたみたいな仕様バグも出てるし、どうしようかな。どんどん完成が遅れていい加減嫌になってくるなぁ。当初5月に完成する予定じゃなかったっけ。