見出し画像

MGL週報 #73 - 今週の作業、Steam Deckようやく購入など

このエントリはゲーム開発用フレームワーク「MGL」の開発記録です。MGLはzlibライセンスの下に無償で提供されています。


今週の作業

gcc(g++)でコンパイルに失敗する問題

解決方法については先週書いた通りです。とりあえずビルドが通る事の確認に加え、その状態で他のプラットフォーム上での動作に影響が無いことも軽くチェックしておきました。当のgccでビルドしたバイナリがちゃんと動作するかは確認できていませんが、これは現時点での環境では確認が難しいため、今後の課題としておきます。

また、先週書き忘れていたのですが、gcc対応絡みで文字列フォーマットにおける値の種類と型の関係性に変化が生じています。

↓現状はこちら。

MGL 1.1.13までのフォーマット引数は「この型はこの種類の値」みたいな感じで処理していましたが、この部分をテンプレート化して処理するようにしました。したがって、MGL 1.1.14以降は次のようなルールが適用されます。

  • 整数型

    • 符号付き → 符号付き整数(64ビットまで)

    • 符号なし → 符号なし整数(64ビットまで)

  • 浮動小数点数型 → 小数点数

  • bool型 → 論理値

  • MGL::STL::string型 → 文字列

  • const char *に変換可能な型 → 文字列

  • 上記以外のポインタ型 → アドレス

このルールを上から順にチェックして、最初に適合するものが値の種類として決定されます。

大きく変わる部分はというと、暗黙的にconst char *型に変換可能なクラスは全て文字列として指定できるようになります。例えば1.1.8で追加されたMGL::File::Pathなどは、実装と同時に文字列として認識する型として手動で対応していましたが、今後はこういった対応は不要になります。

これはアプリケーション側で定義したクラスも同じで、そのクラスにconst char *型へキャストするオペレータを定義することで、MGL側の対応無しにフォーマット引数へと指定できるようになります。

これを対応した理由としては、int*_t や uint*_tなどの組み込みでない型の定義が環境によってまちまちで、場合によっては定義が重複してしまうためです。テンプレート化は前々から行いたかった事だったので、これを機に変更を加えることにしました。

Windows向けコードのリファクタリング

前回の大規模リファクタリングから諸般の事情で漏れていた、Windows固有のソースコードにclang-tidyのチェックを掛けての対応です。これは表向きの動作に影響は無いし、インターフェースへの影響もありません。

これといって話題に挙げるような内容でもないのですが、1点気付いた事として、Visual Studio 2022ではプロジェクト設定が2019(v142)のままだとclang-tidyが正常に動作しないようです。多分何かしら解決策はありそうですが、MGLに限って言えば構成プロパティの「プラットフォーム ツールセット」を「Visual Studio 2022(v143)」に変更してしまうのが手っ取り早い解決方法です。この設定は最初にプロジェクトを開く際に変換するか聞かれるため、素直に従っておきましょう。


Steam Deckようやく購入

前々から開発用に1台欲しいと思っていたSteam Deckをようやく入手しました。日本だといつ確認しても売り切れ状態でしたが、今回の在庫は潤沢のようですね。

Steam Deck OLED 1TBモデル

まだ昨日届いたばかりなのであまり検証できていないのですが、ちょっと触ってみた限り、動作検証だけではなく開発そのものも行えるかもと感じています。その理由は次の通り。

  • システム部分は読み込み専用だけど、コンテナ化されたアプリケーションの追加は可能(読み込み専用は簡単に解除できるけど、システム部分の構成を変えたら検証用マシンとしての価値が薄れる)

  • ホームディレクトリ以下の読み書きは自由に可能

  • podmanがプリインストールされていて、SteamOS向けのSDKのコンテナイメージも公開されている(要するに、ビルド環境が簡単に導入可能)

  • ついでにDistroboxもプリインストールされているらしい

MGLはまだLinuxに対応していませんが、SDKのコンテナイメージの中身を見渡した限り、対応に必要そうなライブラリは一通り揃っているという印象です。つまり、これを元にバックエンド一式を揃えてしまえば、Steam Deck単体でのゲーム開発も可能だよね? と思った次第。

もちろん、実際には環境構築やスペック等の問題もあるので開発用マシンを別途用意するのが理想です。とは言え、このお手軽さにはちょっと惹かれるものがありますね。gccでもコンパイルが通るようになった事だし、Linux対応にも本腰を入れる頃合いでしょうか。

……と、ついでにこちらも購入。

高かった(7,700円)

今からLinux向けのゲームをネイティブに書くならVulkanは必須でしょうし、将来対応したいAndroidにも関わってきますからね。


その他

ここ1ヶ月ほどの出費で懐が痛い。

いいなと思ったら応援しよう!