[もどる]
一括表示
0227 Q:回転するレイヤの表示方法
投稿者:春男 2005/06/07(火) 21:22

春男です。

新機能実装おつかれさまです。

たくみさんのサンプルほぼそのままなのですが、以下のように回転のサンプルを修正してみました。

レイヤが表示されながら回転するのを期待したのですが、ループ終了まで何も画面に表示されず、しばらく待っていると回転の最終描画分のみが表示されて終了しました。

レイヤが回転するさまを表示してみたいのですが、どのように書けばよいですか?

INT[@ROTC=0]
LOOP[]
CGACT[NO=5 BNO=10 ROTATION=1 SET=@ROTC]
@ROTC+=1
IF[@ROTC<360]
LOOPCONTINUE[]
IFEND[]
LOOPBREAK[]
LOOPEND[]

0228 表示させながら処理
投稿者:たくみ 2005/06/08(水) 00:35

春男さんどもです〜
レイヤを表示させながら回転処理ということなので、
以下のように、ループする度にWAIT 命令で1フレーム待つ命令を入れてみてください(^^
そうすることで画面表示されながら実行されるかと思います。
ウェイト命令で待ちが入ったときに、そのウェイト時間を利用してシステムは画面描画処理に入ります。
逆に言えば、ウェイト命令を入れない限りスクリプトがずっと実行され続けるので、
画面は一切変わりません。これを利用して、いろいろレイヤをいじった後で、
最後に画面を一気に書き換えたりすることが可能になります(^^

CG[NO=5 A=0 FILE="cg/back5"]
INT[@ROTC=0]
LOOP[]
WAIT[FRAME=1] //ここで画面が更新される
CGACT[NO=5 BNO=10 ROTATION=1 SET=@ROTC]
@ROTC+=1
IF[@ROTC>=360] LOOPBREAK[] IFEND[]
LOOPEND[]

…そういえばこの掲示板、現状だとTABが無効になりますね(普通はそうなのかな?)
TABは半角スペース数文字分に変換させる等の対策しようかな…。

0229 表示させながら回転はできたのですが…
投稿者:春男 2005/06/08(水) 12:30

春男です。

表示方法を教えていただき、ありがとうございました。

> 以下のように、ループする度にWAIT 命令で1フレーム待つ命令を入れてみてください(^^
入れてみたところ、回転しながら描画されました。ありがとうございます。

ただ、私のPCでは約30度おきに1枚しか描画できませんでした。(涙)

動作としては1度ごとに描画してスムーズに360度回転したかったので、ためしにWAIT命令のフレーム数を増やしてやると、FLAME=3でほぼ望んだ結果になりました。

原因は恐らく私のPCの処理がFLAME=1では追いつかないためだと思います。
(念のためスペックです:AthronXP-1700+,S3 ProSavegeDDR(64MB),RAM:512MB,WINXPSP2。)

> そうすることで画面表示されながら実行されるかと思います。
> ウェイト命令で待ちが入ったときに、そのウェイト時間を利用してシステムは画面描画処理に入ります。
> 逆に言えば、ウェイト命令を入れない限りスクリプトがずっと実行され続けるので、
> 画面は一切変わりません。これを利用して、いろいろレイヤをいじった後で、
> 最後に画面を一気に書き換えたりすることが可能になります(^^
なるほど…。

最終的に今回つくってみたかったものがありまして、それは「加速度的に拡大しながら回転」だったりします。最初は、1×1サイズに縮小された画像が、ゆっくり回転数をあげていきながら拡大して息、画面一杯付近まで拡大され、また縮小されていく…その繰り返しを表現してみたかったんです。(回りながら近寄ったり離れたりするイメージですね。)

とりあえずその前段階として、等速度で回転しながら拡大してゆく様子を表現したかったので以下のように書いてみました。縦横640×480ピクセルの画像を表示することとして、この画像の初期表示サイズを1×1とし、画面のサイズ640×480とします。1描画更新ごとに1/100ずつ表示倍率が増してゆき、ちょうど倍率1倍(横640、縦480)になるまで1度ずつ回転しながら拡大するように書いてみました。

…が、CGACTに指定するSET1,SET2の値がINT値でなければならないようで、拡大縮小率をFLOATで計算したあとにINT値としてセットしてやる方法が見つかりません。以下の例では、INT値として宣言した変数(L-Value)に対して、FLOATの計算式の結果を代入して実現できないか試したのですが、AGACTの実行時に「設定できる値は1〜????です。」という意味のエラーがでてしまいました。一方、コメントアウトしているように、FLOAT型の変数を用意してFLOATとして計算を行った結果をじかにCGACTのSET1,SET2に設定してみたり、FLOAT型の変数の計算結果をINT型の変数にVARACT命令で変換してからCGACTのSET1,SET2に設定しようとしたりしたのですが、いずれもエラーで不可能でした。

Q1.どのように記述すれば実現できるでしょうか。
Q2.今回書こうとしている表現方法のように、拡大縮小回転を、等速度あるいは等加速度運動として表現したい場合ですが、処理の重いPCでも軽いPCでも、等しく一定時間で同じ動作を表現したいと思います。重いPCではコマ落ちしながらの表現になります。WAIT[FLAME=???]の???を増やす方法では、増やした分だけ1描画更新時間が延びてしまい実現できません。うまい記述の方法はありますか。
Q3.WAIT[FLAME=????]とは違うアプローチですが、WAITせず普通に画面に更新してくれと伝える命令と、なるべく精度の高い経過時間を検出して処理を分岐したいので、高精度タイマーが欲しいのですが(timeGetTime()またはマルチメディア系の高精度タイマーのような)、ございますか?

---
CG[NO=5 A=0 FILE="cg/back5"]
CG[NO=6 FILE=""]
CG[NO=7 FILE=""]
FLOAT[@ZOOMXF=1.0]
FLOAT[@ZOOMYF=1.0]
INT[@ZOOMX=1]
INT[@ZOOMY=1]
INT[@ROTC=0]
INT[@CNTR=0]
LOOP[]
CGACT[NO=5 BNO=6 SIZE=1 SET=@ZOOMX SET2=@ZOOMY]
CGACT[NO=6 BNO=7 ROTATION=1 SET=@ROTC]
WAIT[FRAME=1]
//@ZOOMXF=6.4*@CNTR
//@ZOOMYF=4.8*@CNTR
//VARACT[CONVERT=1 SET=@ZOOMX LET=$ZOOMXF]
//VARACT[CONVERT=1 SET=@ZOOMY LET=$ZOOMYF]
@ZOOMX=6.4*@CNTR
@ZOOMY=4.8*@CNTR
@ROTC+=1
IF[@CNTR>100] LOOPBREAK[] IFEND[]
LOOPEND[]
拡大縮小。

0231 拡縮&回転
投稿者:たくみ 2005/06/09(木) 21:33

どうもです〜(^^

> ただ、私のPCでは約30度おきに1枚しか描画できませんでした。(涙)

うわぁ…そんなに遅くなってしまいますか…。
やっぱり拡大縮小させながら回転処理させるとそのくらいになってしまうのかな…。
今のところ、とりあえず実装できたという段階なので、まだチューン出来ていないんですよね…。
まだまだ速度改善できそうなので、近いうちにチューンしてみます。

> 最終的に今回つくってみたかったものがありまして、それは「加速度的に拡大しながら回転」だったりします。

なるほどなるほど。
いろいろYU-RISを触ってくださって有り難うございますm(^^)m

> とりあえずその前段階として、等速度で回転しながら拡大してゆく様子を表現したかったので以下のように書いてみました。

> Q1.どのように記述すれば実現できるでしょうか。

はい。まず、SET の値の代入方法に関してですが、
例えば SET=1.3*5 とすると、式の中に少数(実数)がありますので、式が自動的にFLOATで計算されるようになっています。
で、1.3 * 5 = 6.5 となり、その時点で整数に置き換えられ(小数以下が切り捨てられ)、SET に 6 の値がセットされます。
ですので、そこに関しては問題無いはずなのですが、
下のスクリプトを拝見しましたところ、エラーの原因が分かりました。
「設定できる値は1〜」というエラーが出てしまうとのことですが、

CG[NO=5 A=0 FILE="cg/back5"]
CG[NO=6 FILE=""]
CG[NO=7 FILE=""]
INT[@ZOOMX=1]
INT[@ZOOMY=1]
INT[@ROTC=0]
INT[@CNTR=0]//※3
LOOP[]
CGACT[NO=5 BNO=6 SIZE=1 SET=@ZOOMX SET2=@ZOOMY] //※1
CGACT[NO=6 BNO=7 ROTATION=1 SET=@ROTC]
WAIT[FRAME=1]
@ZOOMX=6.4*@CNTR //※2
@ZOOMY=4.8*@CNTR //※2
@ROTC+=1
//※4
IF[@CNTR>100] LOOPBREAK[] IFEND[]
LOOPEND[]

えと、※1の部分でSETに0が入ってしまったために出てしまったエラーだと思います。
つまり @ZOOMX に0が入ってしまう場面が存在します。
具体的には、まず最初から順に命令が実行されていき、初めて※2の部分を通った時点で、
その時点での @CNTR の値が0なので、@ZOOMX, @ZOOMY の値が0になります。
そして、LOOPEND を通って※1のところに戻り、そこで@ZOOMX, @ZOOMY の値が0であるために
SET=0 となり、エラーになっているようです。
解決策としては、※3の@CNTRの初期値を1にして、あとは ※4の部分あたりに「@CNTR+=1」を追加すれば
OKだと思います。一応修正バージョンを書きますと、

CG[NO=5 A=0 FILE="cg/back5"]
INT[@ZOOMX=1]
INT[@ZOOMY=1]
INT[@ROTC=0]
INT[@CNTR=1]
LOOP[]
CGACT[NO=5 BNO=6 SIZE=1 SET=@ZOOMX SET2=@ZOOMY]
CGACT[NO=6 BNO=7 ROTATION=1 SET=@ROTC]
WAIT[FRAME=1]
@ZOOMX=6.4*@CNTR
@ZOOMY=4.8*@CNTR
@ROTC+=1
@CNTR+=1
IF[@CNTR>100] LOOPBREAK[] IFEND[]
LOOPEND[]

これで動くかと思います。

> Q2.今回書こうとしている表現方法のように、拡大縮小回転を、等速度あるいは等加速度運動として表現したい場合ですが、
> 処理の重いPCでも軽いPCでも、等しく一定時間で同じ動作を表現したいと思います。重いPCではコマ落ちしながらの表現になります。
> WAIT[FLAME=???]の???を増やす方法では、増やした分だけ1描画更新時間が延びてしまい実現できません。うまい記述の方法はありますか。

現状でなんとか解決させるとしたら、一回の移動量を3フレーム分に増やすとか、くらいでしょうか…。
回転だけ、あるいは拡大だけなら、いくらか処理は速いのですが、両方となるとさすがに現状では厳しいようです。
現在のところ、YU-RIS内部の拡大縮小回転の演算があまりに遅いため、
それをチューンする以外に解決法がなさそうです…。
ひとまず参考になればと、今、拡大縮小&回転それぞれのサンプルを作ってますので、しばらくお待ちくださいませ。
明日の朝までには公開できるかと思います。

> Q3.WAIT[FLAME=????]とは違うアプローチですが、WAITせず普通に画面に更新してくれと伝える命令と、
> なるべく精度の高い経過時間を検出して処理を分岐したいので、高精度タイマーが欲しいのですが(timeGetTime()またはマルチメディア系の
> 高精度タイマーのような)、ございますか?

はい。ありますです。システム変数に @_OS_TIME() という変数がありまして、これは中で timeGetTime() を呼び出しています。
なので精度はミリ秒と、十分高いですよ(^^
例えばスクリプトのA地点で @TIME1=@_OS_TIME(0) を処理し、また別のB地点で @TIME2=@_OS_TIME(0) を処理して、
@TIME3 = @TIME2 - @TIME1 とすれば、A地点を通ってからB地点に到達するまでの時間が
ミリ秒単位で @TIME3 に代入されます(^^

0233 拡縮&回転
投稿者:春男 2005/06/10(金) 10:18

春男です。

> やっぱり拡大縮小させながら回転処理させるとそのくらいになってしまうのかな…。
30度おきの表示の場合ですね。この場合は回転処理だけです。

> 今のところ、とりあえず実装できたという段階なので、まだチューン出来ていないんですよね…。
> まだまだ速度改善できそうなので、近いうちにチューンしてみます。
よろしくお願いいたします。標準的なマシン構成で WAIT[FLAME=1] のループで、拡大回転の組み合わせ等よく使いそうな組み合わせでコマ落ちが起きないまたは起きにくい速度の確保ができると色々できそうです。

> > はい。まず、SET の値の代入方法に関してですが、
> 例えば SET=1.3*5 とすると、式の中に少数(実数)がありますので、式が自動的にFLOATで計算されるようになっています。
> で、1.3 * 5 = 6.5 となり、その時点で整数に置き換えられ(小数以下が切り捨てられ)、SET に 6 の値がセットされます。
なるほど、変数の宣言した型に自動キャストされるんですね。スクリプト修正ありがとうございます。うは…ループの開始直後に範囲外の値の代入になっていましたか。お手数かけました。

思ったのですが、エラー表示で「範囲外です」と表示するだけでなく、エラーになった値も一緒に表示頂ければデバッグが速くなるかも知れません。たとえば「0は、1〜????の、範囲外です。」または、「代入処理:範囲外の値の代入:値=0、範囲=1〜????」なんかどうでしょうか。

> > これで動くかと思います。
修正いただきありがとうございました。無事に動作を確認しました。確認したところ、縮小値が大きい(=小さく表示される)あいだはスムーズに表示できているのですが、当倍に近づくにつれてコマ表示になりました。やはり今後の高速化に期待します。

> ひとまず参考になればと、今、拡大縮小&回転それぞれのサンプルを作ってますので、しばらくお待ちくださいませ。
ありがとうございます。

> > > Q3.WAIT[FLAME=????]とは違うアプローチですが、WAITせず普通に画面に更新してくれと伝える命令と、
> > なるべく精度の高い経過時間を検出して処理を分岐したいので、高精度タイマーが欲しいのですが(timeGetTime()またはマルチメディア系の
> > 高精度タイマーのような)、ございますか?
> > はい。ありますです。システム変数に @_OS_TIME() という変数がありまして、これは中で timeGetTime() を呼び出しています。
おお @_OS_TIME() ですか。参考にします。
あと、WAITせず即時画面更新をする命令の方はどうでしょうか。もしかして WAIT[FLAME=0] で実現できたりしますか。または、描画の指示は WAIT[FLAME=?] のみによる実現が推奨されるようなシステムの構造をしていたりするなど意味があるため WAIT[] を使用して欲しい状況でしょうか。

あと、今回 CGACT[] を使ってみて、レイヤの表示状態についてもう少し詳しく知りたいと感じました。

たとえば、サンプルスクリプトの回転処理では CGACT[NO=a BNO=b ...]のように書かれていましたので真似しましたが、これは、レイヤaからレイヤbに回転後の画像を複製する、という意味ですよね。そして、画面に表示されるのはこの場合レイヤbのみのようですが、それぞれのレイヤの表示状態がいつどのような条件で非表示になったり表示状態になったりするのかがわかりません。

0234 サンプルです
投稿者:たくみ 2005/06/10(金) 17:06

すみません、昨日はあれからバタンキューしてしまいました(_ _;
簡単ですがサンプル作りました。こちらにおいておきますね。
http://www.firstia.com/yu-ris/download/down.cgi?yu-ris_0163_sample_1&0

> > やっぱり拡大縮小させながら回転処理させるとそのくらいになってしまうのかな…。
> 30度おきの表示の場合ですね。この場合は回転処理だけです。

なんと(TT;

> よろしくお願いいたします。標準的なマシン構成で WAIT[FLAME=1] のループで、拡大回転の組み合わせ等よく使いそうな組み合わせでコマ落ちが起きないまたは起きにくい速度の確保ができると色々できそうです。

了解です。頑張ってみます。

> 思ったのですが、エラー表示で「範囲外です」と表示するだけでなく、エラーになった値も一緒に表示頂ければデバッグが速くなるかも知れません。
> たとえば「0は、1〜????の、範囲外です。」または、「代入処理:範囲外の値の代入:値=0、範囲=1〜????」なんかどうでしょうか。

あ、表示されていますよ(^^
エラーが出たとき、[内容]の項目内に、CGACT[SET=0] と表示されていたかと思います。
「SETが0の値を取りました」という意味ですね。
ただ、確かにちょっと分かりづらいですね。次回もうちょっと分かりやすいよう修正してみますです。

> 修正いただきありがとうございました。無事に動作を確認しました。確認したところ、縮小値が大きい(=小さく表示される)あいだはスムーズに表示できているのですが、
> 当倍に近づくにつれてコマ表示になりました。

やはりそうですか…。

> WAITせず即時画面更新をする命令の方はどうでしょうか。もしかして WAIT[FLAME=0] で実現できたりしますか。
> または、描画の指示は WAIT[FLAME=?] のみによる実現が推奨されるようなシステムの構造をしていたりするなど意味があるため WAIT[] を使用して欲しい状況でしょうか。

あ、失礼いたしました…(_ _;ゞ
即画面反映ですか。確かにそれも有るといいかもしれませんね。
ただ、レイヤーをひとつ動かす度にレイヤ合成計算が入るので、相当に遅くなりそうです。
あとは画面のチラつきが頻繁に発生してしまいそう…;
いろいろ検討してみて、解決策がありそうなら実装してみたいと思いますね。
>
> あと、今回 CGACT[] を使ってみて、レイヤの表示状態についてもう少し詳しく知りたいと感じました。
> たとえば、サンプルスクリプトの回転処理では CGACT[NO=a BNO=b ...]のように書かれていましたので真似しましたが、
> これは、レイヤaからレイヤbに回転後の画像を複製する、という意味ですよね。

あ、そうです。

> そして、画面に表示されるのはこの場合レイヤbのみのようですが、それぞれのレイヤの表示状態がいつどのような条件で
> 非表示になったり表示状態になったりするのかがわかりません。

あ、いえ、レイヤAも表示されたままです。あくまで CGACT 命令では加工、複製するだけです。
恐らくレイヤBの下にレイヤAが隠れてしまっているために見えなくなってしまっているだけだと思います。
レイヤBの透明度Aを128とかにしてみると、後ろに隠れているのが分かると思います。

0235 サンプルです
投稿者:春男 2005/06/10(金) 20:44

春男です。

> 簡単ですがサンプル作りました。こちらにおいておきますね。
あらら、お疲れさまでした。拝見しました。透明になりつつ小さくなるサンプルがキレイです。参考にいたします。ちなみにベンチによると、自分のPCの処理能力はたくみさんのPen4の半分でした…。(非力ですね。)

このへん高速になれば、一昔前の Premier で作られたマッドムービーみたいな派手なオープニングムービーもどきが、スクリプトだけで実現できそうですね。(…そうなるとむしろ描画そのものよりも、複数の描画オブジェクトの動きとかの管理を処理しやすいシステムと言語が必要になって、そっちの方が検討課題になりそうですね。^^; 最近の商用ノベル作品は、動きをようやく追求しはじめてるようですが…。)

> エラーが出たとき、[内容]の項目内に、CGACT[SET=0] と表示されていたかと思います。
おおぅ失礼しました。見落としたようです。

> ただ、レイヤーをひとつ動かす度にレイヤ合成計算が入るので、相当に遅くなりそうです。
> あとは画面のチラつきが頻繁に発生してしまいそう…;
やはり実装上の関連があるようですね。

ちらつきといいますと V-Sync. 期間中に描画するよう工夫されている関連でしょうか。だとすると、即時といっても、まずその時点で必要なレイヤ合成処理を行って、次回 V-Sync. 期間に入るまでそのまま待ち、そして描画する(SendMessage()的ですね)までの処理をそのコマンドで実行するか、処理だけ投げておいてスクリプトエンジンは先に進みつつ、次回 V-Sync. 期間にはいったらシステム側で描画する(PostMessage()的ですね)ような仕様なら解決しそうですが…システム構造を知らず勝手なこと言ってますよね、きっと。聞き流して下さい。^^;

> 恐らくレイヤBの下にレイヤAが隠れてしまっているために見えなくなってしまっているだけだと思います。
> レイヤBの透明度Aを128とかにしてみると、後ろに隠れているのが分かると思います。
確認しました。なるほどー、こうなっているんですね。

色々ご回答等頂きありがとうございました。それでは。

#スレッドが深くなり失礼しました。

0237 サンプルEXE差し替えてみました
投稿者:たくみ 2005/06/12(日) 22:48

> 簡単ですがサンプル作りました。こちらにおいておきますね。
> ちなみにベンチによると、自分のPCの処理能力はたくみさんのPen4の半分でした…。(非力ですね。)

先日のサンプルを今回のバージョンに差し替えてみました。
http://www.firstia.com/yu-ris/download/down.cgi?yu-ris_0164_sample_1&0
今回のバージョンで、春男さんのマシンでも私の前回のマシンの数値と同じ程度かそれ以上になったのではと期待してます(^^ゞ

> このへん高速になれば、一昔前の Premier で作られたマッドムービーみたいな派手なオープニングムービーもどきが、スクリプトだけで実現できそうですね。

非常にやりたいですね(^^)。
でもレイヤ演算速度が遅いとどうしようもないですしね…。
そのための今後の策をいろいろと考えてます(^^

> ちらつきといいますと V-Sync. 期間中に描画するよう工夫されている関連でしょうか。
> だとすると、即時といっても、まずその時点で必要なレイヤ合成処理を行って、次回 V-Sync. 期間に入るまでそのまま待ち、
> そして描画する(SendMessage()的ですね)までの処理をそのコマンドで実行するか、処理だけ投げておいてスクリプトエンジンは先に進みつつ、
> 次回 V-Sync. 期間にはいったらシステム側で描画する(PostMessage()的ですね)ような仕様なら解決しそうですが…

なるほど。特に後者のほうは良いかもですね。
いろいろ検討してみます(^^

> #スレッドが深くなり失礼しました。

いえいえ、ツリーが右端に着いてしまうくらいどんどん書き込んでやってください(笑

0238 サンプルEXE差し替えてみました
投稿者:春男 2005/06/14(火) 00:39

春男です。

すみません、今回も色々と好き勝手なことを書いてしまいました。ごめんなさい。

> 今回のバージョンで、春男さんのマシンでも私の前回のマシンの数値と同じ程度かそれ以上になったのではと期待してます(^^ゞ
だいぶ速くなりました。お疲れ様です。

今回の版のベンチによると…残念ながら、まだたくみさんの以前のベンチの133.3%ほどの時間がかかっているようですが、しかし大分高速になりました。ありがとうございます。

このあたりに関して2点思ったことが…。

1つめは、これからまたチューニングされるときの目安として、テストで表示させるレイヤの表示サイズおよびアプリケーションの表示領域サイズは 800×600 で検証された方が望ましい気がします。最近 800×600(XGA)サイズが主流になりつつあるようですので、そのサイズで十分な速度を目指された方がと。

2つめは、拡大縮小回転などの処理の抜本的高速化が目指せる方策ですが、ぶっちゃけ Direct3D ベースのシステムにされてはどうでしょうか。要するに「レイヤ=四角ポリゴンのサーフェス」にしてテクスチャよろしく画像を貼り付けた四角ポリゴンをレイヤとして扱うようなシステムにすれば、回転だろうが拡大縮小だろうが、平行移動だろうがなんだろうが、HALがのっており DirectX 8 ぐらい以降に対応しているビデオがあれば、おそらくは2Dで自前で描画するのとは比較にならないぐらい爆速状態になると思われます。今時 HAL のない DirectX の動かないマシンなんてまず考慮しなくて良いのではないでしょうか。

また、 DirectX というか 3D ベースのエンジンにすることによる他のメリットとしては、オブジェクトの表現力が飛躍的に増大することです。レイヤオブジェクトをはじめとして、すべてのオブジェクトを3D物体として自由に操作できますし、パーティクル(光源)や水面、鏡像などの処理も使えるようになります。

そういえばWINXPの後継OSロングホーンでは、OS本体のデスクトップ表現方法としてこういったシステムが標準実装の予定で開発が進んでいたのは周知の事実でしたが結局タイムスケジュール等の影響で、デスクトップの3D化とアクティブディレクトリが削除されたと聞いたときは呆然としました。一体あとに何が残ってるというんでしょうか。ロングホーン=XPSP3なのでしょうか。(笑)

それはさておき、上記の手段をとれば速度の問題が解消し、また表現力が大幅に向上すると思うんですが…なぜか巷のエンジンはこぞって2Dシステムなんですよね…。WINDOWS専用エンジンなば別に DirectX テクノロジを忌避する理由は無いと思いますし、表現力のアップは飛躍的だと思うんですが、どうしてなのでしょうね…?このあたり、たくみさんの開発者としてのご意見うかがえましたら非常に嬉しいのですが、ぶっちゃけどうお感じになりますか?

> > 非常にやりたいですね(^^)。
> でもレイヤ演算速度が遅いとどうしようもないですしね…。
> そのための今後の策をいろいろと考えてます(^^
おお、期待しております。

0239 Direct3D
投稿者:たくみ 2005/06/16(木) 21:10

どうもです〜
いつもレス遅くなってしまい本当にすみません;;

> すみません、今回も色々と好き勝手なことを書いてしまいました。ごめんなさい。

いえ、逆に好き勝手書いてくださった方がこちらにとって助けになりますから(^^

> 今回の版のベンチによると…残念ながら、まだたくみさんの以前のベンチの133.3%ほどの時間がかかっているようですが、

うーん…まだまだですね…。でもまだ高速化の余地がいくつかあるので、どんどんいじっていきたいと思います。

> 1つめは、これからまたチューニングされるときの目安として、テストで表示させるレイヤの表示サイズおよび
> アプリケーションの表示領域サイズは 800×600 で検証された方が望ましい気がします。
> 最近 800×600(XGA)サイズが主流になりつつあるようですので、そのサイズで十分な速度を目指された方がと。

なるほど…そうしたら、サンプルスクリプトのほうも変更しようかな…。
アドバイスどうもです(^^

> なぜか巷のエンジンはこぞって2Dシステムなんですよね…。WINDOWS専用エンジンなば別に DirectX テクノロジを忌避する理由は
> 無いと思いますし、表現力のアップは飛躍的だと思うんですが、どうしてなのでしょうね…?
> このあたり、たくみさんの開発者としてのご意見うかがえましたら非常に嬉しいのですが、ぶっちゃけどうお感じになりますか?

そうですね…。
Direct3Dを使うと、ビデオカードの機能をフルに使うことが出来るので、2Dだけを例にとったとしても、
拡大縮小回転は超高速でおこなえ、レイヤーも何百枚重ねても一瞬で合成できたりと、一見夢のような機能に思えますが、
いざDirect3Dを採用しようとしますと、慎重にならざるを得なくなります。

HALが動かない環境をお持ちのユーザーさんというのはもうかなり減ってきていると思いますし、
場合によってはHELでも、遅いですがとりあえず動くことは動きますしね。
ただ問題として、ビデオカードのドライバのバグや不具合、また環境との相性というのがあります。
仮にYU-RISにバグがひとつも無かったとしても、ドライバ側にバグがあって動かなかったり(今はかなり安定してきていますけど…)、
動いても画面が乱れたり、不具合や相性問題などで最悪フリーズしてしまったりという症状も発生してしまう恐れがあります。
仕事の関係で、いくつかのエンジンでそういったお話をうんざりするほど聞いてきました…。

制作者側としては、「Direct3Dを使って作られたプログラムだし、それが正常に動かないマシンで動かそうとしてもムリだからしょうがない」
ユーザーとしては、「ならDirect3Dを使わないでプログラム組んでくれればよかったのに…」
となります。
どのユーザーも、要求の優先順位として、まずは動くプログラムを作って欲しい、という要求が一番にあります。
次の2番目に、(演出を含め)中身をこだわって作って欲しい、が来ることになります。

ここで言ったことが全てではないですが、そういう理由で、世に出ているエンジンはどれもまずは安定して動くことを
優先して作られているのだと思います。

ただ、ですが…、

そんなことばかり言い続けていたら、いつまで経っても新しい技術を利用した物が作れなくなってしまうのも確かです。
技術の進化に乗りつづけることもかなり重要だと考えています。
結局のところ何が言いたいかというと、YU-RISは実は最初からDirect3Dの採用を予定しています(^^;ゞ
(YU-RISの描画エンジンが最初3Dだったというのもそのためです)
ただ現状のYU-RIS描画エンジンは土台作り(第一段階)という感じでして、まずはフルスクラッチで一通りのことが
出来るようになってから、次のステップに進んでいくつもりです(^^)
3D採用にあたり上で述べた問題も出てきますので、それが解決できる策も盛り込んでの実装をするつもりです。
まだあまりいろいろありまして話せないのですが、とにかくいろいろ考えておりますよ(^^
ただしいろいろと時間がかかりそうなので、一旦まずはその前に正式版を出してしまいたいですね。

と、こんなところでしょうか…(^^;ゞ

> そういえばWINXPの後継OSロングホーンでは、OS本体のデスクトップ表現方法としてこういったシステムが標準実装の予定で
> 開発が進んでいたのは周知の事実でしたが結局タイムスケジュール等の影響で、デスクトップの3D化とアクティブディレクトリが
> 削除されたと聞いたときは呆然としました。一体あとに何が残ってるというんでしょうか。ロングホーン=XPSP3なのでしょうか。(笑)

私もあまり期待できなくなりました…;
もし標準で3Dが載っていれば、そのさらに数年後の世界ではゲームの動作に3D機能必須が標準ということに
なっていたでしょうに…。(3Dが動かない環境ならWindow自体もまともに動いていないだろうから…?)

0240 Direct3D
投稿者:春男 2005/06/19(日) 00:16

春男です。

たくみさん、 3D 技術の導入について忌憚ないご意見ありがとうございます。

> ただ問題として、ビデオカードのドライバのバグや不具合、また環境との相性というのがあります。
安定性を考慮して Direct-X に強く依存しない仕様になっているということですか。

> > そんなことばかり言い続けていたら、いつまで経っても新しい技術を利用した物が作れなくなってしまうのも確かです。
その通りです。Direct-X が世に出てから既に10年経ってるんですよね。PCの世界で1つの技術が10年継続するというのは記録的長さです。7 が出てから数えてももう6年…改めて考えるとずいぶん経ちましたね。

> 結局のところ何が言いたいかというと、YU-RISは実は最初からDirect3Dの採用を予定しています(^^;ゞ
> (YU-RISの描画エンジンが最初3Dだったというのもそのためです)
ぉぉ、なるほど…将来的に導入御予定ということで、いつかレイヤをぶん回せる日を長い目で見守らせて頂きます。

ぶっちゃけ、とりあえずノベルゲームで必要になりそうな処理を考えると、ほぼ「絵オブジェクト(レイヤ?)」としてポリゴンを表示して、必要に応じて回したり近づけたりとポリゴンを動かす、その程度のことでしょうね。現在の Direct-X がいくらなんでもその程度のことで障害を起こす環境があるとも思えません。

さすがに、ポリゴンキャラがぐりぐり動き回るような3D格闘やRPG、シミュレーションなどでハードウェアT&Lなど新しめの技術をバリバリ使っているような場合では、ソフト・ハード構成によってチラツキなど期待しない表示結果になることもあるようですが、それらはまた別の土俵でしょうから。

> 3D採用にあたり上で述べた問題も出てきますので、それが解決できる策も盛り込んでの実装をするつもりです。
いろいろ検討されてよいものにしあがることを期待しています。

0241 どもです
投稿者:たくみ 2005/06/21(火) 03:37

どうもです。

> 安定性を考慮して Direct-X に強く依存しない仕様になっているということですか。

現状はそんな感じです。
目指すは安定性と高速性の両立ですね。
そのために依存できる部分に対して、歩み寄れるところから少しずつ歩み寄っていこうと思います。

> ぉぉ、なるほど…将来的に導入御予定ということで、いつかレイヤをぶん回せる日を長い目で見守らせて頂きます。

私自身も楽しみです(*^^*

> ぶっちゃけ、とりあえずノベルゲームで必要になりそうな処理を考えると、ほぼ「絵オブジェクト(レイヤ?)」として
> ポリゴンを表示して、必要に応じて回したり近づけたりとポリゴンを動かす、その程度のことでしょうね。

まずはそうなりますね。
追ってさらにポリゴン自体の制御命令等を用意すれば飛躍的に自由度が増しそうです。

> いろいろ検討されてよいものにしあがることを期待しています。

ありがとうございます(^^)
技術の進歩に追いつくため、まずは私自身の技術の進歩が急務になりそうです(@@;ゞ