日記みたいな何か

シューティングゲームアルゴリズムマニアックス買いました．まあ，SDLちまちまいじってたのは，これ読んで弾幕とか動かしてみたいと思ってたからなわけだったりします．で，ちょっと読んでみたんですが，すげー面白い．これはためになります．

cvs版，さっそく直ってました．

uim-0.3.9キタ━━━━(゜∀゜)━━━━ッ!! というわけで早速インストールしたわけなんですが，もしやとおもったら，やっぱりmltermがuimオンの状態で上がらなくなりました＿|‾|○．せっかくcvs版かっこいいので捨てたくないわけなんですが，uimの最新版もやっぱり試したい．というわけで，何が悪いのかを調べてみました．めんどくさいので途中経過は省略ですが，結局 uim/uim.c の中で，contextのprop_list_update_cbやprop_label_update_cbを呼ぶときの引数がコンテキストを指すポインタから，コンテキストを指しているコンテキストのメンバのポインタに変わったからのようです(書いててわけわからんですね・・・)．

まあ，きっとmlterm側でここらへんをちゃんと初期化してないから不味いんだろうと思い，コンテキスト作るときの引数とか直したところ，起動するようにはなったものの日本語入れようとした瞬間落ちます．これ以上追うのもめんどくさいし，きっと数日以内に佐藤さんによる修正が入ると見て，この辺で切り上げ．とりあえず，uim/uim.cの側のprop_list_update_cbとかの引数を前のと同じように直して誤魔化して使ってます．

疑似スプライトっぽいもんを実装してみました．が，重い・・・．とりあえずRLEアクセラレーションが効いてないと思われます．何とかせねば・・・．

とりあえず60FPSはかりつつグラフィックを動かす，みたいなところまでやってみました．ていうかほんとシンプルですなぁ，SDL・・・．OpenGLも押さえとかないと・・・．

最近どうなのかな〜，と思いつつもここ数日cvsサーバにつながらずもどかしい思いをしていたわけなんですが，今日リトライしてみたらつながりました．しかも，何かuim回りの機能が強化されている！素敵！が，半角カタカナ入力については，相変わらず自分の環境だと表示が変です(「アイウエオ」と打つと「12345」と出る)．う〜ん，何か設定し足りんのか・・・．

VMWare-4.5.2が出ていたんで，早速インストール．というかさっさと買わねば．ところで，VMWareで音を出そうとすると，/dev/dspを直接叩こうとしてくれちゃうのでaossとかesddspとかかませて多重化したいところなんですが，LD_PRELOADしても効かないわけです．当初，vmware-vmxがsuidされてるからだろうと思ったんですが，suidビット落としてrootで起動してもやっぱり生で/dev/dspを開いてしまうようです．軽く調べたところ，ここに答えらしきものが載ってました．どうもvmwareではopenではなくopen64を使っているためにLD_PRELOADで引っかけられないようです．というわけで，上記URLにあるようなライブラリを噛ませたところ，見事鳴るようになりました．が，なんか起動時にttyのopenに失敗したとか不吉なメッセージが．うまくいってないのか？まあ，とりあえず鳴らなくていいか．

ちょっと始めてみました．とりあえずスプライトを動かすところから，と思ったんですが，こういうのってスプライトっていうのか？？？

先日，UNIX USERの記事見てやったらPPP over SSHうまくいったよ〜，とか書いたわけですが，実はうまくいったのはLinux - Linux間 およびLinux - NetBSD間の接続でして，Linux - FreeBSD間はコネクションが張れるのにpingが通らないという状態でした．まあ，自宅のNetBSDや出先のLANのNATやってるLinuxとの間でPPPできるだけでも十分便利なんですが，同じく出先のLANでNATやってるFreeBSDに繋げないのは何か悔しいし，他の利用者のニーズを考えるとLinux機よりこっちにPPPできた方が圧倒的に便利なので，やっぱ何とかしたいわけで，気合いで頑張ってみました．

といっても，何が悪いのか全然わからんので，まずはクライアントとしているT40の側からEtherealで調査してみました．とりあえずpppの反対側にpingを打つと返事が無いわけなんですが，Etherealで見ているとeth0の方からちゃんとパケットが出ており，サーバ側からの返答もきています．が，ppp0の方を見るとまったくパケットが流れません．また，サーバ側ではtun0にパケットがきています(pingに反応しているんだから当然か)．ということはクライアントで受信した際にsshからpppに上げ(？)そこねているってことなんでしょうかね．

そこで，受信側のLinuxを相手にした際のパケットとFreeBSDを相手にした際のパケットをEtherealでキャプチャして比べてみたところ，何か同じpingなのに一部パケットのサイズが違う・・・．んんー，もしかして圧縮の違いとかなのかなぁ．試しにsshのオプションから「-C」を外してみましたが効果無し．ならば，pppdのmanに載っているcompressを含むものを上から順にと思い，まず「bsdcomp」を外したもののこれは効果無し．ならば「deflate」はどうだ・・・，キタ━━━━(゜∀゜)━━━━ッ!! pppdに「nodeflate」つけたらpingが通りパケットがすいすい流れ始めました．うほほ〜．しかしこうして書いてみるとあっさり解決したように見えますが，何かここにたどり着くまで随分時間かかりました．ああ，疲れた・・・．

ちなみに，FreeBSDのpppだと「set ifaddr 192.168.1.2-192.168.1.253」とかすれば相手のIPアドレスをそっから勝手に選んでつけてくれるようですが，pppdでこれやる方法がわかりません．検索して引っかかったhpのページ見るとなんかttyの番号見てスクリプトで決めるとかすごいことやってますが・・・．どうすんだろ，これ．

実はPPP over SSHに再挑戦する前に，OpenVPNの方にも再挑戦してたりします．こっちはこっちでLinux側のカーネル再構築で突然シンボルが解決できなくなったり(これはソース展開しなおして.configコピーしたら直った)とかして導入までにまたえらく時間がかかったんですが，設定した後はわりとすんなり開通してくれました．ただ，その後，欲が出てクライアント側がサーバ側のDHCP見てIP取得するにしてやろうと考えたのが大失敗．tapを使ってブリッジする，みたいな話だと思うんですが，全然うまくいかず，同じような環境でやってる人もなかなかWebで見付けられず，あれこれ試して散々苦しんだ挙げ句ギブアップ．しかも，よく考えたらOpenVPNって多人数相手のPPPっぽい使いかたには向いてない気が・・・．無駄な時間を過ごしたかも・・・＿|‾|○．

でこっちはPPP over SSHが動いた後の話．今日ここまであれこれ超はまったのに懲りずに，なぜかこの前ちゃんと動かなかったPPTPの方の原因追求を始めちゃいました．そしてお約束通り，またしてもばっちりはまるわけです．先のPPPで使ったLinux機のNATの下にT40ぶら下げて，そこからFreeBSD側のNATの傘下に入るような実験をしたんですが，やはり先日と同じでGREが通らない系の状態に・・・．途中のNATではiptablesとipfilterが動いてるんで，ひょっとしていつの間にかこの辺でGREはたく設定になってんのか？と疑ったりもしたんですが，別にそれが原因というわけでもないようです．ちゃんとWindowsからやってるのに何で何で〜？

FreeBSD側のNATの下にあるWindows機からは普通にPPTP接続できたんで，poptopの設定自体には問題なさげ？じゃあT40こっちにぶら下げたらどう？あ，Linuxからはできるけど，VMWareのWindowsからはダメだなぁ・・・．ってひょっとしてVMWareだからまずいのか！？ホストOSとNAT介してつながってるからダメなのか！？・・・NATやめてブリッジにしたらあっさりつながったよ＿|‾|○．ああ，全然「ちゃんと」Windowsから実験してなかったのが敗因だったわけですね・・・．いつまでたってもネットワーク回りのトラブルシューティングが下手なままなのが実に悲しい・・・(;´д`)=3．

早速インストールしました．kpilotはあいかわらずダメでした．残念・・・．