Hatena::ブログ(Diary)

senzogawaのNな日々 このページをアンテナに追加 RSSフィード

2004 | 11 | 12 |
2005 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2006 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2007 | 01 | 02 | 03 | 04 | 05 | 06 | 11 | 12 |
2008 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2009 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2010 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 12 |
2011 | 01 | 03 | 04 | 05 | 06 |
2012 | 01 | 08 | 09 |
2013 | 02 |

2007-03-25 かこう

素材の加工

| 素材の加工を含むブックマーク 素材の加工のブックマークコメント

 素材の加工といっても、もともと利用できるファイル形式は限られている。

 良いツールを見つけるだけで、大抵の問題は解決できるだろう。

 以下、ファイル形式ごとに加工の内容を記述する。

  • JPEGの加工
  • PNGの加工
  • MIDIの加工

JPEGの加工

 JPEGは主に透過が不要な画像、要するに背景に利用するわけだが、加工といっても、画面に納まるよう、リサイズして減色するだけだ。

 自分なら、後に挙げるPNGのリサイズと減色で利用したツールで実行するところだが、実はこの作業は他人任せだった。

 詳しいことはいえないが、一般的な画像編集ツールでも充分可能とのことだ。


 今回制作したアプリ(以下GSFF)では、JPEGは背景にしか使っていない。

 それでも、枚数がかさめば結構な容量になるため、減色・リサイズ後に、安全にファイルサイズを圧縮する目的で、carmineを使わせていただいた。


 本来は写真撮影後のファイルサイズを圧縮するのに利用するようだが、一応12枚の画像で2KB程度の縮小ができたので、CGだと全く効果が無い、ということもないようだ。

 効果はそんなに大きくないが、やはり少しでもファイルサイズを小さくしたかったので、感謝。


PNGの加工

 PNGは主に透過が必要な、キャラクタやシステムのパーツ類に利用することになるが、この加工についても、リサイズと減色を行う。

 ただし、輪郭と減色について注意が必要だ。


 リサイズした場合、透過と接触する部分が微妙に変色したりすることがある。

 そのまま表示すると、おかしな色合いが目立ってしまうので、リサイズ後に描きなおす、という部分だが、これは画像によると思われるため、実際にやってみて確認するしかないだろう。


 次に、減色については、256色まで落とす必要がある。

 KDDIの公式サイトにはPNGの色数というのは記述があるように見えないが、どうやら色数に制限がある模様で、256色まで落とさないと、おかしな画像幅で表示されてしまう。


 GSFFでは、PC版向けの立ち絵画像と、システム関係の画像について加工を実施した。

 立ち絵画像については、640x640のサイズをバストアップにして表示するため、上下左右80,20,559,289で切り抜き、縦横50%ずつ縮小して、背景と同サイズにあわせ、輪郭を描画しなおした。


 この処理は藤 -Resizer-というツールにて一括で行った。

 切り抜き範囲指定があって助かった。大感謝。


 システム画像については、必要なサイズで予め作成したため、立ち絵画像もあわせて、こちらの「配布物まとめ」にて公開されているBlastPNGというツールを使わせていただき、PNGの減色+ファイルサイズ圧縮処理を実施した。

 BlastPNGはツールの連携で、上記の用途以外にも色々できるみたいだが、今回は、限定的にしか使ってない。


 BlastPNGの設定については、実行するツールでFLAXC,pngrewrite,OptiPNG,PNGOutにチェックをし、FLAXCタブの「透過色ピクセルを指定する」のチェックをしたくらいで、あとは実行パスの入力ミスが無ければ、特に問題は出なかった。

 本来はコマンドラインで動作させるツール群をGUIで楽に利用できるので、こちらも大変ありがたいツールだ。


MIDIの加工

 MIDIの加工は、SMFであればファイルサイズを小さくすることを考えるだけで良い。

 SMFではなかった場合は、形式を合わせる必要が生じるが、今回実施していないので、特に記述しない。

 で、ファイルサイズを小さくするには、曲を短くする方法と、圧縮ツールを使う方法がある。


 曲を短くする方法については、今回実施していないので、詳細は記述できないが、MIDI編集ツールで特定のフレーズ以降をぶった切るなどすればいいだろう。

 編集で意図してないような更新が混入してないか、チェックは必要になるが、圧縮ツールで間に合わない場合は、試してみる価値はあると思う。


 圧縮ツールとしては、SMFパック Proを使わせていただいた。

 圧縮前と後を比較しても、自分の耳では違いがわからなかったくらいで、その割には30〜70%程度のファイルサイズ圧縮が見込める、ありがたいツールだ。


まとめ

 結局のところ、素材ごとにツールを拾ってくるのが手っ取り早いが、どの素材でも以下の作業について考える必要があるだろう。

  • ファイル形式合わせ
  • サイズ・色数・長さなどの要素の調整
  • ファイルサイズ縮小

 この手のツールはプログラマなら自作しなきゃまずい、という考え方もあるけど、適したツールを見抜いて手順を確立する方が大抵早いので、こだわりが無ければ探すほうに時間をかけるといいと思う。

トラックバック - http://d.hatena.ne.jp/senzogawa/20070325

2007-03-22 かんきょう

開発環境

| 開発環境を含むブックマーク 開発環境のブックマークコメント

 開発環境は、プリプロセッサ以外ではそんなに気を使う必要はないだろう。

 考慮した項目は以下。

エミュレータ

 エミュレータは選択の余地は多分無い。

 J2ME Wireless Toolkitをダウンロードすることだ。

 日本語(多言語?)版と英語版があるので、その点だけは注意した方がいい。


 スキンとしては、404 Not Foundにて公開されているファイルを利用すれば、ある程度、実機に近づけることができる。

 結局実機とは違いがあるが、より近い方がいいだろう。実際の相違点については後々記述する。

 上記のサイトはその他の情報もよくまとまっていて、ありがたい。一度、目を通しておくことをお勧めする。


 ちなみに今回制作したアプリ(以下GSFF)では間違って英語版を落として、日本語版に入れ替えるのが面倒だったのでそのまま使ったが、例外メッセージの日本語が化けるので、デバッグしにくかった。


 冷静に振り返ってみると、なんとも間抜けな話だ。

 間違った場合は素直に日本語版に入れ替えることを強くお勧めする。


エディタ

 アウトライン解析と、Java言語向けの強調表示があるなら何でもいい。

 使い慣れたエディタに機能があるなら、それを使う方が、大抵の場合効率がいいので、わざわざ探す必要は無い。

 マクロ定義についてはC言語の記述になるが、C言語の強調表示が無いエディタの方が少ないと思うので、考慮は不要だろう。


 EclipseMEについては、慣れないとかえって面倒が多いと思うが、これを機会にEclipseを使ってみようという人ならお勧めだろう。

 便利な機能も多いみたいだし。


 GSFF制作では、一番慣れているサクラエディタを使わせていただいた。

 アウトライン解析も、強調表示も標準装備している。

 一応Eclipseも試してはみたが、どうもしっくりこなかった。

 ツールが悪いという気はしなかったので、また試してはみたい。


プリプロセッサ

 EclipseMEにはデフォルトで機能があるようだが、ビルドがうまくいかなかったので、どこまでサポートされているのかは、まるで知らない。


 GSFF制作ではppincというツールを使わせていただいた。

 enum、#ifdefによる切り替え、#include、マクロ関数と、充分な機能があるので選んだツールだが、かなり有効に使えたと思う。大感謝。


 基本的には使用上、特に支障は無かったが、'$'と'\\'がある場合に、プリプロセス後のソースがおかしくなることがあった。

 これについては、以下のように\uXXXXで指定して回避した。

#define YEN '\u005c\u005c'
#define DOLLAR '\u0024'

構成管理

 構成管理は、基本的にはツールがフォルダ構成を作ってくれるので、あまり考える必要は無い。

 ただ、プリプロセッサを利用する場合、プリプロセス前のソースを置くフォルダを作成する必要がある。


 GSFF制作では、ppsrcという名前でフォルダを作成し、その中にプリプロセス前のソースを入れ、ppincを通してsrcフォルダにソースが出力されるような.batファイルを作成した。

 以下のような記述だ。

rem srcフォルダと同階層にppsrcフォルダを作成し、
rem 両フォルダの親階層に.batを置く想定。
setlocal
set PP=<pp_incを解凍したフォルダまでのパス>\pp_inc.exe
%PP% ppsrc\Gsff.java src\Gsff.java
rem 他のファイルも同様に記述。

 結局プリプロセスの実行とビルドの実行で、ビルドの手間は増えてしまうわけだけど、これについては自動化できなくはないだろう。

 いずれまたアプリを制作する際に検討してみたいところだ。


まとめ

 開発環境は、大抵の場合、機能差があっても慣れている方が早い。

 現状で欲しくなった機能があるとか、他のツールで試してみたいことがあるなどというならともかく、何も不満が無いなら、現状の環境に近づける方向で考えた方が良いと思う。


 今回の制作は、準備を含めて試作みたいなものだったので、以下を考慮して開発環境を整えた。

 ポイントはわかってきたので、次回はもう少し準備に時間をかけたい。

 テスト方法の検討さえも制作しながらだと、どうしてもコードが汚くなる・・・

トラックバック - http://d.hatena.ne.jp/senzogawa/20070322

2007-03-21

設計・実装観点

| 設計・実装観点を含むブックマーク 設計・実装観点のブックマークコメント

 ある程度要件を決めたら、次に設計・実装を考える。

 考慮した要点は以下の通り。

命令の振り分け

 Javaって関数ポインタのような仕組みが全く使えない。

 よく代替としてObserverパターンが紹介されているけど、あれは命令ごとにクラスが必要になるから、サイズの上限がきつい場合には向いてない。


 スクリプトエンジンのように、文字列で命令を振り分けるためには、文字列を比較して数値化してテーブルを使うようなことはできず、比較したブロック内で命令に対応するメソッドを実行する必要がある。


 調べた限りでは、JavaではString#intern()を使って内部の参照を取得し、この参照と、固定文字列を、「==」で直接比較するという方法があるらしい。

 String#equals()とどちらが早いかについては、実行する状況などにも夜と思われるため、きちんと性能を計測した方がいいだろう。


 今回制作したアプリ(以下GSFF)では、何を思ったのか、最初の4文字を数値化していったん振り分け、その後で文字列比較を行うようにしている。

 それなりの性能は出るが、よりよい方法を探す必要はありそうだ。


 検証してないので、曖昧なことしか書けないが、完全ハッシュをとって、整数で振り分けるのが、一番早くなると思われるが、完全ハッシュは要素を追加するたびに構築する必要があるため、保守・拡張に手間がかかるようだ。


文字コード

 文字エンコーディングについては、移植性を考えるとUTF-8だが、日本語を多く使うノベルゲームのようなゲームの場合、3バイト文字だらけになってしまうため、全く向かない。

 外部および保存時はShift_JIS、内部はUTF-16というのが常道かと思う。


 GSFFでは移植性を無視しているため、外部および保存時はオープンアプリデフォルトであるShift_JISを前提としているが、移植を考えるなら、Shift_JISで指定してみて例外が発生したらUnicodeにする形にした方がいいだろう。


描画周り

 描画周りで注意する点は、Graphics#setClip()だ。

 クリッピング領域はこのメソッドを呼ぶごとに更新されるため、飛び地のクリップは手動で対応する必要がある。

 飛び地になるような場合は、領域のマージをすることになる。


 一方、領域の衝突判定についてはGraphics#clipRect()があるし、Sprite#collidesWith()もあるので、あまり問題は無いだろう。


 GSFFでは、イマイチよくわからないまま組んでしまったため、描画する処理によって対応がバラバラになるという、悲惨な状態となってしまった。

 一応、問題が出ているようには見えないが、領域をマージする処理は別途作っておくべきだった。


 ちなみに衝突判定については、要件レベルで領域が重なるケースを極力排除したため、何も実装してない。


サイズと性能

 サイズを抑えるためには、クラスを作り過ぎないようにすることだろう。

 ある程度の性能を確保するためには、処理を細かく分けすぎず、メソッドの呼び出しを極力減らすことだろう。


 この両方をある程度実現するには、プリプロセッサを活用することだ。

 クラスは配列を定義し、簡単な演算やgetter,setterのようなメソッドは、マクロ関数に置き換えておくといい。


 リファクタリングツールを使ってインラインに展開する、という方法もあるけど、自動化できるケースは少ないと思うので、保守の手間を考えるとプリプロセッサを活用する方が楽だ。


 プリプロセッサの活用が持つ問題である、バグがわかりにくくなる点については、マクロ関数に対する単体テストをしておけばかなり防げる。

 よくあるRectやSizeなどの基本データ型クラスなんかは、プリプロセッサ向きだ。


 GSFFでは、プリプロセッサを使った擬似クラスを5,6個程度使っている。

 他に、ASSERT関数や、無名クラスを用いた非同期呼び出しなんかはプリプロセッサ化している。


 プリプロセス後のソースを確認できなくなるわけではないので、基本的にはデバッグ時もそんなに手間はかからなかった。

 ただ、単体テスト不足の箇所で時間を食ったケースはあったので、単体テストはちゃんとケースを網羅するよう気をつけた方がいい。

 特に、ビットシフトは念入りに。


まとめ

 設計・実装では以下を意識した。

 小さく作るケースではプリプロセッサは有用なので、忌避せず使っていくべきだと思う。

トラックバック - http://d.hatena.ne.jp/senzogawa/20070321

2007-03-19 ようけん

要件観点

| 要件観点を含むブックマーク 要件観点のブックマークコメント

 まずは要件だ。

 早速だが、オープンアプリ向けの要件として、以下の項目を考慮する必要があると判断した。

  • インターネットを使うかどうか
  • キー操作の対応をどうするか
  • フルスクリーンにするかどうか
  • 画面構成

 では、各項目について記述する。

インターネットを使うかどうか

 オープンアプリでは、インターネットを使う場合の制約は少なくない。

  • 接続確認ポップアップが表示される
  • プレイヤーとして1日最大3MBまで
  • 1回32KBまで

 接続確認ポップアップは確実にユーザにとってはうっとおしいだろう。

 この点については、起動後の最初の一回だけダウンロードしてレコードストアに保存しておく、という手段もあるにはあるが、レコードストアのサイズは32KBしかないので、あまり有用とはいえない。


 また、最大サイズが明確な以上、頻繁にダウンロードを行うアプリは不向きだ。

 利用するとしたら、1日にダウンロードするサイズの最大値を予測できるような使い方に限られる。


 今回制作したアプリ(以下GSFF)で利用するかどうか考えたのは、効果音についてだ。

 効果音は比較的大きめのサイズになることが多く、リソースに含めると、300KBに収めることは難しくなる。

 そのため、効果音についてはインターネットから取得するのは一定の利用価値があると思った。


 ただ、効果音というのは、普通結構頻繁に利用することになる。

 まともに使うと、同じファイルに対し、何度もダウンロードが発生し、1日の最大サイズを圧迫していく。

 このあたりを加味し、キャッシュなしではユーザメリットを大きく損なうと判断した。

 で、キャッシュについてはまだ実装していないため、GSFFには残念ながら効果音が一切無い。


 いずれにしても、以下の2点をクリアしない限り、安易な利用は避けるべきだろう。

  • 1日のダウンロードサイズが予測できる
  • アプリ内でキャッシュする

キー操作の対応をどうするか

 オープンアプリ限定ではなく、携帯電話でのキー操作については、以下の3パターンのどれかになると思う。

  1. 上下左右決定キー中心
  2. 番号キー中心
  3. 両方

 大抵は上下左右決定キー中心で問題ないだろう。

 番号キーの方が押しやすい機種もあると思うが、その場合は番号キーも同時に対応するのがスジだ。


 両方を別々に使う場合は、できるだけソフトキーですませて、番号キーはショートカット用に使うとかで、複雑になりすぎないように注意した方がいいだろう。

 携帯電話は主に片手で、しかも大抵は親指だけで操作するのだから、複数のキーが必要な操作はできるだけ避けるべきだ。


 ちなみにGSFFでは、番号キーにはメニューのショートカットを割り当てることを考えていたが、ちょっと厄介なので対応していない。

 その代わりというわけではないが、W51CAのWide Viewスタイルでも操作できるようにするため、左右キー長押しによるソフトキーの代替に対応してみた。


フルスクリーンにするかどうか

 フルスクリーンにした場合のメリット・デメリットは割と明確だ。

 メリットは表示領域が大きくなることであり、デメリットはソフトキーの対応を自前で作成する必要があることと、移植性が悪くなることだ。


 基本的にはソフトキーの動的変更とか、フルスクリーンにしないと収まらないなどのケースでもない限り、フルスクリーンにする必要はないだろう。


 GSFFではフルスクリーン仕様にしたが、理由はフルスクリーンにしないと、画面構成がうまく納まらなかったからだ。

 また、移植をまったく考慮する気は無かったので、移植性が悪くなることはどうでもよかった。


 また、ソフトキーについては、グレーアウトなどを仕掛けることができたので、かえって都合が良かったように思う。

 問題は単純なソフトキーよりも使い勝手が劣っていないかどうかだが、こればっかりは何人かにテストしてもらわないと駄目なので、現時点では判断できない。


画面構成

 画面構成を考える上で、おそらく最も重要なことは、縦長ということだろう。

 PCの場合は横長なので、単にPCを縮小したような画面構成にすると、必ず領域が余ってしまう。

 その余った部分をどう利用するかということをしっかり考えておいた方がいい。


 もちろん、余った部分は単なる余白として使うのもありだ。

 デザイン上の問題もあるが、表示領域を狭くする方が、使用する画像サイズも当然小さくなる。

 最大サイズ300KBに納めるためには、画像サイズが小さい方が有利なので、一考の余地はあるだろう。


 逆に、表示領域が足りなくなった場合、ただでさえ小さい画像を重ねると見栄えが悪くなるため、重ねるだけでなく、表示領域の共有も考慮すべきだろう。

 必要な時に、必要な表示がなされる方が、ユーザにとってもわかりやすい。


 GSFFでは、背景サイズを横240x縦135としている。

 PCで利用していた横640x縦480を、横と縦の比を4:3のまま小さくすると、横240x縦180になるところだが、ハイデフにならって16:9とし、画像サイズが小さくなるように仕向けた。

 また、キャプションの位置を画面中央にすることで、ウェッジインというシステムの表示領域をキャプションと共有させるようにしている。


まとめ

 今回は以下を念頭において要件を絞り込んで制作を行った。

  • インターネットはできるだけ利用しない
  • キー操作はシンプルに
  • 画像サイズは小さく

 成果についてはこの前のエントリにリンクがある。

トラックバック - http://d.hatena.ne.jp/senzogawa/20070319

2007-03-18 ひらく

はじめに

| はじめにを含むブックマーク はじめにのブックマークコメント

 最初に、これから書くことについて、対象者というか、どういう人だったら参考になりそうか、というのを以下にあげてみる。

  • 携帯電話向けのアプリ作ってみたい
  • 素材は一応確保できる
  • Javaを知らない
  • C/C++は知らなくは無い

 これらすべてに当てはまる人・・・いないかもしれないけど、とりあえず、自分がこういう状況だったので。

 概要については以下の通り。

  1. 要件観点
  2. 設計・実装観点
  3. 開発環境
  4. 素材の加工
  5. 実機とエミュレータ

 ちなみに、作成したゲームの内容はノベルゲームなので、動きのあるゲームの作成についてはあまり参考にならないかもしれない。

 それと、シングルスレッドを基本にしたので、マルチスレッドの情報はあまり出せない。


 元のスクリプトを可能な限り生かすため、スクリプトエンジンをエミュレートするような形だったので、何らかのパーサを作ろうとしているなら、多少は参考になるかも。

トラックバック - http://d.hatena.ne.jp/senzogawa/20070318

2007-03-17 くうはく

ゆとり派かガチガチ派か

| ゆとり派かガチガチ派かを含むブックマーク ゆとり派かガチガチ派かのブックマークコメント

 空白論争より。

 自分の場合、MFCから入ったため最初ゆとり派だったけど、左右の片方だけ空白を入れ忘れたりして、徹底できないことが多かったので、あきらめて今はガチガチ派。

 今回制作したオープンアプリのソースもガチガチとしている。


 正直言ってゆとり派の方が見やすいと思うけど、見栄えについては、大抵エディタの強調表示で解決できるので、業務で組む時は最初に書いた人や仲間内での合意に従うことにしている。


 そういえば、組み込み系でゆとり派のソースを見ることは少ないように思うが、IDEの影響なのか、それともガチガチ派が多いからIDEでサポートされることが少ないのか、どっちなんだろう。

 多分後者かな。

トラックバック - http://d.hatena.ne.jp/senzogawa/20070317

2007-03-16 かんせい

オープンアプリ制作完了

| オープンアプリ制作完了を含むブックマーク オープンアプリ制作完了のブックマークコメント

 開発を開始してから2ヶ月ちょうどくらい。ようやく制作が完了した。

 なかなか大変だったが、何とかなるもんだ。

 一応、成果は以下にある。

http://shimanishi.net/gss/mobile/oa/gsff.html


 auオープンアプリプレイヤー対応携帯電話である、W51CA,W51H,W51S,W51SAを持っている方は、基本動作やインタフェースだけでも確かめてもらえるとありがたい。


 今回はおそらく特殊な組み方をしたので、Javaで本格的なアプリを制作する参考にならないだろうが、組み込み向けのJavaが、それほど悪くないとわかったのは収穫だった。

 前に書いたとおり、次からは、オープンアプリの開発について書いていこうと思う。