2005年06月27日
画像認識
NHK映像科学館と言うのが昼前にやっていた。
今日は「人体のしくみ(5) 脳と知覚」の再放送だった。
目から入った情報をどのよう脳で認識しているかというような内容。
かなり面白かった。
CGとか実写映像とかが多くてわかりやすかったし。
そして、一番興味を引かれたのがどのようにして画像を認識しているか？と言うところ。
まだ、完全には解明されていないそうだが、有力なものとして、楕円形などのいくつかの図形パターンに反応する箇所があり、それぞれのところでそのパターンを処理した後に、それを統合して処理すると言うものだった。
なるほどー
脳はすさまじい並列処理をしているので、パターンに分解してから統合し認識しても一瞬で判断できるのだろう。
なら、コンピュータでも、パターンに分割しベイズ理論を使って確率的に判断すれば、かなりの画像識別が出来るかも。と言うか、既にある？
まあ、なんにしても面白そうな分野だ。
投稿者 Takenori : 22:45 | トラックバック
2005年06月30日
音の視覚化
WBSで音を視覚化する装置を紹介していた。
単なるグラフィカルイコライザーの類かと思いきや、実際の映像に音源の位置と音をオーバーラップして表示する装置だった。
音の大きさによって、オーバーラップされる円の大きさが変わり、周波数によって色が変わるようになっていた。
音が出ている位置に表示されるのが面白い。
技術的にも面白かったが、それよりもその映像が良かった。
サーモグラフィのような視覚効果のように使うと面白いかも。
似たような物として臭いを視覚化するようなエフェクトがあると面白いかも。
音の視覚化は今までなかったもので、映像効果としてもなかったが、ないものを効果として作るのは楽しいかもしれない。
コンピュータ上ではいろいろなことが出来るわけだし。
投稿者 Takenori : 23:20 | トラックバック
2005年07月05日
1GB！！ Yahoo!フォト/Yahoo!ブリーフケース
Yahoo!フォト/Yahoo!ブリーフケースの容量が最大1GBに!!
見てみたら、本当に1GBになってた。
これはいろいろと入れたい放題だなぁ。
動画とかも気軽に上げられそう。
とりあえずは、ローカルにあるデジカメの写真をバックアップとして上げるぐらいかな？
前使ったとき、1個1個アップロードするのが面倒だったけど、今も同じかなぁ。
エクスプローラーのように気軽にアップロード＆ダウンロードできるツールないかなぁ。
やっぱり1個1個ファイル選択ダイアログでアップロードしないとダメか。
Vectorで探したけど、ツールも見付からなかった。
作るとなると… 少し時間がかかるなぁ。
投稿者 Takenori : 17:07 | トラックバック
2005年08月06日
シューティングゲーム
シューティングゲームアルゴリズムマニアックス
シューティングもなかなか面白いなぁ。
ただ、自分で作っても自分でクリアできなさそうだけど。
投稿者 Takenori : 14:02 | トラックバック
2005年08月11日
お盆
さてどうするか。
やりたいことや途中になっていることがいっぱいある。
こつこつやっていかないと。
投稿者 Takenori : 23:14 | トラックバック
2005年10月24日
O／Rマッピング
xilionでは、データをSQLiteを使って保存している。
が、SQL文を直に書いていくのはすこぶる面倒臭い。
これを何とかできないかと、Templateを使って楽にテーブルに対応したクラスの定義が出来るようにする方法などを考えていたのだが、このようなことを行うものは既に存在していてO／Rマッピングツールと言うそうだ。
これについては@ITのHibernateで理解するO/RマッピングやCastorでオブジェクトをRDBにマッピングが参考になる。
これらの記事で述べられているツールはJAVA用。
C++用のないかな？
また今度探そう。
投稿者 Takenori : 23:05 | トラックバック
2005年11月06日
Google パーソナライズ
Google パーソナライズを使ってみた。
RSSリーダーなどは少し使っていたが、どうもなじめなかった。
起動待ちやブログはブラウザで読みたいと言ったことが不満だった。
でも、Google パーソナライズはHPなのでいつも通りブラウザで見れる。
いつも読んでいるブログのRSSを登録した。
並び順もD&Dで変更できる。
なかなかいい感じだ。
XOOPSを使って似たようなものを作ろうと思っていたけど、必要ないかも。
ただ、シンプルなGoogleの画面が文字だらけになってしまうので、普段はホームにしておいたほうが良さそうだ。
投稿者 Takenori : 12:47 | トラックバック
2005年11月15日
教育ピラミッド
多くの技術は他の技術を土台にして作られている。
例えば数学はかなりこの傾向が強い。
四則演算、方程式、微積分…… 以前習ったことを理解していなければ、その次のことを理解するのは難しい。
技術が発達していくと、そこに到達するまでに習わなければならないことは増大していく。
もし、ずっと増大を続けるのであれば、いずれ人生の全てを使っても理解出来ないことが出てきてしまうのではないか？
そこまで行かなくても、習得するのにかなりの時間を要するものになってしまうのではないかと思う。
そして、これを何とかできないかと考える。
私は、理解できている人がいるのなら、私もそれを理解できると考える派だ。
理解できないのは、理解に必要な前提知識が足りないからだ。
それはパズルのピースのようなものだと思う。
ピースが欠けているとパズルは完成しない。
おぼろげながら形はわかったとしても、完全ではない。
ならば、初めから理解に必要なピースが列挙できればどうだろう？
『これを理解するのに前提とする知識一覧』が作れたら。
その一覧をいきなり細かくしすぎたら量が膨大になるのは必至だ。
それを避けるためには階層化する必要があるだろう。
そして、それはピラミッドのようになり、一番下のものはかなり平易なものになる。
もし、このようなピラミッドが構築できたと仮定したら、知りたいものを最短で理解できるのではないだろうか？
すでに理解していることなどがデータベース化されていれば、差分を取って足りないピースが列挙できる。
また、その依存関係などから最短の学習プログラムが組めるのではないだろうか？
このピラミッドの構築するには克服すべき課題が多いかもしれないが、やるだけの価値があるのではないかと思う。
そして、それはまるでゲームのようだ。
誰々は何々を覚えた！
誰々が覚えている技術一覧。
何か楽しくなってこないだろうか？
誰か作ってくれないかなぁ。
投稿者 Takenori : 17:05 | トラックバック
2005年12月26日
ゲームキャスティング？
RSSの用法を考えながらふと思った。
ゲームやソフトウェアをポッドキャスト出来ないか？ と。
ソフトウェアのアップデート通知はうざい。
現在の機能に特に不満もないのに起動したら、新しいソフトウェアが・・・といちいち教えてくれる。
別にいらないんだよっ！ と思うが、毎度毎度五月蝿いのでやむなくアップデートする。
それでうまく動かなくなったら目も当てられない。
その点自動アップデートは幾分ましだ。
ウィルス駆除ソフトなどは自動的にアップデートを行って、アップデートしましたよと教えてくれる。
手間いらずだ。
ただ、突然アップデートが始まるので時々びっくりする。
なんかハードディスクがガリガリいい始めた。なんだ？と思ったりもする。
それ以外は快適だ。
ソフトウェアのアップデート通知は、こういったことがあるので少々使いづらい。
その点、ネットラジオなどのポッドキャストは使ったことないけど、使いやすそうだ。
新しいものを取り込んでもらっても特に困らない。
音楽は、ソフトウェアと違って単なるデータだからだろうか？
では、ゲームはデータか？
Yesでもあり、Noでもあるが、データとみなせるだろう。
この場合のデータかどうかと言うのは、感じ方によるものだ。
家庭用ゲーム機ではカセットやCD、DVDでゲームを入れ替える。
CDプレイヤーもDVDプレイヤーも似たようなものだ。
データと言う言い方は少し違うかもしれない。
少しの間楽しむもの・・・メディアやコンテンツと言う言い方が近いだろうか？
プログやニュースなどもそのくくりに入るだろう。
まあ、何にしてもそういう傾向をもつものがRSSなどによる配信に向いているのではないかと思う。
では、現実的にゲームをRSSで配信していくことを考えた場合、どのような形態が良いだろうか？
クライアントソフトが必要なことは間違いないが、勝手にインストールされるのは嫌だ。
データ的なものから離れてしまうし、いろいろと問題も発生しそうだ。
家庭用ゲーム機+カセット(DVD)的な構成が良いだろう。
つまり、ゲームのデータと実行エンジンが分離したような形のものが扱いやすい。
では、クライアントソフトは？
実行エンジンとくっついていると感じるものが扱いやすそうだ。
クライアントソフトから適当に選んで起動できるのがいい。(保守の面を考えるとプログラム自体は分離していた方が良さそう)
クライアントソフトを起動したら、新着ソフトや過去にダウンロードしたソフトウェアが一覧表示され、適当なものを選んでプレイする。
遊ばなくなったものは消したり、お気に入りなどを分類できる。
新着ソフトもジャンルごとに分かれている。
お気に入りの続編は新着リストで優先的に表示される。
かなりお手軽ではないだろうか？
ポッドキャストで有料のものはどのような形態なのだろうか？
ググってみたところ、月額料金のものがすぐにヒットする。
月額、ダウンロードごと、広告がすぐに思い付くものだろう。
なんだかかなり可能性が見えてきた気がする。
吉里吉里を実行エンジンとしたクライアントソフトを試作してみるかな。
投稿者 Takenori : 10:29 | トラックバック
2006年09月18日
忙しいけれど
最近、全然更新していなかった。
かといって、ソフトウェア開発していないわけではなく、詳細などが書けない開発はしている。
それ以外は、ほとんどやっていない状態。
でも、やる時間がまったくないと言うわけではない。
少し前にmixi Alertの機能追加作業をしてみたが、出来なくはないと言う印象。
少しずつ他のも進めて行きたいところ。
まあ、あと数ヶ月でゆとりが出来るはずだけど。
投稿者 Takenori : 12:16 | トラックバック
2007年07月18日
差分表示をデバッガやエディタに
プログラムに変更を加えた時、その変更による影響範囲についてテストを行うけど、その時変更を加えた箇所付近にブレークポイントを張ることが多い。
だから、デバッガでも差分表示できると便利だと思うんだけど、そういうのってないのかな？
後、エディタでも。
アンドゥ・リドゥではなくて、指定した部分を前に戻したり、前がどうなっていたか見ながら編集したり、バグッた時に怪しい箇所をいつ変えたかを簡単に追えたり。
WinMergeのような感じで編集できるといいんだけど。
エディタ側は探せばありそうな気もするな。
WinMergeやサクラエディタ、Eclipseをカスタマイズしていくって手もあるか。
投稿者 Takenori : 15:33 | トラックバック
2007年07月19日
テスト
単体・結合試験をしないとどうも不安な今日この頃。
単体試験、結合試験・・・と進めれば品質が高くなるのは間違いない。
コーディングすればミスをするし、考慮が漏れていることも多い。
試験はその実施のみではなく、試験仕様書の作成自体にも不具合発見の効果がある。
試験仕様書を作成する時、仕様書やソースコードなどを見直し取りうる入力、パスを通すための入力、様々な状態などを列挙していく。
この段階で、この状態でこの入力がきたらバグる、そもそもこの入力に対する考慮が漏れているなどが発見される。
考慮漏れと言うものは、ある程度系統立てて検証しないと発見しづらい。
これはソースコード上のバグのみでなく、様々な成果物に対して言える。
最終段階において元となる要件が漏れていれば、かなりの手戻りが発生することがあるのは周知の通りだ。
少し脱線した。その辺りのことは別の機会に書くとしてテストだ。
ある程度の規模を持ったソフトウェアでは、すべてをテストすることは現実的ではない。
よってそこには時間 ( コスト ) による制限が加わる。
当然、その制限内に終わるように計画を立てなければならない。
単体試験では、全パスを通さなければならない。
それは本当なのだろうか？
実際に結合された段階では通りえないパスが存在する。
使われないものをテストする必要はあるのか？
それはないだろう。
しかし、規模が大きくなればなるほど通らないパスを見つけることは困難になる。
また、今回は通らなかったが、将来加えた変更によって通るようになることもある。
そして発見させるのが潜在バグだ。
ゲーム開発において系統立ててテストが行われることは、経験上や見聞きした範囲ではない。
ゲーム開発でのテストは2種類。
動作確認とシステム全体に対するテスト。
単体や結合なんてすっ飛ばして、いきなりシステムテスト ( 総合テスト ) 。
しかも、そのシステムテストはランダムテストだったりする。
これはある意味合理的とも言える。
システムテストでは、通らないパスをテストすることはない。
しかし、システムテストで見付かった不具合を直したら通らなかったパスを通るようになり不具合が顕在化することはよくある。
潜在バグだ。
では、これをどうやって回避するのか？
回帰テストによって回避する。
不具合修正の影響範囲を調べて、その影響範囲を元に試験書を作成。実施するなどと言うまどろっこしいことはしない。
不具合修正したら、動作確認して次のシステムテストのテストサイクルで何とかする。
同じテストを何度も繰り返して不具合が収束するのを待つ。
それがいつ終わるのかはわからないが、その内収束する。
だから大丈夫。(？)
力業ではあるが、合理的とも言える。
システムテストで基本的なことがすべてカバーできているのであれば、最終製品のクオリティーもある程度保障される。
だが少し心もとない。
もう少し改善できないのだろうか？
つづく・・・
投稿者 Takenori : 15:36 | トラックバック
2007年08月10日
グラフ
マインドマップなどの手法に対して今までどうも懐疑的だった。
なぜか絶賛されればされるほど胡散臭いような。
Vector で Frieve Editor のレビューがあったので見た。
なんかこのソフトは使いやすそうに見えたので、とりあえず使ってみることにした。
初め分類の仕方などよくわからなかったが、ヘルプ自体もこのソフトで作られているので、その構造を見ながらやるとだんだんわかってきた。
なるほどわかりやすい。
まず有向グラフが描きやすい。
ノードのグループ分けがしやすい。
ノードにメモを付けられて、それが後ろにうっすら見えるのが使いやすい。
クラス図や状態遷移図を描いたことがあるのなら、何も言われなくてもどのように使うかはなんとなくわかると思う。
と言うか、私の場合書き方の手法については何も見ていない。
いわゆる我流なのだが、単にノードと関連のあるものをつないでいくだけでわかりやすく整理できる。
しかも、考えやすい。
何かを考える時は、連想ゲームのようにしてAだからB、BだからCかD、Cの場合・・・のように考えるが、これをグラフとして置いておけば、思考の分岐に立ち戻って考えやすい。
いろいろ考えていると、気付いたら全然関係のないこと考えてたりするが、その時も何について考えていたか戻りやすい。と言うか、グラフに描いていたら、それ以外のことはあんまり考えない。
脱線しだしたら、これは後で考えようとかなる。
また、グラフはクラス図に近いので理解しやすい。
各ノードを単純な関連で表しているだけだが、単純な関連ゆえに細かく考えなくていいのでさくさく描ける。
とにかく、何かつながっていると思うからつなげるだけ。
どういう関連かは後で考えればいい。
ただ、クラス図を描いたりする影響か、ああここは継承だなぁと思っても、それを表せないのは少し辛い。
クラス図を描く前に、何がクラスで何がプロパティでなどと考えずに、すべてノードとしてつなげるなどして、クラス図の下書きと言うか、思考の整理段階で使えそうだ。
また、何かを考える時のサポートツールとしても使える。
他に物語も表せそうだ。
大まかなストーリーの流れがあって、それぞれの箇所で詳細が枝分かれするような形で物語が表せそうだ。
このソフトのファイル形式はテキストなので、グラフを他でも使いまわせそうだ。
メモの書き方にルールを設ければ、有向グラフを使うものであれば他用途でも使える。
なんだかいろいろと便利なソフトだな。
関係ないけど、自動スクロールがなんだか気持ちいい。
投稿者 Takenori : 13:13 | トラックバック
2008年01月14日
引数の個数
初めに引数の個数を強く意識したのは、組み込み開発の時のターゲットとそのコンパイラの仕様からだった。
そのコンパイラでは、正確な個数は覚えていないが確か4個まではレジスタ渡しで、それ以上はスタック渡しとなっていた。
つまり、効率を考え出来るだけ引数は4個以内になるように作っていた。
当然、C++ のクラスのメンバ関数では、暗黙的に this が渡されるので 3個以内にしていた。
※ PCでも、呼び出し規約に __fastcall を使えばレジスタ渡しになりレジスタ渡し出来る個数に上限が発生する。ただ、PCの場合は、__fastcall を使い、引数の個数に気を付けても、効果が上がるほど速くなるかどうかは疑問。
そのターゲットから離れて開発をし始めても、だいたい4個ぐらいを目安にしているが、最近は6個ぐらいを限度として書いている。
なぜかと言えば、個数が増えると見辛くなるから。
では、効率云々ではなく、見易さとして考えた場合は何個ぐらいが妥当なのだろうか？
人が瞬間的に判別できる数は3、4個ぐらいという話がある。
テーブルの上にみかんがあるとして、4個ぐらいまでなら、瞬間的に4個と確かな自信を持って言える。
ただ、5個、6個となってくると少し自信がなくなると言うか、瞬間的に認識できないように思う。
6個ぐらいかな？程度に感じる。
でも、この個数は経験によってある程度増えるような気がする。
瞬間的に確かな自身を持って言える数はあまり変わらないが、たぶん6個とか7個とかいうレベルであれば判別でき、誤りも少ない。
このことから考えると、個数を瞬時に認識できると言う意味では、4個と言う目安は悪くないのではないだろうか。
また、6個ぐらいが限度というのも。
他の切り口で見れば、また個数は変わるだろうけど、私は現状では4個以内を目安にし、6個ぐらいが限度として書くかな。
出来れば、4個以内にしたいが。
投稿者 Takenori : 16:15 | トラックバック
クラスメンバ渡しと引数渡し
クラスのメンバに値を入れて、メソッドをコールするか、引数にすべて入れて渡すかはよく迷う。
クラス自身の責務に関係している値であれば、メンバに入れるのは気にならないが、一時的なものの場合はメンバとして持たせるのではなく、引数に入れて渡そうとする。
それが、クラス内部のprivateなメソッドで外部から呼べないとしても、そのような形にしがちだ。
そして、よくクラス非依存になり、static メンバでも問題なくなったりする。
なぜそのような作りにするのか？
それは、出来るだけ依存性を少なくしたいからと言うのが大きい。
クラスからも独立して使おうとすれば使えるように。
ただ、そのようなメソッドを他のクラスに持っていって使ったことは記憶している限りない。
つまり、そのようなアプローチはまったく意味なしとも言える。
もうひとつの理由は、マルチスレッドだろう。
クラスのメンバを経由してしまうと、リエントラントではなくなってしまう。
マルチスレッドのことはよく失念してしまって、気付かないうちに値が変わって、なんか動作がおかしい、なぜ？と言うことが良くある。
しっかり意識して書いている時はいいのだが、そうでないときはミスをする。
そのことが頭の片隅にあるため、クラスのメンバに値を入れて受け渡しすると言うのを無意識のうちに避けているのかもしれない。
投稿者 Takenori : 21:44 | トラックバック
マルチスレッドとアトミック/インターロック
ムービーでは、特に気にせずクリティカルセクションでロックをかけて処理しているが、Windows のクリティカルセクションはかなり遅いらしい。
これはいくつかの文書で見かける。
そして、クリティカルセクションではなく、可能ならインターロック系のメソッドを使うとかなり改善するとも。
インターロック系のメソッドは、InterlockedIncrement や InterlockedDecrement、InterlockedCompareExchange など。
Linux なら、atomic.h の atomic_inc や atomic_dec、atomic_compare_and_swap が該当するもののようだ。
これらは boost の atomic_count_win32.hpp や atomic_count_linux.hpp で使われている。
アトミック/インターロックを使ってプログラムを書く際の触り(？)の部分は、Lock-freeとWait-freeアルゴリズム ( Wikipedia ) に軽く書かれている。
このような方法を使えば、確かにロックせずに動く。
が、ムービーの場合は、処理の単位が大きいので、ロックする方法でもさして問題にはならないような気もする。
まあ、デコーダーの内部処理をマルチスレッド化する際は気にかけた方が良さそうだ。
参考 :
カプコン×インテル。「ロスト プラネット」のマルチスレッド最適化対談
【GDC07】ゲーム開発者はさらなるマルチコア化に備えよ その時の資料 PDF
false sharing の問題 については、OpenMP による共有メモリ並列プログラミング に説明がある。
このようなことを総合すると CUDA や PS3 の SPE のように、コードとデータをパッケージ化して、コアに処理を依頼するような形のプログラミングモデルに向かっているのだろうか？
CUDA で、GPU用に書いたソースコードとCPU用のソースコードが共用できるのであれば、GPU も CPU もわけ隔てなく、空いているコアへ処理を依頼することなども出来そうだが。
投稿者 Takenori : 22:17 | トラックバック
2008年01月24日
TMPGEncのライセンスとテスト用データ
吉里吉里の掲示板のやり取りで気付いたんだけど、TMPGEnc 3.0 XPress や 4.0 XPress って商用利用不可だったのか。
ただ、「お客様（個人または法人のいずれであるかを問いません）」と記載されているので、「本ソフトウェアを個人利用の範囲で利用する権利」を許諾すると言うところの個人は、法人も含まれると言う解釈かな？
私は思いっきり個人的なエンコードと実験用データの作成に使っているが、何らかの製品に TMPGEnc 3.0 XPress でエンコードしたムービーを入れるのは NG か。
で、TMPGEnc Plus 2.5 には、この個人利用云々の記載はないようなので、何らかの製品に入れるにはこちらを使えってこと？
TMPGEnc無料版 ソフトウェアライセンス規約 や FAQ の TMPGEnc 2.5（無料版）の商用利用は？ にもそのような内容のことが書かれている。
これはまったく気付かなかった。
自分的解釈としては、Visual C++でビルドした実行ファイルは売っちゃダメとか、PhotoShopで描いた絵を売っちゃダメとかそんな印象で、それはないだろうと言うことでさして気にしていなかったのだが、TMPGEnc XPress はダメなようだ。
初音ミクなどのVOCALOID で作られたデータについては、声のデータが最終データに含まれるので、作成データの頒布などに関して制限が加わるのは特に違和感はないのだが、エンコーダーでエンコードしたデータに制限が加わるとは思ってもみなかった。
と言うことで、TMPGEnc XPress で作ったデータの扱いには気を付けましょう。
で、終わるかと思ったんだけど、ライセンス的に変なことに気付いた。
それは、FLV4 出力プラグインの存在。
TMPGEnc 4.0 XPress は、FLV4 出力プラグインがあって、これを使えばニコニコ動画向けの動画を出力できる。
TMPGEnc Movie Plug-in FLV4 ページ には、アップロードに便利的なことが書かれている。
でも、ちょっと待って欲しい。
ニコニコ動画にアップロードするのは、明らかに個人利用の範囲は超えている。
後、PEGASYS WEB FLV Player と言う、自分のHPで FLV を表示するに便利なソフトも配布している。
当然、HP で動画を配信するのも個人利用の範囲は超えているだろう。
なんだろうか……
ニコニコ動画用の動画ファイルを作ることは出来るけど、アップロードは出来ません。ってこと？
本当に？
こうなるとつい邪推してしまう。
つまり、「ライセンスには一応書いているけど、黙認していて、特許持ってるところに訴えられたら、それをした人が悪い。うちはライセンスに書いている。」とか？
それとも、生成されたデータに関する制限は加わらないのか？
でも、そしたら掲示板の内容はおかしい。
もしかして制限が加わるのはMPEGのみでFLVについてはないのだろうか？
1度ニコニコ動画に動画を上げた後、AVI 用の FLV 4 Codec を使って動画を作った時、かなり低レートなのに生成された動画が綺麗だったことから、TMPGEnc 4.0 XPress にアップグレードしようかなぁとか思っていたんだけど、使えないのかなぁ。。。
これは問い合わせないと解決しなさそうだな。
投稿者 Takenori : 20:03 | トラックバック
TMPGEnc 4.0 XPressについて聞いてみる
疑問点をペガシスさんに聞いてみる。
とりあえず、以下の質問内容で質問フォームから送ってみた。
----
現在、TMPGEnc 3.0 XPress を使用していて、TMPGEnc 4.0 XPress のアップグレードを検討しています。
その際、使用許諾契約書 を確認していて、気になることがありましたので、ご教授願いたく。
使用許諾契約書には、「本ソフトウェアを個人利用の範囲で利用する権利」とあります。
TMPGEnc 4.0 XPress へのアップグレードの目的は FLV4 プラグインが使えることなのですが、この TMPGEnc 4.0 XPress + FLV4 プラグインで生成された動画は、ニコニコ動画などへアップロードし、公開する事は出来ないのでしょうか？
ニコニコ動画へのアップロードは、明らかに個人利用の範囲を超えていると考えられますので、ライセンス的に不可なのではないかと思いました。
ただ、そうなると FLV4 プラグイン が存在する理由やニコニコ動画対応をアピールしている理由が良くわかりません。
「個人利用の範囲で利用する権利」とは、ソフトウェアの使用に関する制限であって、生成された動画ファイルの頒布に関する制限ではないのでしょうか？
もし、生成された動画ファイルの頒布に関する制限でない場合、それは生成可能なすべての動画ファイルに関して同じ扱いとなるのでしょうか？
つまり、FLV4 以外の WMV や MPEG 1 & 2、AVI ファイル、H.264、MPEG4 も同じ扱いなのでしょうか？
----
数営業日で返信があるようだ。
投稿者 Takenori : 20:26 | トラックバック
2008年01月28日
TMPGEnc 4.0 XPressについてペガシスからの返答
挨拶などを抜いた返答は以下の通り。
----
御質問いただきました件ですが、
|
＞ 使用許諾契約書には、「本ソフトウェアを個人 |
弊社製品機能において、動画配信サイトへのアップロード機能は
含まれておりません。よって本件については、各配信サイト運営先まで
お問い合わせください。
|
＞ 「個人利用の範囲で利用する権利」とは、ソフ |
御指摘の通り、頒布に関しては各ライセンス保持者の規定を
御確認ください。
----
意味がわかりません。
もう少し突っ込んで聞かないことにはなんともいえないなぁ。
2個目のは、頒布の制限はコーデックのライセンス保持者の規定に従えばOKとも取れるが、わかりづらい。
投稿者 Takenori : 20:01 | トラックバック
2008年01月30日
TMPGEnc 再質問内容検討
前回の質問の意味が良くわからなかったので、再質問の内容を考える。
確認したいことを簡潔に書くと、TMPGEnc XPress を使ってエンコードした動画ファイルをユーザーがどのように使おうとも、ペガシスは文句を言わないかどうか。
とりあえず、考えた質問は以下。
-----
ご回答ありがとうございました。
内容を確認しましたが、理解できませんでしたので再度質問させていただきたく。
こちらが確認したいことは明確なため、回答がYesかNoとなる質問と致しました。
疑義が発生しないように、YesかNoで回答していただきたく思います。
また、回答がNoの場合は、その理由をご教示ください。
なお、質問中では敬称を省略させていただいています。
1. TMPGEnc 4.0 XPress でエンコードした動画を動画配信サイトへアップロードすること、およびHPでの配信に関して、ペガシスは関知せず、ユーザーに対して制限は加えていない。
これについて、Yesでしょうか？ Noでしょうか？
2. TMPGEnc 4.0 XPress でエンコードした動画の頒布に関して、ペガシスは関知せず、ユーザーがどのように扱おうともかまわない。
これについて、Yesでしょうか？ Noでしょうか？
3. TMPGEnc 4.0 XPress でエンコードされた動画の頒布は、その動画形式のライセンス保持者の規定に従えば問題ない。
これについて、Yesでしょうか？ Noでしょうか？
以上、よろしくお願いいたします。
-----
こんな感じでいいと思うが、1日寝かせてもう少し検討しよう。
投稿者 Takenori : 01:32 | トラックバック
2008年02月05日
TMPGEnc 再質問回答
再度質問した内容に対して答えが返ってきた。
質問内容はこれ。
挨拶などを抜いた返答は以下の通り。
----
TMPGEnc 4.0 XPressの使用許諾契約書に関してはアプリケーション自体の
使用に関する事になり、これをお守りしていただく限り、出力していただ
いたファイルに関して制限をするものではございません。それを前提とし
た上でいただきましたご質問に対してお答えさせていただきます。
1. TMPGEnc 4.0 XPress でエンコードした動画を動画配信サイトへアップ
ロードすること、およびHPでの配信に関して、ペガシスは関知せず、
ユーザーに対して制限は加えていない。
これについて、Yesでしょうか？ Noでしょうか？
Yesになります。
2. TMPGEnc 4.0 XPress でエンコードした動画の頒布に関して、
ペガシスは関知せず、ユーザーがどのように扱おうともかまわない。
これについて、Yesでしょうか？ Noでしょうか？
Yesになります。
3. TMPGEnc 4.0 XPress でエンコードされた動画の頒布は、
その動画形式のライセンス保持者の規定に従えば問題ない。
これについて、Yesでしょうか？ Noでしょうか？
Yesになります。
上記３点についてですが、文面中の「動画」を全て「動画または音声」
に読み替えて解釈していただけるようにお願いいたします。
また、全ての質問の回答に対し、「一般公開にふさわしくない内容の
コンテンツの公開」や「著作権侵害の恐れのあるコンテンツの作成ま
たは公開」などに関する問題については除外した返答となっているこ
とをご了承ください。これらの問題は今回のご質問とは別に存在し、
弊社の製品はこのような行為を助長するための製品ではないことを付
け加えさせて頂きます。
----
と言うことで、エンコードした動画の再配布に関しては、いわゆる公序良俗に反しない限り問題ないと言うことのようだ。
投稿者 Takenori : 19:54 | トラックバック
2012年11月23日
予想クリア(残り)時間
知りたいのは累積プレイ時間でも進捗率でもなく、あとどれくらいで終わりそうかと言うこと。
話の流れからあともう少しで終わりそうだから、今日中にクリアしようと進めていても、終盤引っ張られて気付いたら外が明るくなってきていて、そろそろ寝ないとやばいと思って寝たりする。
もうすぐ終わりとか思っていたら、裏の世界とか言われて、まだ半分かよ！ということも。
累積プレイ時間はだんだんと後悔する原因になるし、進捗率はあとどれくらいかかるか計算してみないとわからない。
累積プレイ時間も平均クリア時間からクリアできる時間を推測することに使ったりする。
でも、ユーザーのプレイにかける時間から終了時間を予測して、クリアまであと○時間と予想クリア時間が表示されていたら、深く考えなくてもあとどれくらいで終わりそうか分かる。
予想クリア時間が分かれば、今日中にクリアは無理だから、寝たい時間までできりのいいところで寝ようと思うことが出来るし、もう少しで終わりだとはっきり分かる。
面白いと止められなかったりもするけど、わかってやるのとわからずにやるのは違う。
ルート分岐などする場合は、最短と最長を併記してくれていればいい。
だから、予想クリア(残り)時間の表示をやってみてはどうだろうか？
残り時間が素晴らしいと思ったのは、Kindle paperwhite でライトノベルを読んでから。
Kindle paperwhite は、累積時間でも進捗率でもなく、予想残り時間を表示してくれる。
私は、電子書籍は進捗率を分かるようにした方がいいと考えていた。
紙の本の分厚さの考え方の延長だ。
でも、なぜ進捗率が知りたいかというと、あとどれくらいあるかを知りたいからだと気付かされた。
Kindle paperwhite で、読むまではそのことに気付いていなかった。
そして、その便利さに気付いてゲームも同じように表示してくれればあとどれくらいか分かりやすくていいと思った。
時間が分かるとネタばれと思えてしまう部分もあるが、それでもあった方がいいと思う。
投稿者 Takenori : 21:58 | トラックバック
2012年12月07日
アプリストアレビューの問題点と改善案
レビュー周りの話で、開発者側で何か違うと感じるコメントなども見たので、ブログに書く。
アプリストアにアプリを登録する側にとっての問題点は2つに集約されると考える。
1. 自分の店先を汚さないで欲しい。
2. 汚れた店先を掃除させて欲しい。
( 伝わりやすいように店先と言う言葉を使っているが、アプリストアの自分のページとストア全体を指している )
ユーザーが汚い言葉でアプリについて要望や感想を述べるのは自由だ。
そのことについて嘆いて、改めて欲しいとは思うが、普段目にしないところであれば、その発言をする人のためであって、実際のところどうでもいいことだ。
不利益を被るのはその人でしかない。
だが、それが自分の領域だと認識しているところでは話が別だ。
そんなことは止めてほしいし、綺麗にしたい。
問題点を正しく認識できないと改善は出来ない。
私が考える問題点は上述の2つだ。
ユーザーへの啓蒙活動は1番への取り組みだと考えられるが、長い時間が必要だと思うし、すべてを排除するのは不可能ではないかとさえ思える。
もし、システムに手を加えられるのなら、両方簡単に解決する手段はある。
レビューコメントを承認制にすれば一瞬で解決する。
暴言コメントを承認しなければ綺麗になる。
承認制ではなく、消すことができる形だと手間は増えるが綺麗にすることは出来る。
そもそもレビュー機能を無効化できるのであれば、問題自体発生しない。
また、レビューが一方通行なのも問題を増長しているように思う。
せめて返答が出来れば少しは減らすことが出来ると考えられる。
レビューと言う名前だが、要望や不具合の報告が多くあるので、それに対するリアクションはとれるようにするか、分離してほしい。
分離作業を出来て、レビューと考えられるものは公開し要望や不具合は公開/非公開など取捨選択できると助かる。
ストアのシステムを変えられるのは、運営している Apple か Google なので、そこにシステム改善要望を送るのがまず最初にする対策になるはず。
大量に要望が送られれば改善される可能性はあると考えられる。
要望を送っても一向に何も改善されない場合は、また別の方法を考える必要がある。
他のストアに移るのも一つの手だと思う。
願わくば、Windows Store のその辺りのシステムが良くて Windows Phone が普及して、他が追随せざるを得ないような状況になって欲しいと思う。
個人的に Microsoft に期待しているだけだけど。
システムがどうにもならないとするとかなり遠回りしないといけない。
啓蒙はその一つだと思うが、なかなか効果が出ない。
レビュー以外の場所でコミュニケーション出来る場を作るのも一つの方法だと思う。
ストアのシステム外で改善する方法はいろいろと検討の余地がある。
レビュー内容をフィルタリング＆整理して報告してくれる人が欲しいと思うが、それは開発者側の問題で、そう言うことをアウトソース出来たらいいなということ。
投稿者 Takenori : 23:37 | トラックバック
2013年01月22日
電子雑誌を開発者が書くと言うアイデア
開発者に記事を書いてもらい広告を掲載する代わりに原稿料なし、表紙や編集、電子書籍の登録等のやりとりなどのコストは販売代金でまかなう。
基本的なアイデアはこう。
開発者が書いた開発に関する記事などは読んでみたいし、別に商品を宣伝する記事でも意味があると思う。
コストは低く作れるだろうから、200円とか100円で何とかなるんじゃないかと思うけど、調査したわけじゃないし、電子雑誌自体まだあまり見ないので実際にどうなのかわからない。
Amazon の Kindle Direct Publishing を考えると 印税率は 35%で200円なら70円、100円なら35円になる。
広告費をかけづらい小規模なスマフォアプリや同人等なら書きたい人はいると思う。
宣伝は結構困るところだから。
個別のページを見に行くのは面倒だし、知らないところなどは見ない。
雑誌はある程度固まったジャンルでまとまっているのが楽で、知らないところを知ったりもできる。
個別のホームページでは発見できないところを見つけられる。
Amazon ならアダルトも大丈夫なはずだから、エロゲ関係も大丈夫か？
読みたいものが読める、雑誌が安く買える、宣伝できるとなかなか良いアイデアではないかと思ったのだけどどうだろうか？
書きたい人はいるだろうか？
読みたい人はいるだろうか？
投稿者 Takenori : 01:30 | トラックバック
2013年03月17日
無料版なんて要らなかった？
無料版と有料版を作って、公開していたけど、有料版がまったく売れないので無料版の公開を止めてみたらすぐに売れ始めた。
2012/10/27 フリー版公開
2012/11/07 有料版公開
2013/02/12 フリー版非公開 (3カ月で1本も売れない)
2013/03/17 非公開から約1ヶ月で3本売れた。
数は少ないけれど、全く売れない状態から売れる状態になったのは大きい。
無料版と有料版の機能差が少なかったのかもしれないけれど、フリーソフトで用途がある程度満たせるのなら、だいたいはそれで十分。
自分の購入行動を考えてみると、まずフリーソフトを探して、フリーソフトで目的が果たせなければ自分で作るか有料ソフトを購入する。
だから、無料版があると有料版は大きな機能差がないと売れないのだろう。
昔だと300円とか500円などの価格でシェアウェアを売ろうとして、Vector 等に登録すると月に数本しか売れない場合はほとんど振込手数料などで消えてしまうので、フリーソフトにしても大差なかったが、今なら Paypal を使うと手数料が安くて、購入された瞬間に Paypal の自分のアカウントに入金される。
末締め翌月 or 翌々月ではなく、購入された瞬間なのでその点も助かる。
まあ、引き出すにはある程度の金額超えないと手数料がかかるんだけど、Paypal で購入できるところならそのまま使えるのでだいぶまし。
購入ボタンを追加してスクリプトを組めば、購入されたときにメールでライセンスキーを送ることも出来る。
フリーソフトで公開するのなら、300円とか500円と価格をつけて販売した方がいいのかもしれないと思い始めている。
最近ますますソフトウェアの価値が低下していると感じるし、フリーソフトがあると同機能のソフトは売れなくなるし。
作ったから他に使いたい人がいればどうぞとフリーソフトで公開したり、その分野の発展を願ってフリー公開したりもしているけれど、無料でも鬱陶しい人に絡まれたり、いろいろと文句言われたりと疲れるのは変わらない。
逆に有料で買ってくれた人の方が礼儀正しかったりするし、有料版に文句を言うのはほぼ買わない人だけなので、労力的にも有料の方が楽なんじゃないかと思えるくらい。
フリーで公開した方が疲れるとかどういう状況なんだこれという……
いろいろと考え方を改めた方がいいのかと思うことが多い。
投稿者 Takenori : 18:29 | トラックバック
2014年10月09日
スマフォでノベルゲームが売れない理由を考える
アメ車が日本で売れない、なぜだ。昔聞いた話。
日本の住宅事情考えたらコンパクトカーの方がいいし、そもそも都市部では車なしで普通に生活できる。
アメ車が日本で売れないことについて色々と言ってる車会社に対し、何を当たり前なことを言っていると思ったのは記憶に新しい。
PC用ノベルゲームをスマフォに移植してもあまり売れない、なぜだ？ スマフォ市場はだめだ。
何か似たものを感じるのだが気のせいか？
スマフォでは長時間プレイは辛いが、総プレイ時間や1回のプレイ時間が長いゲームになっているノベルゲームをプレイしたいか？
累積プレイ時間が長くなるのはいいとしても、1回のプレイ時間が長いのは辛い。
スマフォは、縦画面が基本で持ちやすいが、横画面のノベルゲームをプレイしたいか？
片手で手軽にプレイするには縦画面ではないと辛い。
横向きでも出来るが、持ちづらいし、長時間になると難しい。両手で持つことになる。
スマフォで何度も何度もタップするのは辛いが、タップで進めるノベルゲームをプレイしたいか？
メッセージが指の位置に被っていると、指を画面から外しながらタップしなければならず、余計にしんどい。
指を画面から外さずに読めるのならまだいい。
出来れば指を画面に置いたままで読めるような形の方が楽。
他にも色々と考えられることや思い浮かぶこと、要因はあると思う。
何十年かけてPCでのプレイやそのユーザーに向けて最適化されてきたノベルゲームをほぼそのままスマフォに移植したとして、それはプレイしやすい物なのだろうか。
常識を一度取り除いて、スマフォ用の最適化が必要なんじゃないかと思う。
売れないと言う話を見聞きしながら、システム的な部分に問題があるんじゃないか？と考える。
投稿者 Takenori : 15:05
2014年10月10日
スマフォでもノベルゲームはそこそこ売れているらしい
スマフォでノベルゲームが売れない理由を考える と書いたが、現状はそうでもない様子。
そこそこは出ていると言う話を複数人から聞いた。
ただ、スマフォ用に最適化するためにコストをかけると言うのは難しそうな感じ。
やって損はないくらいなのかな。
前に言われたことあるんだけど、やはりサクッとスマフォ用に出力できる環境整備が重要そう。
吉里吉里2(Z)/KAG3 をそのまま持って行って動くようなものが一番望まれているのかもしれないけれど、やる気の問題で言えばそういう後ろ向きなものは今は激しくやる気が出ない。
仕事として依頼されればやるけど、趣味開発としてはやらなさそう。
次善策は、KAG3 部分に相当する新スクリプトを作って、そこで互換性を取ってPC/スマフォで動かせるようにすることかな。
この形であればやる気が出るし、以前から何とかしたいと思っていた部分ではある。
ボタン一つでPC用、スマフォ用等リリース出来る形。
個人的には、スマフォ用に最適化されたものが遊びたいと言うか、PCと同じならPCでやるからスマフォ用は要らないと言うところだけども。
投稿者 Takenori : 17:51