この画像を使って
こう表示したいと。
が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段階あって、
・モデル化
・符号化
に分かれます。
んなことしらんわアホって感じなので、次回はとりあえずモデル化について解説します。
データを圧縮するって言われても、よくわかんねーじゃん。
ほんであれですわ、データ圧縮。
元に戻せる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段階あって、
・モデル化
・符号化
に分かれます。
んなことしらんわアホって感じなので、次回はとりあえずモデル化について解説します。
「ほもいではしば」をリリースしました。
今回はなんと18禁です。
どのへんが18禁なのかはやればわかりますが、たぶん18禁ってほどでもありません。
R指定ぐらいでしょうか。
西尾さんと徹夜で先ほど無事にリリースを終えました、疲れた。
今回は半年と長い開発期間だった(主にシナリオ、画像の作成)ため、
なんかでかいものをやり遂げたという達成感があります。
2007年もあとわずかですが、「チソコっち2(仮題)」のリリースをしないといけないためまだ多忙ではありますが、
とりあえず一段落ということで今夜しゃぶしゃぶ食べ放題でもしてきますわ。
動作端末はDoCoMoの505iシリーズ以降ですが、505/506シリーズ実機で動作確認をしていませんので動作確認していただけたらご報告いただけるとうれしいです。
FOMA機種に関しては一通り動作テストをしたので大丈夫です。
ダウンロードはこちらから。
今回はなんと18禁です。
どのへんが18禁なのかはやればわかりますが、たぶん18禁ってほどでもありません。
R指定ぐらいでしょうか。
西尾さんと徹夜で先ほど無事にリリースを終えました、疲れた。
今回は半年と長い開発期間だった(主にシナリオ、画像の作成)ため、
なんかでかいものをやり遂げたという達成感があります。
2007年もあとわずかですが、「チソコっち2(仮題)」のリリースをしないといけないためまだ多忙ではありますが、
とりあえず一段落ということで今夜しゃぶしゃぶ食べ放題でもしてきますわ。
動作端末はDoCoMoの505iシリーズ以降ですが、505/506シリーズ実機で動作確認をしていませんので動作確認していただけたらご報告いただけるとうれしいです。
FOMA機種に関しては一通り動作テストをしたので大丈夫です。
ダウンロードはこちらから。
ADFにて
こんな感じでおｋ
AppIconはふつーの小さいアイコン。
AppMainTitleはDoJa5.1(905シリーズ)からのでかいアイコン。
画像はresに入れる。
アイコンサイズは端末依存なので、
AppIconは48*48、AppMainTitleは160*160にしとけばおｋ
端末によってはそれ以上のサイズでもいいらしいけど、表示できない端末もあるので注意。
あとjpegでもいいらしい。
こんな感じ。
AppIcon = appicon.gif
AppMainTitle = appmaintitle.gif
AppMainTitle = appmaintitle.gif
こんな感じでおｋ
AppIconはふつーの小さいアイコン。
AppMainTitleはDoJa5.1(905シリーズ)からのでかいアイコン。
画像はresに入れる。
アイコンサイズは端末依存なので、
AppIconは48*48、AppMainTitleは160*160にしとけばおｋ
端末によってはそれ以上のサイズでもいいらしいけど、表示できない端末もあるので注意。
あとjpegでもいいらしい。
こんな感じ。
どんな数字でも0乗すると1になる。
ってのを中学校くらいで習った気がする。
教科書には詳しく書いてなかったんだけども、
例えば2の3乗は
ということになり、これは
でもあるし
でもある。
だから、2の0乗は
でもいいし、
でもいいし、
つまり
こういうことになる。
2 / 2は1。だから2の0乗は1。
じゃぁさ、0の0乗ってなんなのよって話。
これでしょ?
0で割ったら解無しじゃねぇの?
ってなるじゃん。
わけわかんねーからruby先生に聞いたのよ。
0で割ったらいけないんだぜって言われたんだけど
0の0乗ってやったら「それは1ですねぇ」って言われた。
わけがわからない。
このままだと、今後この手の話題が出たときに
「たしまくんってアホなんですね」
と言われてしまうので、0の0乗の件についてgoogle先生に聞いてみた。
そしたらね、Yahoo!知恵袋に良いことが書いてあったのよ。
なるほど!!
ﾌﾞﾋﾌﾞﾋ、これで俺も0乗マニアだぜ。ってなった。
数学は必ず解があって、屁理屈が無くて、銀河系宇宙共通のものだと思ってたけど、
この「0」がすげぇ厄介で胡散臭くてわけがわからない。
インド式数学マニアなインド数学哲学野郎に、0について熱く語って欲しいと思った。
ってのを中学校くらいで習った気がする。
教科書には詳しく書いてなかったんだけども、
例えば2の3乗は
2**3 = 2 * 2 * 2 = 8
ということになり、これは
2**3 = (2 * 2 * 2 * 2) / 2 = 2 * 2 * 2
でもあるし
2**3 = (2 * 2 * 2 * 2 * 2) / (2 * 2) = 2 * 2 * 2
でもある。
だから、2の0乗は
2**0 = (2 * 2) / (2 * 2)
でもいいし、
2**0 = (2 * 2 * 2) / (2 * 2 * 2)
でもいいし、
つまり
2**0 = 2 / 2
こういうことになる。
2 / 2は1。だから2の0乗は1。
じゃぁさ、0の0乗ってなんなのよって話。
0**0 = 0 / 0
これでしょ?
0で割ったら解無しじゃねぇの?
ってなるじゃん。
わけわかんねーからruby先生に聞いたのよ。
irb(main):001:0> 0 / 0
ZeroDivisionError: divided by 0
from (irb):1:in `/'
from (irb):1
ZeroDivisionError: divided by 0
from (irb):1:in `/'
from (irb):1
0で割ったらいけないんだぜって言われたんだけど
irb(main):002:0> 0**0
=> 1
=> 1
0の0乗ってやったら「それは1ですねぇ」って言われた。
わけがわからない。
このままだと、今後この手の話題が出たときに
「たしまくんってアホなんですね」
と言われてしまうので、0の0乗の件についてgoogle先生に聞いてみた。
そしたらね、Yahoo!知恵袋に良いことが書いてあったのよ。
ｎ≠０とします。
０のｎ乗は、０ですから、ｎを０に近づけていくと、当然、０に近づきます(というか、ずっと０のまま）
ｎの０乗は、１ですから、ｎを０に近づけていくと、当然、１に近づきます（というか、ずっと１のまま）
なので、０の０乗は、決められない、定義できない、とするのが、正しい考え方です。
０÷０＝ａは、ａ×０＝０だから、０に何を入れても成り立つから、決められない、
だから、０÷０はやっちゃいけない、というのと、似たようなことです。
０の０乗はいくつ？ - Yahoo!知恵袋
０のｎ乗は、０ですから、ｎを０に近づけていくと、当然、０に近づきます(というか、ずっと０のまま）
ｎの０乗は、１ですから、ｎを０に近づけていくと、当然、１に近づきます（というか、ずっと１のまま）
なので、０の０乗は、決められない、定義できない、とするのが、正しい考え方です。
０÷０＝ａは、ａ×０＝０だから、０に何を入れても成り立つから、決められない、
だから、０÷０はやっちゃいけない、というのと、似たようなことです。
なるほど!!
ﾌﾞﾋﾌﾞﾋ、これで俺も0乗マニアだぜ。ってなった。
数学は必ず解があって、屁理屈が無くて、銀河系宇宙共通のものだと思ってたけど、
この「0」がすげぇ厄介で胡散臭くてわけがわからない。
インド式数学マニアなインド数学哲学野郎に、0について熱く語って欲しいと思った。
core2duoが悪いのかどうかは知らないけど、VC6でリンク時にたまに固まる。
5回に1回は固まる。仕方ないのでPentium MのノートPCで開発中。
オーバークロックも解除したけどダメだった。殺したい。
でもVC6は軽くていい。
5回に1回は固まる。仕方ないのでPentium MのノートPCで開発中。
オーバークロックも解除したけどダメだった。殺したい。
でもVC6は軽くていい。
Create
Read
Update
Delete
createとdeleteが苦手。
Read
Update
Delete
createとdeleteが苦手。
結構難しいです、脳がかゆるなるようなゲーム。
ダウンロードは以下から。
マニクラmobile(iモード専用)
思えば今年の3月から久々のiアプリ公開に至りました。
多忙だったという理由にしてますが、「やる気」の問題だと思います。
たしまは現在、iアプリもRailsもどっちも中途半端な状態で、どっちも面白くてどっちつかずな感じ。
そしてこっそりデコブロにブログと掲示板を移動。
これは俺のおかげでPVが増えるに違いない!!とか思った。
いや、まじで年末の「チソコっち2」公開時には・・・
if (hoge == null) {hoge=123;}
つまりhogeに値が入ってなかったら「123」を入れる、入ってたらスルーするという構文。
Rubyだと
hoge ||= 123
と書ける。
Rubyは面白い。
とあるサイトで、URLが
hoge.php?page=index
hoge.php?page=link
みたいになってるものを見つけた。
試しに
hoge.php?page=../index
とやったら上の階層のファイルを表示した。
$_GET[page]で指定されたファイルをそのまま表示しているのだろう。
某有名掲示板スクリプトサイトが配布している掲示板が設置されていたので、
これはもしや・・・と思いログファイルのパスを指定したら表示されてしまった。
hoge.php?page=../bbs/log.dat
みたいな感じで。
こんなんでいいんだ・・・、最近は誰でも気軽に自宅でサーバー運用したり、
PHPとかで気軽にサーバーサイドプログラミングを楽しんでいるようだが、
なんつーか、こういう単純なセキュリティホール(とも呼べない程)に気付かないで運用しているのはすごく怖いと思う。
hoge.php?page=index
hoge.php?page=link
みたいになってるものを見つけた。
試しに
hoge.php?page=../index
とやったら上の階層のファイルを表示した。
$_GET[page]で指定されたファイルをそのまま表示しているのだろう。
某有名掲示板スクリプトサイトが配布している掲示板が設置されていたので、
これはもしや・・・と思いログファイルのパスを指定したら表示されてしまった。
hoge.php?page=../bbs/log.dat
みたいな感じで。
こんなんでいいんだ・・・、最近は誰でも気軽に自宅でサーバー運用したり、
PHPとかで気軽にサーバーサイドプログラミングを楽しんでいるようだが、
なんつーか、こういう単純なセキュリティホール(とも呼べない程)に気付かないで運用しているのはすごく怖いと思う。
