mieki256's diary

今まで、ヘッドフォンを使う時は、根元に書いてあるRとLの文字を頼りにして耳に刺していたのだけど。

_次世代USBコネクタは表裏なし | スラッシュドット・ジャパン ハードウェア というページの中で「ヘッドフォンにもポッチをつけよ！ 左右が分かりにくいんだよ！」という意見を目にして。ふと、自分が使ってたヘッドフォンを眺めたら…。

ポッチついてるやん！ 「L」のほうに、ポッチついてるやん！

知らなかった、というか、気づかなかった…。自分は今まで一体何をしてたんだ…。audio-technica ATH-C500M、偉い。地味に素晴らしい。

他のヘッドフォンはどうなのだろうと思って眺めてみたら。SONYは…まあ、コレは、ケーブルの長さが左右で違うし、スピーカ部分とその根元の2ヶ所で、「R」「L」が書いてあるし。まだ気を使ってるほうなのかなと。さすがSONY、なのでしょうか。

Panasonic は…これもポッチがついてた。さすがPanasonic、なのかな。

とりあえず手持ちのヘッドフォンは、左右が分かりやすくなるように、ちょっとした工夫はしていた模様。これは勉強になった…。

マウスのボタンも、ポッチがついてたらよかったのに。

ここ数日、DXRuby絡みの記事を書くことを意識してますが、タグが無いのもアレだなと思ったのでその手の記事にはつけておくことにしました。

昨日、一昨日と、DXRubyのウインドウをキャプチャしてGIFアニメにして貼り付けているわけですが。キャプチャする際に、GifCam というソフトを使っておりまして。

_【レビュー】デスクトップを動画キャプチャーしてアニメーションGIFファイルにする「GifCam」 - 窓の杜

コレ、大変便利です。コレが無かったら、あの手のGIFアニメを作って載せるとか、ちょっと無理だったかもしれず。これで、録画開始と終了をホットキーで出来たら文句なしなのですが…。

ちなみに、他にも同種のソフトをHDDにインストールしてある状態でして。

_LICEcap - ｋ本的に無料ソフト・フリーソフト
_【今日のお気に入り】GIFアニメ作成など多彩な機能を備える画面キャプチャーソフト「窓フォト」 - 窓の杜

どのソフトも、ウインドウ枠でキャプチャサイズを指定するタイプです。

LICEcap は、GifCam と同様、キャプチャ結果を即座に GIFアニメにしてくれるソフト。FPSを指定できる点はイイ感じ。ただ、GifCamのように、録画後、フレームを削除したりはできないようで。

窓フォトは、一旦、bmp、jpg、png等でHDDに連続でキャプチャ画像を保存した後、それら画像群を使ってGIFアニメ作成を行うタイプ。おそらく、キャプチャ画像はフルカラー相当でしょうから、それら画像群を元にして綺麗な動画を作る等の作業もできるのではないかと。また、マウスカーソルに赤い丸をつけて表示する機能もあるので、操作説明動画を作るには向いてるかもしれず。

自分は使用してないですが、 _Gyazo というツール＋Webサービスも便利らしいですな。録画したソレを、即座にWebサーバに送るそうで、URLを相手に知らせれば、すぐにキャプチャ結果を共有できるのが売り、らしいです。

ただ、興味は湧いたものの、キャプチャ結果を一般公開できるのかどうかがよく分からなくて…。一般公開もできるのであれば、自分の手持ちのサーバ容量や回線の転送量を圧迫しないで済みそうだなと。いや、件のWebサービス提供側がその分負担してるだけだから、ホントにソレっていいのかなという気もしますが。

今回も、DXRubyを使って、そっち関係の記事を…。いや、もう DXRuby は関係なくて、ただの昔話ばかり書いてる気もしますが…。それはさておき。

昨日の記事で時間ギリギリだったので、今日は少し軽い話にしとこうかなと。…や、昨日のソレは、ソースは1時間ぐらいで書けたのですけど、blenderでモデル作るだけで半日かかっちゃって…。あんなヘボ画像でも、ボディ部分のモデルは3回作り直してたり…。ホントは超兄貴みたいな画像にしたかったんですけど、これが全然そんなレベルにはならず…。モデリングを仕事にしてる人達、絵描きさん達はやっぱりスゴイと再認識ですよ…。

さて本題。自分、何かしらを動かす時に、好きな動きというか、好きな書き方があるのです。そのあたりを紹介してみようかなと。

例えば。メニュー画面で十字キーを押すと、各項目に向かってカーソルが動いていく、といった処理を書かなきゃいけない場合。さて、カーソルに、どういう動きをさせますかね？

真っ先に思いつくのは、等速度運動ですかね。等速度、つまり、速度が一定の動きです。こんな感じの動きかなと。

# 動きのテスト。等速度運動

require 'dxruby'

font = Font.new(24)
img = Image.load("ufo.png")
CNTMAX = 60
cnt = 0
x = 0 # 現在座標
y = 0
tx = 0 # 目標座標
ty = 0
dx = 0 # 速度
dy = 0

Window.loop do
  break if Input.keyPush?(K_ESCAPE)

  if cnt % CNTMAX == 0
    # 1秒ごとに現在座標と目標座礁を初期化
    x = 0
    y = 0
    tx = Window.width
    ty = Window.height
    dx = (tx - x).to_f / CNTMAX
    dy = (ty - y).to_f / CNTMAX
  end

  # 等速度運動
  x += dx
  y += dy
  
  # 目標座標に到達したらメッセージを描画
  if x == tx and y == ty
    Window.drawFont(32, 32, "到達", font)
  end
  
  Window.draw(x - img.width / 2, y - img.height / 2, img)

  cnt += 1
end

たしかにコレでも仕様は満たせますが。自分はどうも、物足りなさを感じてしまって…。

そこで、加減速運動(?)をさせることが多いのです。

# 動きのテスト。加減速

require 'dxruby'

font = Font.new(24)
img = Image.load("ufo.png")
CNTMAX = 60
cnt = 0
x = 0 # 現在座標
y = 0
tx = 0 # 目標座標
ty = 0

Window.loop do
  break if Input.keyPush?(K_ESCAPE)

  if cnt % CNTMAX == 0
    # 1秒ごとに現在座標と目標座礁を初期化
    x = 0
    y = 0
    tx = Window.width
    ty = Window.height
  end

  # 加減速運動
  x += (tx - x) * 0.2
  y += (ty - y) * 0.2
  
    # 目標座標に到達したらメッセージを描画
  if x == tx and y == ty
    Window.drawFont(32, 32, "到達", font)
  end
  
  Window.draw(x - img.width / 2, y - img.height / 2, img)

  cnt += 1
end

現在座標と目標座標の差を1/nにして、現在座標に足すという処理です。等速度運動より、なんかちょっぴりカッコイイ感じがしませんか？ 自分だけかな？ また、ソースを見れば分かりますけど、速度を管理しなくて済むあたりも、ちょっとだけ美味しくて。

ちなみに。以前、DXRuby を使って _Anime PV Easy Maker ZERO てのを書いたんですけど。メニューがヒュンヒュンと動くあたりは、全部こういう書き方をしています。お気に入りなんです。この動き。

ただ、この書き方、ちょっと問題があって。

コレ、いつまで経っても、目標座標に到達してくれないのですよ…。なんだかちょっと、 _「アキレスと亀」 みたいな状態ですから。いや、この場合、亀は止まってますけど。

なので、「一定距離まで近づいたら、強制的に、現在座標を目標座標で上書きする」という処理が必要になりまして。

# 動きのテスト。加減速。目標座標に近づいたら現在座標を設定する版

require 'dxruby'

font = Font.new(24)
img = Image.load("ufo.png")
CNTMAX = 60
cnt = 0
x = 0 # 現在座標
y = 0
tx = 0 # 目標座標
ty = 0

Window.loop do
  break if Input.keyPush?(K_ESCAPE)

  if cnt % CNTMAX == 0
    # 1秒ごとに現在座標と目標座礁を初期化
    x = 0
    y = 0
    tx = Window.width
    ty = Window.height
  end

  # 加減速運動
  x += (tx - x) * 0.2
  y += (ty - y) * 0.2

  # 目標座標に近づいたら現在座標を設定する
  x = tx if (tx - x).abs < 0.5
  y = ty if (ty - y).abs < 0.5

  # 目標座標に到達したらメッセージを描画
  if x == tx and y == ty
    Window.drawFont(32, 32, "到達", font)
  end
  
  Window.draw(x - img.width / 2, y - img.height / 2, img)

  cnt += 1
end

現在座標を変更した直後に、ちょっと条件判定してますよね。こうしないと、目標座標に到達してくれない。このへんが、ちょっともにゃもにゃした気分に…。

まあ、こういう動きが自分は好きでよく使ってます。てなだけの話でした。

一応ソースと画像も置いときます。Public Domainってことで。

_movetest.zip

ちなみに、こういう書き方って、今はあまり主流じゃないのだろうな、とも思うのですけど。

昔のTVゲーム機上で動いてたプログラムって、上に書いたソースのように、毎フレーム、現在座標に速度を足したり、速度に加速度を足したり、という書き方をしてたんですけど。

今は、座標移動は数式で行う場合が多いのかな、という気がしています。

例えば、JavaScript のライブラリで、Tween.js てのがあるらしいですけど。動きの一覧を見ると、どう見てもフレーム毎にどうこうしてる動きじゃないなと。たぶん、座標値を求めるための数式が、ライブラリ中にそのまま書かれているんじゃないのかなと。あくまで想像ですけど。

_Tween.js / graphs

Unity あたりも似たような感じで。「前回のフレームから今回のフレームまで何ミリ秒かかった、という値が取得できるから、それを速度に掛けて座標に足せ」みたいな書き方が基本としてあるわけですよ。

このあたり、昔のことを思い出すのです…。

子供の頃、ベーマガという雑誌を買って読んでたんです。ベーマガ＝マイコンBASICマガジンの略なんですけど。

その雑誌の中に、「あのゲームの敵の動きは、こうやって実現している！」てな記事がありまして。そこではBASICを使って、座標移動が数式で書かれてたんですね。子供だった自分は、「そうかー。こういう動きって、数式で書くものなんだー」と素直に信じていたのです。

ところが、その手の業界に入ってみたら、そんな書き方してる人は誰も居ない。皆、毎フレーム、速度や加速度をひたすら足して、動きを作っていて。「うわあ。これは騙された。ベーマガに騙されちゃった」てな気分になった記憶があります。

ところが…どうも昨今、座標移動は数式で、という書き方が主流になってる気がするのです。

考えてみたら、数学の教科書その他に載っているのも、数式ですから…。数学をちゃんと勉強してきた人なら、たぶんそういう書き方のほうが分かりやすい。では、どうして、昔はそういう素直(?)な書き方をしなかったのかなと。

このあたり、ハードウェアが関係していたのだろうと思うのですよね。

• 昔のCPUは性能が低かったから、数式を素直に書くなんて無理だった。何せ、掛け算・割り算の命令すら無かったですから…。いや、あったとしても、足し算・引き算に比べたらクロック数が多かったので、なかなか使いづらくて。「2、4、8、16等を掛けたり割ったりするときは、ビットシフト」とかよく使ってました。
• 昔のTVゲーム機は、ブラウン管TVを使う関係上、必ず1/60秒で割り込みが入る・フレームレートが一定であることを強要されてた。

そんな事情があったので、毎フレーム、速度・加速度を“足す”“引く”という書き方だったのだろうなと。

しかし、3Dゲームが普及して、状況が変わってくるわけです。

3Dゲームは、描画処理が重いので、フレームレートが一定にならない。フレームレートが一定であることを期待したプログラムを書くと、ハマってしまう。おそらくは、まだ、数式を素直に書くべく志向したほうが、ハマりにくいのだろうなと。

さらに、CPUの性能も向上した。おそらくは掛け算・割り算はもちろんのこと、浮動小数点演算まで当たり前のようにできるようになってきた。昔のTVゲーム機に使われてたCPUは、整数演算しかできませんでしたから…。固定小数点演算が関の山で…。

そんなわけで、昔、「ベーマガに騙された」と思ったソレが、ゲームの見た目が変わって、CPUが性能向上して、着々と主流になっているような気がして、なんだか不思議な気分になったりするのでした。

ちなみに昔の書き方も、全然間違ってないのですけど。むしろ、速度や加速度というものが理解できてるから、そのように書けていたわけで。

速度とは何でしょうか？ この時間で、どの程度の距離を進むのか。それが速度ですから。1時間で進む距離は「時速」と呼ばれてるし、1秒で進む距離は「秒速」と呼ばれてる。ゲームの場合は、1フレームで進む距離ですから…「フレーム速」とでも呼べばいいのでしょうかね？

ただ、3Dゲーム全盛時代は、可変フレームレートが当たり前なので…。いくつかのゲーム用ライブラリを眺めていた際、速度の単位が全て「秒速」で統一されてたりして、「昔とは違うんだなあ」と感じた記憶もあります。

まあ、何の役にも立たない昔話でした。

待てよ？ ふと思ったけど、このあたり、もしかすると、PC文化とTVゲーム機文化の違いでしかなかったりするのかな…？

今頃になって、 _Anime PV Easy Maker ZERO の苦労話、というか悩んだ点について、書けなくもなかったかな…と思えてきてしまったり。途中途中で悩んだ点があったことを少し思い出してきたというか。せっかくだから忘れないうちにメモしておきます。

◎ フラットデザインを意識。 :

◎ 画像は事前に用意。 :

◎ レイアウトを考える際の問題。 :

◎ フォント絡みの問題点その1。 :

◎ フォント絡みの問題点その2。 :

◎ 他にも何かあったような。 :

上の記事でちょっと書いたあたりを補足というか。もっとも、フリーのゲーム、同人ゲームを作ってる人なら、えてしてフォントのライセンス問題は知ってると思いますけど…。念のため、自分も軽く(?)書いておこうかなと。

世の中、「フリーで使えるフォント」なるものがたくさん紹介されていますが。各フォントには、使用条件・ライセンスがついていて、「フリー」だからといって「自由」ではないのが実状で。また、ゲームの場合、画面内でメッセージを表示しなければいけない場面も時々あるわけですけど。そのためにはフォントファイルを、アプリと一緒に同梱しておく必要がありまして。

しかし、この、「アプリと同梱」を禁止してるフォントが多いので、色々と困ってしまうわけでして。

◎ 企業が提供するフォントの場合。 :

◎ フリーの日本語フォントの場合。 :

◎ 英語圏のフリーフォントの場合。 :

◎ 画像化するなら話は別。 :