swfmill
swfmill
について調べてたら土日が終わった。

成果はほとんど無し、Flexもそうなんだけど、結局はFlashやってActionScriptやれってことなんだよ。先走りすぎた。
yum糞
linuxな人ならyumとお友達なんだけど、yumでapache入れたら糞ゴミconfigで糞チンポで死んだ。
殺した。
rand関数を使わずにBox-Muller法を使う
#define PI 3.141592653589793

int bm_rand(void) { /* Box-Muller random */
return (int)fabs((sqrt(-2.0*log((double)rand()/RAND_MAX))*cos(2.0*PI*((double)rand()/RAND_MAX)))
*RAND_MAX-1);
}


例えばこんな感じでエセBox-Muller法な乱数生成をすると、ふつーのCのrand関数よりもキレイな感じになってとってもお買い得。



0〜99の乱数を10億回、それぞれ生成した昇順な分布表。
Box-Muller法のほうがかっちょいいでしょ。
E6750 オーバークロック(その2)
以前のエントリでE6750は400が限界とか、420が限界とか抜かしたが、460でもいけた。

デフォOverClock
CPU
Core Voltage1.248V1.344V
Core Speed2.66GHz3.68MHz
Bus Speed333MHz460MHz
Rated FSB1.33GHz1840MHz
メモリ
Frequency400MHz460MHz
FSB:DRAM5:61:1
ベンチマーク
Superπ2分1秒1分25秒


これで安定、1週間放置したけどフリーズせず。
メモリは512MB3枚のうち2枚が糞バルクなので1:1で妥協。燃えるよ。

次回はクロックを下げてファンレスなC2Dに挑戦。
割り算について
10/21.546
10*0.51.516
10>>11.375
表はそれぞれ式と、10億回計算したときの処理時間。

ちなみに3つの式とも、解は同じ。
10 / 2 = 5
10 * 0.5 = 5
10 >> 1 = 5

ちょっとだけALUとお話しできた気がした。
僕と計算機
スポーツ選手がスポーツをしている姿はかっこいいように、
計算機が計算している姿というのも、またかっこいいんですね。

計算機も、生き物です。
計算機もいつか死にます。
計算機の死に際に、飼い主であるあなたはこう思うに違いありません。

こいつにはいつも迷惑ばかりかけて(エロゲーばかり計算させて)いたなぁ・・・、ゆっくり休めよ・・・と。

悲しい、悲しいです。計算機の散り際というのはとても悲しい。
今までいっぱい計算させて疲れ果てた末路です。

生涯をエロゲーの処理に費やした、それはとても悲しいとは思いませんか。
まさにあなたを写す鏡のよう。
そう、計算機はあなたの人生そのものです。



うちの計算機は最近CとJavaばっか計算していて退屈のご様子。
たまにはエロゲーでも計算させてやろうかなぁと思った。

そういえばエロゲー、久しくやってない。
メモリを使ってCPU負荷軽減するヒント


この画像を使って



こう表示したいと。



が25個。
なので描画処理は25回。



25回を1回に減らす方法。

表示されない画面領域を作る。

を25回描画する。


が完成する。

あとは

を描画するだけ。

初回に25回の描画処理をしなければならないが、1回やっちゃえばあとは描画処理1回で済む。

但し画面のキャッシュ領域を作るため、そのぶんメモリ消費量は増える。
でもCPU負荷は実質1/25になる。



メモリも使いたくないなら、元の画像データに

を作ればいい。
これならCPUもメモリも節約できる。(メモリはあんま減らない)
但し、全体のバイナリ容量が大きくなる。



ファミコンみたいなのがわかりやすいかも。
マリオの背景とか。
あの背景をいちいちブロック単位で描画したらファミコンじゃまともに動かない。
(ファミコンの最大スプライト数は64個だっけ?)
ステージ開始時に背景だけ作っちゃう。
そんな感じ。




そんな感じで全体の容量とCPU負荷とメモリの3人とお話しながら、ゲームは作られていく・・・。
データ圧縮とは 基礎編
データ圧縮について



データを圧縮するって言われても、よくわかんねーじゃん。
ほんであれですわ、データ圧縮。
元に戻せるzipとかrarとかの可逆圧縮と、
元に戻せないjpgとかmp3みたいな非可逆圧縮があんのよ。

jpgとかmp3とか、ものすげぇ圧縮できるけど、完全に元に戻せないの。
どーでもいいところのデータ消してっから。
どーでもいいデータってなんじゃらほいって方は、食品偽装について考えてみよう。
例えば100円寿司で出るウナギ。
あれウナギじゃねぇのよ。
でもウナギじゃん、食うとウナギとしか思えないじゃん。

「ウナギっぽいからまぁいいんじゃね」

オリジナル:ウナギ・・・?
データ圧縮:100円回転寿司マジック
データ解凍:ウナギ!

これが非可逆圧縮。



可逆圧縮は、もうどうしようもなくオリジナルのものに戻したい場合。
例えば、水で元の大きさに戻るワカメ。
水に漬けたらワカメじゃなくてタバコになったら嫌でしょ?俺はうれしいけど。

オリジナル:ワカメ
データ圧縮:すげぇ縮んだワカメ
データ解凍:やっぱワカメ

これが可逆圧縮。



ほんで、今回は可逆圧縮について考えを深めていきましょうということなんですけども、
なんでかっつーと実はjpgとかmp3とかの非可逆圧縮の方が難しいんですよ。
デジタルでアナログを扱うのは非常に難しい。難しいことはよくわからない。難しいこと反対。
なので最初から最後までデジタルな可逆圧縮の方がアホ(俺)でも理解できるって寸法ですわ。



とりあえず、全世界のマニアが常に編集をして巨大なマニア本と化しているとっても素敵なWikipediaを見る。

データ圧縮 (Wikipedia)

わからん。

Wikipediaは超絶マニアが編集しててマニア向けすぎてわかんねー。
わかんねーから俺が解説してやんよ。
ってことなのよ。






まず、圧縮が得意とするデータは

「連続したデータ」
「同じ文字が何回も出現するデータ」


となっております。なんのこっちゃ、とね。



「連続したデータ」については、例えば

「AAAAAAAAAABBBBBBBBBBCCCCCCCCCCDDDDDDDDDD」(40文字)

という文字列の場合。(ABCDそれぞれ10文字ずつ)

ポイントとしては同じ文字が連続している点。
この場合だとそれぞれ連続して10文字ずつになっていますので、

「A*10文字、B*10文字、C*10文字、D*10文字」

とすることができます。
単純に

「A10B10C10D10」(12文字)

とかやっちゃえば、12文字になります。
元のデータが40文字だったので、28文字もお得です

極論で言えば、
Aという文字が1億文字連続である1億byte = 100Mbyteのデータがあったとしても、
この理屈で
「A100000000」(10文字)
に変換してあげれば、なんと100Mbyteがたったの10byteになってしまうんです。

逆にこの方法、連続していない文字に対しては逆効果。

「ABCD」
だった場合、それぞれ1文字ずつなので
「ABCD」
となり、変わりません。

また
「AABBCCDD」
とそれぞれ2文字ずつの場合でも
「A2B2C2D2」
となり、変わりません。

一般的な文字列の場合、連続して同じ文字を書くことはあまりないので、実際はあまり効果が無いんですねぇ。

西尾さんみたいに「キィィィィィィィィィ」とか書く場合にはもってこいなんですけど。



次に「同じ文字が何回も出現するデータ」について。

これは、いっぱい出る文字列をまとめちゃおうって寸法です。

例えば徹英語辞典があります。
徹英語辞典には以下の単語が登録されています。

1ページ目:hoge
2ページ目:fuck
3ページ目:unko

なんとも悲しい辞書です。
この辞書と、次の文字列があったとします。

「unko moreru, fuck daze. hogehoge」(32文字、ちなみに「ウンコ漏れる、ファックだぜ。ほげほげ」)

これを辞書と照らし合わせながら変換してあげるという感じです。

「3 moreru, 2 daze. 11」(20文字)

数字は辞書のページ番号になっています。
これだけでも12文字節約できました。

この場合の辞書はあらかじめ決められた辞書、というわけではなく、
文字列を全て参照し、多い順ランキングを作って、最も多く使われる文字を辞書にしてから、
ページ番号に変換してあげる、といった感じです。

例えば
「rHOGEoiuhgHOGEpncwyHOGEfpcpHOGEficuhpHOGE」
という文字だったら、なんか「HOGE」って文字がいっぱい入ってるから「HOGEは1にしよう」ってなって、
「r1oiuhg1pncwy1fpcp1ficuhp1」
に変換できるわけです。

ただ、この手法は圧縮したデータと「辞書データ」も必要になるため、短い文字列だと不利です。
ものすげぇ長い文章とかだと役に立ちます。
長編小説で主人公の名前が「1」になったり。(>>1さん・・・)



ということで、とにかく
「連続したデータ」
「同じ文字が何回も出現するデータ」
が重要ということがわかっていただけたかと思います、わからなかったらごめんなさい。


データ圧縮の作業は基本的に2段階あって、
・モデル化
・符号化
に分かれます。

んなことしらんわアホって感じなので、次回はとりあえずモデル化について解説します。
iアプリ「ほもいではしば」リリース
「ほもいではしば」をリリースしました。



今回はなんと18禁です。
どのへんが18禁なのかはやればわかりますが、たぶん18禁ってほどでもありません。
R指定ぐらいでしょうか。

西尾さんと徹夜で先ほど無事にリリースを終えました、疲れた。
今回は半年と長い開発期間だった(主にシナリオ、画像の作成)ため、
なんかでかいものをやり遂げたという達成感があります。

2007年もあとわずかですが、「チソコっち2(仮題)」のリリースをしないといけないためまだ多忙ではありますが、
とりあえず一段落ということで今夜しゃぶしゃぶ食べ放題でもしてきますわ。


動作端末はDoCoMoの505iシリーズ以降ですが、505/506シリーズ実機で動作確認をしていませんので動作確認していただけたらご報告いただけるとうれしいです。
FOMA機種に関しては一通り動作テストをしたので大丈夫です。


ダウンロードはこちらから。
DoJa5.x で アイコンの設定
ADFにて

AppIcon = appicon.gif
AppMainTitle = appmaintitle.gif


こんな感じでおk

AppIconはふつーの小さいアイコン。
AppMainTitleはDoJa5.1(905シリーズ)からのでかいアイコン。

画像はresに入れる。

アイコンサイズは端末依存なので、
AppIconは48*48、AppMainTitleは160*160にしとけばおk
端末によってはそれ以上のサイズでもいいらしいけど、表示できない端末もあるので注意。

あとjpegでもいいらしい。



こんな感じ。

もっと古いエントリへ

豚小屋

糞豚大先生