よねぞん画像掲示板

スレッドもかなり伸びましたので、検証していただいたことや調べたこと等を一旦まとめてみます。

まず前置きとして、何故IntelのCPU／チップセット内蔵GPUでポリゴンが伸びるという問題が起きるのか。たむたむす〜るで四角変形を用いてポリゴンを縮小させた時、ある限界を過ぎると座標の値がNaN(“not a number”の略。数字じゃないという意味ですね)という特殊な値になります(こちらの掲示板の記事番号8も参考にしてください)。このNaNという値はIEEEの規格で無限大などとともに定められているのですが、GPUでこれらの値を正しく扱うことは演算速度の低下、もしくは演算回路の規模拡大を招くので、「浮動小数点数で表せる最大値とか最小値で代用しちゃえ」という考え方が以前は優勢だったようです。IntelではDirectX9世代になってもこのIEEE規格を厳密に扱わないモードをGPUの基本動作モードに据えた為、シェーダーの演算結果が(NaN，NaN，NaN)となるべきところも何らかの描画しうる値が設定されたりし、その結果下に引き延ばされたポリゴンが表示されるというす〜るの不具合が起きます。…もちろん私の推測を含んでますからそのつもりで。

次に不具合を如何に解決するかですが、

1. 頂点処理(バーテックスシェーダーによる計算)をIEEEの規格に則った動作をするモード(IEEEモード)で行わせる
2. 頂点処理はDirectXで用意されているソフトウェア実装によるシェーダーで行う
3. GPUの演算ユニットを一切使わずに、バーテックスシェーダーもピクセルシェーダーもソフトウェア実装によるものを使う(シェーダーは全てCPUで処理する)

といったことが考えられると思います。なお、順序は処理速度が上がると思われる順です。

あさはかさんがブログで紹介されている“3D-Analyze”というツールを使う方法は2を実現するものです。と言いますか、チェックを入れている項目が「force SW TnL」だけであるのを見て、2で不具合回避ができそうだと判断した次第です。尚、TnLは“Transform and Lighting”の略なのですが、この“Lighting”がピクセルシェーダーのことを指しているのだとすると2ではなく3の動作ということになります。この辺り実際はどちらか判らないのですが、Direct3D9初期化時の設定で“SoftwareVertexProcessing”というのが選べるので、それのことかなと思い2としました。

3D-Analyzeによる不具合回避は、何よりも他のソフトの動作に影響を及ぼさないという点でとても優れた方法だと思います。これで済んでいるのなら他の方法は考えなくても良いのではと思わないでもないです。ただ3D-Analyzeはかなり前に開発を終えたので(多分)、Windowsの描画の仕組みが変わった時に対応できない可能性があります(3D-Analyzeは本来の描画デバイスに成り代わるのですが、これによってゲームから描画システムに送られるメッセージを横取りして細工した上で本来の描画デバイスに再送出しているものと思われます)。実際、Windows8.1／64bitで上手くいかないという報告があったから、今回の調べ物を始めて、皆様方にご協力を仰ぐことになった訳です。(症例報告が少ないので「Win8.1／64bitでは3D-Analyzeが動かない」と断言するには至らないと思っています。何より自分自身で確認できないのが…)


2を実行するのには、Intel自身が用意しているGPUのコントロールパネルで設定するという方法もあります(www.intel.com/jp/support/graphics/sb/cs-030506.htm参照。記事番号76や78でも触れてます)。但しこれは、基本的には“Sandy Bridge”世代(または第2世代Coreプロセッサ、GPUで言うとHD Graphics 3000／2000)以前に限られるようです(確認にご協力いただいた皆様、どうもありがとうございました)。す〜る以外のプログラムの実行に影響が出る点にも注意が必要です。

2014年末現在IntelがSandy Bridge向けに提供しているドライバのバージョンは9.17.10.3517(ドライバパッケージは152822)になります。他方“Ivy Bridge”(第3世代、HD Graphics 4000／2500) 向けのバージョンは10.18.10.3958(ドライバパッケージは153330)、“Haswell”(第4世代、Iris Graphics 5100 及び HD Graphics 5000／4600／4400／4200)向けはバージョン10.18.10.3960(ドライバパッケージは15367)となります。(尚、Pentium／CeleronのGPUは一括りに“HD Graphics”という名前が付いていますが、実際には同世代のCoreプロセッサに準じたGPUが内蔵されており、ドライバも同世代のCoreプロセッサと同じものです。)ver.9以前の系列のドライバとver.10系列のドライバでは付属しているコントロールパネルのプログラムが異なっており(ファイル名も“GfxUI.exe”、“GfxUIEx.exe”と違います)、外観も設定できる項目も違います。そしてver.9以前では「3D」→「頂点処理」という項目で“ソフトウェア処理”を選択することができたのですが(先のIntelサポートページの上から2段目のコントロールパネル)、ドライバver.10付属のコントロールパネルではその設定項目が無くなってしまったようです(サポートページの最上段のコントロールパネル)。

GfxUI.exeによる設定は多分レジストリのどこかに書き込まれると思われるので、場所を特定できれば、コントロールパネルに設定項目が無くてもレジストリに値を書き込むことが可能かもしれません。しかしドライバ自体のバージョンが違う為、設定した値をver.10のドライバが参照しない可能性はかなり高いと思います。DirectXとの橋渡しをしていると思われるユーザーモードドライバ(ドライバを構成するファイル群のうちの1つです)を眺めると「頂点処理をソフトウェアで行うかどうかのフラグ」みたいな説明がver.10のドライバにもあるので、何らかの形で設定を書き込む処がドライバのバージョンに関わらずあるのだろうとは思うのですが、それがレジストリであるとは限りません。ビデオBIOS(UEFIかどうかってのは置いといて)による設定だったりすると、BIOSに設定項目があったりしない限りこちらからはまず手出しできないと思います。

かわいそうなお父さんさんのノートPCです〜るの不具合が発生しなかったのは、BIOSで頂点処理をソフトウェアで行うように設定されていたのではないかと想像しています(ユーザーが設定変更できるとは限らない)。


次に3を実行する手段ですが、これはレジストリの書き換えで達成できるものと思われます(未確認)。が、もしかしたらDirectXを構成するDLL群が開発用(デバッグ用)である必要があるかもしれません。書き換える(もしくは書き加える)のは(記事番号84にも書きましたが)“HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Direct3D\Drivers”というキーの「SoftwareOnly」という値になります。ここのデータを1(テキストかバイナリかは不明。多分どちらでも可)にすることで、DirectXのシェーダーが全てCPUで処理されるようになるはずです。全てと言ってもDirectX10以降を使うプログラムには影響しないと思われますが。

因みに、今この文を書いているPCには上記のレジストリ・キーが有るのですが(“SoftwareOnly”の値は無い)、報告を頂いた透過好きさんのPCには同じキーが無いそうです。どこからその違いが生じるかなどは判っておりません(という理解レベルで話をしております)。

厄介なのは、この「Drivers」というキー(と言いますか、「Direct3D」以下のキー)に書き込む権限があるのが“TrustedInstaller”だけだということです(多分Windows Vista以降)。“Administrators”のメンバーでも、つまり通常の管理者権限では値を書き込むことはできません。なので「レジストリエディターでキーと値を作ってください」と案内する訳にもいきません(ググればやり方出てくるとは思うのですが)。

ではどうにもならないかというと、結構大ごとに思えたので自分でも試してないんですが、DirectXのSDK(Software Development Kit)をインストールしてその中の“dxcpl.exe”というプログラムを使うことで上記の「SoftwareOnly」という値を設定できるそうです(記事番号108も参考に)。ただ、SDKのアーカイブの中から取りだしたdxcpl.exeを手もとで動かしてみたのですが、それだけではレジストリを書き換えることはできませんでした。SDKをきちんとインストールしてない為(DLしたアーカイブから抽出しただけのプログラムにTrustedInstallerの権限が与えられるというのは無さそうな気がする)かDirectXのランタイムが想定されてる開発用のものでないかのどちらかが理由だとは思いますが。(何故インストールしなかったのか言い訳しておくと、うちではレジストリに書き込めるかの確認はできますが、値を書き込んだ効果の程はよくわからないので、手間に見合わないと思ったからです…)

DirectXに限りませんが、SDKのインストールはVisual Studioなどの開発環境の存在を前提にしていると思われます(あ、でもVisual Studio無しでもWindows SDKは入った気がする。私「開発環境はテキストエディタ」な人で、Visual Studioは使ってないのです)。まあ、インストールが無事終了するにしてもしないにしても、dxcplだけを使いたいが為にインストールするにはDirectX SDKは規模が大きいと思います。

実は最新のDirectX SDKは単独で存在しておらず、Windows SDKに含まれる形になっています(それだけDirectXとWindowsは不可分になったといいうことですね)。なので何らかの理由でWindows(8用)SDKをインストールされてる方は、手もとに正しくインストールされたdxcpl.exeがあるものと思われます。が、残念なことに、(記事番号107で透過好きさんが報告してくださったように)新しいdxcpl.exeにはDirect3D9に関する設定を行うタブが存在しません。なので上記のレジストリ・エントリーを書き換える役には立ちません。

尚、最後の単独で存在するDirectX SDKは2010年6月バージョン(DirectX11までカバー)のものですが、これが想定しているインストール環境では3D-Analyzeが使えます。なのです〜るの不具合回避だけが目的なら3D-Analyzeを用いる方が現実的と思われます。


最後に1が何とかならないかですが、これは現在模索中かつ見通し立たずという感じです。なんも成果が上がってないということですね。一応これが実現すると、内蔵GPUであっても人数を出さなければ(それなりに)快適にす〜るが動作すると思われますので、何とか実現したいところではあります。今後ますますIntel内蔵GPUだけのPCが増えるでしょうし。

冒頭でIntelのGPUがNaN等の厳密には数でない値を正しく扱ってないと書きましたが、GPUのリファレンスマニュアルによると、この様な動作モードをAlternativeモード(略してALTモード)と呼ぶそうです。対してIEEEの規格に則ってNaN等も正しく扱うモードはIEEEモードと呼んでるそうです。Ivy Bridgeまでのマニュアルでは「Direct3D9まではALTモード、Direct3D10以降はIEEEモード」みたいに書いてあったと思うのですが、Haswell以降のマニュアルでは「モデル3.0以降のシェーダーはIEEEモード、それより古いシェーダーはALTモード」となってます。記述が変わっただけなのかドライバの動作が実際に変わったのかは判りませんが、一応新しい方のドキュメント(シェーダーのバージョンによって、の方ですね)に添って考えることにしました。

す〜るの実行ファイルをバイナリエディタで眺めてみるとHLSL(DirectXで使われているシェーダー記述言語)をコンパイルしたバイトコードと思われる箇所があります。また“vs_1_1”や“ps_3_0”という文字列が見られるので、ver.1.1からver.3.0までのシェーダープログラムが使われていると推測できます。実は、以前「“ToolGraphicConfig.dat”の[ShaderVer]という項目の値が“AUTO”になってたら“V30P30”に書き換えて試してみて欲しい」とお願いしたのは、これによって使用するシェーダーモデルのバージョンの下限が指定されないかと期待した為です。リファレンスマニュアルによればver.3.0のシェーダープログラムしか走らせなければIEEEの規格通りに頂点データが処理されるはずなので。結果は、透過好きさんから報告をいただきましたが、全く期待外れでした。件の設定項目は使用できるシェーダーモデルの上限を指定するものであって、下限を指定するものではなかったようです。ver.1.1のシェーダープログラムが使われるところは、使えるモデルの上限が3.0であっても1.1のシェーダーが使われるみたいです。

先に述べたdxcpl.exeの新しい版(Direct3D10／11用の設定タブしか無い方)に“Feature level limit”という設定項目があるので少々調べてみたのですが(設定項目の内容は透過好きさんに教えていただきました)、こちらもプログラムが使用するAPIバージョンの上限を指定するものであって、下限を指定するものではありませんでした。

この様な感じなので、レジストリや設定ファイルとかによる設定では、1は実現できないのではないかと思っています。ではどうするかと言いますと、
・す〜る(及びカレカノ、FINAL!)の実行ファイル中のver1.1や2.0で記述されたシェーダープログラムを3.0で記述したものに置き換える。
などという手があるかなと漠然と考えております。実際にできるのかはわかりませんが、幸いHLSLの逆アセンブルはできるようなので、全く可能性が無いという訳でも無いように思えます。バイトコードの長さが元より長くなるととてもとても面倒そうですが。

もう一つ、Intel HD Graphicsのドライバは大きく分けてカーネルモードドライバとユーザーモードドライバとに分かれているのですが、
・ユーザーモードドライバからカーネルモードドライバへの通信を横取りして、全てのシェーダープログラムの実行がIEEEモードで行われるように指示を細工する。
という方法もあるのかなと考えています。他のプログラムの動作へ影響が出ますが、ALTモードがIEEEモードになるぶんには特に問題は出ないでしょう。ただ、これはIntel内蔵GPUの動作をきちんと理解したり、ドライバ間の通信をフックするようなプログラムを書けるようにならないといけないので、自分がやるとなるとかなりハードルが高いです。

自力だとまだ前者の方が可能性があるかなと思います(が、それでも途は遠そうです)。どなたか分かる方がやってくださるということなら、後者の方が現実的でしょうか。もちろんドライバに直接パッチを当てるというのもアリだと思います。

1に関してはこの様に全く目途が立っておりません。何か良いアイデアが浮かんだ方は是非ご披露いただければと思います。


以上、大変長々と失礼いたしました。最後まで読み通した方がいらっしゃいましたら、読んでくださったことに御礼申し上げます。大変お疲れ様でした。

新年の挨拶と言うには少々遅くなりましたが、本年もよろしくお願いいたします。


あ、IntelのGPUに限ったことのように書きましたが、SiS系やS3系のGPUがどうなのかは確かめておりません。もう使ってる人もいらっしゃらないかと思うので割愛いたします。まあ、モデル3.0のシェーダーが動くのは無かった気がするし、そもそもChrome(ブラウザじゃないよ)持ってないですし。Matroxや3DlabsのチップはDirect3D9に対応してたっけかなあ…

Re: Intel内蔵GPU(長文) - 透過好き 2015/01/08(Thu) 21:06 No.113
あけおめことよろでーす
全部よみましたｗ 逆アセンブルですか。
C#ソースの改造でギリギリ言ってる私には遠い世界で ＞＜；

何かテスト項目あったら言ってくださーい。
不具合確認方法 - のぞく人 2015/01/08(Thu) 21:56 No.114
書き忘れ。
もし、「これからたむたむす〜るを使ってみたいんだけれど、自分のPCで不具合が出るか先に確かめたいな」という方がいらっしゃいましたら、体験版(URLはよねぞんのどこかに書いてある？)をインストールして、よねぞん フリーアップローダーのNo.910、“クッキー.alp”(Dさん作)を読み込んでみてください(と、伝えてあげてください)。サムネイルやこの掲示板の記事番号82のように表示されれば問題なしです。(表示確認用として紹介することをご承諾いただき、Dさん、どうもありがとうございました。)
Re: Intel内蔵GPU(長文) - のぞく人 2015/01/08(Thu) 22:04 No.115
透過好きさん、今年もよろしくお願いします。
全部読みましたか。お疲れ様でした。
逆アセンブルと言ってもHLSLの所だけなんで、それ程多くないです。流石に全部やる根性は…
ああ、でも、エロアイテムの藻の所だけは、少しはやらないといけないかもしれないですね。

昨年は本っ当に助かりました。また何かテスト項目が出た時はよろしくお願いいたします。
Re: Intel内蔵GPU(長文) - よねすけ 2015/01/08(Thu) 22:52 No.116
皆さん、検証お疲れさまです。
透過好きさん、細かな検証までご協力いただき、ありがとうございました。

先日のぞく人さんにお伝えしましたように、たむたむす〜る逆引きTIPS(FAQ)に追記しておきました。ありがとうございます。

体験版を落とせる場所は複数ありますが、入れておいたほうが良いですかね？割とすぐに見つかるので要らないかなと思っていたのですが。（イリュ□ジョンさんに消されたりすると嫌かなと思っていたのでｗ
Re: Intel内蔵GPU(長文) - のぞく人 2015/01/09(Fri) 03:00 No.117
体験版が置いてある場所は、以前皆で知ってる場所を持ち寄った気がするのでコメント欄か掲示板のどこかにあるんじゃないかと思ったんですが、どこだったろ？
私も参加した気がするのでtwitterじゃないと思ったんですけど、よねすけさんにメールでお知らせしただけだったのかなあ…

ミラーとは持ちつ持たれつのはずだから強くは言わないだろうと思いますが、確かに「まだ落とせます」と明言しておくだけで良いかもしれませんね。(ﾒﾉｳｴﾉｺﾌﾞﾅﾝﾀﾞﾛｳｶﾗﾈ･･･)
Re: Intel内蔵GPU(長文) - よねすけ 2015/01/09(Fri) 20:39 No.118
もう既に販売していないゲームの上、あちらにとっては目の上のたんこぶですしねえ。目立たない方がいいかなとは思います。
実験用す〜るUPしました - のぞく人 2015/01/16(Fri) 00:06 No.119
Intel内蔵GPUでの不具合対策を施したつもりのたむたむす〜る実行ファイルをよねぞんアップローダーへUPしました。ファイルは体験版のver.4.01になります。これでOKのようなら製品版用やゲーム本体用のパッチを作る予定です。

なお申し訳ないですが、これは上で挙げた解決策1を目指したものではなく、2を実現する(はずの)ものです(Direct3Dの初期化をしてる場所がわかったので、ちょっといじってみました)。3D-Analyzeを使用した場合と多分同程度の速度になってるはずです。なので体験版用のパッチが出来てもWindows8の人以外には恩恵はないと思われます。

ともかく、先ずはちゃんと効果が出てるかどうかですので、実験にお付き合いいただける方がいらっしゃいましたら、こちらに結果を書き込んでいただければと思います。尚、ダウンロードのパスワードはティータイムを半角小文字にしたものです。よろしくお願いいたします。
Re: 実験用す〜るUPしました - のぞく人 2015/01/16(Fri) 00:12 No.120
上の記事番号119で

>体験版用のパッチが出来てもWindows8の人以外には恩恵はないと思われます。

とあるのは「製品版用のパッチ」の誤りです。
暗証キー忘れたらしい…
Re: Intel内蔵GPU(長文) - 透過好き 2015/01/17(Sat) 00:27 No.121
製品版だとエラー落ちしてたので体験版入れましたー

結果：２２たむ→１８たむ
　　　荒ぶる前髪が落ち着かれましたー

Re: Intel内蔵GPU(長文) - のぞく人 2015/01/17(Sat) 01:17 No.122
透過好きさん、いつもありがとうございます。どうやらポリゴン伸びなくなったようですね。良かった。上手くいかなかった時はこれまでの想定が根底から覆るということにもなったので。本当に、毎度毎度検証ありがとうございます。

3D-Analyzeを使った時より結構速いというのはちょっと意外でした。それにしてもIntelのCPUはやっぱり速いな…

製品版は体験版にあるファイルは全部有るはずだから動くだろうと思ってたのですが、ダメのようですね。そういえばインストールフォルダをチェックしに行ってたかも。だとすると、一般ユーザーで動くようにした方も、動かそうとするアカウントのレジストリにインストール先を書き込まないと動かない…
Re: Intel内蔵GPU(長文) - 透過好き 2015/01/17(Sat) 14:13 No.123
いえいえこちらこそー

>3D-Analyzeを使った時より結構速い
そですねー
たぶんバックグラウンドで動いていたものとか
3D-Analyze自体の重さとか関連してたのかもしれません

ムービーとかがんがんBGMにしながら動かしてたりもしてたので(^^;
す〜る及び本体の書き換え場所 - のぞく人 2015/01/20(Tue) 23:19 No.131
パッチは公開までもうちょい掛かると思うので、取り敢えず情報だけ。

●たむたむす〜る.exe (体験版、ver.4.01)
0003E5B4: 44 24
0003E5DF: 24 84

●たむたむす〜る.exe (カレカノ製品版、ver.4.10)
0003E704: 44 24
0003E72F: 24 84

●カレマチカノジョ.exe (ver.1.08)
0003F205: 44 24
0003F230: 24 84

●たむたむす〜る.exe (らぶデスFINAL!製品版、ver.5.06)
00036C89: 46 26
00036CB4: 26 86

●らぶデスＦＩＮＡＬ！.exe (ver.1.06)
000384B1: 46 26
000384DC: 26 86

以上になります。バイナリエディタで書き換えるからいいやという方はご自分試してみて下さい。書き換え場所直前の1バイトは何処も「6A」です。

なお、実際に必要なのは「4x → 2x」の方だけで、「2x → 8x」の方は同じルーチンが続くのが何となく嫌だったので書き換えてみただけです。(実行時はここは通らないはず。)

少しだけ解説しておきますと、例えば「6A 44」をニーモニック(機械語)で書きますと、
push 44h
となり、ここではDirect3D9の「CreateDevice」という関数に16進数の44をパラメータとして渡すことを意味します。このパラメータの下から2桁目が頂点処理の動作モードを表しており、
2 … SOFTWARE_VERTEXPROCESSING
4 … HARDWARE_VERTEXPROCESSING
8 … MIXED_VERTEXPROCESSING
という対応になっています。今回はソフトウェアで処理するようにしたいので、初期化パラメータを4xから2xに変更しているという訳です。
Re: Intel内蔵GPU(長文) - 透過好き 2015/01/21(Wed) 15:50 No.132
体験版以外の４種のポリゴン伸びの改善確認しましたー
やっぱちょっとカクつくけど、まだ良い方？（18たむ程度）

>ニーモニック
あはははははわからないということがわかりましたー orz
びみょーにpushpopとかいう暗号が記憶の片隅から・・・
Re: Intel内蔵GPU(長文) - のぞく人 2015/01/21(Wed) 22:23 No.133
透過好きさん、今度も検証ありがとうございます。これで安心して作業を進められます。実はそろそろ自前のテスト環境を用意できそうなのですが、検証結果は多ければ多い程いいので、引き続き御協力いただけたらと思います。まあ、まともに考えると「動きます」と言いきるのに1人2人の結果では全然足りないんですけどね。

動きが少々カクつくのは、ソフトウェア処理である以上仕方がないのでしょうね。Core i7の上位のやつとかだと結構いけるかもしれませんが。何とか解決策1が実現できるように頑張ってみます。

説明はかなり端折ってると言いますか、あれで理解してくれという方が多分無理なので(笑)。スタックの説明も省いてますし。「初期化パラメータに手を加えただけ」ということだけ理解していただければと。

今回透過好きさんはご自身で値を書き換えてくださいましたが、本音を言うと他の方々にもそうしていただけたらなあと思っています。自己展開型のパッチを作るつもりでいますが、実行フィルは作成者が何を仕込んでいるか外から判らないですから、適用する側に不安が残ると思いますので(よねぞんアップローダーにUPする予定です。他所にUPされてもそれは私ではありません)。コマンドラインに慣れてる方は適用後に「FC /B」で変更箇所を確認していただきたいところです。

そんなことも考えてますので、今回率先して書き換えでできるということを見せてくださったことにも大変感謝しております。ありがとうございます！
Re: Intel内蔵GPU(長文) - 透過好き 2015/01/22(Thu) 09:18 No.136
>1人2人の結果では
環境がほとんどばらばらだし統計学方面に突っ走りますねｗ

>「初期化パラメータに手を加えただけ」
あーなるほど
C#で言えばCSファイルの最初あたりに積まれてる初期データみたいなものですね
this.Name = "****";とかの中身を書き換えてるっぽい

>何とか解決策1が実現できるよう
超期待〜
Re: Intel内蔵GPU(長文) - yomeko2905 2015/01/23(Fri) 21:34 No.137
THINK PAD X240 intelGPUで検証した報告です。
たむたむす〜る.exe (らぶデスFINAL!製品版、ver.5.06)のバイナリ書き換えでOKでした。

すーるだけAMD搭載の旧マシンを使っていたんですが、助かりました。

Re: Intel内蔵GPU(長文) - あるお 2015/01/26(Mon) 01:53 No.138
バイナリ書き換えで直りました！
長年の悩みの種がこれで…ありがとうおございます！
Re: Intel内蔵GPU(長文) - のぞく人 2015/01/26(Mon) 02:34 No.139
>yomeko2905さん
遅くなりましたが、検証報告ありがとうございます。根気の結晶のようなSSはAMDマシンで作られていたのですね。少しでもお役に立てたようなら幸いです。AMDユーザー(でもGeForceだ)の自分としてはIntelに人が流れてゆくのはちょと寂しくもありますが(笑)。

>あるおさん
こちらこそ、報告いただきありがとうございます。成功例が増えていくのは心強いです。まあ、不具合解消法自体は既出のものがあったりしますが、今回のバイナリファイル書換の方が幾分速度が出るようです。
Re: Intel内蔵GPU(長文) - ゴート 2015/08/22(Sat) 17:38 No.166
今更ですが、「もしかして直るのか、ポリゴン落ち」と思い
記事、一字一句もれなく読ませていただきました。

結果、直りました！！！！！！！！！！！！！！！！

ビックリです。

この記事に、半年以上気づかなかったことが
悔やまれます、、、、

今まで、「ポリゴン落ちのデータは、いずれ時間をかけて
自分で製作するさ」と、たかをくくっていましたが
直るものなら、ホントこっちのがいいです！

助かりました、ありがとうございます！！

あ、せっかくなんで自分が使っているパソコンですが、
acerのcore5使用のノートです。

これより古いパソコンは、問題なかったんですが、
やっぱりBIOSの関係でしょうか・・・

バイナリエディタに関しましては、さすがにシロウトには
敷居が高いので、パッチ公開までお待ちいております。

贅沢なお願いですが、もし画像でご説明いただければ、
自分でやってみます。

自分は、やはりDさん作成のクルル様で検証いたしました。
SSは、パッチ後の画像です。

出来れば、ポリゴン落ちの状態も取っておきたかったんですが、
気が回らずに・・・というか、思い出したくも無いのが
本音です。

でも、本当にありがとうございました。

PS,ワタシのほうも、やはり読み込み　早くなった感じいたします。

パッチ暫定UP - のぞく人 2015/08/25(Tue) 01:03 No.167
>ゴートさん
暫定的にですが、kie.nu/2H9Bにカレマチカノジョ用とらぶデスFINAL!用の差分を上げておきました(差分本体だけ)。PWは「ティータイムを英小文字半角」です。(体験版で確認されたということでいいんですよね？)

使い方です。まずゲームの修正パッチの類を全て当てます。次にカレマチカノジョだったら「カレカノ差分.EXE」を、らぶデスFINAL!だったら「ＦＩＮＡＬ！差分.EXE」を、それぞれアーカイブからインストールフォルダにコピーして実行して下さい。実行ファイル(たむたむす〜る.exeとかカレマチカノジョ.exeとからぶデスＦＩＮＡＬ！.exe)が書きかわります。書き換えが終わった後は差分ファイルを消去してしまって構いません。

差分ファイルはオリジナルを残すようにしてあったとは思うのですが、書き換え作業中の不意の再起動などもあり得ますので予め実行ファイルを別フォルダ(出来れば物理的に別ドライブ)にコピーするなどして備えて下さい。あと実行ファイルが最新版になってないと差分適用に失敗するようにしたような気がします。(時間が経ったので忘れた。)

自分の手許で動かして様子を見ていたつもりだったのですが、いつの間にか何か別の目的でオリジナルに戻してしまっておりました…。まあ、何かありましたらこちらに書き込んで下さい(掲示板使わせていただきます、よねすけさん)。
Re: Intel内蔵GPU(長文) - ゴート 2015/08/25(Tue) 23:36 No.168
パッチありがとうございまーす♪
さっそくいただきました！
無事に機能しております。
正直あきらめていたので、ホント感謝しております。

最近メインパソコンになりつつあるレ○ボノートでも
ちゃんと直りました。

返信いただけるまでは「こりゃ、バイナリエディタ覚えにゃ、ならん」と思い、
あれこれ調べ始まった矢先にお返事いただけたので
助かりました。

これで、海外メーカーの格安パソコンでも
たむたむす〜るが使えそうで（←まあ、既存データなら問題ないけど）たむたむ信者獲得に一役買えればいいんですが。

それよりも現在の使用状況をご報告させていただきます。
とはいっても、まだ半日程度の時間しかやっていませんが、
不具合的なものはなさそうです。

ま、ポリゴンの「落ち」が多かったキャラほど
動きがカク付いているかもしれませんね。
ただ、ワタシの「たむたむす〜る」の使用内容には、
まったく影響しませんので　これは問題無いです。

Win７の入ったパソコンでは、なんの問題も無く
立ち上がったんですが、
Win８のほうは、初め「CRCが一致しません」とかいう文言が
出て、書き換えが出来なかったんですが、
先日、いろいろやってインストールしなおしたときに、
修正パッチを当ててなかったのを思い出しまして、
当てなおしたら、問題なく走りました。

いやー、ホントに今回はありがとうございました。

いずれ今回のことを、ブログかピクシブにでも
書いて、さらなる「タムラー」を増やすことに尽力させていただこうかと考えております。

とはいっても、今現在はソフト入手が激ムズらしいですからね。ムリかなー・・・・・
Re: Intel内蔵GPU(長文) - たむたむす〜る、楽しい 2016/05/15(Sun) 02:07 No.188
初めまして。
今さらな感がありますが、書き込ませていただきます。

最近、このす〜るを知り、体験版を試してみましたが、私のところでは、表示が崩れてしまう場合があるようです。
私のPCは、SandyBridgeの4コア、HD Graphics 3000です。Windows8／64bitです。

もともと、「メインメモリと共有と表記のあるビデオシステムは動作保証外となります」なわけですし、
しょうがないか、と思っていたのですが、解決方法があるということなので、いろいろ試してみました。

まずは、バイナリの書き換えを試してみました。
これは、問題無くうまくいきました。FPSが下がるのは、しょうがないですね。
FPSは、書き換え前が、アンチエイリアス無し→57たむ。x2→43。
書き換え後は、アンチエイリアス無し→21。x2→18。といったところです。
解像度は、800x600です。

FPSがもう少し上がらないかな、と思って、次に、3D-Analyzeを試そうと思いました。
上記に、「Win8.1／64bitでは動かない」とありましたので、ダメもとで試しましたが、やはり動かず。
EXEを指定した後、何かしようとすると、「応答なし」になってしまいます。

GPUのコントロールパネルで設定するという方法ですが、私のPCでは、「頂点処理」という表示が無いみたいです。
一応、詳細設定モードにしているのですが。

レジストリの書き換え（というか、値の追加）も試してみました。
ただし、場所は、"HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Direct3D\Drivers"です。
32ビットのキーは、"Wow6432Node"以下になるとのことです。
もともと、、"SoftwareOnly"という値は無かったので追加しました。ただし、DWORD値のようです。
で、再起動した後、す〜るを実行してみました。
すると、起動直後に、

　----------------------------------------------
　CheckDeviceType_Error
　バックバッファフォーマットに対応していません。
　----------------------------------------------

　----------------------------------------------
　CreateDevice_Error
　DirectXの初期化に失敗しました。
　----------------------------------------------

　----------------------------------------------
　エラー
　DirectXの初期化に失敗しました
　----------------------------------------------

と、３回、エラーのダイアログが出た後、自動で終了します。
よく分かりませんが、とにかく、動きませんでした。
これは蛇足かもしれませんが、"SoftwareOnly"という名前を変更すれば、元に戻るようです。

結局、私のところでは、す〜るの実行ファイルを書き換えるしかないみたいです。
FPSが落ちるのは、やっぱり残念ですね。

あと、私のPCは大手メーカーのノートパソコンなのですが、BIOSには、グラフィック関連の項目は無いようでした。

以上です。
長文、失礼しました。

Re: Intel内蔵GPU(長文) - yomeko2905 2016/11/13(Sun) 09:19 No.207
DirectXが勝手に12にされて、バイナリ書き換えをしてたりするとFPSが1/10（30たむが3たむとか）になっていたのですが、解決策がありました。

イリュのHPから、d3d9.dllのexeをダウンロード、展開してインストールフォルダ（たむたむすーる.exeが入ってるフォルダ）に入れれば、元のFPSに戻りました。

DirectX12に悩まされている人は意外と多かったのかな。
Re: Intel内蔵GPU(長文) - よねすけ 2016/11/13(Sun) 11:07 No.208
yomeko2905さん、情報提供ありがとうございます！

イリュージョンのサポートのWindows10動作確認表というところですね。

Windows10のDirectXのバージョンの問題は先日どなたかも話しておられましたが、イリュージョンが公式に情報提供してくれたようで助かった方も多いと思います。



Re: Intel内蔵GPU(長文) - yomeko2905 2023/09/07(Thu) 01:23 No.2092
もしかしたらIntelチップの問題が解決されたかもしれない！
という話です。


相変わらずIntelチップ内蔵のノーパソを使っていて、フレームレートとらぶギアの本編で使う関係でたむたむす〜るの実行ファイルはorg（オリジナル）とnew（スクリーンショット撮影用パッチ適用）の二つを使い分けているのですが、
現時点でパッチ適用してないorg（オリジナル実行ファイル）でも平滑等で頂点削除した衣装が普通に表示されていることに気が付きました。

代わりにメッシュ表示がされなくなったみたいなので赤青の編集頂点表示を使っています。
まあ古いソフトなので使えるだけでありがたいのですが。

仕事とゲーム用にデュアルブートでwin10とwin11を使ってますがどちらも改善されているのを確認しました。
チップはIntel(R) Iris(R) Xe Graphicsです。
旧チップはどうなのか、実験も面白いかもしれません。
Re: Intel内蔵GPU(長文) - yomeko2905 2023/09/13(Wed) 23:01 No.2093
本日のWindowsUpdateでまた表示がおかしくなりました。
安心しきっててWindowsだけでなくドライバーも全部Updateしたのですが、なにがどう影響しているのか今のところ不明です。
まあ今まで通りorg（オリジナル）とnew（パッチ適用）と使い分ければいいのですが、ちゃんと表示されたのは今後に期待です。

記事番号76に書いた「“intelグラフィックプロパティの3D設定”(www.intel.com/jp/support/graphics/sb/cs-030506.htm)を参考に『3D』の『頂点処理』を“ソフトウェア”に設定してみる」の件、できましたらどなたか検証してみて下さいませんでしょうか。パフォーマンス的な問題が残るとは思いますが、上手くいけば助かる人が幾らかいらっしゃると思うので。私の使えるPCでインテルGPUが入ってるものは1台も無いので、自力で実験できないのです。

検証に使うalpファイルですが、新たにす〜るv.4体験版をインストールする場合も考えて、体験版で表示できると明言されているファイルをいくつか見繕ってみました。よねぞんフリーアップローダーからDLできるファイルでは、Dさんの“クッキー.alp”と藤宮さんの“ちゅんちゅんおやつ(体験版用).alp”の2つが、髪で頂点削除が使用されています。また直接はDLできませんが、tamzone保管用スレから辿れる変態紳士Ｐさん作品アーカイヴ中の“たまらない超振動.alp”は(少なくとも)衣装類で頂点削除が使用されています。あとよねぞんフリーアップローダー外になりますが、かさつんさんがブログ(よねぞんにリンク有り)で公開されている“たむたむすーる+ver4.01体験版用キャラデータ+マギカセット.rar”中のalpファイルは、各所で頂点削除が使用されています。

これらファイルで(通常は)表示に問題が出るということであれば(何度も言いますが自分では確認できないので)、体験版で事前に表示に問題が出るか(またそれを解決し得るか)を確認するのにも丁度良いかと思います。

あの時あさはかさんに実験お願いしておけば良かったなあ…

追記
上記の手段は3D-Analyzerによる問題回避の代替手段として考えたものです(ことりニョッキさんのお話から考えるに3D-Analyzerが上手く動作しない環境がありそうなので)。なので現在3D-Analyzerを使っている方に代わりに使って同様の効果が得られるかを確認していただけると一番助かります。

字面的には3D-Analyzerでもインテルのコントロールパネルでも同じようなことが書いておりますが、実際に試してみないと同じ効果が得られるかは分かりません。

コントロールパネルによる設定はツールを別途DLする必要がない点、OS他に左右されない(と思うけど、Win8版では機能が削られてるとか無いこともないですね)点が優れていると思います。しかし、Direct3D9を使う全てのプログラムに影響を及ぼしてしまうため(使ってないものには影響ないと思います、多分)、す〜るの使い始め・終了時に一々設定を変えなければいけません。3D-Analyzerを使った場合は効果を及ぼすプログラムがす〜るに限られるため、実際に使うにはこちらの方が勝っていると個人的には考えます。

Re: 検証協力のお願い - のぞく人 2014/12/17(Wed) 21:59 No.79
すみません。寝るんだったらその前に実験協力していただけないでしょうか、あさはかさん。まだあの時のノートパソコンがあればですが。

おとうさんも“オンボ”とのことなので、お時間取れるようでしたら協力していただけると大変助かります。よろしくお願いします。
Re: 検証協力のお願い - かわいそうなお父さん 2014/12/17(Wed) 22:31 No.80
お手伝いしますよ。

とりあえず対象のalpをす〜る体験版にぶち込んでみます。
まずす〜る体験版をダウンロードしなければ･･･。
Re: 検証協力のお願い - あさはか 2014/12/17(Wed) 22:31 No.81
こちらではご無沙汰してます。
「『3D』の『頂点処理』を“ソフトウェア”に設定してみる」をすればいいんですよね？
残念ながら私のノートでは3Dの項目に『頂点処理』について出ません。
HD4000ですがその項目ができたのが4000以降なのか、グラフィックドライバがPCの製造元でカスタマイズされたものなので項目が出ないようになってる可能性があります。
というわけで協力できそうにないので、かわいそうなおとうさんが解決してくれるのを期待しますー。
Re: 検証協力のお願い - かわいそうなお父さん 2014/12/17(Wed) 23:17 No.82
早速検証しました。
Dさんのクッキーさんをお借りしています。

環境
OS　ウインドウズ７ 32bit版
インテルHDグラフィックス3000
たむたむす〜る　ぴゅあ
３D頂点処理　ソフトウェア

ごらんのとおり、削除した頂点がヘンテコに復活する様子はありませんでした。

ただし、環境を
３D頂点処理　標準（デフォルト）
に変更しても、変更前と同じように表示されていましたので、そもそも当方の環境では頂点のヘンテコ復活現象が起きない可能性があります（詳しいことはなんとも）。

とりあえず、検証結果はここまでです。
お役にたてれば幸いです。

Re: 検証協力のお願い - かわいそうなお父さん 2014/12/17(Wed) 23:28 No.83
追伸。

ちなみにダイレクトXのバージョンは10.1でした。
あまり重要じゃないかもしれませんが、念のため。
Re: 検証協力のお願い - のぞく人 2014/12/18(Thu) 00:22 No.84
お父さん、あさはかさん、ご協力どうもありがとうございます。いや、もう、感謝感謝。

>お父さん
え〜と、体験版でなくて良かったのですが、とにかくそちらでは最初からポリゴンが伸びる現象は起きないってことでよろしいでしょうか？3D-Analyzerを使わなくても大丈夫となると、理由が判ればかなり役立つ情報かと思われます。

DirectX10.1とのことですが、最初にす〜る(お父さんだとカレカノですか？)を起動したときに「DirectX9のランタイムが無いから入れろ」のメッセージが出たんじゃないかと思うのですけど、入れてないってこと無いですよね？(入れても数字が大きい方が表示されます。)

あと、できましたらレジストリの「HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Direct3D\Drivers」というキーに“SoftwareOnly”という名前の値があるかどうかと、もしあったらデータが“1”か“0”か(テキスト値かバイナリ値かも判れば)、も見ていただけますでしょうか。レジストリエディタの使い方がよく解らない場合は、変な値を書き換えても困るので結構です。あともう遅いので明日以降で構いません。
Re: 検証協力のお願い - のぞく人 2014/12/18(Thu) 00:36 No.85
>あさはかさん
検証ありがとうございます。件のインテルのサポート情報を見るとHD4000も含まれているので、PCのメーカーがカスタマイズしてる可能性が高そうですね。

すみませんが、3D-Analyzerを使わないときに先に挙げたファイル群で表示に異常が起きることだけ確認していただけないでしょうか。異常が起きてもほとんど判らないものも有るかもしれませんし。

ちなみにあさはかさんの「藤.alp」と「たんぽぽ.alp」は削除頂点が無いことを確認しております。
Re: 検証協力のお願い - のぞく人 2014/12/18(Thu) 01:00 No.87
現在確実に入手できるファイルで、「これを見ればあなたのPCで問題が起きるかが判ります」というものを確定しておきたい訳です。「見たいファイルで問題が起きなきゃいい」という方も当然いらっしゃると思いますが。
Re: 検証協力のお願い - のぞく人 2014/12/18(Thu) 07:17 No.88
お父さんへのお願いの追加です。
メーカーサイトからドライバをDLして直接見てみたいので、差しつかえなければPCのメーカー、型番等を教えていただけないでしょうか。報告上げたら追加のお願いが色々返ってきて申し訳ないですが、よろしくお願いいたします。
Re: 検証協力のお願い - 透過好き 2014/12/18(Thu) 20:47 No.89
WIN7 HomePremium SP1 64bit
インテルHDグラフィックス4600
DirectX 11 （「9じゃない」メッセージはでなかったような・・）
たむたむ5

regeditにて「HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Direct3D\Drivers」のキーなし
SoftwareOnlyのサーチ引っかからず

頂点処理は・・・設定がない！がっくし・・・
クッキーさんも前髪が地面に伸びてます・・・
ちなみに3D-Analyzerで伸びがなくなるです。確か。005たむになったりしてますがｗ
Re: 検証協力のお願い - あさはか 2014/12/18(Thu) 21:41 No.90
“クッキー.alp”と“ちゅんちゅんおやつ(体験版用).alp”で検証しました。
結果は“クッキー.alp”では髪のポリゴンが伸びる。
“ちゅんちゅんおやつ(体験版用).alp”では異常は見られない。
となりました。おそらく藤宮さんのものでは片側のエクステを全削除しているためだと思います。
ちなみに私の環境はASUS製ノートwin7(64bit)です。

それと今更かもしれませんが、3D-Analyzerで選択するときはす〜るのショートカットは使えません。す〜る.exe本体のほうになります。確かどこかで書いた気がするんですがうちのブログに書いてなかったようなので。
Re: 検証協力のお願い - のぞく人 2014/12/18(Thu) 22:05 No.91
あさはかさん、検証お疲れ様です。

藤宮さんの“ちゅんちゅんおやつ(体験版用).alp”はチェック用には不適ということですね。一応バイナリエディタでチェックしたのですが、全削除されているのには気付きませんでした。やはりす〜るでチェックしないと判らないですね。どうもありがとうございます。

Win7(64bit)で3D-Analyzerが動作するというのも貴重な情報と思います。取り敢えず64bitだと動かないということはないと。
Re: 検証協力のお願い - のぞく人 2014/12/18(Thu) 22:34 No.92
透過好きさん、あさはかさんと順番逆になっちゃいましたが、検証に参加いただきありがとうございます。

取り敢えずお二方の処で表示に異常が出たので、“クッキー.alp”はチェックに使えそうです(それでDLカウンターが増えてしまっても構わないと、Dさんが仰って下さればですが)。

“頂点処理”の項目はあさはかさんの処でも出なかったということですから、もしかしたらWin7(64bit)だと出ない、もしくはHD4000以降では出ないということかもしれません。

レジストリは、今見てるPCではキーだけはあるので(Win7 Home Premium 32bit)、64bitだとキーからして無いのですかね。“SoftwareOnly”という値が有りデータが“1”に設定されていたとすると、3D-Analyzerを使った場合よりももっと遅くなると予想しています。動けばですが。

こちらです〜る(体験版)を最初に起動した時に確か「d3dx9_??.dllが見つかりません」(正確な数字は忘れた)みたいなダイアログが出たのですが、もしかしたら64bitだとまた違うのかもしれませんね。とにもかくにも、こちらまで出張ってきていただき(ですよね？)ありがとうございました。
Re: 検証協力のお願い - 透過好き 2014/12/18(Thu) 23:29 No.93
>(ですよね？)
あ、たぶんちがうかと。
あちらで腹部だけ透過の仕方の質問をしてた
通りすがりです。
パーツが伸び伸びに表示されてると
透過で遊んでるのがメインになって・・・ｗ
Re: 検証協力のお願い - かわいそうなお父さん 2014/12/18(Thu) 23:54 No.94
いま帰宅しました。
検証は明日以降でお願いします。

年末進行からは逃げられなかったよ･･･。
Re: 検証協力のお願い - のぞく人 2014/12/19(Fri) 00:38 No.95
ああ、“3D-Analyzer”かと思っていたら“3D-Analyze”だった。どこでrが増えたんだろう(あさはかさんのblogでは正しく3D-Analyzeとなっています)。

>透過好きさん
あ、違いましたか。これは大変失礼いたしました。(あと私が答えた質問ではなさそうですね…)

とにかく、事例があまりに少ないと検証の意味が薄くなってしまいますので、直接お願いした方以外にご報告いただけたのは本当にありがたいのです。

3D-Analyzeを使うと表示レートが005たむ位まで落ちてしまうというのは、あさはかさんのところも同じなのか聞いてみたいところですね。HD4600ということはCPUも下位ってことはないでしょうし。今回の検証で何か方策が見つかるといいのですが。

>お父さん
お仕事お疲れ様です。了解です。ゆっくりお休み下さい。
Re: 検証協力のお願い - のぞく人 2014/12/19(Fri) 00:49 No.96
フレームレート1桁というとVolariより遅い？まあ、あの時動かしたのはす〜るじゃなくてデス４か５５５！辺りだけど。
Re: 検証協力のお願い - あさはか 2014/12/19(Fri) 23:12 No.97
800×600、アンチエイリアス×2で、
たむたむすーるver4.00体験版通常起動→3D-Analyze
ノーマル心愛さん：28たむ→18たむ
クッキー.alp：30たむ→16たむ
となりました。
Re: 検証協力のお願い - のぞく人 2014/12/19(Fri) 23:38 No.98
あさはかさん、返信ありがとうございます。個人的には許容範囲内です(速いマシンを使ってこなかったので)。人によっては遅くてダメだとなるでしょうが。

基本的に同じOS(Win7_64bit)だから、透過好きさんのPCもどこか見直せば5たむまで落ちずに済むのかな？でもHD4000もHD4600も調べたらi3から設定がありましたから(上位のCPUにしか無いのだと思ってました)、CPUの差ですかね？

コントロールパネルですが、どうも新しい世代のGPUに付属してるものは以前のもの(お父さんのPCのものは多分こちら)とファイルが変わったようで、新しいものには“頂点処理”の項目が無いということかもしれません(あさはかさんが仰ったように)。“HD Graphics(数字無し)”には古い世代のものと新しい世代のものがあったんですね…
Re: 検証協力のお願い - あさはか 2014/12/20(Sat) 00:27 No.99
CPUはi5の2.5Gです。SSやこねるだけなら16たむでも平気(かすたむ時に全体表示OFFにすればもっと良くなる)ですが、エロでは少しカクついて見えると思います。

頂点処理の項目がないのはメーカーがカスタマイズしてる可能性もありますね。
自作PCの人にGPU外してオンボで動かしてもらえばHD Graphicsの世代の違いか検証できますが、そこまでする必要があるかと言われると…。
Re: 検証協力のお願い - のぞく人 2014/12/20(Sat) 02:01 No.100
まあ、項目の有無は本筋じゃありませんので。現在、“頂点処理”の設定内容が何処に記録されるかを特定しようと、古い方のコントロールパネルを眺めています。インストール時のinfファイルにそれらしい所を見つけらんなかったんで。

自分のところに有ればグラフィックカード外す(無効にする)くらいはするんですが、残念です。今はアクティベーションのハードウェア変更にカウントされると思うので、余計に他人にお願いしづらくなってしまいました。
Re: 検証協力のお願い - かわいそうなお父さん 2014/12/20(Sat) 12:31 No.101
型式分かりました。

Dell　Inspiron　n5110

です。
Re: 検証協力のお願い - のぞく人 2014/12/20(Sat) 13:15 No.102
お父さん、お疲れ様です。型式ありがとうございます。
一応確認なんですが、そのn5110確かに外付けGPUは載ってないのですよね？仕様を確認したところ、Inspiron n5110はGeForce GT 525MもしくはRadeon HD 6470M／7450Mが載せられるらしいので。申し訳ないですが、デバイスマネージャーから今一度確認してみていただけないでしょうか…
Re: 検証協力のお願い - のぞく人 2014/12/20(Sat) 13:51 No.103
なんかDellのサイト、実機持ってるかアカウント作ってあるかじゃないとドライバDLできないみたいですねえ。困った。
Re: 検証協力のお願い - かわいそうなお父さん 2014/12/20(Sat) 18:56 No.104
デバイスマネジャー見ましたらば、グラフィックボード未搭載でしたよ。
Re: 検証協力のお願い - のぞく人 2014/12/20(Sat) 23:14 No.105
>お父さん
確認どうもありがとうございました。「実は外付けGPUが載っていた」だと色々話が簡単になって(調べ物が減って)楽だったんですが、残念。もしかしてHD3000／2000は元々問題が出ない？

もうちょい調べるべきかがハッキリしなかったので、お父さんの気分を害すかもしれないと思いつつも質問させていただきました。お答えいただきありがとうございます。


という訳で、インテルHD Graphics 3000及び2000の事例、絶賛募集中です。
Re: 検証協力のお願い - のぞく人 2014/12/25(Thu) 00:50 No.106
リファレンスとか見ておりますが、HD3000／2000だけ動作が違うということも無いようです。お父さんの使われていたノートPCで問題が出ていなかったのは、ドライバの設定が違うか、(ドライバの)そもそもの動作が違う(ちょっと古いので)かではないかと思われます。情報集まってないんで何とも言えませんが。

ドライバを差し替えたりとかパッチ当てたりとか、す〜るにパッチ当てて試してみたりとかしたくなってきましたが、ここまで来ると誰かにお願いできる範囲を超えますね。

>あさはかさん
申し訳ありませんが、“インストールフォルダ\data\Config”にある“ToolGraphicConfig.dat”の[ShaderVer]という項目の値が“AUTO”になってたら“V30P30”に書き換えて、3D-Analyze無しでも正しく表示されるか確認してみていただけないでしょうか。なおす〜るver.5の実行ファイルはまだ確認してないので、カレカノかす〜るver.4体験版でお願いいたします。度々お手間取らせてしまい申し訳ありませんが、お手空きの時にでもお願いいたします。(期待度としては上手くいったら儲けものくらいです。)

一応あさはかさん宛としましたが、他の方が確認して下さっても勿論OKです。
Re: 検証協力のお願い - 透過好き 2014/12/25(Thu) 10:25 No.107
DirectX11のdxdiagがあるSystem32フォルダにdxcplというツールっぽいのを見つけました。
添付画像の画面が出てきたのでこれっぽいようなこれっぽくないようなｗ
で、どこをいじればいいのやらいけないのやらｗ

Re: 検証協力のお願い - のぞく人 2014/12/25(Thu) 12:57 No.108
透過好きさん、情報ありがとうございます。
こちらのPCで探したところ“dxcpl.exe”(exeじゃなくても)は残念ながら見つかりませんでした。どうもDirectX(もしくはWindows8以降)のSDK(Software Development Kit)をインストールするとデバッグランタイム(開発用のランタイムですね)と一緒にインストールされるもののようです。

一応DirecX10のSDKを落として中のdxcpl.exeを動かしてみましたが、こちらでは何だかタブがたくさん表示されました。画像では“Direct3D 9”というタブを選択してますが、この中の「Software Only」という項目にチェックを入れると、最初の方でお父さんに検証を依頼した(そして透過好きさんがチェックしてくださった)レジストリの項目が作成されてす〜るの表示が正しくなるものと“予測”されます。ただ全部ソフトウェア処理になるはずなので速度的にはかなり苦しいと思いますが。

因みにこちらの環境ではリリース用のランタイムしか入ってないためか、チェックを入れてもレジストリに変化はありませんでした。“Direct3D 10”のタブを選択しても、ほぼ全ての項目がグレーアウトされています。

透過好きさんの環境で何故タブが1つしか表示されないのかは謎です。64bit環境だとまた何か違いがあるのかもしれません。ざっと見たところデバッグに関する設定と思われるので、す〜るの表示改善には役立つものは無いかなあ…と思います。一番下の“Feature level limit”が何が制限できるのかは気になりますが。

追記
コントロールパネルフォルダに“DirectX”というアプレットはありませんか？そちらからなら全部のタブが有効になるかもしれません。またSysWOW64フォルダに32bit版の“dxcpl”が有るかもしれないので、有ったら試してみるというのも。

Re: 検証協力のお願い - のぞく人 2014/12/25(Thu) 21:50 No.109
No.106の検証のお願いですが、らぶデスFINAL!のす〜るver.5でも実行ファイル中に同じ選択肢があることが確認できました。す〜るv.4体験版、製品版、す〜るv.5製品版のどれか一つでもどなたか実験していただけると大変助かります。うちの環境では値を“V30P30”に書き換えても無事す〜るが起動しました。

因みに設定できる値の中に“NO”というのがあったので、これにすればシェーダーをCPUで処理するようになるかなと思い試しに設定してみましたが、「シェーダー1.1以上が必要です」というメッセージが表示されてす〜るは起動しませんでした。
Re: 検証協力のお願い - 透過好き 2014/12/26(Fri) 14:09 No.110
コントロールパネルフォルダに“DirectX”というアプレットはありませんでした。
SysWOW64フォルダにもう一つ“dxcpl”を見つけましたがSystem32のものと変化なしです。
“Feature level limit”に入っている項目は
9_1
9_2
9_3
10_0
10_1
11_0
11_1
の7項目でVerの制限を行うところかもしれません。

[ShaderVer]を“V30P30”に書き換える件。
らぶデスすーる（Ver5）ではくっきーさんの前髪が伸び伸びと育ってます（変化なし）
カレカノすーる（Ver4?）でもくっきーさんの前髪が伸び伸びと荒ぶっています（変化なし）

・・・と思いましたが面白いことに気がつきました。V30P30と書き換えても
すーるを起動するとAUTOに戻る現象です。なーにーこーれー
むかついたので読み込み専用にして再度チャレンジ。

AUTOに戻ることはなくなりましたが、やはり荒ぶるのは変わらず。どなたか追試をー
あ、ちなみにGameConfig.datというのも見つけたのでこれをいじっても同じ。
Re: 検証協力のお願い - のぞく人 2014/12/28(Sun) 06:03 No.111
透過好きさん、検証どうもありがとうございます。本っ当に助かります。今時間がないので取り敢えずお礼だけで。

あ、dxcplで表示されるタブの数が違うのは、バージョン違いの為のようです。透過好きさんのところにあるのが新しい方で、私が先日落としてきたのが古い方。

ネタがす〜る直のことじゃなくてアレなんですが、C#でツールを書くにあたり新しい.NETと.NET Frameworkで変える必要がある点をメモ的に。

まず最初にお断りしておきますが、単純に.NET Frameworkから.NET(含む.NET Core)への移行の話であって、最新の話題ではないです(本来なら2年くらい前の話題)。自分が今になって経験したというだけです(経験したことなので移行に関する話のほんのほんの一部です)。なお本来なら一次情報に当たるのが最善なのですが、日本語訳があまりにアレなので書いておくことにした次第です(https://docs.microsoft.com/ja-jp/dotnet/api/system.text.codepagesencodingprovider.instanceの日本語訳が一番マシかも)。

.NET6を使ってみたの2 - のぞく人 2022/03/03(Thu) 00:55 No.1860
.NETが何者かの説明は後に回していきなり本題に行きます。今のところですが、出くわした要変更な要件は2点です。一つはバイト列から文字列を読み出す際に必要なEncodingオブジェクトの取得方法、もう一つはNull許容参照型への対応です(こちらは回避しようと思えばできる)。

なおプログラムのビルド環境ですが、.NETのSDKを使っています。Visual Studioは使っておりません。なのでVisual Studioでは状況が異なる部分もあると思いますが、使っているライブラリ自体は同じ(なはず)であることとVisual Studioもビルド時はSDKを呼び出しているはずなので、大きく変わることはないはずです。

.NET(含むFramework、Core)を使ってファイル等から文字列を読み込む場合はEncodingクラスのオブジェクト(インスタンスの方がしっくり来る人は以下読み替えて下さい)を使って

　string name = enc.GetString(buf, 0, len);

のようにします(「enc」がEncodingオブジェクト、「buf」はファイルから読み込んだ生のデータを格納した配列、「len」は読み込むデータの長さ)。このEncodingオブジェクトは読み込んだデータで使われている文字エンコーディング(コード体系)に応じたものを使います。ツールを書いたりす〜るをバイナリエディタで見たことのある方はご存じのことと思いますが、す〜る関連のデータで使われている文字エンコーディングはCP932(Shift-JISを若干拡張したもの)です。

ではEncodingオブジェクトを得るにはどうするかと言うと、自分の場合は

　Encoding enc = Encoding.GetEncoding(932);

のようにしていました。他に

　Encoding enc = Encoding.GetEncoding("shift_jis");

のように文字列で指定する方法もありますが、とにかく.NET Frameworkでは(そのOSがサポートしている)文字エンコーディングに対応したEncodingオブジェクトが一回のメソッド呼び出しで取得できました。

が、.NET Core以降、Windows(と言うかOS)と.NETの切り離しを進めるためだと思いますが、この辺りの事情に変化がありました。Unicode系(とUS-ASCIIと西ヨーロッパ言語)だけが標準でサポートされるようになったのです。.NET Frameworkの時のソースそのままでもビルドは通るのですが、実行時に

Unhandled exception. System.TypeInitializationException: The type initializer for 'DecMDL.DecMdl' threw an exception.
---> System.NotSupportedException: No data is available for encoding 932. For information on defining a custom encoding, see the documentation for the Encoding.RegisterProvider method.
　 at System.Text.Encoding.GetEncoding(Int32 codepage)

のようなエラー(例外)が発生します。

Shift-JIS等のエンコーディングが標準でサポートされなくなったと言っても、幸いなことに使えるようにする方法と必要なデータは標準で用意されています。上のエラーメッセージにも「EncodingクラスのRegisterProviderメソッドを調べろ」と書いてありますが、ドキュメントを読むとEncodingProviderオブジェクトを取得してRegisterProviderメソッドで登録してやればいいということが分かります(解読できれば)。具体的には

　EncodingProvider encprovider = CodePagesEncodingProvider.Instance;
　Encoding.RegisterProvider(encprovider);

の2工程の追加です。1行目でCodePagesEncodingProviderクラスのInstanceプロパティからEncodingProviderオブジェクトを取得して、それをそのまま2行目でランタイム環境に登録しています(2行にする意味無いですね、これ)。EncodingProviderオブジェクトに関しては設定も何もありません。CodePagesEncodingProviderクラスから渡されたオブジェクトを右から左で次に渡すだけです。

以上の手順を踏んだ後であれば、今まで通り

　Encoding enc = Encoding.GetEncoding(932);

で必要なEncodingオブジェクトが取得でき、バイト列を文字列に変換することができます。なお上で「ランタイム環境に登録する」と書きましたが、スコープ外でGetEncodingメソッドを呼んだ場合は正しいEncodingオブジェクトが返ってこないと思われますので(確認してないけど多分。やるべきじゃない気が…)、その辺りはご注意下さい。あと変数名の前に一々型名を書いてますが(説明上そちらの方がいいと思ったので)、全部varでビルドは問題なく通ると思います。
.NET6を使ってみたの3 - のぞく人 2022/03/03(Thu) 00:58 No.1861
上で文字列の読み込みはできたのですが、実は公式ドキュメントにはもう一工程、「System.Text.Encoding.CodePages.dll アセンブリへの参照をプロジェクトに追加します」と書かれています。「参照の追加ってやり方こうだったっけ？」と思いながらプロジェクトファイル(csprojファイル)に

<ItemGroup>
　<Reference Include="System.Text.Encoding.CodePages"/>
</ItemGroup>

という項目を追加してみたのですが、その結果ビルド時に

・warning MSB3245: この参照を解決できませんでした。アセンブリ "System.Text.Encoding.CodePages" が見つかりませんでした。アセンブリが間違いなくディスクに存在することを確認してください。 コードにこの参照が必要な場合、コンパイル エラーが発生する可能性があります。
・warning MSB3243: "System.Text.Encoding.CodePages, Version=6.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" と "System.Text.Encoding.CodePages" の間の競合を解決する方法がありません。一時的に、"System.Text.Encoding.CodePages, Version=6.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" を選択します。

と2つの警告が出されました。1つ目を見る限り参照追加の方法がどこか間違っていると思われますが、2つ目の警告を見るとSystem.Text.Encoding.CodePagesは参照アセンブリの中に既に存在しているようです。実際参照追加のための行をプロジェクトファイルから除いたところ、今度は警告を出さずにビルドが終了しました。SDKだけを使ったビルド環境ではSystem.Text.Encoding.CodePagesへの参照追加は必要ないようです。

Visual Studioを使う場合、参照アセンブリの管理はプロジェクトファイルを直接編集せずにUIから行うようになっていたと思います。管理方法が違うので同じように参照の追加なしで行けるのか判断が付きませんが、「ビルド時にエラーになるようなら参照を追加する」みたいな進め方でも大丈夫なんじゃないかと思われます。
Re: .NET6を使ってみた - のぞく人 2022/03/03(Thu) 01:02 No.1862
2件目のNull許容参照型について。公式ドキュメント(https://docs.microsoft.com/ja-jp/dotnet/csharp/language-reference/builtin-types/nullable-reference-types)によるとC#8.0で導入されたものみたいです。「Null許容参照型」という新しい分類の型が導入された訳ではなく、null値が代入された状態の参照型変数を参照してしまうことを防ぐための追跡機構を構成するもの、ということのようです(型扱いした方が話が簡単なので型と呼ぶことにした模様)。

.NET6のSDKが(自動で)作成するプロジェクトファイルに

<Nullable>enable</Nullable>

という行があるのですが、これをdisableにしてやればNull許容コンテキスト(追跡機構の根幹)は無効になるそうです(.NET5以前ではdisableがデフォルトとのこと)。古いコードを使う場合、手っ取り早くdisableに設定するか、enableにしてコンパイラが出す警告を見ながらコードを手直しするかのどちらかになります。

で、どの辺りでこのNull許容参照型が使われているかですが、自分の場合はファイルパスの処理で出くわしました。PathクラスのGetDirectoryNameやGetFileNameWithoutExtensionといったメソッドの返値がNull許容参照型であるstring?に変わっていて(引数もstring?に変わっているがこちらは影響なし)、以前のままのコードでビルドを行ったところ

・warning CS8600: Null リテラルまたは Null の可能性がある値を Null 非 許容型に変換しています。

という警告が出されました。これはstringとして宣言した変数に返値をそのまま代入していたからです。また

・warning CS8603: Null 参照戻り値である可能性があります。
・warning CS8604: 'void File.Move(string sourceFileName, string destFileName)' 内のパラメーター 'destFileName' に Null 参照引数がある可能性があります。

といったコード分析の結果と思われる警告も出ました(デフォルトの設定ではいずれも警告で、ビルドエラーにはなりません)。

次に、警告にどう対処するかですが、最初のCS8600に対しては単純に返値を格納する変数を「string?」で宣言してやればOKです(stringで受けても警告が出てない箇所もあります。処理の流れ的にnullが返ってこない所だからなのか、単に見落とされているだけなのか不明です)。あとは変数を参照する前にnull値が格納されていないかチェックすることになります(stringならString.IsNullOrEmpty()を使うとか)。それで他の警告も消えてくれるはずです。

とは言え、返値を格納した変数がnullかどうか毎回チェックするのも面倒です。なので変数を使う箇所で変数名の後ろに「!」(このケースでは「null免除演算子」と呼ぶそうです)を付けるという回避手段が用意されています。例えば

　File.Move(srcpath, bakpath!);

みたいに使います(bakpathはstring?として宣言している)。使いどころとしては、処理の流れ上明らかにnull以外の値が代入されている所や、nullが代入されていたとしても敢えて後ろに流したい所を考えているようです。上の例も「bakpathを得るためのメソッドを前に呼び出していてそちらでnullでなかった場合にのみそこに来る」ということを踏まえて使用しています。

他にも、自分で書いた文字列及びnullを返すメソッドの型をstring?に変更してみました(そのままでも警告は出されなかったのですが、一応)。併せて受ける変数の型もstring?に変更し、使用前にnullが入っていないかチェックする処理も加えています。これら一連の書き換えを行って警告が出ない状態になれば、Null許容コンテキストに取り敢えずは対応できていると思います。

.NET6を使ってみたの4 - のぞく人 2022/03/03(Thu) 01:07 No.1863
以下、上に書いてある内容が必要な方には多分要らない内容だと思います。まずエンコーディングについて補足を少々。

基本的な文字コードの話やそれをどの様に記録するかの話は長くなるので割愛します。大本の文字コード体系からコンピュータで処理するのに都合が良いように手を加えた別のコード体系が作られ、更にメモリー上のデータと記録媒体上のデータとでは違うコード体系が使われていたりと複雑怪奇なのです。あるコード体系から別のコード体系への変換はみんな「エンコード」か「デコード」な訳ですが(目線の方向で呼び名が変わる)、プログラミングの場合は記録媒体に書き出す方向の変換をエンコードと呼ぶようです。で、この「エンコード」のやり方(規則)を「エンコーディング」と呼ぶ、みたいに自分は理解しています(でも大抵の場合「エンコーディング＝文字コード体系」の意味で使われているかも)。

たむたむす〜る他のTEATIMEのゲームに限ったことではありませんが、当時のプログラムには記録媒体(ハードディスクとか)に文字データを書き込む際「Shift-JIS」(を元に拡張したCP932)というコード体系を用いているものが多数あります。なので古めのゲームを扱うツールを書く際には上に書いたことは必須です。一方、Unityを使って開発されたイリュのゲームなどでは「UTF-8」というコード体系が使われています。こちらは.NETの標準サポートなのでEncodingオブジェクトの取得はCP932より簡単にできます。が、.NET(含むFramework、Core)を使う限り(UTF-16LEのデータであっても)Encodingオブジェクトを介して文字データの読み書きを行うという手順は一緒です。

も一つ。平文のODFファイルをバイナリエディタで見たことがある方は気付かれたのではないかと思いますが、す〜る付属のデータではメッシュやモーフの名前は全てアルファベット表記です(「全て」だったはず)。じゃあ「CP932」ではなく「US-ASCII」のEncodingオブジェクトを使えば話が済むのでは、と思われるかもしれませんが、MQO読み込みで作成されたODFファイル(MODも含む)の場合はメッシュ名に仮名や漢字が含まれる場合があります(実在する)。なのでODFファイル(含むODAファイル)しか扱わない場合でも仮名や漢字への対応は必要と思われます。なお、かすたむデータファイルは作者名(ALPはキャラクター名も)で仮名や漢字が使われています。

あ、.NET6を使ってみたの6だ - のぞく人 2022/03/03(Thu) 01:10 No.1864
冒頭で説明を飛ばしたので.NETについて簡単に。自分でプログラムを書く方以外は.NETとか.NET Frameworkとか言われても「たまにランタイムとかいうものをインストールしろと言われるやつ」というくらいの認識なんじゃないかと思います。が、プログラムを書く人間にとっては「プラットフォーム」などと呼ばれる様々な機能を提供してくれる存在です。特にC#というプログラミング言語を使ってアプリケーションを書く場合はWindowsの機能を呼び出す方法が事実上.NET(含むFrameworkとCore)経由一択なので、とても重要な存在です。

Windows2000の頃に.NET Frameworkが登場してからWindowsと共にバージョンアップを重ねてきましたが、何年か前に「一度Windowsと切り離して0から書き直そう」という話になり、「.NET Core」というものが登場する運びとなりました。その後「.NET Frameworkと.NET Coreを統合しよう」と話が進み、現在の「(ただの).NET」へと至ります。

.NET FrameworkはWindows Vistaの頃からランタイムライブラリ(プログラム(この場合は.NET Frameworkを利用して書かれたプログラム)を実行する時に必要となるプログラム)が標準で添付されるようになり、併せてソフトウェア開発に必要なコンパイラも標準搭載となったので(みなさんのPCにもcsc.exe(C#コンパイラ)やvbc.exe(Visual Basicコンパイラ)といったファイルが入っているはずです)、特に個人でちょっとしたプログラムを書く際に広く使われるようになりました。そして新しい.NETへの統合に向けて新規の開発が止まり、バージョンが4.8で打ち止めになっているのが現在の状況です。

.NET6を使ってみたの7 - のぞく人 2022/03/03(Thu) 01:13 No.1865
今まで.NET Frameworkのランタイムが標準添付されていたことから考えて、適当な時期を見て標準添付のランタイムを.NET5(今なら.NET6)のものに切り替えるものと自分では予想していたのですが、いまだにそうなっていません。Windows11に至ってもまだ.NET Framework4.8のランタイムが添付されています。なので今.NET Frameworkから.NETへと移行する特別な理由は無いと考えます(SDKやVisual Studioを使うぶんには新しめのC#で書けますし)。でも、いずれ切り替わることになっているのだから試してみてもいいよなあと思った結果が上で書いたことです。

今から新しくす〜るに向けてツールを書いて下さる方がいらっしゃるかと言うと限り無く0だろうなとは思いますが、古いツールのメインテナンスに役立つかもしれないし、古めのゲームを今からいじろうって方もいらっしゃるかもしれないので、少しでもどなたかの参考になれば幸いです。「谷間」の時期のためか情報があまり多くない気もしますし。

以上。連投失礼しました。

関係ないですが、イリュのゲームのランチャー、今でも.NET Framework3.5で書かれてるの何とかならんですかねえ。今動いているPCに入っているランタイムはみんな4.8になっていると思うのですが。何かコンパイルする時のターゲット設定変えるだけじゃ済まない話があるのかなあ…(私自身はexe.configファイルを置くことで3.5ランタイムのインストールを回避しています)

どうもはじめまして。いきなりの質問で申し訳ありません。

タイトルの通り過去の質問と被る部分があるかと思いますが
数年ぶりにALP2PMXでALPを変換しようとしたら
「実行時ｴﾗｰ'9':
ｲﾝﾃﾞｯｸｽが有効範囲にありません」
と表示され正しく変換できなくなっていました。
Modelとodfファイルに顔と体のペイントデータのみが出るだけで正しく変換されません。

FINAL製品版を使っているかつ数年前はちゃんと変換できていたのですが
エラーがNo.454の方と同一なので同じくレジストリの問題なのでしょうか。

素人ながらに見様見真似でレジストリを追加してみたりしたのですがどうも解決できなく質問をした次第です。

Re: 454と重複するかもしれ - よねすけ 2021/01/23(Sat) 17:57 No.864
mandamさんこんにちは！

私もしばらくalp2pmxを触ってないのですが、エラーの9番は原因がいくつか考えられるため、とりあえず現在の環境とalpに使ってる素材を記載していただければだいたい（のぞく人さんとかが）わかるのではないかと思います。

もし体験版を使っているなら、製品版とは参照先が異なるため、No.454そのままとは思いますが。
Re: 454と重複するかもしれ - のぞく人 2021/01/23(Sat) 18:17 No.865
mandamさんとは初めまして、でよかったでしょうか？のぞく人と申します。

実行時エラー9は大抵の場合ファイルが見つからない時に起きます(と記憶してるけど時間が経ってるので勘違いが混じっているかも)。「ファイルが見つからない」も大きく分けて２パターンありまして、インストールされているゲーム(FINAL!やカレカノ等)が見つからない場合と、ALPで指定されているファイルがインストールされているゲーム中に見つからない場合とがあります。

後者はDLしてきたALPで使っているアイテムが環境に無い場合、例えばFINAL!にしか無いエイルの服を使ったALPをカレカノや体験版で変換しようとするケースです(要は自分のところで表示できないALPを変換しようとしている)。す〜るに馴染みがないとやりがちなことだと思いますが、mandamさんは長らくす〜るを使ってこられた方なのでこっちは大丈夫かと考えます。

レジストリの登録情報に関しては再インストールが一番手っ取り早いと思います。が、古いPCからコピーしてきたFINAL!がPC上にあるのでインストール情報だけ入れたいということでしたら、基本的には454のスレッドに書いてある通りです。ただレジストリに書き込むゲーム名がFINAL!の場合は
「らぶデスFINAL!」
とインストールフォルダ名と違うので(FINAL!の部分が半角)それだけ注意してください。あとインストール先のフォルダ名の後ろはらぶギアと同じで「\\」が付きます。

もし体験版しか入ってないPCでALP2PMXを使いたいということだと少々話が変わってきますが、FINAL!が認識されないということでよろしいでしょうか？
Re: 454と重複するかもし - mandam 2021/01/24(Sun) 13:49 No.866
よねすけさんこんにちは、お久しぶりです。
のぞく人さん初めまして、ありがとうございます。

>ALPで指定されているファイルがインストールされているゲーム中に見つからない場合
FINALで正常に表示されているALPですしデフォルトのALPでもダメだったのでご指摘通りその可能性は薄そうですね。

>FINAL!が認識されないということでよろしいでしょうか？

そうですね。
数年前に瞳を外部ツールでペイントする為に変換していた時は問題なくできていたのですが
数年ぶりにやる気になってやろうとした所正常に変換できなくなっていました。
PCを新調していたりファイルの場所を変えたりはしていません。

FINAL!を半角にしてレジストリを登録しましたが改善されず。

魔改造されているので少々手間がかかってしまいますが再インストールしようとしましたが
再インストールしようとすると固まって落ちたり、データを削除してもそもそもインストールという項目が出ない(本編＆すーるを開始するという項目しかない)と再インストールができず。

なのでネトワクの方を再インストールしたらネトワクのデータは正しく変換できるようになりました。（因みにネトワクの方も再インストール前は正常に変換できませんでした）
変換も瞳を外部ツールでペイントする為に使用したかったので取りあえずは目的は達せられそうです。

FINAL!も再インストールできれば解決できそうなんですがコンパネにFINAL!のデータがそもそもないんですがそういう仕様でしたでしょうか？
Re: 454と重複するかもしれ - のぞく人 2021/01/24(Sun) 17:02 No.867
まずコントロールパネルにFINAL!のアイコンがあるかどうかですが、申し訳ないのですが今手許のPCにす〜るの体験版しか入ってないのでFINAL!そのものでの確認ができません。ただ体験版は「プログラムと機能」にアンインストール用のアイコンが表示されています。記憶をたどってもTEATIMEのゲームは全部アイコンが表示されるようになったと思います(再インストールしたカレカノのアイコンも表示されてるかと)。

ただし、プログラムと機能にアイコンがあるのはインストールに使用した管理者アカウントだけで、一般ユーザーのアカウントには出来ないようです。PCにユーザーアカウントを複数作っていなければ関係ないことですが。

基本的にコントロールパネルへのアンインストール用アイコンの作成とレジストリへのインストール情報の書き込みとはインストール時に必ず行われるはずです。なので、どこかの段階でPCからインストール情報が失われたものと思われます。例えば「PCのリフレッシュ」を行うと自分でインストールしたソフトの情報は全部消されてしまいます(だったと思った)。Windows10の機能アップデートの時もリフレッシュと似たような動作が走るので、どこかでズッコケるとインストール情報をすっ飛ばすとか十分あり得ます。

ただ、メニューというのはディスクを入れた時に出るメニューのことだと理解したのですが、通常の起動メニューが出て「インストールします」が出ないということは、最初に起動する「autorun.exe」というプログラムが「既にインストール済み」と判断しているということでもあるはずなので、その辺りが謎です。

なおインストールメニューが出ない場合でも、「LoveDeathFinal!」フォルダにある「setup.exe」を直接実行すれば強制的に上書きインストール出来ると思います。(でも全く認識されてない訳でもなさそうなので…)

レジストリの状況ですが、手許のPCだと画像のようになっています(インストール先フォルダがちょっと特殊ですね、うちの場合)。mandamさんのPCでも、同じようにTEATIMEというキーの下に再インストールで作成された「カレマチカノジョ」やご自分で追加された「らぶデスFINAL!」等のサブキーがあることと思います。今までの経験からするとALP2PMXはゲームのインストール確認はここしか見てないはずなので、ここに間違いが無いのにALP2PMXが動かないとなると私も理由がわかりません。レジストリエディタで今一度内容が正しいか確認(カレマチカノジョとらぶデスFINAL!でどこか違っているか)していただければと思います。なお454のスレッド等で値「INSTALLDIR」のデータ中のフォルダの区切り文字が「\\」となっていますが、これはREGファイル中はそうしなければいけない決まりがあるからであり、レジストリエディタで直接編集する時は通常通り「\」1つです。あとは「INSTALLDIR」に正しくFINAL!のインストールフォルダが入力されていればいいはずなのですが…

(なお、レジストリも「ゲームインストール時のユーザーアカウントとALP2PMXを動かすアカウントが違う場合は…」という話があるのですが、カレマチカノジョの再インストールでALP2PMXが動作したということであれば多分要らない話だと思います。)

最後にFINAL!のインストール中に固まったということですが、ディスクをガチャガチャ読み込んでる時に問題が出ることがあるらしいので、それじゃないかと思います(固まらなくても精神衛生上よくないですよね、アレ)。Windows10の場合は一旦ディスクのイメージファイルを保存して、それをマウントしてそちらからインストールを実行することで回避できるんじゃないかと思います。

あ、そうだ。レジストリを編集する時は、先にレジストリのバックアップを取っておいてください(もしくは復元ポイントを作っておくとか)。

Re: 454と重複するかもしれ - のぞく人 2021/01/24(Sun) 17:12 No.868
追加。

再インストールした場合ですが、インストール(レジストリへの書き込みやコントロールパネルへのアイコン作成やスタートメニューへの項目作成等)が終わったら、今まであったデータにゴッソリ入れ換えてしまって大丈夫です。

ちょっと推測を付け加えておきますと、ディスクを入れた時に走る「autorun.exe」は多分レジストリ中に「らぶデスFINAL!」のキーがあるかどうかでインストール済みかどうか判断していると思われます。なので追加されている「らぶデスFINAL!」のキー名は多分間違ってないと思います。

一方ALP2PMXは同キー中の値「INSTALLDIR」の内容を見ます。変換に必要なファイルの場所はこの値を見て判断します(って外から見て言ってるだけですが)。なので、この値がどこか違うんじゃないかと思っています(失礼)。

なおFINAL!のゲーム自体やす〜るの動作には、このキーは関係しません。あっても無くても動作します。(過去作の性格が使えるかの判断は過去作のキーの有無で行う。)
Re: 454と重複するかもしれ - のぞく人 2021/01/24(Sun) 22:57 No.869
お詫びと訂正。

ディスク入れた時のメニューでゲームの起動メニューが出るということはautorun.exeがFINAL!のインストール場所を見つけられるということだから、レジストリの内容も合ってるはずということですね。大変失礼しました。

ALP2PMXが上手く動かないのはどういうケースがあるのか、出来る範囲でもうちょい探してみます。
Re: 454と重複するかもしれ - のぞく人 2021/01/24(Sun) 23:57 No.870
訂正の追加。

上でautorun.exeがレジストリのキーが存在するかどうかしか見ていないと書きましたが、値の内容もちゃんと見ていました。画像の上側が「らぶデスFINAL!」のキーに値「INSTALLDIR」を作成する前で、下半分が「INSTALLDIR」を作成してインストールディレクトリを書き込んだ後です。

なのでメニューに「インストール」が無いということは、レジストリに書き込んだ値は正しいということになります。本当に失礼致しました。

なお「INSTALLDIR」の末尾に「\」が無くてもALP2PMXからは認識されるようです。

FINAL!で正常に表示されるALPだということなのでファイルシステムの問題でALP2PMXから見えないということは考えづらいのですが、コマンドプロンプト(管理者として実行)で
　chkdsk [ゲームがインストールされているドライブ]:
とやってファイルシステムに問題が無いことを確認しておいていただけると助かります。

Re: 454と重複するかも - mandam 2021/01/25(Mon) 17:42 No.871
色々と調べて下さってありがとうございます。

コマンドプロンプトは特に問題は見つかりませんでしたと出ました。

ディスクのイメージファイルを保存は保存してる途中で何度やっても固まって落ちてしまいますし
「LoveDeathFinal!」フォルダにあるsetup.exeを起動させると即固まってインストールに移らず。

取りあえずこれからもちょくちょくチャレンジしてみますが
一度ネトワクに移す必要があるものの
ALPを変換して外部ペイントツールで目を塗る当初の目的は達しているのでいいかなと思っています。

以前は問題なかったのにできなくなった原因がよく分からないのはちょっと解せないですけども。
Re: 454と重複するかもしれ - のぞく人 2021/01/25(Mon) 19:34 No.872
ディスクチェック、御協力ありがとうございます。原因切り分けに潰しておきたい項目なので。

以前ミスマさんから頂いた情報なんですが、DVDのロットによって相性が悪いドライブが存在することがあるそうです。イメージファイルの保存途中で固まるのはそれかもしれません。TEATIME健在な頃は連絡すればDVDを交換してもらえたそうなのですが、今となっては…

setup.exeが即固まる件はちょっとわからないです。こちらで動かしてみるとインストールが始まるので…。謎です。


幾つかのケースを試してみたのですが、レジストリに「らぶデスFINAL!」のキーがあって且つそのキー中の「INSTALLDIR」に書かれているインストールパスが無効な場合に、「実行時エラー9で即落ちして出力にModelフォルダとodfフォルダが作成されてペイントデータがそこに書き出される」という状況になりました。こちらでは、キーそのものが無い時やキー中に「INSTALLDIR」が無い時はまた違う挙動になっています(前に何を変換したのかも影響する模様)。

ただ、レジストリに書かれているインストールパスが無効だとautorun.exeで出てくるメニューにインストールの項目が表示されるはずなので、そこが矛盾するよなあと。autorun.exeがFINAL!の存在を見つけられるのにALP2PMXが見つけられないという状況に「？？？」です。

変換しようとしているALPファイル固有の問題ということも考えましたが(表示できるALPでも変換が上手くいかないことがある)、デフォルトのALPでも上手く行かないということでしたので、やっぱり違うんだろうなと。

(表示できるけれど変換できないALPにゲーム付属のeir.alpとrota.alpがあります。ALP2PMXが通常通り動作する場合も「頂点数が一致しません」というエラーが発生します(TGA書き出しだけなら発生しないかも)。す〜るで一旦保存し直せば変換できるようになります(eirの方は記憶がハッキリしてるけどrotaの方もそうだったはず)。)

幾らか調べてはみたものの、原因まで行けなかったですね…

FINAL!のALP(実際はALP以外のWBSやFSP等の部分のかすたむファイルでも行けると思います)であっても、変換する時にALP2PMXの「ALPファイル」の下に並んでいるラジオボタンで「ネトワクネトラル」を選択すれば、FINAL!のデータを見にいかずにこちらのデータを参照して変換します。FINAL!にしか無いアイテムを使っていると問答無用でエラーな気がしていたのですが、無い時はそこだけ飛ばして変換するようです。もしかしたら服アイテムと髪エクステでは挙動が違うみたいなこともあるかもしれないので、エラーになったらごめんなさい(飛ばしたアイテムもフォルダが作られたり作られなかったりで挙動が今一つ掴み切れてないのです)。

Re: 454と重複する - mandam 2021/01/26(Tue) 20:05 No.873
ALP2PMXでネトワクにチェックを入れると正常に変換できましたね。
これならわざわざネトワク用にALPを変換する手間をかけずにできそうです。

コントロールパネルにFINALの項目がないというのもおかしい気もするんですが
正常に動いている時からなかったような記憶がありますし
その時から変わった点はWindows10のアップデートぐらいでしょうか。
でも他に同じような案件を聞かない所を見るとWindows10のアップデートは関係ないですよね。
Re: 454と重複するかもしれ - のぞく人 2021/01/27(Wed) 00:18 No.874
Windows10の機能アップデート(バージョンUP)でインストール情報が消えたみたいな話は確かに聞いてないですが、十分有り得るんじゃないかと思います。あれはファイルの置き換え以外にも結構色んなことを書き換える処理なので、自分的には直前でPC全体のバックアップを取ってなければやらないようにしています。

「ロック画面の画像の設定が保存されない」という影響が出たこともありますが、設定関連のフォルダやファイルで所有者情報やアクセス権(ACLというものにまとめられています)の書き換えが上手くいかないケースがあると個人的には思っています。この辺がおかしくなると、ファイルがあるけど見えないということやシステムからアクセスできないということも起こり得ます。

レジストリの情報とコントロールパネルの登録情報が両方無くなるというのもちょっと難しいよなあとは思いますが、アップデートを行ってる最中に走る登録情報を引き継ぐ処理が途中で止まってしまえば起こり得なくはないかと考えます。まあ、誰かのところで「プログラムと機能」からアイコンが無くなっていたとして、今からアンインストールしようという方はまず居ないだろうから気付かないんじゃないかなあと。

とまあ、インストール情報が吹っ飛ぶもしくは見えなくなるということは起こりうると考えていますが、autorun.exeとALP2PMXは同じユーザー権限で走っているはずなのに一方からはFINAL!のインストール先が見えて一方からは見えないというのがやっぱり分からないー！あとカレマチカノジョの方は見えるのにFINAL!の方は見えないというのも。レジストリキーのアクセス権の関係で見えないとかも考えたけど、同じユーザーが走らせているプログラム同士だし…
Re: 454と重複するかもしれ - のぞく人 2021/01/28(Thu) 19:33 No.875
「プログラムと機能」のアンインストール用のアイコンですが、こちらでは存在するのが確認できました。画像はWin7から引き継いだやつですが、Win10に新しくインストールしたPCでもアイコンが作成されました。

mandamさんのPCではどこかのタイミングでインストール情報が失われたか、存在してるけど読めない状態になっているかだと思われます。

(うちのメインのPCはここのアイコンが無くおとうさんのところもそうらしいのですが、どちらもインストールプログラムを動かしてないので無いのが“正しい”状態です。)

454とは既に方向が - のぞく人 2021/01/29(Fri) 19:29 No.876
訂正

AutoRunLauncher(autorun.exe)はレジストリキー「らぶデスFINAL!」の値「INSTALLDIR」の存在だけ見ていて、中身まで見ていませんでした。書かれたパスにファイルが存在しなくても、値が空でもゲーム起動の方のメニューを出します。

なのでメニューに「ゲームのインストール」が無いのはレジストリに書かれたパスが有効かどうかとは関係がありません。

setupが固まるのは、もしかしたらレジストリに値があることで情報の不整合が生じているのかもしれません(まだ何とも言えない)。もう少しチェックしてみます。
念のため - のぞく人 2021/01/30(Sat) 16:52 No.877
お手数掛けますが、画像みたいな手順で「らぶデスFINAL!」キーの値「INSTALLDIR」を設定し直してみて頂けないでしょうか。今まで通りALP2PMXがFINAL!を認識しない可能性が高いとは思うのですが、これだと手入力を介さないでパスが入るので、念のためということで。

setupが固まる件ですが、今のところこちらでは「固まる」という事態には遭遇しておりません。が、InstallShieldがFINAL!が存在するフォルダを見つけるとそこをチェックし始めるので、とても時間が掛かるということが判りました。この時「応答なし」となるので固まってるように見えます。少なくともファイル名のチェック、もしかしたらファイル内容のチェックまでしてるのかもしれません(ウィルスチェックプログラムまで見に行ってました)。mandamさんの場合saveフォルダ以下にファイルが大量にあることと察せられますから、これに掛かる時間が特別長く固まっているように見えるのではないかと推測します。本当に固まっているのかもしませんが。

フォルダのチェックが始まるタイミングはインストール先がデフォルトかどうかで違うようです。デフォルト以外(うちの環境だとこっち)だとインストール先フォルダを指定したところでチェックが始まり、デフォルトだともっと早く始まるようではあるのですが今一つよくわかりませんでした。

また一つ訂正。

FINAL!のインストール、ディスクイメージ(やDVD)からでなくてもできました。「LoveDeathFinal!」フォルダの中身全部、もしくはフォルダごとどこかにコピーしてそこからsetup.exeを実行するので行けます。ディスクイメージが駄目、DVD直も駄目ということでしたら、この方法も試してみて下さい。

Re: 454と重複する - mandam 2021/01/30(Sat) 21:10 No.878
色々試した結果、何とか再インストールができALP2PMXでFINAL産ALPが変換できるようになりました。

正常になったと思われるレジストリを見ても違いが判らなかったので原因はよく分かりませんが
ともかく助かりました、本当にありがとうございました。

結局は困ったら再インストールしろという至極シンプルな話でした。
Re: 454と重複するかもしれ - のぞく人 2021/01/30(Sat) 23:18 No.879
再インストール成功されたのですね。ALP2PMXが無事動くようになったとのこと、良かったです。

「レジストリの値が正しくてもアクセス許可情報がおかしければALP2PMXが動かないことはあり得るかな？」と考えていたのですが、その場合チェックや修正がとても難しそうだったので、再インストールが上手くいってくれて正直良かったと思います。

何か役に立ったことがあったのなら何よりです。

あけましておめでとうございます＆お久しぶりです。

カスタムした衣装って、保存して
更に保存してあるカスタムした衣装と合わせる時って
みなさん、どのようにやっておられますか？
今さらなんですが、カスタムしたスタジャンと
カスタムしたジーンズ着合わせようと思ったら、
「あれ？片方は一から作り直さなきゃならんのか」と
今、思っている最中なんですが、いい方法とか
「なんだ、そんなのは・・・」とか
解決策、いただけると嬉しいのですが・・・

Re: カスタムした衣装を… - のぞく人 2021/01/06(Wed) 18:06 No.861
おめでとうございます。

例としてスタジャンとジーンズが別衣装ということでいいのでしたら、まずジーンズを履いてる状態で「着替え」→「服かすたむ」と進んで、ジーンズの装備スロットを選んで「セーブ」を選択します。ここからジーンズのかすたむデータを保存できます。

次にスタジャンを着た状態で「着替え」→「服かすたむ」と進んで、ジーンズを装備したい空きスロットを選択して「ロード」を押すと服かすたむデータの選択メニューになるので、そこで先程セーブしたジーンズのかすたむデータを読み込めます。

…って感じでOKでしょうか？ちなみに服かすたむデータはsave\Importフォルダにicpという拡張子で保存されます。

「オーバーオール＆ジャケット」みたいなデータで別々にかすたむしたジャンパーのデータとジーンズのデータを合成したいということでしたら、うーん、出来るのかなあ…

取り敢えず思いつくのはスロット2つ使って別々に読み込むという手ですか。もしかしたら、かすたむ画面で一方の形状かすたむデータとペイントデータを保存しておいて、他方のデータを読み込んだ状態でかすたむ画面に入って残したい箇所を編集対象から除外して、メニューから形状データ・ペイントデータを読み込む、で行けるかもしれませんが、試したことないですし、上手く行きそうな気があまりしないです。

Re: カスタムした衣装を - ゴート 2021/01/06(Wed) 20:55 No.862
のぞく人さん、毎度ありがとうございます。

早々のお返事、ありがとうございます。

完全な経験不足を露呈して、恥ずかしい限りです。
早速実践させていただきました。
出来ました、ありがとうございました。

今年こそは、お酒を辞めて、粉骨砕身の気持で、
たむたむす〜るの創作に励めるよう、
かように思う次第でございます。

・・・ありがとうございました。(＠＾−＾)