2026:08:11
差分
このページの2つのバージョン間の差分を表示します。
| 両方とも前のリビジョン前のリビジョン次のリビジョン | 前のリビジョン | ||
| 2026:08:11 [2026/08/11 19:57] – machiaworx | 2026:08:11 [2026/08/12 03:34] (現在) – machiaworx | ||
|---|---|---|---|
| 行 24: | 行 24: | ||
| * あとモーション同士の補間が必要になってくるわけで、これをどうやって補間するのかという問題もある。 | * あとモーション同士の補間が必要になってくるわけで、これをどうやって補間するのかという問題もある。 | ||
| * ただこれができれば、同じモーションで別の攻撃みたいな事もできる。 | * ただこれができれば、同じモーションで別の攻撃みたいな事もできる。 | ||
| - | * また、モーションを別途並べかえてフェイント攻撃みたいなこともできる。そこまで必要かは置いておいて。 | + | * また、モーションを別途並べかえてフェイントかけて攻撃みたいなこともできる。そこまで必要かは置いておいて。 |
| ---- | ---- | ||
| 行 46: | 行 46: | ||
| * これができればゲームも量産しやすくなるはず。 | * これができればゲームも量産しやすくなるはず。 | ||
| - | * 元々仕事の関係上ゲームを短時間で作りやすくするフレームワークを作りたい、という目標を建てているので、今のやつでもだいぶ楽ではあるけど、上記項目が解決できれば更に楽になるという考え。 | + | * 元々仕事の都合上ゲームを短時間で作りやすくするフレームワークを作りたい、という目標を建てているので、今のやつでもだいぶ楽ではあるけど、上記項目が解決できれば更に楽になるという考え。 |
| ===== プログラム ===== | ===== プログラム ===== | ||
| 行 61: | 行 61: | ||
| * MiniScriptは正直使い慣れてる言語ではある。2の正式リリースももうすぐの模様。2になって全体的な速度の向上、コンパイル後の言語を読み込み可能になっているため、今より速度が上がるのは間違いない状態。 | * MiniScriptは正直使い慣れてる言語ではある。2の正式リリースももうすぐの模様。2になって全体的な速度の向上、コンパイル後の言語を読み込み可能になっているため、今より速度が上がるのは間違いない状態。 | ||
| * Quirrelは元はSquirrelというLuaからの派生言語（LuaをもうちょっとC言語寄りにしたやつ）。元々LuaではなくSquirrelをちょくちょく使っていたこともあり、こっちを使いたい気持ちもある。過去にはWiiのFFシリーズにつかわれてたっぽいね。 | * Quirrelは元はSquirrelというLuaからの派生言語（LuaをもうちょっとC言語寄りにしたやつ）。元々LuaではなくSquirrelをちょくちょく使っていたこともあり、こっちを使いたい気持ちもある。過去にはWiiのFFシリーズにつかわれてたっぽいね。 | ||
| - | * umkaはレイトレーシングとかにも使えるくらい早いスクリプト言語。あとゲーム用のライブラリもあるので、これ使ってゲーム開発が可能。 | + | * umkaは（リアルタイムではないにせよ）レイトレーシングにも使えるくらい処理速度が早いスクリプト言語。あとゲーム用のライブラリもあるので、これ使ってゲーム開発が可能。 |
| * PocketLangは今ほとんど更新されてないけど、メモリ観点での最適化が行われている言語なので、こっち使うのもひとつかなーと思ったりする。言語もクセがないし。 | * PocketLangは今ほとんど更新されてないけど、メモリ観点での最適化が行われている言語なので、こっち使うのもひとつかなーと思ったりする。言語もクセがないし。 | ||
| * PocketPyはPython3.xの仕様が1個のヘッダーにまとまったもの。アプリに組み込むなら公式よりこっちがいいとのこと。 | * PocketPyはPython3.xの仕様が1個のヘッダーにまとまったもの。アプリに組み込むなら公式よりこっちがいいとのこと。 | ||
| * Luaはおなじみの組み込み言語。ただ正直バインダを書くのが辛いのです。 | * Luaはおなじみの組み込み言語。ただ正直バインダを書くのが辛いのです。 | ||
| + | |||
| + | ---- | ||
| + | * あとはGodotEngineで使われているGDScript。 | ||
| + | * Godotを使うのを前提にするため、高速化の手法が他と違う可能性があるし、ベース部分からして実装しなきゃいけないので最適化の範囲も違う。 | ||
| + | |||
| + | ---- | ||
| + | * これはどちらかというとベース部分の実装の最適化ではあるけど。 | ||
| + | * スクリプトがPythonに似ているのもあるためか、配列へのアクセスが遅い（インデックス化を頻繁に行うせい）よう。弾幕STG作るのにあまりよろしくない。 | ||
| + | * そのためにPackedVector2Arrayのような専用設計の配列を使うことになる。 | ||
| + | * https:// | ||
| + | * 別のページでは削除新規を毎度行っていくサンプルを記載していたが、新規削除にするとメモリを再確保することになり、キャッシュミスは防げるけど、メモリが似たような位置にあるか？と言われると怪しい部分ある。SOAとして扱う意味ある？とも思うし。 | ||
| + | * ということでシーンの開始時に確保して、削除したものも再利用していく使い方になりそう。 | ||
| + | * ゼロクリアすれば再利用できるし、別の配列で空き状態を管理する必要が出てくるだろう。（Unityベースでも似たようなことしてる） | ||
| + | * こんな風に最適化はできそうだけど、まだノウハウがたまってないので、GDScriptで全部作り直しも視野にいれるかなー。 | ||
| + | * ちなみに細かいところだけど、GDScriptはホットリロードもやりやすく、デバッグ中に更新しても動きが反映される。だいぶ楽。 | ||
| + | |||
| + | ---- | ||
| + | * ほう。SIMD使う実例ねえ。なんか珍しいと言うか。 | ||
| + | * https:// | ||
| + | * 正直SIMDまわりはあまり実例ないし助かる。 | ||
2026/08/11.1786445828.txt.gz · 最終更新: 2026/08/11 19:57 by machiaworx