| 書籍化されたで！ | 監修したで！(｀ω´) | 絶版なってしもた | 大好評発売中です！ | 少し書いたデ！(｀ω´) | これにもな！(｀ω´) | |
|
|
|
|
 |
 |
| YaneuLabs / YaneuraoGameSDK.NET / 掲示板 / やねうらおにメール / twitter / プロフィール |
# rita 『アリスソフトのSystem3.x/4.xについての言及に期待age。 実際開発に使ったこともあるのでかなり好きな環境なんですが。 3DでSys4.xのような環境作ろうと現在奮闘中なので、どのような評価を されてるのか知りたいところです。』
残念ながらSystem3系の商用利用は別途連絡が必要(おそらく別途ライセンス料が必要？)だったので、私の眼中には無かった。ごめん。
当時、候補として考えられたフリーのノベルエンジンとしては、吉里吉里とNScripterぐらい。あとメジャーなシステムとしてはVisualArtsのAVG32があった。
吉里吉里は、最近であれば月姫に採用されたりしているし、その実装技術の高度さは目をみはるものがある。
RGBA8888の32bpp*1のバックサーフェースを持っていて、ソフトウェアでPhotoShopのレイヤ重ね合わせのようなことをやっていた。レイヤのエフェクトが豊富なのも特徴で、早い段階でoggをサポートし、自前の高圧縮率の画像圧縮フォーマットを実装していたこと、そして、自前のスクリプト言語(ガーベジコレクタ付きの！)を実装していることなどからも作者のW.Dee氏の技術力の高さをうかがい知るには十分だろう。
言うまでもなく現在であれば、この手のスクリプト言語は自作せずに、Luaをそのまま採用したり、C#のリフレクションなりで実装するのが、有力だと思う。(そういう安易な実装を好まないのが、職人気質のプログラマなのだろうけども…。)
当時の吉里吉里の弱点は、当時のマシンにとって遅かった、ということに尽きる。バックサーフェースが32bppだったので、ユーザーが16bppの画面モードで動かしていても、32bppのバックサーフェースから転送するのだから、バックサーフェースをユーザーの動作モードと同じbppで保持する描画エンジンに比べて半分ぐらいのFPS*2しか出なかった。*3
(つづく)
*1：bpp = Bits Per Pixel : 1ピクセルあたりのビット深度
*2：FPS = Frames Per Second : 一秒あたりの描画フレーム数
*3：と思う。当時、実際に調べたわけではない。当時の吉里吉里でも更新された矩形部分のみを描画する機能(俗に言うdirty rect)は実装してあったと思うので、画面にあまり更新がないタイプのゲームでは十分だと思われる。
いいかげん、ちっとは調べてから発言するようにして下さい。
更に言うと、だいぶ前の吉里吉里でもCPUのキャッシュに収まる範囲に分割演算したりといった最適化は行われていたので半分なんて事はありません。
もう一度いいます、
「調べても無いことを偉そうにくっちゃべらないで下さい」
月箱は月姫シリーズなんだから、別に間違っちゃいないと思うけども。
> 更に言うと、だいぶ前の吉里吉里でもCPUのキャッシュに収まる範囲に分割演算したりといった最適化は行われていたので半分なんて事はありません。
条件1)
バックサーフェース 16bpp
セカンダリサーフェース 16bpp
プライマリサーフェース 16bpp
条件2)
バックサーフェース 32bpp
セカンダリサーフェース 32bpp
プライマリサーフェース 16bpp
私は、条件1と条件2を比較している。(条件2が吉里吉里)
バックサーフェースからセカンダリサーフェースにまるごと転送(全画面転送)し、それをプライマリサーフェースへまるごと転送する。
画面サイズが680×480だとすれば、前者の転送に必要なメモリアクセス量は600K×2 = 1.2MBのreadとwrite。(アクセス総量 2.4MB)
後者の転送に必要な、メモリアクセス量は、1.2MB×2のreadと1.2MB + 600KBのwrite。(アクセス総量 4.2MB)
このメモリアクセスは、「CPUのキャッシュ」なんかに到底収まるサイズではないし、単純な転送であるから高速化のしようもない。
条件2のほうは、32bppを16bppに減色する処理が必要だが、この処理時間を0で済むと仮定して単純なメモリ転送だとしても、2.4MB/4.2MB = 57%。
条件1は条件2の57%の時間で済む。何かおかしい？
>単純な転送であるから高速化のしようもない。
>何かおかしい？
そりゃおかしいだろｗ
単純なメモリ転送量だけが、FPSを決定付けるのかよｗ
実測もしてねーのに「半分ぐらいのFPSしか出なかった」って言い切るなってこった。
と思ったら注釈で言い訳追加してるｗ
> 単純なメモリ転送量だけが、FPSを決定付けるのかよｗ
DMAを使うわけでもHALに頼れるわけでもない上に、CPUキャッシュ(L1,L2)に収まる量ではないから、処理時間は単純にメモリ転送量に比例すると考えるべき。
「ビデオメモリへのアクセスにwaitがかかる」というなら話は別だけど、そこにしてもアクセス量に比例するwaitだと仮定できるから、back surfaceを32bppで持つと16bppで持つ場合の半分ぐらいの速度しか出ない。
他に何が関係すると思ってるわけ？
> 実測もしてねーのに「半分ぐらいのFPSしか出なかった」って言い切るなってこった。
「当時、実際に調べたわけではない」と私が書いたのは、当時の吉里吉里が本当にback surfaceを32bppで持っているのか自分のこの目でソースを調べたわけではない、というだけで、back surfaceを32bppで持っているなら、実測するまでもなく原理上16bppの半分程度のFPSしか出ない。
> と思ったら注釈で言い訳追加してるｗ
今日のエントリは、一度書き込みをしただけ。編集は一切していないよ。
数年前までならリポジトリからソースコード引っ張ってこれますんで。
pmokyではなくpmonky
pmokyはもう少し利口だろな
> 吉里吉里は、画面単位でのビデオメモリ転送などというyaneSDKでやってるような古臭い方法はとっていませんが
画面単位での転送って、yaneSDKでもそんなことはしてないよ。
上の私の返答では、どれくらいFPSが出るのかを推定するために毎フレーム画面全体が更新されるのをモデルケースとして想定しただけ。
この仮定がノベルゲームにそぐわないと言うならわからなくはないけども、それは本エントリの3番目の注釈として最初から書いている。
> というか、その「当時」を大体でいいんで示して欲しいんですが。
http://d.hatena.ne.jp/yaneurao/20060909
を見てもらえればわかるように、この一連のエントリでは「1996年〜1999年」を「当時」と書いている。
上でコメントをしているouou氏はただの煽りだろうけど、pmonky氏はまともな技術者っぽいので、pmonky氏にはくれぐれも冷静で客観的で有意義な議論をしていただきたいですね。
ただ、確かにこの”エロゲ製作は〜”シリーズのエントリの流れとして、90年代後半の吉里吉里について語るのは間違いではありませんが、昔の事を引っ張り出すなら、現在の吉里吉里に付いても適切ににその能力を挙げて述べ、結論として昔の吉里吉里は遅かった、とまとめるべきでしょう。
「俺がみた時は遅いエンジンだった、だから今もたいしたエンジンじゃない」という意思が少しばかり含まれているように感じてしまいます。
勘ぐりすぎかと
本エントリ中でも書きましたが、吉里吉里は高機能で素晴らしいエンジンです。W.Dee氏も私なんかよりよほど実装経験と実装能力のある人ですからね。だからこそ真っ先に例として挙げました。
しかし、当時のマシンはロースペックであり、back surfaceを32bppで保持するというのは毎フレーム全画面更新を行なうタイプのゲームでは荷が重すぎた、というだけのことです。
吉里吉里はdirty rectの管理をしていましたから、ノベルゲームで(描画の)動きの少ないものであれば、当時でも十分なものだったと思いますよ。
>ノベルゲームで(描画の)動きの少ないものであれば、
>当時でも十分なものだったと思いますよ
だったらそれを最初から併記すべきではないでしょうか？
実際にエロゲのエンジンとして動作している状態に近いのは、
全画面更新ではなくdirtyRectを管理した部分更新でしょう？
やはり”悪い部分だけを大げさに吹聴”する意図があったように感じます。
全画面更新ではなくdirtyRectを管理した部分更新でしょう？
私は違うと思いますね。
ユーザーはシナリオ(テキスト)を読んでいるときは遅さなんてほとんど感じないのです。もともとその部分は動きがほとんど無いですから、2,3FPSぐらいしか出ていなかろうが、まったく気づかない。(マウスカーソルをソフトウェアで描画しているなら、マウスカーソルがもたつけばさすがに気づくでしょうけども。)
だからユーザーが遅さを実感するのは、雨が降ってくるエフェクトだったり、画面遷移の時のトランジションだったり、そういうものです。要するに全画面更新の遅さが致命的になりかねないのです。
あとまあ、普通ADVエンジンのトランジションの処理は時間をあわせるほうを優先で遅いときはコマ落ちするように作るでしょうから（違う人もいたらゴメン）、「遅さ」よりは「粗さ」の問題になるような気もします。
> 普通ADVエンジンのトランジションの処理は時間をあわせるほうを優先で遅いときはコマ落ちするように作るでしょうから（違う人もいたらゴメン）、「遅さ」よりは「粗さ」の問題になるような気もします。
確かに、フェードイン/フェードアウトや簡単なトランジション(大半がこれに属する)はそうですね。セルオートマトンのようなセルが状態を持つようなトランジションはその限りではないですが。(私は自分が関わっていたエロゲーでは、セルオートマトンを用いたエフェクトも使っていました。)
「月姫はNスクリプターです。吉里吉里を使っているのは月箱以降です。」
11：レッテル貼りをする
「やはり”悪い部分だけを大げさに吹聴”する意図があったように感じます。」
４：主観で決め付ける
「ただ、確かにこの”エロゲ製作は〜”シリーズのエントリの流れとして、90年代後半の吉里吉里について語るのは間違いではありませんが、昔の事を引っ張り出すなら、現在の吉里吉里に付いても適切ににその能力を挙げて述べ、結論として昔の吉里吉里は遅かった、とまとめるべきでしょう。」
「だったらそれを最初から併記すべきではないでしょうか？」
さて、次は何番だろう、、、wktk
「昔の事を引っ張り出すなら、現在の吉里吉里に付いても適切ににその能力を挙げて述べ、結論として昔の吉里吉里は遅かった、とまとめるべきでしょう」とあるけど、
「吉里吉里は、最近であれば月姫に採用されたりしているし、その実装技術の高度さは目をみはるものがある。」って書いてある部分はシカトですか、そうですか。
全てがあなたの思い通りに記述されていないと気がすまないのでしたら、他人の文章や意見は目にされないほうがよろしいですよｗｗｗ
実際のゲーム上で典型的な「『多数のレイヤ合成をしながらの』全画面更新」においてとても強い、というのが個人的印象で、その状況では 16bpp への変換＆転送はたいした影響ではなく、結局 fps 半分といったことにはなりません。
自分がつくってたやつが、トランジション時は合成結果同士を処理させて、まあ、こんなもんかと思ってたら、リアルタイムで表裏、それぞれで動きつつ合成してるレイヤ同士をトランジションしてる吉里吉里2のがさくさくうごいてて、うちのめされましたよ orz
LittleWitchのFFDシステムも凄く作りこまれてますね
正直、アレは感動しました
32bitカラーで166MHzが最低動作環境だそうです
オフィシャルファンクラブ会報5号に諸々の最適化手法が
（一般人向けですが）載ってます
秒間３文字…
速度を早めに調整してる場合は明らかにFPS足りないでしょ…
1フレームに1文字とは限らない。当然ながらフレームスキップを導入する。おわかり？
現在の利点は抽象的な一言ですましている。
これでも適切に述べられてますか？
読み違えてますよ。
ここは、
「（文字を描画するときに）2,3FPSぐらいしか出ていなかろうが、まったく気づかない。」ではなく、
「（表示された文字を読むときに）2,3FPSぐらいしか出ていなかろうが、まったく気づかない。」
だと思います。
貴方以外の大多数の人は描画されてる間に追ってテキストを読むと思いますよ。
yaneurao氏の今回の一連のエントリは「当時」はこういう状況でした、ということを書くのが主旨だよなぁ？どうして現在の利点なんか書かなきゃなんねーんだ？どうして現在の利点を書いてないことにそんなに粘着するんだ？お前、まともな技術者かと思ったけど正直気持ち悪いよ。
低技術のエロゲ如きで大論争するインターネットがあると聞いてやってきました。
お前ら哀れですね。
>貴方以外の大多数の人は描画されてる間に追ってテキストを読むと思いますよ。』
えーとですね。
「文字描画するときに2,3FPSしか出ない」という言葉はどこにも出てないよ？
って事なんですよ。
「文字を描画するときに2,3FPSぐらいしか出ていなかろうが、まったく気づかない。」
というのは先の書き込みを見て、SB_sunnydayさんがこう読み違えたのではないかな？という想像です。
だから誰も
「文字を描画するときに2,3FPSぐらいしか出ていなかろうが、まったく気づかない。」
なんて言ってないですよ。
この文脈からは、文字をユーザが読んでる時(≒文字が描画されている時間)の(文字の描画の)FPSが2〜3、としか受け取り得ないと思われますが…。
私が書いた「ユーザーはシナリオ(テキスト)を読んでいるとき」ってのは、シナリオが描画されるときではなく、表示されたあとにプロンプト表示してクリック入力を催促してる状態ね。
テキストを1文字ずつ描画させたいなら2,3FPSじゃあさすがにまずいけど、frame skipさせるなり、セリフ部分だけプライマリサーフェースを更新するなりすればいいので、そこは全画面更新を前提としなくて良い。
そもそもpmonky氏の最初の主張は「実際にエロゲのエンジンとして動作している状態に近いのは、全画面更新ではなくdirtyRectを管理した部分更新」だと言うから、私がそれに対して「ユーザーにとって体感的に問題となるのはそこではない」という趣旨の反論をしているのに、なんでまったく関係ないところを突っ込んでくるのかまるで意味がわかんない。
少なくとも、私は文字表示速度を設定できるゲームでは最大速度にする人間だけども…
別に新たにテキスト周り以外でうだうだ言おう、というわけではないです。失礼致しました。
便乗で申し訳ないんですが、個人的に好きなシステムなもんで…
私はrUGP(+AGES)は技術的に面白いと思います。
月箱はいくつも出された月姫シリーズの最終作なわけで。しかも収録された旧作はNScripterのままで、追加のいわばおまけのみが吉里吉里なわけで。
ぎりぎり間違っちゃいないかもしれませんが決して正しくはないと思うのですが。