2013/12/18(水) [n年前の日記]
#1 [neta] 車の中の妖精さん
寝ていたら、車のダッシュボード? グローブボックス?の中ですやすや寝ている小人の女の子、が出てくる四コマ漫画、を読んでいる夢、を見たのだけど。そういう漫画ってどこかにあるのかな…?
こんな感じの夢で…。
主人公、新車を買って、乗り込んで、中を色々弄ってる。
ダッシュボードを開けたら、寝息を立ててる小さい女の子が居て、目が点に。
女の子「むにゃむにゃ…。ハッ! すいません。今、西暦何年ですか?」
主人公「…2013年だけど」
女の子「ああー! なんてこったー! ここで30年も寝続けてたー!」
主人公「いや、これ新車なんだけど」
女の子「あっ」
なんでこんな夢見たんだろ。わからん…。
こんな感じの夢で…。
主人公、新車を買って、乗り込んで、中を色々弄ってる。
ダッシュボードを開けたら、寝息を立ててる小さい女の子が居て、目が点に。
女の子「むにゃむにゃ…。ハッ! すいません。今、西暦何年ですか?」
主人公「…2013年だけど」
女の子「ああー! なんてこったー! ここで30年も寝続けてたー!」
主人公「いや、これ新車なんだけど」
女の子「あっ」
なんでこんな夢見たんだろ。わからん…。
◎ 艦船のメンタルモデルなる設定があるのだから。 :
「蒼き鋼のアルペジオ」には、戦艦のメンタルモデルと称して女の子が出てくるのだから…。
車やバイクにも、そういうのがあってもいいのかもしれないなと。
む。考えてみたら、それって「ナイトライダー」の「K.I.T.T」かもしれないか…。
日本製アニメで「ナイトライダー」をリメイクしたら、「K.I.T.T.」は女の子になるのかな、と妄想。いや、ドライバーを美女 or 美少女にして、「K.I.T.T.」はイケメン男性にするのもアリかな…。
まあ、日本は、Windowsや電車が美少女になるぐらいだから、車やバイクでそういうソレの漫画やアニメも既にたくさんありそうですかね。
車やバイクにも、そういうのがあってもいいのかもしれないなと。
む。考えてみたら、それって「ナイトライダー」の「K.I.T.T」かもしれないか…。
日本製アニメで「ナイトライダー」をリメイクしたら、「K.I.T.T.」は女の子になるのかな、と妄想。いや、ドライバーを美女 or 美少女にして、「K.I.T.T.」はイケメン男性にするのもアリかな…。
まあ、日本は、Windowsや電車が美少女になるぐらいだから、車やバイクでそういうソレの漫画やアニメも既にたくさんありそうですかね。
[ ツッコむ ]
#2 [pc][neta] 「MZ700 Advent Calendar」とか「X1 Advent Calendar」とか無いのかな
別に、
今の時代にソレを書いてみてどうするのだ…という気もしますけど。
- X68K Advent Calendar
- FM-7 Advent Calendar
- PC-6001 Advent Calendar
- PC-8801 Advent Calendar
- Apple II Advent Calendar
今の時代にソレを書いてみてどうするのだ…という気もしますけど。
[ ツッコむ ]
#3 [nitijyou] 明日の分の日記も一部アップしてみたり
今のうちに出しとけば色々楽かなと思ったのでアップロードしておきます。
[ ツッコむ ]
#4 [dxruby][game] とりあえずBGマップを表示するべく作業中
先日、Tiled で実験用BGマップを作ったものの。画面に表示してみないと実験もへったくれもないので、そのあたりを勉強中。
もしかすると、そのうち DXRuby Advent Calendar で紹介されるのでは、という予感もあるけど…。Ruby には、Tiled の保存フォーマットを読み込める _tmx というライブラリがあるので、今回はソレを使わせてもらおうかと。
ちなみに、以前触った際には、nokogiri、oj が必要だったのだけど。現在の版は、nokogiri、multi_json を要するように変わったらしい。
もしかすると、そのうち DXRuby Advent Calendar で紹介されるのでは、という予感もあるけど…。Ruby には、Tiled の保存フォーマットを読み込める _tmx というライブラリがあるので、今回はソレを使わせてもらおうかと。
ちなみに、以前触った際には、nokogiri、oj が必要だったのだけど。現在の版は、nokogiri、multi_json を要するように変わったらしい。
◎ 今時の2Dゲームの適切なタイルサイズってどのくらいなんだろう。 :
昔のTVゲーム機は、QVGA = 320x240前後の画面サイズで、タイルサイズは8x8ドットが最小だったのだけど。
今時のPCゲームは、いくらなんでもVGA = 640x480より小さくなることはないだろうから…。画面ドット数が縦横2倍になってるのだから、タイルサイズも、最小で16x16ドットになるのかなと。
でも、本当にそれでいいのかしら。例えば…。
今時のPCゲームは、いくらなんでもVGA = 640x480より小さくなることはないだろうから…。画面ドット数が縦横2倍になってるのだから、タイルサイズも、最小で16x16ドットになるのかなと。
でも、本当にそれでいいのかしら。例えば…。
- GPU、もしくは、使用ライブラリが、小さいテクスチャを大量に出すより、大きいテクスチャを少量出すほうが速いのであれば、タイルサイズを32x32や64x64にしたほうが安心できそう。
- 「今時 640x480 の画面サイズのゲームなんてないよ?」「800x600もないよ?」「1280x720 とか 1920x1080 でもいいぐらいだよ」ということなら、タイルサイズも大きいほうがヨサゲ。
◎ 表示はできた。 :
表示もできたし、当たってるかどうかの判定までは、どうにか動いたような。
後は補正処理 ―― 補正後の座標を返す処理を書かないと、かな…。
先日作ったテスト用マップは、最低限のBGアタリ番号だけでマップを作れないかと思って作業してたけど。プログラムを書いてる最中、やっぱり、属性で分けて、別のアタリ番号にしたほうが良さそうだなと思えてきたので、そのようにマップを作り直したり。ぶら下がり棒や、空中に浮いてる床=ジャンプして飛び乗れる床は、別のアタリ番号に、みたいな。
Tiled でマップ作成する際にも、見た目からして、「ここは空中に浮いてる床」「ここはぶら下がり棒」と分かるほうが、バグを入れずに済みそうだし。
もし、最低限のBGアタリ番号でどうにかしようとすると、
それよりは、それぞれ別のアタリ番号を用意して、配置してもらうほうが分かりやすいだろうなと。
先日作ったテスト用マップは、最低限のBGアタリ番号だけでマップを作れないかと思って作業してたけど。プログラムを書いてる最中、やっぱり、属性で分けて、別のアタリ番号にしたほうが良さそうだなと思えてきたので、そのようにマップを作り直したり。ぶら下がり棒や、空中に浮いてる床=ジャンプして飛び乗れる床は、別のアタリ番号に、みたいな。
Tiled でマップ作成する際にも、見た目からして、「ここは空中に浮いてる床」「ここはぶら下がり棒」と分かるほうが、バグを入れずに済みそうだし。
もし、最低限のBGアタリ番号でどうにかしようとすると、
- 平らな床は、上下2マス分、床タイルを置くこと。
- ぶら下がり棒は、上下2つの斜め床の組み合わせ、及び、空中に浮いてる一マス分の床で配置すること。
- 空中床は、床タイルの下に、高さ半分の床を配置すること。
それよりは、それぞれ別のアタリ番号を用意して、配置してもらうほうが分かりやすいだろうなと。
◎ 各タイルのアタリ判定用データについて。 :
昔、このあたりの処理を書いた時は…。アタリ番号一つ一つに対して、「当たってるか、当たってないか」の判定処理を、わざわざプログラムで書いてたのですが。
当時は、テーブルで持ったらROM容量を圧迫してしまうのではないかと不安だったので…。タイル種類が増えるたびに、その形に合わせて、毎回コツコツと書いていくという、ちとアホみたいな作業をやっていて。
だけど今では、RAMは比較的余裕があるだろうし、テーブルで持ってしまっていいよなと。そのほうが処理もシンプルになるし、どのタイルでも実行時間が一定になるし。
場合によっては、当たってるか当たってないかの判別用に、0/1で、タイルサイズ分の二次元配列 or ビットデータ列を持ってしまってもいいぐらい、かもしれない。
*1
さておき。今はテーブルを用意して処理するとしても、テーブル作成が面倒臭い。ので、プログラム側に画像を渡して、各タイル内のドットの有無をスキャンして、配列に入れる形にしてみたり。与える画像さえ修正してしまえば、即座にテーブルに反映される上に、画像上で凝った形状を作っても、ちゃんと反映されるので、作業は楽になるかもしれないなと。
待てよ? どうせ画像を渡すなら、当たってるかどうかの判定も、画像中のドットを見て、やっちゃっても良さそうな。いや、どのみち補正用の座標を得るためにテーブルが必要になるのだから、それを使って判定してもいいか…。
このあたりの処理って、どのくらいの個数のオブジェクトが、地形アタリを取るのかで違ってくるから…。やたらと呼ばれるなら速くしないといけないけれど、たいして呼ばれないなら、処理を速くしてみたところで、さほど意味は無いし。動かしてみて重くなったら、その時に最適化を、てなノリでも良さそうな。
だけど今では、RAMは比較的余裕があるだろうし、テーブルで持ってしまっていいよなと。そのほうが処理もシンプルになるし、どのタイルでも実行時間が一定になるし。
さておき。今はテーブルを用意して処理するとしても、テーブル作成が面倒臭い。ので、プログラム側に画像を渡して、各タイル内のドットの有無をスキャンして、配列に入れる形にしてみたり。与える画像さえ修正してしまえば、即座にテーブルに反映される上に、画像上で凝った形状を作っても、ちゃんと反映されるので、作業は楽になるかもしれないなと。
待てよ? どうせ画像を渡すなら、当たってるかどうかの判定も、画像中のドットを見て、やっちゃっても良さそうな。いや、どのみち補正用の座標を得るためにテーブルが必要になるのだから、それを使って判定してもいいか…。
このあたりの処理って、どのくらいの個数のオブジェクトが、地形アタリを取るのかで違ってくるから…。やたらと呼ばれるなら速くしないといけないけれど、たいして呼ばれないなら、処理を速くしてみたところで、さほど意味は無いし。動かしてみて重くなったら、その時に最適化を、てなノリでも良さそうな。
*1: 今になって考えてみたら、上下方向用に2つのy座標、左右方向用に2つのx座標を持てば済んだのだから、当時もテーブルで持ってしまったほうが良かったのではと思えてきたり。当時は1タイル32x32ドットで処理してたけど、座標1つにつき5bit、いや、ヌケ部分も考えると6bitで済んだのだから、1タイルにつき、192bit x 4方向 = 96byte、かける、タイル種類分で済んだよな…と思ったけど、それはそれで結構容量を食いそうな。3KByte…当時としてはどうだったんだろう…。上下左右の反転もあるから、もうちょっと少なくできるかな…。
[ ツッコむ ]
#5 [ruby] Ruby 1.9.3上でirbを使うとフリーズしちゃう
環境は Windows7 x64 + Ruby 1.9.3 mingw32版。irbを使ってちょっと動作確認しようとすると、何かの拍子にフリーズしてしまう…。上書きインストールで更新してしまったせいだろうか…。
Ruby 2.0.0 の irb なら問題は…。いや、こちらも時々反応が返ってこないな…。何か補完関係で処理時間がかかってるんだろうか。よくわからんなあ…。
Windows/DOS窓だから、なのかな…。*NIX や Macなら、もしかするとスンナリ動くのかしら。
それとも、何か変な設定ファイルが、自分の環境に残ってしまってるのだろうか…。~/.irbrc は消してみたんだけどな…。うーん。
Ruby 2.0.0 の irb なら問題は…。いや、こちらも時々反応が返ってこないな…。何か補完関係で処理時間がかかってるんだろうか。よくわからんなあ…。
Windows/DOS窓だから、なのかな…。*NIX や Macなら、もしかするとスンナリ動くのかしら。
それとも、何か変な設定ファイルが、自分の環境に残ってしまってるのだろうか…。~/.irbrc は消してみたんだけどな…。うーん。
[ ツッコむ ]
以上、1 日分です。