機能要望 (render_texture, キーボード)

[daisuke...@nifty.com]

はじめまして、Star Ruby を使用させていただいております。
どの程度需要があるかはわかりませんが、個人的に欲しい機能を提案致します。

1、Texture#render_textureにおいて変換用の行列を直接指定

　　例えば、affine=>[1.0, 0.2, 0.0, 1.0]　この様なオプションで指定できると
　　文字の斜体表示、クォータービュー用の画像の動的生成、簡易的なポリゴン表示等に使えるかと思います。

　　現時点でも、手動のラスタースクロールと拡大縮小回転の組み合わせで可能ではありますが、
　　速度および画質の両面で、直接指定とは比べ物になりません。


2、一部の記号のキーコードについて
　 -,;/[] 等の記号についても拾えるようにならないでしょうか。


ご検討いただけないでしょうか。

[Hajime Hoshi]

星です。メールありがとうございます。

> はじめまして、Star Ruby を使用させていただいております。
> どの程度需要があるかはわかりませんが、個人的に欲しい機能を提案致します。
>
> 1、Texture#render_textureにおいて変換用の行列を直接指定
>
> 例えば、affine=>[1.0, 0.2, 0.0, 1.0]　この様なオプションで指定できると
> 文字の斜体表示、クォータービュー用の画像の動的生成、簡易的なポリゴン表示等に使えるかと思います。
>
> 現時点でも、手動のラスタースクロールと拡大縮小回転の組み合わせで可能ではありますが、
> 速度および画質の両面で、直接指定とは比べ物になりません。

要するにアフィン行列でせん断変形できればよいということですよね。
確かに行列は指定できたほうが何かと便利かとはおもっていますが、
既存のオプションと競合してしまうので、そこら辺をなんとかしなきゃなあと思います。
(思えば最初から行列オンリーにしてもよかったかもしれません。)
というわけで API さえちゃんとすれば実装はさくっとできそうです。

> 2、一部の記号のキーコードについて
> -,;/[] 等の記号についても拾えるようにならないでしょうか。

これは SDL の制限によるもので、実装は難しいですね...。
ひょっとしたら SDL で使えているものを見落としているだけかもしれないので、もう一度見てみます。

--
Hajime Hoshi <hajim...@gmail.com>

[daisuke...@nifty.com]

> 要するにアフィン行列でせん断変形できればよいということですよね。
> 確かに行列は指定できたほうが何かと便利かとはおもっていますが、
> 既存のオプションと競合してしまうので、そこら辺をなんとかしなきゃなあと思います。
> (思えば最初から行列オンリーにしてもよかったかもしれません。)
> というわけで API さえちゃんとすれば実装はさくっとできそうです。

オプション指定で変換用の行列の初期値を変更するという形ではどうでしょうか。
現時点では 拡大縮小 → 回転 となっているところを、 アフィン変換 → 拡大縮小 → 回転 とすることにより、
既存オプションとの競合も解決できるのではないでしょうか。

> これは SDL の制限によるもので、実装は難しいですね...。
> ひょっとしたら SDL で使えているものを見落としているだけかもしれないので、もう一度見てみます。

SDL/keysym.hでは SDLK_COMMA, SDLK_MINUS, SDLK_COLON 等、定義されているので
問題ないかと思います。

[Hajime Hoshi]

星です。

>> 要するにアフィン行列でせん断変形できればよいということですよね。
>> 確かに行列は指定できたほうが何かと便利かとはおもっていますが、
>> 既存のオプションと競合してしまうので、そこら辺をなんとかしなきゃなあと思います。
>> (思えば最初から行列オンリーにしてもよかったかもしれません。)
>> というわけで API さえちゃんとすれば実装はさくっとできそうです。
>
> オプション指定で変換用の行列の初期値を変更するという形ではどうでしょうか。
> 現時点では 拡大縮小 → 回転 となっているところを、 アフィン変換 → 拡大縮小 → 回転 とすることにより、
> 既存オプションとの競合も解決できるのではないでしょうか。

それはいいかもしれませんね。ちょっと考えてみます。

>> これは SDL の制限によるもので、実装は難しいですね...。
>> ひょっとしたら SDL で使えているものを見落としているだけかもしれないので、もう一度見てみます。
>
> SDL/keysym.hでは SDLK_COMMA, SDLK_MINUS, SDLK_COLON 等、定義されているので
> 問題ないかと思います。

SDLK_MINUS あたりははテンキー用だったような気がします。
コロンに関しては日本語キーボードと英語キーボードでこれらの文字は違う位置にある文字ですが、
(というか、英語キーボードではシフトと同時押しじゃないと出てこない)
daisuke...@nifty.com さんはどちらを想定されてますか?

--
Hajime Hoshi <hajim...@gmail.com>

[Hajime Hoshi]

星です。

> コロンに関しては日本語キーボードと英語キーボードでこれらの文字は違う位置にある文字ですが、

訂正。

コロンに関しては日本語キーボードと英語キーボードで違う位置にある文字ですが、

--
Hajime Hoshi <hajim...@gmail.com>

[daisuke...@nifty.com]

> SDLK_MINUS あたりははテンキー用だったような気がします。
テンキー用はSDLK_KP_MINUSですね。

> コロンに関しては日本語キーボードと英語キーボードでこれらの文字は違う位置にある文字ですが、
> (というか、英語キーボードではシフトと同時押しじゃないと出てこない)
> daisuke.ADA...@nifty.com さんはどちらを想定されてますか?

ライブラリ側では101キー、106キー（最近はほとんど109ですね）どちらでもいけるよう、
: = @ ' 等、どちらかではシフトが必要なものでも用意しておき、
どのキーボード(もしくは両方)に対応するかはアプリ製作側で決定する
という形が良いのではないかと思います。

[Daigo]

行列変換はあっていいんじゃないでしょうか。透視変換のAPI気持ち悪いですし、そこに含めちゃっていいんじゃないかと。

[Hajime Hoshi]

星です。

>> SDLK_MINUS あたりははテンキー用だったような気がします。
> テンキー用はSDLK_KP_MINUSですね。

おっと、さようですか。どうも。

>> コロンに関しては日本語キーボードと英語キーボードでこれらの文字は違う位置にある文字ですが、
>> (というか、英語キーボードではシフトと同時押しじゃないと出てこない)
>> daisuke.ADA...@nifty.com さんはどちらを想定されてますか?
>
> ライブラリ側では101キー、106キー（最近はほとんど109ですね）どちらでもいけるよう、
> : = @ ' 等、どちらかではシフトが必要なものでも用意しておき、
> どのキーボード(もしくは両方)に対応するかはアプリ製作側で決定する
> という形が良いのではないかと思います。

よく分からないのですが、 SDL のキー名で通しちゃってよいということでしょうか。

なんで SDL のキーの全部が Star Ruby 側で実装されていないかというと、
歴史的 (?) 事情がありまして、 Star Ruby で扱うキー名はなぜか
.NET の System.Windows.Forms.Keys に対応するキー名になっています。
SDL 側にあるキー名で、かつ .NET 側にもある共通のキー名を定義しています。
こうすべきであった理由は特になかった気がするので、 SDL でしかか定義されていない
キーも使えるものは定義していこうと思います。

--
Hajime Hoshi <hajim...@gmail.com>

[Hajime Hoshi]

星です。

次のキーを追加しました。
すべて英語キーボードにおけるキー名です。
これでご要望のキーは大体把握できてるかと思います。

:backslash ('\') (.NET だと OemPipe で、 OemBackslash はまた別物?)
:closebrackets (']')
:equals ('=') (.NET だと Oemplus)
:minus ('-')
:openbrackets ('[')
:quotes (''')
:semicolon (';')
:separator (',')
:slash ('/') (.NET だと OemQuestion)

キー名は慣例に従って System.Windows.Forms.Keys から採用しました。
(一部例外があります。)
.NET の名前に従うのは単なる慣習であって、特に強い理由はなかったりします。

101 キーボードで動作確認しました。
そのほか SDL のキー定数で定義されているキーはたくさんあるのですが、
動作確認ができないため見送りました。
(101 と 106/109 以外のキーボードだとあるものかもしれませんが…)

リリースは来週中には行いたいと思います。

2009/03/15 12:41 <daisuke...@nifty.com>:

--
Hajime Hoshi <hajim...@gmail.com>

[Hajime Hoshi]

星です。
すみません訂正です。

> :separator (',')
:sepqrator は :comma に訂正します。
また、次のキーを追加します。
:period ('.')

ところで、今の :decimal がピリオドキーに対応してしまっていますが、実装ミスでした。
:decimal はテンキーの小数点キーに対応すべきキー名でした。
(自分が書いたはずの Star Ruby のドキュメントにもそう書いてあります。)
次期バージョンでそのように修正します。

--
Hajime Hoshi <hajim...@gmail.com>

[daisuke...@nifty.com]

すばやく対応いただき、ありがとうございます。
101キーに関しては ` (backquote) があれば網羅できるかと思います。
私も101キーボードを使っているので確認はできませんが、
106用に@ : ^ を追加するといいのかもしれません。

[Hajime Hoshi]

星です。

2009/03/16 19:06 <daisuke...@nifty.com>:

なるほど。 backquote については検討します。

たとえば 106 の @ は 101 キーボードでは [ と同じキーですが、
それを使ってもらうしかないかと。
SDL 側でキーボードの種類を認識出来ないため、
@ をアットマークが押されたとするのは難しいと思います。

(仮に認識出来たとしても、 101 はよいとして
106 だけ特別扱いするのはアンフェアな気がします。
他にもキーボードマッピングは沢山あるようなので。)

--
Hajime Hoshi <hajim...@gmail.com>

[505GTI]

> > 101キーに関しては ` (backquote) があれば網羅できるかと思います。

あと、テンキーのenterを忘れていました。すみません。

> たとえば 106 の @ は 101 キーボードでは [ と同じキーですが、
> それを使ってもらうしかないかと。
> SDL 側でキーボードの種類を認識出来ないため、
> @ をアットマークが押されたとするのは難しいと思います。
>
> (仮に認識出来たとしても、 101 はよいとして
> 106 だけ特別扱いするのはアンフェアな気がします。
> 他にもキーボードマッピングは沢山あるようなので。)

了解です。
キーコードは101キーボードを基準にしていることを
ドキュメントに記載しておけば問題ないかと思います。


話は戻りますが、render_textureにアフィン変換を追加してみました。
拡張ライブラリを書くのは初めてなので、合っているのかどうか解りませんが・・・
:affine=>[a,b,c,d] の形式で、既存の拡大縮小回転もそのまま残してます。
パッチをアップしましたので、もしよければ確認いただけないでしょうか。

[Hajime Hoshi]

星です。返信遅れてすみません。

パッチを確認しました。大体よさそうです。
引数はフラットな配列でいいのかなあ。
[[a, b], [c, d]] でもいいかなと思ったのですが。
両方受け付けるようにするかもしれません。
新しいクラスは作りたくはありませんけど。

2009/03/17 21:21 505GTI <daisuke...@nifty.com>:

--
Hajime Hoshi <hajim...@gmail.com>

[505GTI]

> 引数はフラットな配列でいいのかなあ。
> [[a, b], [c, d]] でもいいかなと思ったのですが。
> 両方受け付けるようにするかもしれません。
> 新しいクラスは作りたくはありませんけど。

フラットの方が実装が少しだけ楽で、オブジェクト生成のコストが低いかとは思いますが、
どちらでもいいんじゃないでしょうか。

[Hajime Hoshi]

星です。

すみません、今週 (日曜) までに新版をリリースする予定でしたが、
諸般の事情から延期いたします。

MinGW をセットアップしているのですが、 Sourceforge.jp のサーバーが
落ちてしまっているようです…。
というわけでサーバー復活次第作業再開いたします。

2009/03/21 19:12 505GTI <daisuke...@nifty.com>:

--
Hajime Hoshi <hajim...@gmail.com>

[Hajime Hoshi]

星です。

リリースが遅れてしまってすみません。。明日にはリリースします。はい。

:affine という名前より :matrix という名前のほうがよいと思ったのですが、
そのように変更してしまって大丈夫ですかね。
このオプションの本質は、「アフィン変換行列」というよりは
「幾何変換のための行列」だと思ったので。

2009/03/22 23:57 Hajime Hoshi <hajim...@gmail.com>:

--
Hajime Hoshi <hajim...@gmail.com>

[505GTI]

> :affine という名前より :matrix という名前のほうがよいと思ったのですが、
> そのように変更してしまって大丈夫ですかね。
> このオプションの本質は、「アフィン変換行列」というよりは
> 「幾何変換のための行列」だと思ったので。

平行移動が含まれてないので:affineだと紛らわしいかもしれませんね。
:matrixのほうが適切かと思います。

[505GTI]

r961では行列を指定したときに:center_x、:center_yが反映されないようです。

[505GTI]

> r961では行列を指定したときに:center_x、:center_yが反映されないようです。

RenderTextureWithOptions()に下記の修正でうまくいきそうです。

AffineMatrix mat = options->affineMatrix;
mat.tx -= mat.a * centerX + mat.b * centerY;
mat.ty -= mat.c * centerX + mat.d * centerY;
if (scaleX != 1 || scaleY != 1 || angle != 0) {　　　　　←　この if も不要かも
if (scaleX != 1) {
　 中略
}
mat.tx += centerX + dstX;
mat.ty += centerY + dstY;
const double det = mat.a * mat.d - mat.b * mat.c;

[Hajime Hoshi]

星です。
バグ報告ありがとうございます。

その if は高速化のために冗長にあるものです。
center_x や center_y は matrix と相性がなんだか悪そうですが、
どういう挙動にしたもんですかね...

2009/03/26 23:27 505GTI <daisuke...@nifty.com>:

--
Hajime Hoshi <hajim...@gmail.com>

[505GTI]

> その if は高速化のために冗長にあるものです。

現状だと変形の有無に関わらず最初のifで1～3回の比較(変形なしの場合は3回で確定)が発生し、
変形がある場合はさらに3回の比較が増えるんですよね。
最初のifをはぶいても3回の比較で済むのではないかなあ。
もしくはフラグを一つ用意してscale,angle,matrixが指定された時はそちらを立てるほうが効率がいいかもしれません。

> center_x や center_y は matrix と相性がなんだか悪そうですが、
> どういう挙動にしたもんですかね...

:angle=>a と :matrix=>[cos(a), -sin(a), sin(a), cos(a)] のどちらを使用しても
同じ結果になるべきかと思います。

[Hajime Hoshi]

星です。

>> その if は高速化のために冗長にあるものです。
>
> 現状だと変形の有無に関わらず最初のifで1～3回の比較(変形なしの場合は3回で確定)が発生し、
> 変形がある場合はさらに3回の比較が増えるんですよね。
> 最初のifをはぶいても3回の比較で済むのではないかなあ。
> もしくはフラグを一つ用意してscale,angle,matrixが指定された時はそちらを立てるほうが効率がいいかもしれません。

比較の回数は変わりませんが、 center_x / center_y の加算、減算の手間が省けます。
(浮動小数点の演算なので、地味に効果があります。)
ただ center_x / center_y の仕様があるので、その if をなくしたほうがよさそうですね。

>> center_x や center_y は matrix と相性がなんだか悪そうですが、
>> どういう挙動にしたもんですかね...
>
> :angle=>a と :matrix=>[cos(a), -sin(a), sin(a), cos(a)] のどちらを使用しても
> 同じ結果になるべきかと思います。

ふーむなるほど。
ではそうしてみましょう。

--
Hajime Hoshi <hajim...@gmail.com>

[Hajime Hoshi]

星です。

if をなくすだけでは不十分でした。 tx / ty の値に補正を加える必要があります。

mat.tx -= centerX;
mat.ty -= centerY;
const double tx = mat.tx;
const double ty = mat.ty;
mat.tx = mat.a * tx + mat.b * ty;
mat.ty = mat.c * tx + mat.d * ty;
if (scaleX != 1) {
...

アップいたしましたのでご確認くださいませ。

2009/03/27 1:29 Hajime Hoshi <hajim...@gmail.com>:

--
Hajime Hoshi <hajim...@gmail.com>

[505GTI]

確認しました。
matrix と center の組み合わせでも問題なく動いています。
また、matrixとscale,angleを併せて指定しても大丈夫です。

ついでにお願いですが、SDLK_KP_ENTER（テンキーのenter）も拾えるようにはならないでしょうか?

[Hajime Hoshi]

星です。

了解しました。名前はいくつか考えられます:
* numpadenter
* separator (Win32API 由来)
分かりやすさをとって前者でいこうと思います。
ちなみに .NET には二つのリターンキーの区別がありません (Keys.Separator はあるが、その値にならない)。
興味深い。

あんまり関係ないですが、 .NET の Keys 列挙型や、 Win32API の仮想キーコードだと、
リターンキーの名前は Enter ではなく Return ですね。失敗したなあ。いまさら変えようがない。

ただいま Windows で、 BGM の途中再生ができないバグに遭遇しています。

2009/03/27 6:52 505GTI <daisuke...@nifty.com>:

--
Hajime Hoshi <hajim...@gmail.com>

[Hajime Hoshi]

星です。

ごめんなさい、やっぱり separator にします。
.NET の Keys 列挙型からキー名をとる、というルールはあまり崩したくないので。

2009/03/27 7:26 Hajime Hoshi <hajim...@gmail.com>:

--
Hajime Hoshi <hajim...@gmail.com>

[505GTI]

> 分かりやすさをとって前者でいこうと思います。
> ちなみに .NET には二つのリターンキーの区別がありません (Keys.Separator はあるが、その値にならない)。
> 興味深い。

キーを押したかどうかを判別できればよいので、どちらでもいいかと思います。
.NETに合わせるなら、どちらも:enterを返すというのも有りかもしれません。

> ただいま Windows で、 BGM の途中再生ができないバグに遭遇しています。

sample の audio.rb しか確認してませんが、linuxでは問題ないようです。(SDL_mixerは1.2.8を使用)

[Hajime Hoshi]

星です。

>> 分かりやすさをとって前者でいこうと思います。
>> ちなみに .NET には二つのリターンキーの区別がありません (Keys.Separator はあるが、その値にならない)。
>> 興味深い。
>
> キーを押したかどうかを判別できればよいので、どちらでもいいかと思います。
> .NETに合わせるなら、どちらも:enterを返すというのも有りかもしれません。

区別しない状態から区別する状態に移行するのは大変ですが、その逆はまだマシであると思われますので、
:separator にしました。

今までの問題点をまとめてみると、 Input.keys の配列を返すという
インターフェイスはいろいろ問題があることが分かりました:

* :enter を :return と勘違いしている場合、 Input.keys(:keyboard).include?(:return) が
false を返してしまうので「あれ?」となる。
* :enter と :separator を区別しなければならなくなる。
かといって区別しない (両方 :enter にする) と、いざ区別したいときに困る。

代替案としては、配列を返すのではなく「今このキーが押されているか」を
返すメソッドを Input モジュールに用意して、配列の include? メソッドよりも
柔軟なインターフェイスにする、というのが考えられます。
ただそうするとブラックボックスな部分が増えてしまいます。
いいことづくめということではありません。

Input.keys が返す配列に特異メソッドを設けるということも考えられますが、あまりやりたくないなあ。

>> ただいま Windows で、 BGM の途中再生ができないバグに遭遇しています。
>
> sample の audio.rb しか確認してませんが、linuxでは問題ないようです。(SDL_mixerは1.2.8を使用)

どうやら Windows だけの現象のようです。
フェードイン時間が短すぎた場合に生じるバグのようでした。
SDL_mixer もそのうち捨てて、自力で実装したいなあ…。

Version 0.3.2 をリリースしました。後ほど公式にリリース告知します。

--
Hajime Hoshi <hajim...@gmail.com>

[505GTI]

> * :enter を :return と勘違いしている場合、 Input.keys(:keyboard).include?(:return) が
> false を返してしまうので「あれ?」となる。

101キーと106キーの記号類に関しても同様の問題が発生するかと思われますが、
これに関しては利用者にドキュメントを読んでいただくしかないかと・・・

> * :enter と :separator を区別しなければならなくなる。
> かといって区別しない (両方 :enter にする) と、いざ区別したいときに困る。

こちらに関しては問題ないかと思います。　区別したくないときは

case key
when :enter, :seperator
~
end

あるいは、　{ :enter=>:enter, :seperator=>:enter }[key] とか
逃げ道が色々ありますので。

> 代替案としては、配列を返すのではなく「今このキーが押されているか」を
> 返すメソッドを Input モジュールに用意して、配列の include? メソッドよりも
> 柔軟なインターフェイスにする、というのが考えられます。
> ただそうするとブラックボックスな部分が増えてしまいます。
> いいことづくめということではありません。
> Input.keys が返す配列に特異メソッドを設けるということも考えられますが、あまりやりたくないなあ。

キーリピートの指定を考えるとややこしくなりそうですが、
Input.key_pressed?[] のようなメソッドがあると使い勝手がいいかもしれませんね。

ただ、配列は残しておいた方がいいと思います。
タイピングゲーム等、文字列入力をする場合は押されたキーの配列の方が便利かと思います。
ほぼすべてのキーに対して判定が必要になるため、
毎回 all_keys.each{|k| if Input.key_pressed?[k} then ~ } というのは大変です。


> Version 0.3.2 をリリースしました。後ほど公式にリリース告知します。

早速ダウンロードしました。
問題なく動いているようです。

[Hajime Hoshi]

星です。

>> * :enter を :return と勘違いしている場合、 Input.keys(:keyboard).include?(:return) が
>> false を返してしまうので「あれ?」となる。
>
> 101キーと106キーの記号類に関しても同様の問題が発生するかと思われますが、
> これに関しては利用者にドキュメントを読んでいただくしかないかと・・・

現状ではそうなんですが、配列ではなくてたとえばキーが押されているかどうか
確認するためのメソッドを用意すれば、 :enter と :return 両方受け付ける、なんて
ことができるわけです。

>> * :enter と :separator を区別しなければならなくなる。
>> かといって区別しない (両方 :enter にする) と、いざ区別したいときに困る。
>
> こちらに関しては問題ないかと思います。　区別したくないときは
>
> case key
> when :enter, :seperator
> ~
> end
>
> あるいは、　{ :enter=>:enter, :seperator=>:enter }[key] とか
> 逃げ道が色々ありますので。

なるほど。
!(Input.keys(:keyboard) | [:enter, :separator]).empty? なんてのもありそうですね。

>> 代替案としては、配列を返すのではなく「今このキーが押されているか」を
>> 返すメソッドを Input モジュールに用意して、配列の include? メソッドよりも
>> 柔軟なインターフェイスにする、というのが考えられます。
>> ただそうするとブラックボックスな部分が増えてしまいます。
>> いいことづくめということではありません。
>> Input.keys が返す配列に特異メソッドを設けるということも考えられますが、あまりやりたくないなあ。
>
> キーリピートの指定を考えるとややこしくなりそうですが、
> Input.key_pressed?[] のようなメソッドがあると使い勝手がいいかもしれませんね。
>
> ただ、配列は残しておいた方がいいと思います。
> タイピングゲーム等、文字列入力をする場合は押されたキーの配列の方が便利かと思います。
> ほぼすべてのキーに対して判定が必要になるため、
> 毎回 all_keys.each{|k| if Input.key_pressed?[k} then ~ } というのは大変です。

なるほど、配列としてとっておけたほうが、使いまわすときに便利ってことですね。
ご意見ありがとうございます。

>> Version 0.3.2 をリリースしました。後ほど公式にリリース告知します。
>
> 早速ダウンロードしました。
> 問題なく動いているようです。

ありがとうございます。

--
Hajime Hoshi <hajim...@gmail.com>