さようなら7月、こんにちは8月

タイトルにこそ季節感を演出してみたものの、結局やることは変わらず。
SDL Lesson15.
Lesson14の内容を応用して、一秒あたりの平均フレームレートをタイトルバーに表示させるサンプルです。

コーディングしてて、目についた新要素もなく、粛々とコーディング。
以下、画像。


へー。うちのコンピューターの出せるフレームレートって、こんなものなんだ。

SDLでフレームレートのお勉強。

Lesson14
フレームレートを使った、単純なアプリケーション。

レッスンサイトの絵もそうだけど、ソースを組んでても、何をしてるのか理解しづらい。
要するに、フレームレートに合わせて文字列が上から下に降りてくるっていうプログラムなんだけど…。
（Enterキーで、落下速度を変化させられる。（言うまでもなく、実際にはフレームレートが変化している））

そんなわけで、組み上げてみたものは、GIFアニメにしてみた。
ただし、キャプチャーした画像枚数が少ないし、動きも雰囲気を味わってもらうためだけのもの（つまり、実際の速度では無い）から、それほど意味があるとは思えないけど。
Bloggerのイメージをアップロード機能でアップしたんだけど、アニメーションしてないみたい。
どうしたものか。。。めんどいから直さないけど。

そうそう、ここのところのレッスンは、Timerってクラスを設計してそれを利用しているわけだけれども、それだとコンパイル後のファイルサイズがめちゃめちゃでかくなる。

そこで利用するのが -02 とか -Os といった、gccのオプションと strip コマンド。
前者はコンパイラが最適化をかけてくれる。
-O2なら（確か）レベル２の速度最適化、-Osならサイズ優先の最適化がなされる。
stripコマンドは、プログラム中から余分なシンボル情報を削除してくれるユーティリティ。

この二つをかければ、おそらくファイルサイズが何もしない時の半分以下になるはず。
お試しあれ。

SDLで遊ぶ。

Lesson13
Advanced Timersってなってるから、もっと精度のいいタイマー関数を紹介してくれるのかと思いきや、SDL_GetTicks()関数をクラスでラップして、（C++から）扱いやすいタイマークラスに仕上げましょうって話題だった。

まぁ、なかなか汎用的なTimerクラスなので、今後タイマーを使うゲーム（ってほとんどのゲームが当てはまるけど）に使えそうな予感。
覚えるだけ覚えて、ゲームは作らないってのもあるかもしれないけど、未来のことは予測できないので。

だもんで画像だけ。
最近Opera ウィジェットに興味が出てきたことはナイショ。
SDL飽きたらそっちにいくかもしれない。



# トップのカンタンUbuntu2の宣伝は、（日付からおわかりいただけるとおり）
# ８月末まで表示させておくつもりです。
# ご不便をおかけしますが、ご了承ください。

SDLで時間を測定その１

うってかわって、
SDL_GetTicks()関数を使って時間を取得しようというLesson12.
マニュアルによれば、経過ミリ秒を取得する関数だそうで、精度はミリ秒単位ってことでいいのかな？

起動してから背景使いまわしだってことに気づいたけど、直すつもりはなし。
（まぁ、画像ファイルさしかえればすぐ直るんだろうけど。）

とまぁ、特にコメントすることもなく、なんとなく組んだだけ。
テキスト表示部分を工夫すれば、ラーメンタイマーぐらいならすぐに実装できるかな？

ズンチャカチャ♪ズンチャカチャ♪

帰りの車中で爆睡しながら、SDLの夢を見ました。

さて、今日も今日とて寝る前のLesson11。
今回はSDL_mixerを使うようで、ちゃんとインストールがうまくいってるかを確かめるいいチャンスになりそう。

そんなわけでざくっとコーディング。
いつもは配布されてるlesson[nn].zipファイルなんて持ってこないんだけど、今回は音素材をもらうためにダウンロード。

音素材は軽快なパーカッションの音源だった。
これなら、ゲーム素材配布サイトで探してもよかったかなぁ？

んで、例によって文字はみかちゃんフォントで描画。
みかちゃん好きになりそう（笑）

いつものように、オプションとして -lSDL_mixer を使わないとコンパイルが通らないので注意。
あと、Mix_PlayingMusic()関数とMix_PlayMusic()関数、Mix_PausedMusic()関数とMix_PauseMusic()関数など、SDL_mixerは紛らわしい関数名多すぎ。
関数名だけで１０分ぐらいハマった。

引数の数が違う関数名のタイプミスなら、コンパイラが教えてくれるからいいけど、Mix_PausedMusic()とMix_PauseMusic()はどちらも引数なしで呼び出せるタイプの関数だったから、実行してから思い通りの動きをしてないことに気づくまで、間違っていることに気がつかなかった。
こういうの、潜在的なバグっていうんだろうね。

本当は、動画で音とか出せてるとカチョイイんだろうけど、めんどいからやらない。
というわけで、動いてる様子画像。

SDL_gfx for Windows (and MinGW??)

SDL_gfxを試してみようかと思ったんだけど、いかんせん公式サイトじゃソースが配布されているだけで、Windows向けlibファイルとか、dllなんかが配布されていない。

で、みんなどうしてるのかと思って探してみたら、どうやらソースから自前でコンパイルしているらしい。
（なんて面倒なことを…）

きっと、ネット上にはそんな迷える私のために、コンパイル済みライブラリを配布してくれている親切な人がいるはずだと思って探してみるも、古いバージョンばかりが見つかる。

古いバージョンで我慢するかな・・・と思っていたところに、JessePなる人物が、2008/7/9付（ついこないだ！）で、最新と思しきSDL_gfxのコンパイル済みライブラリを作ったって、SDLのMLに投稿してた。

これを使わない手はないと思って、さっそくインストール。
（手順はSDL_imageなんかと同じ。）
で、入れたところで力尽きて、まだ試していない（笑）

時間があったら試そう。（どうやら、VC向けにコンパイルされたものらしいから、MinGWじゃだめかもしらんし。）

あと、そこで配布されていたものにはSDL_gfxのヘッダーファイルが含まれていなかったから、勝手に含ませてzipで固めて配布。
LGPLだし、問題ないよね？

（配布物に含まれているのは2.0.17のヘッダーだけど、DLLとlibがそれに対応していない可能性大。｛←まだ試していないことに起因する｝そんなわけで、もしうごかねーぞ、コンパイルとおらねーぞという問題が出たら教えてください。｛＆古いバージョンのSDL_gfxライブラリに切り替えればイケる可能性大なので、あきらめないでください｝）


# 以下、別文の機械翻訳

I need the SDL_gfx pre compiled library.

But, that library not distribute from the official SDL_gfx web site.

Today, I found the web, and I got that files.

Relation:
[I made below zip file include SDL_gfx header files]
[libsdl.org ML archives]
[JesseP's web site]
[SDL_gfx official web site]

楽しいなぁ。SDLは。

プライベートで色々あって、相変わらずのお疲れモードだけれども、SDLは楽しいと感じる。
思えば、プログラミングを始めたきっかけというのが、「ゲームがやりたいけど買えない→よし作ろう」だったことを思い出した。

いつからツールやら実験データの変換フィルターやらばかり組むようになったのかなぁ。

そんな初心に還る思いがするからか、SDLでプログラムを組んでると、「あー。これとこれを組み合わせればこんなゲームになりそうだなぁー。」とか考えながら作ってる自分に気づく。
そしてこれが案外楽しい。

そんなわけでLesson10。
キーボードのどのキーが押されているかを判断するというプログラムなんだけど、我が家では２キー以上の同時押しに反応しなかったし、上下や左右といった反対キーの同時押しも反応してくれなかった。
アクションゲームやRPGつくるぐらいなら困らないだろうけど、格ゲーとなるとどうだろうか？
（後半にジョイパッドの取得があるから、それを応用するのかなぁ？）

これとスプライト処理を組み合わせれば、ダンスダンスレボリューションもどきぐらいは作れるんじゃないだろうかと思った。

例によって画像を複数くっつけようかと思ったけれど、各４キー＋上右＋上左＋下左＋下右という、合計８状態をキャプチャーしてくっつけるのは面倒だから、一枚にした。

最近２レッスン／日のペースで進めてるわけだけど、このペースなら、ひと月ぐらいで全部クリアできそう。
（理論値では36÷2=18なんだろうけど。そんなハイペースでやり続けるとは思えないので。）

ご冗談でしょうファインマンさんだか、ファインマンさん最後の手紙だかにあった、晩年彼が数学や物理学の問題を解くことを「楽しんでいた」という記述を思い出した。
確か彼は、初心に還ってそれらの問題に楽しみながら取り組んでいたというのが印象的だったなぁ。

まったりコーディング。

コーディングとはいえ、やっぱりやるのはSDL。
今回はLesson9、マウスイベントの処理。

久しぶりにC++に触ったなぁという気になった。
ここまでもC++で組んでたはずだけど、クラスとか意識しなかったし（作りもしなかったし）、今回ボタンイベントの処理において、久しぶりにC++でクラスを組んで動かしたわけで…。

ともあれ、マウスイベントをゲーム内で使うってことはそう無いんじゃないかなぁ？
（少なくとも、私が作るようなレベルのゲームではの話。ほとんど2Dのアクションゲームやパズルゲームなんかの、個人が趣味で作り捨て出来るようなタイプのゲームしか作らないし。）

でも、3D空間でキャラクターを動かすときに、マウスで操作できると便利だとか、2Dゲームでも、選択肢を選ぶときのカーソルの動きを、マウスである程度制御できると便利だとか（ノベルゲームなんかの場合ね）、役に立つことがあるのかもしれない。

画像は昨日と同じく、動きがないとわかりにくいタイプのプログラムだったことから、4つをくっつけてある。
重たいので、閲覧するときは注意。




# 最近毎日SDLのレッスンをこなしてるって記事書いてて思うんだけど、ソースもUPするべきかなぁ？
# でも、面倒なんだよね。ブログでそういう類のファイル扱うの…。

最近疲れてるのかな？

しばらくパソコンから離れて、のんびり農芸したり、本を読むのもいいかなと思った。
どうも、目の疲れやら体の疲れやらがとれないからなぁ。

まぁ、生活スタイルが不規則になってるっていうのもあるのかもしれないけど。

と、前置きはよしとして、Lesson8。
ここのところ、SDLが楽しくて、他の事をあんまりやってない。

トラ技の付録も、開けたきり手つかずだし。
接続してインストールして、五目並べゲームぐらい組めば満足するんだろうけど、まだそこまでいかないなぁ。
買っただけ満足なんて、そう無いのになぁ。
どうしたかなぁ。。。

そんなことは良しとして。
今回もみかちゃんフォントを使用。
前回、フォントがやや小さく感じたので、今回はポイント数を48にしてみた。


今回はループ内で押されたキーに対応する再描画が必要なんだけど、それをしてなかったり、7thのプログラムをだいぶ使いまわしたためにifの条件判定にミスがあったりして、15分ぐらいハマった。

gdbの使い方を覚えたいと思うと共に、クロスコンパイル環境だと、デバッグが難しいんじゃないだろうか？と思った。
Turbo debuggerとかでも、MinGWの吐き出すコードってデバッグできるんだろうか？
っつうか、大規模な環境を導入しなくてもさくさくMinGWの吐き出したコードをデバッグできるデバッガってないもんだろうか？（まさにgdbがそれなのかな？どうも、GNUファミリのコマンドをたくさん入れないと動かない気がするんだよなぁ。）

今回のプログラム、起動直後は背景画像が表示されてるだけだけど、矢印キーを押せば、押したキーに合わせてメッセージが表示される。
でも、キーを押していないからって、背景画像だけに戻ったりはしない。
そこをどうしたら背景画像だけに戻るか考えてみれば、キーが入力されている間だけXXするってコードはすぐに書けるようになると思う。

矢印キーの入力ができれば、ここまでのとあわせて、簡単なゲームぐらいなら作れそうな気がしなくもないけど、まだレッスンサイトの半分もいってないから、特別なにかを作ろうとは思わない。

あくまでゆっくりやってこう。

画像は、一枚だけだとわかりづらいかと思って、４枚くっつけてみた。
重たいから、クリックして見る人は注意。




# 追記
ということを書いたあとに調べてみたら、MinGWのGDBがあった。
解説サイトによれば、MSYSとかもダウンロードしろってなってたけど、GDBだけ落としてきて、展開→bin/フォルダからgdb.exeを取り出してみたけど、うまく動いてくれているみたい。
少なくとも、私が実行したいデバッグ作業（主としてブレークポイントの設定とステップ実行）はこなせそう。
これにprintfデバッグをつければ、小規模なデバッグ作業なら事足りるしね。
さ、gdbの勉強もはじめなきゃ。

今日もきょうとてSDL（SDL_ttf で日本語を使う。）

そんなわけでLesson7。
SDL_ttfを利用して文字列を描画するっていうお話。

レッスンサイトでは、lazy.ttfってオリジナルのフォントを使っているけれど、私は使用条件のゆるいみかちゃんフォントを利用することにした。

そのほか、フリー（あるいはそれに近い条件）で使用できるフォントについては、このページがよくまとまってると思う。
真面目なゲームとかじゃ、明朝やゴシックを使いたいこともあるだろうから、状況によっては参考にさせてもらおう。

さて、レッスンサイトのプログラムをそのまま使うと、実は日本語が表示できない。
以前に、今回構築したMinGWで日本語を通すにはソースをSJISにエンコする必要があるって書いたけれども、実はSDL_ttfに限って言えば、それも通用しない。

そのまま通しても、SJISにしても日本語が通らない。
じゃあどうするか？
レッスンサイトで

TTF_RenderText_Solid

となっているところを、

TTF_RenderUTF8_Solid

として、ソースコードをUTF8で保存→コンパイルを通せば、下の画面のように日本語を表示できる。

あとは、

mingw-c++ filename -lmingw32 -lSDLmain -lSDL -lSDL_image -lSDL_ttf -mwindows

としてコンパイルを通せばOK。
そうそう、SDL_ttf.hを#includeで指定するのも忘れずに。

これでSDL_ttfはdevel-VC8をもってきて、ヘッダーとライブラリをいつもの場所にコピーしておけば使えることがわかった。

追々調べてみると、どうやらfreetypeライブラリが必要なのは、*NIX上で文字を描画する場合だけらしい。
（Macだと必要なのかな？）今回の環境は、Windowsへのクロスコンパイル環境だから、freetypeのインストールは必要ないという結論になりそうな感じ。

文字が描画できると、またいろいろ出来そうなことの幅が広がる気がするよね。

SDLの続き。

昔から、継続は力なりと申しまして（以下略

Lesson6。クリップというやつ。
たとえば、この例では一つのファイルに書かれた４つのボールをクリップして取り出しているけれど、実際のゲームだと、キャラクターのモーションパターンやマップチップ、魔法のエフェクトなんかでよく見る。

特にアニメーション系だと、ファイルオープンのオーバーヘッドが気になったりすることもあるから、あるていどの大きさの画像ファイルに、ある程度関連性のある画像をまとめて、クリップして取り出すような操作がいろんなところでテクニックとして扱われているみたい。

クリップまで出来たらから、たとえば適当なマップチップのセットから、マップを作りだすようなことも、ここまで学んだ内容でできるわけか…。



やらないけど。

眠れない。。。

ちょっとばかし、寝るタイミングを逃した感じ。

そんなわけで、SDLの続きをやる。Lesson5。

今回やるのはカラーキーを指定して、画像を重ねてみましょうというもの。
ゲームプログラミングでは必須？最近は違うのかな？？
ミソは

Uint32 colorkey = SDL_MapRGB( optimizedImage->format, 0, 0xFF, 0xFF );

関数でカラーキーを指定するところで、ここのSDL_MapRGB関数の第２～第４引数は、抜きたいカラーをR,G,Bの順に１６進数で指定しなくちゃいけない。
ショッキングピンク（#FF00FF）なら、0xFF, 0, 0xFFってな具合。

そんな調子で作ったのが以下。
キャラの画像出力するとき、キャラのまわりにアンチエイリアスかけちゃったから、微妙にピンクが残ってる（笑）
でもまぁ、一応うまくいったので良しとしよう。

# 追記
よく考えたら、キャラクターの光の当たり方がおかしい。
明らかにおかしい。
やっぱり深夜に作業するべきじゃないな。
生産性どころの問題じゃないや…。

チュートリアルをこなす。

ほぼ日課になっていると噂（？）の、SDLプログラミングを進める。
今日はLesson4。

SDL_mixerやSDL_ttfの使い方じゃなく、イベントドリブンプログラミングの基礎が主題。
前回までは、２秒間ウィンドウが表示されたら勝手に消えたわけだけど、今回はウィンドウの×ボタンをクリックするまで、ウィンドウがそこに居続ける、ごく普通のタイプのプログラムを作ろうって話。

動かしてみると、CPUファンがウァンウァン唸りだした。
whileでループをかけてるのが原因だろうか？それとも、SDL自体が重たいのかな？？

まぁ、とりあえずチュートリアルどおり進めただけだしな。
スクリーンキャプチャーをアップして寝ることにした。

残りのSDL系ライブラリを放り込んでみる。

調べてみたら
・SDL_mixer
・SDL_ttf
・SDL_net
というライブラリがあったので放り込む。
SDL_ttfは、Require:freetypeとあったけど、それはまだ入れてない。

というのも、どのライブラリもSDL_imageの手順に従ってライブラリとヘッダーを放り込んだだけで、テストコード書いたりしてないから、本当にfreetypeが必要かとか、この方法で動くのかとかがわからないから。

テキストの描画をfreetypeに投げてるらしいけど、これは実行時のみなのかな？
だとしたら、dllでこと足りるんだろうが…。

あと、SDL_gfxってのもあったけれど、こちらはSDLプロジェクト内で動いていない風味なのでやめといた。
導入のために、ライブラリそのもののコンパイルも必要だしね。

coLinux + Debian + MinGW + SDL のクロスコンパイル環境で、SDL_imageを使う。

相変わらず資料が少ないこの問題に取り組んでいる。
普通の人のやらないことっておもしろいじゃない？

んで、今日はSDLに機能拡張を施すSDL_imageやらSDL_mixerやらSDL_ttfやらを扱うにはどうしたらいいか？
という問題。

で、とりあえず今日取り組んだのはSDL_imageを使う方法。
公式サイトにはMinGW向けアーカイブがない。
となるとソースからコンパイルするべきか…？

とも考えてしまいがちだけど、レッスンサイト曰くVC8向けのもので良いらしい。

で、VC8向けのdevelパッケージをとってきたらunzipする。
古いMinGW向け情報だと、ここで*.libを*.aに変換するなんて話題が出てくるけど、この件に関して言えば、それは無視してOK。

unzipした中から、include/以下をいつものSDLのインクルードファイルが置いてあるディレクトリに、lib/以下の*.libファイルを、いつものSDLのライブラリファイルが置いてあるディレクトリに配置する。

で、lib/ディレクトリ以下にある*.dllファイルは、Windowsに送っておく。
（レッスンサイトにもあるけど、これらのDLLは、プログラム本体の配布時に一緒に配布しないといけない。さらに予断だけど、libpngとかzlibなんてのは、配布ライセンスが自前のプログラムと異なったりするから、zlibやlibpng（それだけに限らないだろうけど）のライセンスは、ゲーム本体と違いますよ！ってのを明記するべきだと思う。）

ここまで出来たら、プログラムを書く。とはいっても、Load_BMP関数をIMG_Load関数に置き換えるだけ。
前者がBMP専用なのに対して、後者が汎用だと思えばいい。
そうそう、読み込むファイル名の調整も忘れないように。
（違いを理解するために、PNGファイルを別に用意したほうがいいかも。）

（私のようにものぐさで）Lesson2のプログラムを流用しているならば、またもや２秒間、指定した画像を擁したウィンドウが表示されるはず。



但し、ここでまたもや注意があって、それはコンパイルオプションをきちんと指定しないといけないということ。
これまでの段階で、SDLのコンパイルコマンドをスクリプトに直している人なら、（スクリプトファイル名をsdlcppとした場合）

$ sdlcpp [filename] -lSDL_image

ではダメで、sdlcppの中身を直接いじって、

mingw-cpp $1 -lmingw32 -lSDLmain -lSDL -lSDL_image -mwindows

のようにしなければいけないということ。
（SDL_imageぐらいなら毎回使うから、こうしてスクリプトを修正してもいいかもしれないが、ほかのライブラリの場合には、状況によって考える必要があるかも。）

さて、もしもこの手順を守らないでコンパイルするとどうなるか？
それは、_IMG_Loadへの参照が見つからないという旨のエラーになった。（少なくとも我が家では）

（実は、これにつまづいて、ここに到達するまでに非常に時間がかかった。*.libは使えないんじゃないかとか、*.aに変換する必要があるのかとか、そんな無駄な考えを起こしてしまった。reimpがdebianのaptで入れた一連のmingw32関連パッケージには含まれておらず、急遽windows側でgnu-utilsとmingw32-utilsを取り寄せて、ライブラリを変換できるように頑張ってみたりとか。でも、結局それはいらない作業だったってことがわかった。なぜならVC8用として配布されているlibパッケージも、そのままリンクすることができるんだもの。）

coLinux + Debian + MinGW + SDL のクロスコンパイル環境を構築

これまでに、OpenGLが扱える環境を構築してきたので、こんどはそこにSDLの使える環境を追加するという、変態的環境構築。

相変わらず、こちらを参考にさせていただく。

まずはDirectX-develなパッケージをもってきてインストール。
http://www.libsdl.org/extras/win32/common/
インストールとはいっても、/usr/i586-~/include と 同lib/に、展開したパッケージのinclude/以下およびlib/以下をコピーするだけ。
これで、DirectX+SDLなプログラムを、Debian上でコンパイルすることが可能になる。

次に、SDLをとってくる。
SDLオフィシャルサイト
執筆時点では1.2.13が最新安定板だった。

ここで間違っちゃいけないのが、ソースコードをとってきたり、Linux向けdevelパッケージをとってこないこと。
（実はソースなら、Makefileをいじることで対応できなくはないが、めんどいので出来合いのものを使う。）

必要なのはDevelopment Libraries:のWin32項目にある、SDL-devel-1.2.13-mingw32.tar.gzというパッケージ。
なぜなら、コンパイルはLinux上でするけれど、動かすのはWindows上だから。
（VC用のパッケージは、ライブラリの形式が違うから使えないので、そちらも注意。）

ここからとってきたら、tarでSDL-devel-1.2.13-mingw32.tar.gzを展開する。
開くといろいろ出てくるけど、必要なのはinclude/以下のSDLディレクトリとその中に含まれるファイルと、lib/ディレクトリ以下のライブラリのみ。

これを、OpenGLの回よろしく、/usr/i586-~/include/ と /usr/i586-~/lib/ 以下にコピーする。
includeファイルに関しては、SDLディレクトリの中身をぶちまけないことがポイント。

ここまで出来たら準備はOK。
http://lazyfoo.net/SDL_tutorials/lesson02/index.php
のチュートリアルを参考に、テストコードを書く。

よくSDLのサイトで引き合いに出されるtestディレクトリ以下のテストコードは、変態環境においてはあまりあてにならないので注意。

コードが書けた（あるいはダウンロードしてきた）ら、それをコンパイルする。
コンパイルのためのコマンドは、（ここまででmingw-c++をMinGWのC++コンパイラに対するリンクとして定義しているはずなので）

$ mingw-c++ filename -lmingw32 -lSDLmain -lSDL -mwindows

を使う。
コンパイルオプションの指定順序を間違うと、WinMain16@が見つからねーよ！というエラーに遭遇するので注意。（ただし、-lSDLmain と -lSDLの順序は逆でもよさげ）

例によって、これを適当なスクリプトに落して、/home/username/binあたりに保存しておくと使いやすくなる。

これでコンパイルができたら、Windowsに出来上がったファイルをコピーする。
Windows上ではこのプログラムの実行にSDL.dllが必要なので、どこかから落としておくか、さっき落としてきたDevLibに含まれているものを、Windows上に送っておく。

うまくいけば、チュートリアルサイトで示されているような画面が、２秒間表示されるはず。
ここまでいけば、一応うまくいっているといえるんじゃないかと思う。

#追記：画像があったほうがわかりやすいかと思ったのでアップ。
うまくいくと、↓のような画面が２秒間表示されるハズ。



わー。うまくいった。ハッピーハッピー。

お客様の中にclispパッケージはいらっしゃいませんか？

Debian(Lenny)で過去に書いたCommon Lispなコードを走らせなくちゃいけなくて、

# apt-cache search clisp

したんだけれども、Lennyにはどうやらclispパッケージが用意されていないらしい。

そんなわけで、CLISPのオフィシャルからtar.gzパッケージをwgetしてきて自前でコンパイル。
gaucheは用意されているのに、CLISPが用意されていないとは…。
(etchのときは逆だった気がするなぁ。)

# と思ったら、書いたコードをschemeでリライトしたものが見つかったので、CLISPのインストールをしなかった。
# libsigsegvとか探したのになぁ（笑）

イラストレーター10 フォント名が文字化けする問題。

自分の環境ではないが、解決したのでメモ。

ヘルプで呼ばれてみれば、Windows版イラストレーター10のフォント名が文字化けし、かつその化けたフォントで入力しても、文字が入力されない問題で困っているという話だった。

Macとかだと、フォントキャッシュを消すとかいろいろ解決策があるみたいだけど、どうもWindowsで有効な解決策を見つけることができなかった。

んで、結局とった対策は
[編集]→[環境設定]→[キー入力・オートトレース]から、□フォント名を英語表記にチェックマーク（☑）を入れることで解決。

解決とはいえ、フォント名が英語表記になるので、人によっては使いにくく感じるかもしれない。

クリアクリーンのコマーシャル

でんじろう先生が出て、摩擦力がUP！みたいなことを強調してるけど、本当にあの領域に働いて歯垢を落とすのに寄与しているのは摩擦力なんだろうか？

ミリサイズの顆粒が砕けてより小さいサイズになるわけだから、どうやってそこに働いている力が摩擦力であると同定したんだろうか？

そんな測定装置を持ってるのかな？

CMのイメージ映像を見る限りでは、顆粒が上から下に砕けた顆粒を押す圧力で、歯垢を押し出しているように見えたんだけど…。
あの削り取ってる感じを、摩擦力が働いて…って表現してるのか？

ちょっとアヤシイこと言ってるCMなんじゃないだろうかと思った。

MinGW + coLinux + Debian + OpenGL のクロスコンパイル環境で日本語を扱う。

タイトル長いけど、先日作った環境において、日本語を扱うにはどうしたらいいか？っていう話。

結論からいえば、

 $ nkf -s [original_filename] > [output_filename]

というスタイルにすればよし。

つまり、解説したようにして導入したMinGWコンパイラは、SJISなら日本語が扱えるように作られているということ。

それに対して構築したDebian環境はUTF-8を文字コードとして選択しているから、そのままコンパイルに通してしまうと日本語が文字化けする。

したがって、日本語を含んでいるUTF-8なりEUC-JPでエンコされたソースコードを、nkfなりなんなりでSJISに変換してからコンパイルを通してやればOK。

これはOpenGLに限った話ではなく、コンソールで日本語を使うときも同じだけど、自分があんまりコンソール上で日本語を使うことがないので、OpenGLも含めた環境に対してメモしておく。

「俺はプログラムの表示メッセージは、可能な限り日本語にする派だ。いちいち変換なんて面倒だ。」という方は、シェルスクリプトを組めばいいと思う。




# なんにせよ眠い。

トランジスタ技術８月号

書店でみかけて、USBマイコンに負けて購入してしまいました。
トランジスタ技術のホームページはこちら。

今さっき、書店の袋から出したばっかりなので、ぜんぜんさわってないんですが、久しぶりの衝動買いメモということで（笑）

Linux/Windowsのクロスコンパイル環境の構築２

つづき。

http://www.libsdl.org/extras/win32/common/opengl-devel.tar.gz
から、OpenGLのヘッダーファイルをもってくる。

tarで展開して、/usr/i586-mingw32msvc/include/下に、展開したヘッダーをコピー。

次に、glutを放り込む。
ナマのOpenGLたたくより便利だろうから。
そんなわけで、
http://www.rimath.saitama-u.ac.jp/lab.jp/tsakurai/opengl/mingw-lib/
からglut.hをとってきて、OpenGLのヘッダーを叩き込んだところに同居させる。

こちらのサイトにあるサンプルソースを拝借して、適当にテスト用のCプログラムを書く。
書けたら、

$ mingw-cc filename -lglut32 -lglu32 -lopengl32 -mwindows

などとしてコンパイル。
できあがったファイルを、Windowsにもっていく。

Windowsサイドでは、
ftp://ftp.sgi.com/sgi/opengl/glut/glutdlls.zip
あたりからdllをもってきて保存。そして展開しておく。
展開したら、パスの通ったディレクトリか、さっきWindows側にもってきた、Linuxで作ったexeファイルのある場所と同じ場所に、glut32.dllとglut.dllをコピーする。

ここまでできたら、持ってきたexeを実行する。
で、下図のようになればOK。うれしいたのしい。ハッピーハッピー。

Linux/Windowsのクロスコンパイル環境の構築１

というわけで、coLinux+Debian(Lenny)+mingw-cc+OepnGLで、Windows上で動くOpenGLアプリをcoLinux上で作れる環境を整えてみようっていう話。

以前にetch上で整えたときに、時間があればまとめる的な話をしつつ、まったく手をつけていなかったのに、今回の再インストールという事態になったため、早めに残しておくことに。

まずは

# apt-get install mingw32 mingw32-binutils mingw32-runtime

で、必要なものを放り込む。

次に、

# locate mingw32

して、mingw32コンパイラなどの関連ファイルを見つける。
我が家のcoLinux+Debianでは、/usr/bin/i586-mingw32msvc-*としてコンパイラ群がインストールされていた。

そこで、これに対してシンボリックリンクを作成し、コンパイルの時打ち込むコマンドが少なくて済むようにする。
私はmingw-ccをCコンパイラに、mingw-c++をC++コンパイラに割り当てた。
全体で使うなら、コンパイラのあるディレクトリ内に一緒にシンボリックリンクを作成してもいいけど
個人で使うだけなら/home/user_name/binあたりに置いとくほうがいいかも。

リンクをはったら、

$ mingw-cc --version

とかして、うまくいってることを確認。

うまくいっていたら、Hello world.あたりを書いてコンパイルする。
コンパイルしてできたファイル（デフォルトならa.exe）をWindowsに移動させ、実行する。

うまくいったら、クロスコンパイル環境はできあがり。
（ここまでうまくいってれば、mathライブラリを使うときのコンパイルオプション-lmとかも普通に通るはず。）

まずはここまで。
OpenGL導入は次の記事で。

プラスの電子

coLinuxの話題ばかり書いているので、たまには日記風のことでも。

今日、みなとみらいというところに行ってきたわけですが、そこにある、巨大ショッピングモールで不思議な名産品を見つけました。
写真を撮ってこなかったので、文章だけで伝えなくちゃいけないのが残念ですが、モノは炭で作られた置物でした。

犬の形やらねこの形やらしていて可愛らしく、脱臭剤代わりに部屋においておいてもいいかな？と思うようなつくりでした。

が、その宣伝文句がちょっと不思議。
曰く、「お部屋にある悪いプラスの電子を取り去り、マイナスの電子を放出してくれます」




…電子って、プラスに帯電してたっけ？




あれ？陽電子の話？
でも、陽電子を吸収して、通常の電子を放出するんだとしたら、中でどんな変換が行われているんだろうか…。

coLinux - cofs を利用して windows とファイルをやり取りする

便利なcoLinux。
Windowsとのファイルのやり取りも手軽。
最近じゃsambaなんてモダンなものを導入するのが流行りのようだけど、私はこっちのほうが好き。

以下、導入手順のメモ。
メモに残す理由は、今回ハマった部分があるから、次回の参考にするため。

手順１．filename.confに、cofsを使う旨を記述。
たとえば、c:\workをcofsでマウントするなら、次のように書く。

cofs0=c:\work

設定ファイルの末尾にでも追記しておけば、幸せになれるかも。

手順２．/etc/fstabに設定を書く。

cofs0   /mnt/win  cofs  default,uid=username 0 0

あたりを追記しておけばいい。
uid=usernameとしたユーザーが、このディレクトリの所有者になる。
gid=groupnameとすれば、ディレクトリの所属グループも設定できる。
これをしておかないと、root以外は書き込めなくなるので注意。

不安なら、手順２．の前にmountコマンドでただしくマウントできるかチェックしておくとよさげ。

Lenny快適。

せっかくコメントをもらったのに、Archじゃなくてスイマセン。
後日、まとまった休みがとれたときにでも、Arch+coLinuxでの日本語TeX構築をがんばってみたいと思います。

それにしても、Lenny快適すぎ。
TeXは日本語環境やらdvipdfmxまで含めてaptでぽんと手に入るし、lennyではgaucheまで手軽に入手することができた。

ただし、やっぱり日本語周りは手動インストール。
特に意味は無いんだけど（笑）

途中、uim+emacsの連携において、uim-el-helper-agentが反応しないってエラーでうまく機能してくれない症状に遭遇したけれど、AnthyのINSTALL末尾にあった環境変数に、/usr/local/libをセットすることで解決した。

emacs+leim+uim+anthy（やけに連携するやつが増えたな(^^;）で、かなり快適に作業できています。
この調子なら、必要な資料作成にwordを使わなくて済みそう。

よかったよかった。

むぐ、むぐ、むぐぐぐぐぐ～

Arch Linuxはとっても良い環境だと思う。
けれど、TeXまわりがそろわないのは、今の私にとっては致命的だ。

なので、Debianに帰ります。
さよなら、Arch。

# 追記
あ、せっかくなんで、
http://d.hatena.ne.jp/masahi6/20071119/1195471511
を参考にlennyにしてみました。
Emacs22にも慣れておきたいしね。

ごりごりと環境構築

TeXLiveはインストールをするものの、texconfig-sysが無いってインストールスクリプトに怒られたりする。
でも、どのパッケージに所属しているのかもよくわからないし、X serverとか余計なものまで入れてくれちゃった。

いくら依存関係の問題とはいえ、本当に必要なものじゃない気がするんだけど…。
↑ということを思った人たちが、新しいパッケージシステムを考案するのかな？と思った（笑）

で、emacs22に手をつけている。
特に日本語まわり。
これまでの.emacsを流用したいから、anthy+uimでいこうと考えている。

んで、pacman -S anthy とか pacman -S uim したら、ものすごい依存関係が示される。
gnome-panelとか…。いらんだろ。

結局、これまでに倣ってソースからビルドすることに。
途中、gettextがみあたらねー！って怒られたけど、それはpacmanで解決。

インストール自体はうまくいったみたい。
でも、肝心の日本語まわりがうまく動かない。

特にanthy+uimの時。
anthyオンリーなら動かすことができた。（LEIM経由だけど。）
でも、uimはLEIM経由にすると、うんともすんともいわなくなるし、LEIM経由じゃないと、モードを切り替えた際、モード欄に Look[_] なんて表示される。これまでここは、日本語入力をONにすれば[あ]になってくれていたはずだ。

そんなわけで、原因究明をしながら、しばらくはanthyオンリーで我慢。
おそらく、解決策はLEIM近辺に潜んでいると読んだので、そこを中心に情報収集することにしました。

もし、今 Anthy + UIM + Emacs22 + Arch Linux で日本語入力してるぜ！って方（特に、anthy,uimはソースからビルドしましたって方）がいらっしゃいましたら、コメントをください。
あなたのコメントが、私を救うかも知れません。

#追記。
解決。
やはり、uim-leim.elを叩くことで解決できた。
具体的に利用している、anthy+uimまわりのコードが以下。

;; anthy
(push "/usr/local/share/emacs/site-lisp/anthy/" load-path)
(load-library "leim-list")

;; uim-leim
(push "/usr/local/share/emacs/site-lisp/uim-el/" load-path)
(require 'uim-leim)
(set-input-method "japanese-anthy-uim")
(setq uim-default-im-prop '("action_anthy_hiragana"))
(setq uim-candidate-display-inline t)
(toggle-input-method nil)
(global-set-key "\C-\\" 'toggle-input-method)

無くても動くものがあるのかもしれないけれど、私の頭の中では
・leim-listでemacsにanthyの存在を告知
　↓
・uim-leimでanthy+leimを捕まえる
　↓
・C-\でuimを起こして、入力をする
的な流れなんじゃなかろうかと。

こういうとき、Lisp読めてよかったと思うよね。

快適空間。ArchLinux。

一度構築してしまえばこちらのものだ。
256mbイメージではやはり狭苦しいので、5gbの新しい家を用意してやる。
今回は元が256mbと小さい環境だったので、ddを使って環境を移築した。

emacsやzsh、sudoといった、普段使いのアプリケーションを入れて、環境構築は完了。
emacsが22になった。（debianでは21を利用していた。）

ArchLinuxの公式wikiにあったhowtoに従ってsshdを動かし、ssh経由でログインできるようにした後、作業用ユーザーを作って完了。

さて、ここからTeX環境を整える作業に入るわけだが。。。
これがうまくいかないことには、使える環境にはならないぞ（笑）

#追記
弱った。
一番重要なTeXまわりが、一番厄介そうだ。
TeXLive以外に選択肢はなさそうなんだけど、TeXLiveは日本語周りがアレみたいだし…。
そもそもdvipdfmxとか動くんだろうか？
心配になってきた。
はてさて、どう転ぶか…。

こんにちは。Arch Linux。

めちゃめちゃ苦労した（笑）
やっぱり悔しくて、試行錯誤してようやく導入できた。

結論からいえば、pacmanの責任。
恨むぜ、ナxコ。

というのも、以前にレポジトリの変更があったらしく、pacman3以前だとうまくアクセスできないようになってしまったらしいから、それが原因じゃないだろうか？というのが結論。

らしいばっかりで、憶測だけども、手元じゃそれでうまく言ってるから、あながち間違っていないと思う。
実験事実こそすべてなのだ。

それで、肝心の解決策だけれども、512mbイメージじゃなく、256mbイメージを使うことで解決。
ナンジャソリャ。な解決だった。

でも、動いてるし問題なし。
一通りアップデートしたら、環境を充実させることとか、Archの使い方とか、少しずつ勉強していこう。

ともあれ、TeXでしたかった作業は間に合いそうにないから、OpenOffice.org Writerで仕上げた。
たまにはいいだろう。でも、やっぱりTeXのがいいと思うんだな。

早く環境そろえなきゃ♪

というわけでFedora7+coLinux

Fedoraは８やら９やら出ているらしいけど、とりあえず７で。
http://d.hatena.ne.jp/tetsuarossa/20070923/p1
を参考に環境を整えた。

ダウンロードも含めて、所要時間３０分ほど。
ものすごくお手軽。


でも、すごく負けた気がする。
できれば、Archを導入したい。
次のまとまった休みにでもやるかな。


それにしても、こんな時間まで、何してんだ俺。

#追記。
せっかくなので、fedoraからyum install wgetしてwgetの動作を検証。
あれ？うまくいく…。
どういうことだ？
なぞだ。。。

原因不明のエラーにお手上げ。

coLinux + Arch Linuxの話。
pacmanでエラーが出るために先に進めないことがわかっているので、その周辺を調査。
と、どうやらwgetがファイルをとってこられないのが原因らしいことを突き止める。

が、手動でwgetしてみるも、ダウンロードできない。
ためしに、arch関連以外のファイルをとってこさせるとうまくいくので、arch関連、特に拡張子が.pkg.tar.gzのものに限ってそうなようだ。

よく見てみると、ファイルサイズ不明の警告を出す場合や、550のFTPエラーを返してくる場合もある。

まったく理解できない。
フォーラムも一通りあさってみたけど、近いものは出てくるものの、決定打となる解決策はなし。
そんな訳で、原因不明のエラーにお手上げ。

でも、Linux環境はなんとしてもそろえないといけないからなぁ。

かといってUbuntuに行くのもなぁ。
VineじゃUTF-8が標準じゃないし…。
Fedoraでも試してみるか？

悔しいからリトライ。

Archに失敗したから、Debian 4.0に戻ろうとおもったら、イメージの配布がされていない…。
ここでUbuntuに逃げたら負けだと悟り、リトライすることに。

もう少し情報を集めてきます(`Д´)ゞ

#追記
よく探したら、etchがあった。
でも、ここまできたら戻れまい。

coLinux + Arch。挫折。

そんなわけで（どんなわけで？）

coLinux + Arch Linuxの導入メモ。



まず、coLinuxのダウンロードページ（sourceforge内）から、ArchLinux-0.7.2-ext3-512mb版をダウンロード。

そして展開。

（7zなんてマイナーな圧縮方式じゃなく、せめてbzip2とかにすればいいのに。）



展開したものを、coLinuxのあるディレクトリにコピー。

コピーしたら、ArchLinuxSlirp.batをエディタで開いて編集。

メモリ量増やしたりする。

どうせコンソールしか使わないし、96MBぐらいにしとこう。

それから、cofsとしてc:\をマウントするようになってたりするアブナイ設定だったから、適当なディレクトリに直しておく。



あと、（起動スクリプトの名前からしてアレなんだけど）slirp使うみたいだから、tuntapに直しておく。



直ったらコマンドプロンプトから起動。

rootでログイン。

パスワードはかかってないみたい。



で、

# cat README.1st.orig

して、ファイルの内容どおりに設定やらなんやらを行う。

（実は最初、これを無視してnanoで設定ファイルを編集しようとしたところ、nanoもviもpicoも入ってなくて焦った。）

e3viなるエディタを使うらしい。そのほかにもe3**なエディタが用意されているから、使いやすいのを選ぶとよさげ。

ｃ⌒っﾟдﾟ)っφ　ﾒﾓﾒﾓ...



とりあえず、/etc/fstabを覗いて怪しい設定がされてないことを確認し、/etc/pacman.confでpacmanの設定を行う。

currentとextraぐらい設定しておけばいいか。

testingの書式が参考になる。



で、/etc/rc.confの修正にはいる。

使用言語とかタイムゾーンとかあるけど、それらの設定は後回し。

まずはホスト名とネットワークを設定する。



ついでだから/etc/resolv.confでnameserverも設定しとく。

で、reboot。



yahoo.comあたりにpingして、ネットワークが生きているのを確認。



screenしてから/root/get.shで、pacmanによる自動ベースシステムインストールのスクリプトを見守る。



……いろいろ試行錯誤するも、挫折。

フランスだのドイツだの、世界中にネットワークでアクセスしようとしている様子。

でも、どれもこれもアクセスできず…。

をい…。

資料少ないし、お手上げでございます。

coLinux

久しぶりのcoLinuxネタ。

しかもアップデート以外。

とはいえ、作業前の報告なんですが。



先の記事でポストしたとおり、システムの再インストールを余儀なくされたので、この際だからいろいろとソフトウェア構成も（可能な範囲で）変えてしまおうと画策中です。



すでにFirefoxをやめてOperaにしてみたり、Avast!をやめてAviraにしてみたり、Adobe ReaderをやめてFoxitにしてみたりと、あれこれ動いているわけですが、一通りそろったところで手をつけようとしているのが、coLinuxなわけです。



いや、実は、昼間・・・というか今朝方andLinuxでお手軽環境構築だー！

などと勇んで構築してみたものの、リソースを馬鹿食いすること、起動速度が遅いこと、Xの反応がいまいちなこと、ネットワーク設定がめちゃめちゃなこと（インストール時に設定させてくれないこと）、日本語周りが弱すぎること、rootでの作業を余儀なくされること…など、たった数十分ほどの使用で数々の不満が噴出したために、さっさとアンインストールしてcoLinuxに戻ろうというわけなのです。



実は、Linux上でこなさなくちゃいけない作業がいくつかあったりするわけなんですが、そんな中で今チャレンジしようとしているのが、DistroFreakで、記事書きのために１時間ほど使った経験があるだけのシステム、Arch LinuxをcoLinuxとあわせて動かしてみようってものです。



うまくまとまって記事にできるといいなぁと思ってます。

さぁ！がんばるぞー！







…途中で挫折したらごめんなさい。

Windows再インストール

いろいろあって再インストール。

ただ一言私から言わせてもらえることがあるとすれば、「β版には要注意」ということ。



あとは察してくださるとうれしいです。



で、いつもバックアップはとっとけと言うだけあって、きちんとバックアップしてあったはずなのに、やっぱり落ちはあるわけで…。



その落ちとは何か？



私の場合、メールだった。

普段からメールのバックアップをとる癖をつけていればよかったのだろうけれど、Thunderbirdで簡単にメールバックアップを取る手法がないか探したものの見つからなかったことから、メールのバックアップというのを放置していた。



それで、今回の再インストール…。

実に数年分のメール（といっても、ほとんどMLからのメールだが）がパァだ。

次回からは気をつけるようにしよう。



そんなわけで、メール送ったけど帰ってきてねぇぞ！な方、あるいは重要なメールを送ったけど、返事がないぞ！な方。



申し訳ないですが、もう一度メールしてください。

Adobe Reader 9

リリースされたらしいので，試してみることにした．
私は，文書をTeXで書くことがおおいのだが，出力は必ずPDFにする．
だから，確認のためにもPDFビューアは必須なのだ．

動作の軽いFoxitというツールを使っていたこともあるが，表や図が崩れる場合が多いことから，結局利用しなくなってしまった．

さて，話を戻そう．
Adobe Reader 9の話だ．
まず，おかしいと思った点から．

・Adobe Download マネージャー　Add-on　のインストールを要求してくる
私がインストールしたいのはAdobe Reader 9だ．
なのに，なぜダウンロードマネージャーまで入れなくちゃいけないんだろうか？
目的のソフトにたどり着くために，なぜよけいなソフトを導入しなければいけないのだろうか？
先日ニュースになったビルゲイツのメールにも，よけいなソフトを入れさせるなという文句があったそうだが，作っている側は，なにがうれしくてこんなによけいなソフトを入れさせようとしているのだろうか？
これは，明らかにおかしな点であると思う．

・PDF+Flashって，本当に必要だったの？
これは9で新しく追加された，Flash再生機能に関するものだ．
Flashは，最近Webサイトや広告でも多く使われるが，案外重たいコンテンツだ．
ブロードバンドが普及しているから，あまり気にならなくなっているのかもしれないけれど，その実，CPUのパワーをガツガツと食らっていたりする．
そして，PDFといえば，（Adobe Readerの起動速度が遅いことも相まって）重たいファイルの代名詞となっている．
その二つをくっつけるというのは，とても正気の沙汰とは思えない．

・なぜインストール先を尋ねてこない？
ダウンロードマネージャーを利用したインストールでは，勝手にHDDドライブの「どこか」にインストールされる．
「どこそこに入れますよ」あるいは「ここにいれますけど、いいですか？」、また「インストール先のフォルダを教えてください」に相当するメッセージはいっさい出てこない．
だまって作業を進めて，黙って終わる．
作業ログすら画面に表示しようとしない．
そう，インストールされたファイルの一覧すら表示してこないのだ．
これは，最初にダウンロードマネージャー Add-on をインストールした時点で，もしマルウェアたぐいを入れられたとしても，文句を言えないということではないだろうか？
もしかしたら，メッセージが大量にでるとあたふたしてしまうユーザーには優しいのかもしれない．
が，それはこちらに選択する余地を残しておくべきだろう．
あまりにも，開発者よりのソフトウェアづくりな気がしてならない．

（9になったために付け加えられた，これまでにない）良いところは，今のところ見つかっていない．
起動速度も速くなったらしい．けれど，手元では体感できるほどではないので特筆しない．
（確かにソフト単体での起動は早くなったのかもしれない．が，このソフトはPDFを素速く開けてこそだと思う）

あと，勝手な妄想かもしれないが，起動を早めるために，裏でプロセスを常駐させてたりするんじゃないだろうか？
もしそうだとすれば，言語道断な作りだと言えるんじゃ無かろうか？

ScribeFire 2.2.8

アップデート．
ScribeFire QuickAdsなる，広告表示サポートみたいのが付いた様子．
なんか，方向性間違ってる気がしなくもない．

それから，これまでトップページで更新された情報が確認できてたのに，それができなくなったのも不親切．
やっぱり方向性が違う気がする．

でも，他に代替えツールが無いから仕方ないね．

マウスを買い換えた。

５年ぶりぐらいにマウスを買い換えた．
左クリックがダブルクリックとして認識されてしまうことが多くなってきたことと，ホイールの動きがイマイチになってきたことの２点が主たる理由だ．
（「マウスは消耗品だ」なんて誰かに言われた気がするけど，自分の場合，キーボードの方がへたるのが早くて，マウスってそんなに買い換えたことないんだよなぁ．）

で，どれを購入していいやらわからないっていうのと，とりあえず上記の不満点が解決されればいいやという思いから，ビックカメラで４８０円というセール品を買ってきたのだが，あけてみるとチルトホイールなる，横スクロールも可能なホイールのついたマウスだった．
横スクロールホイールなんぞ，出た当初はこうして手にするとは思いもしなかったのに・・・．

今やこれほどの製品が，ワンコインで手に入るほどの時代になったということか．

年寄り臭いことをいっているが，使い心地は上々．
半年保証もついているっていうし，満足いく買い物・・・だったかな？たぶん．
（この先使い込んでいくと，不満が出てくるのかもしれないね）