> はじめまして、Star Ruby を使用させていただいております。
> どの程度需要があるかはわかりませんが、個人的に欲しい機能を提案致します。
>
> 1、Texture#render_textureにおいて変換用の行列を直接指定
>
> 例えば、affine=>[1.0, 0.2, 0.0, 1.0] この様なオプションで指定できると
> 文字の斜体表示、クォータービュー用の画像の動的生成、簡易的なポリゴン表示等に使えるかと思います。
>
> 現時点でも、手動のラスタースクロールと拡大縮小回転の組み合わせで可能ではありますが、
> 速度および画質の両面で、直接指定とは比べ物になりません。
要するにアフィン行列でせん断変形できればよいということですよね。
確かに行列は指定できたほうが何かと便利かとはおもっていますが、
既存のオプションと競合してしまうので、そこら辺をなんとかしなきゃなあと思います。
(思えば最初から行列オンリーにしてもよかったかもしれません。)
というわけで API さえちゃんとすれば実装はさくっとできそうです。
> 2、一部の記号のキーコードについて
> -,;/[] 等の記号についても拾えるようにならないでしょうか。
これは SDL の制限によるもので、実装は難しいですね...。
ひょっとしたら SDL で使えているものを見落としているだけかもしれないので、もう一度見てみます。
--
Hajime Hoshi <hajim...@gmail.com>
>> 要するにアフィン行列でせん断変形できればよいということですよね。
>> 確かに行列は指定できたほうが何かと便利かとはおもっていますが、
>> 既存のオプションと競合してしまうので、そこら辺をなんとかしなきゃなあと思います。
>> (思えば最初から行列オンリーにしてもよかったかもしれません。)
>> というわけで API さえちゃんとすれば実装はさくっとできそうです。
>
> オプション指定で変換用の行列の初期値を変更するという形ではどうでしょうか。
> 現時点では 拡大縮小 → 回転 となっているところを、 アフィン変換 → 拡大縮小 → 回転 とすることにより、
> 既存オプションとの競合も解決できるのではないでしょうか。
それはいいかもしれませんね。ちょっと考えてみます。
>> これは SDL の制限によるもので、実装は難しいですね...。
>> ひょっとしたら SDL で使えているものを見落としているだけかもしれないので、もう一度見てみます。
>
> SDL/keysym.hでは SDLK_COMMA, SDLK_MINUS, SDLK_COLON 等、定義されているので
> 問題ないかと思います。
SDLK_MINUS あたりははテンキー用だったような気がします。
コロンに関しては日本語キーボードと英語キーボードでこれらの文字は違う位置にある文字ですが、
(というか、英語キーボードではシフトと同時押しじゃないと出てこない)
daisuke...@nifty.com さんはどちらを想定されてますか?
--
Hajime Hoshi <hajim...@gmail.com>
> コロンに関しては日本語キーボードと英語キーボードでこれらの文字は違う位置にある文字ですが、
訂正。
コロンに関しては日本語キーボードと英語キーボードで違う位置にある文字ですが、
--
Hajime Hoshi <hajim...@gmail.com>
>> 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>
> :separator (',')
:sepqrator は :comma に訂正します。
また、次のキーを追加します。
:period ('.')
ところで、今の :decimal がピリオドキーに対応してしまっていますが、実装ミスでした。
:decimal はテンキーの小数点キーに対応すべきキー名でした。
(自分が書いたはずの Star Ruby のドキュメントにもそう書いてあります。)
次期バージョンでそのように修正します。
--
Hajime Hoshi <hajim...@gmail.com>
2009/03/16 19:06 <daisuke...@nifty.com>:
なるほど。 backquote については検討します。
たとえば 106 の @ は 101 キーボードでは [ と同じキーですが、
それを使ってもらうしかないかと。
SDL 側でキーボードの種類を認識出来ないため、
@ をアットマークが押されたとするのは難しいと思います。
(仮に認識出来たとしても、 101 はよいとして
106 だけ特別扱いするのはアンフェアな気がします。
他にもキーボードマッピングは沢山あるようなので。)
--
Hajime Hoshi <hajim...@gmail.com>
>> その 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>
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>
>> 分かりやすさをとって前者でいこうと思います。
>> ちなみに .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>
>> * :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>