UE4/C++,Blueprint: BPへ関数のパラメーターを参照だけど入力としてノードを与えたい場合にどうするか
問題
UFUNCTION( BlueprintCallable ) static void Something1( FVector& VR , const FIntVector VC );
このような UE4/C++ で生成される Blueprint ノードは、 VC を入力ピン、 VR を出力ピンにしてしまう。 VR も入力ピンの意図で実装した場合に Blueprint で問題となる。
参照の関数パラメーターを Blueprint で入力ピンにする方法
// 仮引数に UPARAM(ref) を付ける UFUNCTION( BlueprintCallable ) static void Something2( UPARAM(ref) FVector& VR , const FIntVector VC );
絵
参考
UE4: Camera の GetActorLocation で得られる位置と1フレームの Tick の中のタイミングのメモ
状況例
「サードパーソンテンプレートのようなプロジェクトを作り、プレイヤーキャラクターとカメラのちょうど中間に何かしらアクターを移動させたい。」
実装手順
中間の位置に出したいアクターの Blueprint へ次のように実装する。
おそらく遭遇する問題
カメラの GetActorLocation が1フレーム程度遅延した位置を返すため、中間に出したいアクターが少しずれた位置へ出てしまい、ブレ感が発生してしまう。
View post on imgur.com
この問題は ACharactor が基底型 APawn の APlayerController 型の Controller メンバーを介して Rotation 等の入力を処理する場合（サードパーソンテンプレートのプレイヤーキャラクターなどでの初期設定状態）に発生する。入力をイベントが受け付けた段階での処理、またはキャラクターや中間に起きたいアクターの Tick では Controller には変化量が保持されているだけで、まだ実際の変化は適用されていない。（なぜ、あるいは詳細は APawn::AddControllerPitchInput, APlayerController::AddPitchInput, AController::SetControlRotation とその呼び出し元の実装を探索すると理解が早いかもしれません。 ）
無駄な対処法
AddTickPrerequisiteActor でどうにかしようとする。
どうにもなりません。
解決方法: 中間に起きたいアクターの Tick でブレずに（遅延せずに）カメラの位置を取得する方法
中間に起きたいアクターの TickGroup を PostUpdateWork に変更する。
UE4Editor の標準状態では TickGroup は非表示状態になっているので、 Actor Tick の「▽」的なボタンを展開して変更する。
View post on imgur.com
遅延しなくなりました😃
Reference
UE4/C++: Stats ( Profiler ) 機能の組み込みと使い方メモ
Runtime/Core/Public/Stats/Stats.h で宣言・定義される Stats ( Profiler ) 機能を C++ コードに仕込んで UE4Editor のプロファイラーでお手軽に負荷など調べる方法のメモ。
仕込み
// MySourceFile.h #pragma once #include "CoreMinimal.h" // 略
// MySourceFile.cpp #include "MySourceFile.h" // グループ定義 DECLARE_STATS_GROUP( TEXT( "MySomething" ), STATGROUP_MySomething, STATCAT_Advanced ); // 具体的な計測項目の定義。複数使いたければ使いたいだけ定義する DECLARE_CYCLE_STAT( TEXT( "AMySomething::DoSomething" ), STAT_MySomething_DoSomething , STATGROUP_MySomething); // 略 void AMySomething::DoSomething() { SCOPE_CYCLE_COUNTER( STAT_MySomething_DoSomething ); // ↑のスコープが終わるまでが記録される }
使い方
記録をファイルへ取る
UE4Editor の Output Log の Cmd または Development/Debug で自動的にゲームに組み込まれるコンソール機能に
- 記録開始:
stat startfile - 記録終了:
stat stopfile
を投げる。ファイルは実行状態に併せて自動的に命名されて、プロジェクトのディレクトリー以下の Saved/Profiling/UnrealStats/ 以下によしなに保存される。ファイルの拡張子は .ue4st 。
記録したファイルを見る
- UE4Editor のメニューから Window > Developer Tools > Session Frontend を表示
- Session Frontend ウィンドウ内の Profiler タブを表示
- Profiler タブ内の Load ボタンから記録ファイルを開く
付記事項
- UE4のログマクロなどと同じ形式で複数ファイルへ跨って使用したい場合には必要に応じて
DECLARE_CYCLE_STAT_EXTERNを使う。（参考2）
参考
UE4: PS4 の DualShock4 コントローラーを Windows PC に Bluetooth 接続して UE4 の Input で使う方法
1. PS4 DS4 を Bluetooth で PC に接続
- DS4 を
SHARE+PSの同時長押しで Bluetooth ペアリングモードにする- このモードになるとインジケーターがピピッ的に断続的に発光する状態になる
- Windows PC の設定 "Bluetooth & other devices" からペアリングする（日本語でもたぶんそれっぽいカタカナになっているだけでしょう、たぶん）
これだけで DS4 を Windows PC で使用可能になります。動作テストは Monster Hunter: World などで適当にどうぞ。STEAM を使っている場合には、 STEAM の設定機能から DS4 のインジケーターの発光色を変更するなどもできます。
3. UE4 のプロジェクトから使えるようにする
方法が幾つかある様子ですが、簡単に期待動作が得られたものは次の3つのうちでは1つだけでした。
- UE4 標準の Built-In プラグイン Windows RawInput を使う （期待動作せず）
- UE4 標準の Built-In プラグイン Steam Controller を使う（ようわからんかった）
- katze7514/UEDirectInputPadPlugin プラグインを使う（まともに動く方法はこれだった）
3.1. Windows RawInput で遭遇した問題
Windows RawInputのドキュメントを参考に試してみたものの…
- 軸の入力がおかしい。 Offset が必要なだけかと思いましたが、 Offset を設定してもセンターを調整できない状態でした💀
- DS4 の ○ ボタンなどの応答がおかしい。押してもイベントが発火しない事の方が多く、何度か押しているとたまに Pressed が来る状態でこれはもうダメだと思いました💀
こんなところのソースに興味は無いし、他の方法も試せるのでこれはもう諦めました。（DirectInputの複数デバイス、アナログ入力、フォースフィードバックの実装を書いた事はたぶん人生で3回くらいはありますが、また書きたいとも思いません😅）
Note: Steam が動作中は DirectInput コントローラーを Steam が専有するため、 UE4Editor で開いたプロジェクトどころか、Windows の Game Controllers やそこから開けるコントローラーのキャリブレーションとテストができるプロパティーウィンドウなどもデバイスの認識はしているものの入力は一切受け取れない状態になります。 Windows RawInput を試す場合は Steam が起動していない状態を確認しましょう。（これにもちょっとやられました…💀）
3.2. Steam Controller を使おうと思ったものの…
Steam Controller プラグインを有効にしても Windows RawInput のような設定画面も用意されておらず、 Steam の入力イベントもバックボタンとタッチがあるのみなので、一般的な軸やボタン群は自動的に標準の XInput パッドへ割り当てでもされるのかな、と勝手に期待して実行してみるも反応せず💀 Steam Online Subsystem プラグインも必要なのだろうか、など有効にしてみたものの、特に変化もなく💀
UE4側に有用でわかりやすいドキュメントもなさそうだし、STEAMのドキュメントからはUE4のプラグインの内部処理でやってくれるであろう取得方法とかしかでてきませんし、使い方がようわからんし、ソース見るのはもう1つ見つけていた方法を試してもダメだった後にしようと思いとりあえず諦めました💀
3.3. katze7514/UEDirectInputPadPlugin で幸せになる
DirectInput 汎用のプラグインのため、 PS4 の DS4 を使う場合にも一部リマップやリマップ相当の対処は必要でしたが、ほぼ期待動作してくれました😃 若干期待動作しなかった機能はリマップ相当の代替手段で対処すれば、見かけ上は期待動作になります。
↑の絵のようにリマップすると、はじめのリマップノード2つ DS4 のクロスとサークルへの割り当ては期待動作しますが、残念ながら3つめのリマップノードの右スティックのY軸への割り当ての Negative は動作しないようでした。この部分はプロジェクトの設定の Engine の Input 設定を反転させるなり、それを使う実装側で反転させる係数を書ければその場しのぎはできます。
ただし、XInputのコントローラーと PS4 の DS4 のコントローラーどちらにも同様の動作を設定したい場合は接続状態を確認して係数を反転させてあげないと、一般的な3Dアプリの操作系でいえばカメラのY軸が接続するコントローラーによって順方向と逆方向がリバースしてしまうという怪奇現象になり、少々面倒です。これは後ほど Issues へ Negative が期待動作していない旨をポストしておこうと思います。パッチまで投げるかは…気分と必要の次第としつつ。
（追記: Issue投げました → Set Key Map の Negative が期待動作しない #5 ）
（追記の追記: プラグインを開発された katze7514 さんから「その用途なら Set Key Map の Negative じゃなくて Set Axis Reverse の Reverse でできるよ！」と↑の Issue で教えて頂きました。私がプラグインの仕様を勘違いしてしまっていただけで綺麗に意図した動作を組み込めました😃 ）
↑今回の目的で組むべきだった本来のノードとパラメーター。
A. おまけ、接続したコントローラーの VID, PID の確認の仕方
Windows RawInput プラグインを使う場合に確認が必要となります。
- "Device Manager" の "Human Interface Devices" を展開して HID-compliant game controller を探す
- プロパティーを表示する
- "Details" の "Property" を "Hardware Ids" に変更して
VIDとかPIDっぽい値を確認する
DS4（CUH-ZCT2J）の場合は VID=054C PID=09CC のようです。 VID は Vendor ID 、 PID は Product ID で、それぞれ販売元と製品を一意に認識するための ID です。この番号はデバイスに自由に与えられるものでは無く（野生のUSBデバイスを作ればものとしては作れるけれど）、通常一般的に流通している USB 製品にはすべて割り当てが存在します。DS4でも型式が違えば、PIDが異なる可能性があります。また、Horiのゲームパッドなど販売元が異なるコントローラーではVIDも異なる可能性があります。横着せず、実際に挿したデバイスの VID, PID を調べてから進みましょう。
ゲームエンジンをいじりたいならいいんですが、立派なフレームワークの上でそれほどマイナーでもなかろうゲームコントローラーが標準機能で安心して使えない状況はちょっとショッキングな事態でした。これまでゲームコントローラーの動作試験は XInput のゲームパッドだけで行っていたので気づきませんでしたが、 UE4 に PS4 の DS4 を使いたいというありがち…であろうと思われるニーズで少々苦労があるとは思いもしませんでした。
とりま、動いたのでとりあえずヨシという事にします😃
（はいはいヨシネコさんでいいですよ…DirectInputとかSTEAM Controllerの実装書くモチベーションは特にありませんしー。 ）
今回は katze7514/UEDirectInputPadPlugin の存在に感謝しつつありがたく使わせて頂く事にします。
UE4/C++: DECLARE_DYNAMIC_MULTICAST_DELEGATE_OneParam と TArray
問題
C++ コードの実装に DECLARE_DYNAMIC_MULTICAST_DELEGATE_OneParam マクロを使い、パラメーターに TArray を入れて Delay （Blueprintノード右上に時計マークの出るアレ）を経て結果を処理できる非同期動作のデータのジェネレーターを UE4 の勉強と練習として作ってみました。しかし、不思議な事に C++ ソースコードのコンパイル（ビルド）は完了し、 UE4Editor も動作するのですが、実際にその実装を Blueprint で試すと、 Blueprint がコンパイルエラーとなり使用できない状況に遭遇しました。
// 例えばこんな動的マルチキャストデリゲートを使おうとする。 // このようにパラメーターに TArray を直接入れると Blueprint で使う段階になってから問題が起こる。 DECLARE_DYNAMIC_MULTICAST_DELEGATE_OneParam( FGenerateMyDataDelegate, TArray< uint8 >, MyData );
// ↑を使ったクラスの例 UCLASS() class MyExperimental_API UAsyncTaskGenerateMyData : public UBlueprintAsyncActionBase { GENERATED_UCLASS_BODY() public: UPROPERTY( BlueprintAssignable ) FGenerateMyDataDelegate OnSuccess; UPROPERTY( BlueprintAssignable ) FGenerateMyDataDelegate OnFail; // 実際にはこのクラスを作って投げる機構なども付ける // UE4 標準の AsyncTaskDownloadImage のソースなど参考にするとよい };
Blueprint で発生するエラーは↓のようになる。
LogBlueprint: Error: [Compiler VW0_BP] Generate My Data Signature Error: The function/event 'OnSuccess_C9A93DFE4DF51C0C6C9496873C6AAC62' does not match the necessary signature - has the delegate or function/event changed? LogBlueprint: Error: [Compiler VW0_BP] Generate My Data Signature Error: The function/event 'OnFail_C9A93DFE4DF51C0C6C9496873C6AAC62' does not match the necessary signature - has the delegate or function/event changed?
他の型を与えた場合について
ちなみに、パラメーターに TArray ではなく、代替として次のような USTRUCT ラッパーを定義して与えると Blueprint でもコンパイルエラーが発生せずに意図通り動作する。
USTRUCT( BlueprintType )
struct MyDataWrapper
{ GENERATED_BODY()
TArray< uint8 > MyData;
};
// ラッパーを噛ませたマクロを使うと Blueprint も意図通りに動作可能になる。
DECLARE_DYNAMIC_MULTICAST_DELEGATE_OneParam( FGenerateMyDataDelegate, MyDataWrapper, MyData );
また、 UTexture* など適当なコンポーネント（のポインター）を DECLARE_DYNAMIC_MULTICAST_DELEGATE_OneParam のパラメーターへ与えた場合も Blueprint は意図通り動作する。
解決
// マクロに対して const & でパラメーターを与えれば TArray を使用し、 Blueprint も意図通りに使用可能になる。 DECLARE_DYNAMIC_MULTICAST_DELEGATE_OneParam( FGenerateMyDataDelegate, const TArray<uint8>&, MyData );
なるほどー😃 C++er にはピンと来る答えです。教えて貰う前に気付けるのが真の C++er とか嫌味を言われそうですが、気にしない。
参考
MHW, STEAM: モンスターハンターワールドSTEAM版のユーザー視点からの観測とTips
モンスターハンターワールドのSTEAM版、7月のうちにお布施のつもりで購入してありました😃 お布施のつもり、というのは PS4 版で既にトロフィーをコンプリートしてエンドコンテンツも全て楽しく遊ばせて頂いてしまっている状態で、事前からどうもセーブデータの移行はできないらしいと噂されていたためです。
そんなわけで、改めてPCでやり込むかはさておき、序盤をSTEAM版でしばらくプレイしてみて気づいた事を幾つかメモします。
1 マルチモニター環境での表示モニターの変更方法
最初に困ったのがこれ。横に3つモニターを並べている環境で、右側のモニターがタスクバーの居る1番にしてあるのですが、ゲームや仕事などで中心的な操作対象は真ん中のモニターに出したかったのです。MHWを起動すると案の定モニターの認識上最初のモニターにしてある右側へ画面が出ました。
リアル・フルスクリーン・モードで起動した事には今時は古風で残念なものの、日本のゲーム屋さんが作るウィンドウズのアプリだしなー…とやや諦め気味に思ったものの、これはPCの操作性上好ましい疑似・フルスクリーン・モード（MHWの設定表示ではボーダーレス・ウィンドウ・モード）がコンフィグレーションに用意されており、少し心が安らぎました。
他に、ウィンドウモードもあったので、試しに一度ウィンドウモードで再起動して、それからウィンドウを真ん中のモニターへ移動させて、それからまた疑似フルスクリーンモードへ切り替えて再起動させてあげたところ、疑似フルスクリーンモードで真ん中のモニターで起動させる事に成功しました。
めでたしめでたし。
2 疑似フルスクリーンでの解像度に注意
FHDモードで使用中のモニターへ疑似フルスクリーンモードでモンスターハンターワールドを起動した際にも、内部的なレンダリングの解像度はコンフィグレーションの解像度設定が生きており、モンスターハンターワールドの解像度設定もFHDにしておかないと、「一見するとFHDなのになんか汚い」という状態になってしまいます。汚さですぐに気づきそうなものだけど、これはちょっとした注意どころでした。
https://twitter.com/USAGI_WRP/status/1028318674812198912
↑こういう間抜けな事になります(´・ω・｀)
3 アンチエイリアス効いてなくない？
続けて絵作り設定からアンチエイリアスについて。どうも TAA （一般的に考えればたぶん Temporal-AA ）が実質的に効いていないバグがあるのではないか？という疑問が感じられました（よくよく観察すると効いているっぽい事がわかりましたが…）。
#MHW STEAM版、解像度設定ミスによる汚さはなくなったけれど、 Temporal AA がきいていないのは相変わらずのような。1枚目がTAA、2枚目はFXAA。FXAAはきいてるのがわかる。 pic.twitter.com/JfZvY2UUQA
— デス味（デス・ウェイ）うさぎ // Usagi Ito (@USAGI_WRP) August 11, 2018
↑のツイートより後、この記事を書くにあたり改めて確認してみた絵が↓
こうしてよーくよーく見ると TAA も一応仕事をしている様子。たそもそもこれ、 TAA と表示して TXAA では無いらしい事と、この絵で None と TAA をよく比較して眺めてみた様子からは、 PC ゲームの少なくとも近年の NVIDIA GPU で一般的になった TXAA ではなく独自に Temporarl AA の基礎的な実装をしたものなのかな、という気もします（MHWの元プラットフォームのPS4のGPUはAMDらしいし・ｗ・）。
Temporal AA の基礎的なコンセプト、実装は描画対象のフレームとそれよりも前のフレームをブレンドしてギザギザを隠すもの。スクリーンショットの比較でも、動きの無い掲示板やその張り紙では効果が目視ではわからない状態ですが、常に微妙に動いたりアクションしているオトモの身体や装備に注目すれば AA が効いているように、あるいは寧ろ効きすぎてぼやけてしまっている程の部分に気づきます。静止したオブジェクトやシーンでは None と違いが少なくとも目視では無く、動く部分もボケすぎる心配もあるモンスターハンターワールドの TAA は AA を設定するユーザーの求める絵作りに対しては中途半端で微妙かな、と個人の感想としては思います。
一方、 FXAA は一般的な FXAA で全体に綺麗な AA 処理がされていて、 AA を設定するユーザーにとっては目的に適った絵ができているように見えます。モンスターハンターワールドでは半透明の描画はディザリングで代替されている様子なので、半透明処理の工夫や相性と AA の組み合わせによっては汚い絵ができてしまう懸念もありませんし、モンスターハンターワールドで AA が欲しいユーザーは FXAA を使うのが良いのかな、と個人の感想としては思います。
4 操作関連あれこれ
4-A プレイ開始からしばらくカメラがリバース問題
どうしようもないので、リバースのまましばらく耐えて進めましょう…。モンスターハンターワールドのカメラの回転の初期設定、順方向は FPS 視点が基準になっています。このゲームには FPS モードは無くて基本的に常に TPS なんですけどね😅 そして、ゲーム開始からムービーシーンと接続して操作可能になる最初のプレイアブルシーンではコンフィグを開けません💀 しばらく進めるとコンフィグのボタンも反応するようになるので、それまでどうにか耐えて進みましょう。
4-A-Appendix ここでちょっと FPS / TPS カメラと 順方向 / 逆方向 のだそく
ちなみに、 FPS 視点基準と表現したカメラ操作は、プレイヤーが「右っぽいボタン（レバー）」を操作すると視点（カメラ≃目玉のある位置）は動かずに注視点（見つめる場所、≃視線）が「右側」へ移動します。これは FPS としては自然な順方向でしょう。
一方、 TPS 視点基準では、カメラ（≃プレイヤーキャラクターを俯瞰・衛星軌道的で捉える第三者の視点≠プレイヤーキャラクターの目玉の位置）を操作するのであって、仮にプレイヤーキャラクターの視線を操作しても、シーンの中でプレイヤーキャラクターが目玉や首や場合によっては身体の向きを変えるだけで、 TPS 視点におけるプレイヤーキャラクターを含めたシーンの視錐台は変わりません。プレイヤーが操作するカメラはプレイヤーキャラクターの目ではなく、プレイヤーキャラクターを捉えるドローンカメラの位置を操作する事になります（一般的にはプレイヤーキャラクターを原点とした経度・緯度・高度からなる極座標系で周るように操作できるようにする）。そうすると、 TPS を基準とした順方向の操作結果は FPS で注視点を回すのとは逆向きになります。「右っぽいボタン（レバー）」を操作するとプレイヤーを捉えるカメラの緯度を右側へ回す事になるので、これは一般的にプレイヤーを背後から捉えている状態を基準に考えると、「画面（視線）は左側へ回っていく」ことになります。つまり、 FPS 操作の操作方向と結果画面の動く方向と TPS のそれはこういう理屈では逆転（リバース）します。あくまでもこういう理屈では。
しかし、読んでくれている方の中にも「いやいや…」と思う方も少なからずいらっしゃるはず。プレイヤーによってはこうした理屈とは異なる反応を脳が学習・示す事も少なくはなく発生するらしく、人によっては同じゲームで FPS と TPS の両方を切り替えて操作するようなものであれ、「常に」結果の画面の移動方向がレバーを操作する方向と同じ（あるいは逆転）にならないと脳が混乱してしまう、という事も起こります。FPS でも TPS でも操作ではなく「結果画面の動く方向」を FPS 基準または TPS 基準のどちらかに固定しないと頭痛で楽しくプレイできない、という方たちがそのタイプ。
加えて複雑な事に、私にも理屈はわからないのですが、上下、左右で順方向と逆方向を個別に異なる設定にしないと頭痛が…という方も少なくなくいらっしゃるようです。いぜん、少数ながら複数の友人に確認してみても人それぞれかなりばらつきがありました…。
世の中には、
- FPS ならレバーの操作方向は視線の操作方向、 TPS ならレバーのの操作方向は背後から捉えるカメラの操作方向（ FPS でも TPS でも画面ではなく操作対象は何かで視錐台の変化を捉える人）
- FPS でも TPS でもレバーの操作方向は結果画面の順操作方向（画面が TPS でも脳は FPS で捉える人）
- FPS でも TPS でもレバーの操作方向は結果画面の逆操作方向（画面が FPS でも脳は TPS で捉える人）
の3つのパターン＋(1),(2),(3)を上下方向と左右方向で独立して異なる組み合わせで捉える人たち、さらにもしかしたらこれも理屈はわかりませんが(1)の逆の操作パターンが脳にしっくりくる人もいるかもしれません。私は(1)タイプで、他の操作系では数秒で強い頭痛、目眩、吐き気などでゲームプレイどころではなくなってしまいます…。たぶん、他のパターンの人たちも別の操作パターンでは程度の違いこそあれそういった症状がでる人が多いかと思います。
3Dアプリ作る時に、いつもどうデフォルトにするか、どうコンフィグレーションを付けるか、悩みます。特に、ユーザー層がゲーマーならどうデフォルトにしてもコンフィグを付けておけばOKなんですが、非ゲーマー向けだと違和感が生じる人への説明と設定方法も工夫が必要で、こうして文章で説明どころか図解してもなかなか話が通じません…、そしてどうコンフィグレーションすればあなたにピッタリの操作感になるかもしれないので設定してみてくれ…というのも説明が難しいという💀 ソフトウェア開発者ですら、かつ日常的にゲームを楽しんでいるはずの人を相手にしても、これを説明するのには非常に大変な事もあります💀💀
とりあえず、せめて、ゲームプレイ開始前にコンフィグできるようにお願いします💀💀💀
4-B キーボードとマウスの操作があばばばば
わかりやすい動画が STEAM のレビューに貼ってあったので↓参考
この問題、キーボードとマウスで操作する派にWASDを諦めろ！というのはたいへん酷なはなしなので（先のカメラ設定の感覚くらい脳に染み込んでいる人も多いハズ…）、私なりの解消アドバイスとしては、
- 「W」「A」「S」「D」 はそのまま
- 「マウス右」に「エイム（元V）」を変更
- 「SPACE」 に「特殊攻撃（元マウス右、調べるその他超複合ボタン）」を変更
- 「X」 に 「しゃがむ（元SPACE）」を変更
- 「SHIFT」に「リロード（元R）」を変更
- 「CTRL」に「ダッシュ（元SHIFT）」を変更
- 「V」に「武器を構える（元CTRL）」を変更（これは元々「マウス左」も割り当てられているので、キーは念の為に一応割り当てた程度）
私はWASDについて、Aを薬指、WSを中指、Dを人差し指で操作しています。そのため、リロードがRのままだと右へ移動しながらリロードできません。同様にR+SPACEでボウガンの近接攻撃も右移動と同時に動作できません。そこで、SPACEの親指とも同時押ししやすく、WASDで使用しない小指だけで移動しながらでも押せるキーとして、SHIFTへリロードを変更しています。これはSHIFTではなくCTRLでも操作しやすいかもしれません。この影響を受けつつも、元SHIFTのダッシュもWASDと同時に押せないと意味が無いのでCTRLへダッシュを変更しています。
これで起爆竜弾、ボウガン殴り、竜の一矢（実用する事があるかはさておき）など、比較的激しいアクションを要求されるモンスターハンターワールドでもWASD移動と同時に使える設定になったと思います。（序盤の任務プレイとトレーニングルームで検討した程度なので、ラスボスさんやその後までプレイしたらもっと別の上手い設定が欲しくなるかもしれませんが、とりあえず、ということで。）
4-C そもそもマウス操作の応答に大きめのディレイが生じる
マウス（あるいは任意のポインティングデバイス）の位置を操作したら、画面のカーソルの位置が倍率はともかく操作どおりに応答してくれる。ふつー、そう思うじゃないですか・ｗ・ モンスターハンターワールドでは謎のディレイが体感ですが恐らく数十ミリ秒単位で入ってマウス操作にカーソル位置がディレイして適用されます。
感覚的にしんどいのでマウス操作は私には無理ですね😅
これは…諦めました💀
エイム時には1フレームかせいぜい数フレーム程度のディレイに感じられたので、戦闘中に問題になる事はなさそうですが、メニューや装備変更などマウス操作する際にはいらいらしそうです…。
5. PS4と・・・
無理です諦めましょう。
PS4とセーブデータを移行する手段は少なくとも公式には存在しません（セーブデータの解析からツールを作ればある程度はできそうな予感はしますが、MOかつ他のプレイヤーに影響する事はまず無かろうとは言え、何かと問題の引き金になりかねないので健全なプレイヤーは考えない方が良いでしょう）😭
また、マルチプレイのマッチングもSTEAM版はSTEAM版のプレイヤー同士のみで、PS4版のプレイヤーとは一緒に遊べないようです。これはもう、本当にどうしようもないので諦めましょう😭
さておき
と、問題と対応方法を並べてみましたが、モンスターハンターワールドはゲームとしてはよくできたコンテンツを十分に楽しめる良作と私は思います。STEAM版ではPS4版よりも綺麗な見栄えでプレイできますし、キーボードの存在を前提にした使いやすさはゲームパッドを主として使用するプレイヤーにも恩恵があります。スクリーンショットや動画の撮影と共有のためにわざわざシステムメニューを介在してちまちま操作する必要もなく、Twitterへの共有などもコピー、ウィンドウ切り替え、ペースト、ポストだけでできてPS4よりもテンポよく処理できます。低性能ではないWindowsのPCを使える方で、モンスターハンターワールド未プレイの方、興味があればSTEAM版をぜひ楽しんで欲しいなとおすすめします。
私の中でのモンスターハンターワールドのゲームとしての総合評価は☆5満点で☆4です。少なくともエンディングまでのストーリーと付随するフリークエストなどはとても楽しいし、音楽も世界観にあったよいものに感じています。エンドコンテンツややりこみ要素については一概におすすめできませんが、少なくともPS4版ではHR360、トロフィーのコンプリート、これまでのすべての追加モンスターを私は楽しみました。そろそろどうかなーとは思いますが、それでも4ヶ月間楽しませて貰えた良作です。お値段もSTEAM版にせよ、PS4版にせよ、ずいぶん公式価格で安くなりましたしね。ゲームとしておすすめな事は確かです。
さて、それでは改めまして、一狩り行きましょうか😃
rust, windows: crate gdal を windows, vscode 環境で使用可能にするメモ
こんかい使えるようにする対象物
- Rust crates.io gdal https://crates.io/crates/gdal
- GDAL https://gdal.org/
crate gdal は内部的に元のGDAL（の動的リンクライブラリー）を呼びつけて GeoJSON を読んだりできるラッパータイプのライブラリー。 extern crate gdal だけでは使えないので使える状態にするメモを残す。
extern crate gdal なプロジェクトをビルド・実行可能にする手順
1. myapp プロジェクトを用意、 crate gdal を取り込む
cargo new myappcd myappcargo add gdal(note: https://github.com/killercup/cargo-edit )- main.rs を↓のように gdalのdocs冒頭のサンプルなど参考に動作確認程度に用意します。
cargo buildを試す (この段階では失敗しますがエラーメッセージを読むとなんでかわかります。この後のメモで解決するための作業を記します。)
extern crate gdal; use std::path::Path; use gdal::vector::Dataset; fn main() { println!( "[start]" ); let mut dataset = Dataset::open(Path::new( "sample1.geojson" ) ).unwrap(); let layer = dataset.layer( 0 ).unwrap(); for feature in layer.features() { let geometry = feature.geometry(); println!( "{}", geometry.wkt().unwrap() ); } println!( "[end]" ); }
2. vscode の Task として crate gdal をビルド可能にする
2.1. GDAL の動的リンクライブラリーを用意する
2.1.1. vcpkg を用意
いくつか方法があります。このメモでは vcpkg を使う方法を採用します。vcpkg はシステムレベルではなくユーザーディレクトリーレベルでの使用を前提に設計されているようです。適当な場所に用意します。
Super(Win)+R->powershell(note: mingw/mintty などから powershell を起動するとインストールスクリプトがまともに動作しない可能性があります。)cd %USERPROFILE%mkdir optcd optgit clone https://github.com/Microsoft/vcpkg.git( git が使えませんとかはこのメモでは解説の範囲外という事にします。必要ならぐぐってください。 )cd vcpkg.\bootstrap-vcpkg.bat- Windows の環境変数に
VCPKG_DEFAULT_TRIPLET=x64-windowsを追加しておく。(x64にしたくない場合は設定しないとか、実行ごとにパラメーターを付ける方法とかもあります。必要なら適当に調べてください。参考)
これで vcpkg.exe が生成されるので、必要ならパスを通すとか、alias を用意して使いやすくするとかしておきます。また、 Visual Studio で C++ プロジェクトから簡単に vcpkg を使用できるようにしたければ vcpkg integrate install などもREADME を参考にしておきますが、さしあたり今回メモの用途としてはどうでもいいです。
2.1.2. vcpkg で GDAL と依存ライブラリーを芋蔓に用意する
vcpkg install gdal- 最大で118個のパッケージをダウンロード、ビルドされるのを待つ。長い時間が必要なので1時間くらいゲームなどしてくるとよいかもしれない。
これで vcpkg を配置したディレクトリーへ installed\x64-windows ができて、その中に include lib bin などプログラマーならわかるな？的なディレクトリーも作られ、インストールを叩いたパッケージと芋蔓されたパッケージの全てのそんなようなものが入っています。
3. extern crate gdal している myapp プロジェクトをビルドできるようにする
- tasks.json を↓な具合に調整。大事なところは
envで設定している crate gdal が内部的で依存している gdal-sys のビルド時に要求されるGDAL_HOMEGDAL_INCLUDE_DIRGDAL_LIB_DIRの3つの環境変数群です。%USERPROFILE%など環境変数の展開は機能しなかったので vcpkg のパスを地味に書きます。実際に入れたパスへ読み替えて下さい。 - vcpkg で生成した lib に入っている gdal.lib を gdal_i.lib としてコピーしておく。（crate gdal の中の gdal-sys のビルドの要求でそのようになっているので、こうしておくのが手っ取り早い。）
{ "version": "2.0.0" , "tasks": [ , { "label": "cargo build debug" , "type":"shell" , "command": "cargo" , "args": [ "build" ] , "group": { "kind": "build" , "isDefault": true } , "problemMatcher": "$rustc" , "presentation": { "panel": "new" } , "options": { "env": { "GDAL_HOME": "C:\\Users\\your_name\\opt\\vcpkg\\installed\\x64-windows" , "GDAL_INCLUDE_DIR": "C:\\Users\\your_name\\opt\\vcpkg\\installed\\x64-windows\\include" , "GDAL_LIB_DIR": "C:\\Users\\your_name\\opt\\vcpkg\\installed\\x64-windows\\lib" } } } ] }
これで myapp のビルドは完了できるようになります。一応。しかしまだ、実行できません。
4. myapp を実行可能にする
- vcpkg の install で生成した
binの中には↓の実行時リンク用のライブラリーファイルが格納されているので、全て myapp の target/debug/myapp.exe と同じディレクトリーへコピーしましょう。なお、ライブラリーのファイル名は実行環境や実行時のパッケージに定義されているライブラリーのバージョン等により異なります。
boost_atomic-vc141-mt-x64-1_67.dll boost_math_tr1l-vc141-mt-x64-1_67.dll geos_c.dll libpq.dll boost_chrono-vc141-mt-x64-1_67.dll boost_prg_exec_monitor-vc141-mt-x64-1_67.dll icudt61.dll libxml2.dll boost_container-vc141-mt-x64-1_67.dll boost_random-vc141-mt-x64-1_67.dll icuin61.dll lz4.dll boost_date_time-vc141-mt-x64-1_67.dll boost_regex-vc141-mt-x64-1_67.dll icuio61.dll lzma.dll boost_filesystem-vc141-mt-x64-1_67.dll boost_serialization-vc141-mt-x64-1_67.dll icutu61.dll openjp2.dll boost_graph-vc141-mt-x64-1_67.dll boost_system-vc141-mt-x64-1_67.dll icuuc61.dll proj_4_9.dll boost_iostreams-vc141-mt-x32-1_67.dll boost_thread-vc141-mt-x64-1_67.dll libbz2.dll sqlite3.dll boost_locale-vc141-mt-x64-1_67.dll boost_timer-vc141-mt-x64-1_67.dll libcharset.dll ssleay32.dll boost_math_c99-vc141-mt-x64-1_67.dll boost_unit_test_framework-vc141-mt-x64-1_67.dll libcurl.dll webp.dll boost_math_c99f-vc141-mt-x64-1_67.dll boost_wserialization-vc141-mt-x64-1_67.dll libeay32.dll webpdecoder.dll boost_math_c99l-vc141-mt-x64-1_67.dll expat.dll libiconv.dll webpdemux.dll boost_math_tr1-vc141-mt-x64-1_67.dll gdal203.dll libmysql.dll webpmux.dll boost_math_tr1f-vc141-mt-x64-1_67.dll geos.dll libpng16.dll zlib1.dll
これでビルドした myapp.exe は実行可能です。（データが無ければ panic して動作確認できませんが。）
5. 動作確認用の GeoJSON データを用意して動作確認する
- https://github.com/gsi-cyberjapan/geojson-with-style-spec/blob/gh-pages/sample1.geojson など適当に GeoJSON を入手するなり手書きするなりして myapp.exe と同じディレクトリーまたはソースコードでパスを指定した場所と併せて配置します。
- デバッグ実行なり、直接 myapp.exe を叩くなりして動作確認しましょう。
おつかれさまでした😃
だそく
もし、vcpkg による install や、それによって生成あるいは他の手法であれ確保した実行時ライブラリーファイル群のコピーを自動化したい場合には Cargo.toml には残念ながらそのような依存ファイルのコピー機能は無さそうなので、 vscode の tasks.json で制御すると良さそうです。
あんまり美しくないので積極的に使いたいライブラリーとは言い難いところはありますが、他の手段ではなく GDAL を rust から使いたい場合には有用かもしれません。
