差分

このページの2つのバージョン間の差分を表示します。

--- 2026:11:14 [2026/11/14 17:01] – machiaworx
+++ 2026:11:14 [2026/11/15 09:06] (現在) – machiaworx
@@ 行 2: / 行 2: @@
 ===== ゲーム開発 =====
-  * フレームワーク作り直すの構わないんだけど、やるとするとCryPic.リリース後だなあと思った。
+  * 今ゲーム開発で使っているフレームワークを改修、もしくは作り直すことを検討中。
+  * ただ、やるとするとCryPic.リリース後だなあと思った。
 ----
-  * 作り直し案はいくつかあって、以下を検討中。
+  * 案はいくつかあって、以下を検討中。
-  -Unityでできてるフレームワーク作り直し（修正箇所はほぼ決め打ち可能
+  -Unityでできてるフレームワーク機能改修（修正内容はある程度まとめている
-  -MonoGameで作り直し（ゲーム部分はUnityから移植ができそうだが、リソース読み込み等は新規作成
+  -MonoGameで作り直し（ゲーム部分はUnityから移植ができそうだが、メニューやリソース読み込み等は新規作成
   -Godotで作り直し（実装からやり直し
   -DXライブラリで作り直し（実装からやり直し
 ----
-  * １．についてはすぐ動く。むしろ適当に改修してもいい。現状はリソースの持ち方とプログラムの関連性に問題があるだけなので、プログラムの改修ではなく最低限リソース再配置だけで動くのはメリット。
+  * １．についてはそれほど時間かけずに検証できるのがメリット。むしろ適当に改修してもいい。現状はリソースの持ち方とプログラムの関連性に問題があるだけなので、プログラムの改修ではなく最低限リソース再配置だけで動く。
-  * ２．については一番有用な選択肢。もともとUnityに依存しない（引き剥がしやすい）形で実装してあるので、ゲーム部分は楽に移植できそう。ただリソース周りは実装しなおしのため、そこにどんだけ時間をかけられるかがポイントだと思う。
+  * ２．については１．以外だと一番有用な選択肢。もともとUnityに依存しない（引き剥がしやすい）形で実装してあるので、ゲーム部分は楽に移植できそう。ただリソース周りは実装しなおしのため、そこにどんだけ時間をかけられるかがポイントだと思う。
-  * ３．は１．と再度同じことする。できはするんだけど、結構Unityの上で動かすのを面倒なことしていたのもあって、あまりやる気にならない。ある程度リソースの持ち方も検証したんだけど、シーンごとに管理するのが面倒そうでどうしたもんか。
+  * ３．は１．と再度同じことする。ただ、元々Unityの上で動かすのに面倒なことしていたのもあって、現状やる気にならない。リソースの持ち方も検証したんだけど、シーンごとに管理するのが面倒そうでどうしたもんか。
-  * 少なくとも、あまり期待できない移植のためにゲームエンジンの上で独自フレームワーク動かすというのは、リソースの扱いが便利な面もあるけど実装そのものが面倒かつトリッキーになるのがわかったので、もう一回はやる気がしない。それであれば２．か４．を選ぶ。
+  * 少なくとも、あまり期待できない移植のためにゲームエンジンの上で独自フレームワーク動かすというのは、リソースの扱いが便利な面もあるけど実装そのものが面倒かつトリッキーになるのはわかっており、もう一回はやる気がしない。それであれば２．か４．を選ぶ。
-  * ４．は最後の選択肢って感じ。実装自体はできるけど、全部実装しなおしになるので。しかもC言語で。
+  * ４．は最後の選択肢って感じ。実装自体はできるけど、全部実装しなおしになるので。でもやるとしたら前提になる動作を考えなくていいだけあって楽ではあるんだよね。少なくとも既存ゲームエンジン上で動かすのと比較すると楽。
-  * C言語自体はメガデモ作るときも書くし音楽ツール作るときも書くので言語の習熟度合いに問題はないんだけど。
+  * C言語自体はメガデモ作るときも書くし音楽ツール作るときも書くので言語の習熟度合いに問題ないし。
 ----
-  * いずれも動くものを移植するのに手間かからなさそうだが、リソースの仕組みが違うので要新規作成
+  * UnityからGodotに移行してすぐ動かせるかというと全然動かせないんだよね。
+  * 基本的な考えは１．にして、あとは２．で実装しなおしを検討かなあ。MonoGameは英語しか資料がないけど、翻訳駆使すれば問題なかろと思ってる。
+===== カメラ =====
+  * https://www.cosina.co.jp/voigtlander/vm-mount/nokton-classic-35mm-f1-4-ii/
+  * 買った。レンズの表現としては「柔らかめ」という言い方が適切。
+  * 現在使っているレンズとは真逆の映り方しているので、使い分けができるかと思った。
+----
+  * フォーカス合わせはマニュアルフォーカスだけどガイドを使えば問題ない
+  * ただ、手ブレ補正ができない。
+  * 今確認したら使っているカメラ（R50V）は「レンズに」手振れ補正機能が入っている模様。すなわちこのレンズは手ブレ補正されない。
+  * とはいうものの、すごい映りがいいし柔らかさがあって撮ってて割と絵を作ってる感があり、通常の記録用途とはまた違うアプローチができる。これを使わない手はないなと思った。
+  * そもそも枚数を大量に撮って絵作りを選定するアプローチもある。数を撮ればいつかは手ブレなしのものにあたる考えで撮るとよさそう。
+  * 記録の保持を目的として撮るなら純正パンケーキカメラで、適当に撮るときや絵作りの一環で撮るなら当該レンズでいいと思った。
+  * ほぼ単焦点で撮るなかなかの縛りプレイをすることになりそう。
+----
+  * あと絞り値の扱いについて。
+  * 1.4にすると映りがだいぶ変わるみたいなので使うとして、1.4以外の範囲をどうやって使っていくかが問題。
+  * ただ絞り値を上げるとカメラがBusy状態になるのもあって、R50Vで撮影する場合絞り値を上げて撮影するのには向いてない。
+  * 撮影を試してみて、瞬間的に撮影が成立する上限は5.6かそれより下くらいだと思った。
+  * 上記を踏まえて撮影していくのが良さそう。
 ===== プログラム =====
@@ 行 29: / 行 51: @@
   * https://docs.unity3d.com/ja/Packages/com.unity.addressables@1.20/manual/SynchronousAddressables.html
   * Addressablesを使わなかった理由のひとつが「同期読み込みができない」ことだったんだけど、これなら使ってみても良さそう。
-  * 特にCryPic.フレームワークはあえて非同期で処理しないことにしているので、非同期処理がコア部分に関わると厄介なのですよ。
+  * 特にCryPic.フレームワークはあえて非同期で処理しないことにしているので、非同期処理がコア部分に関わると厄介なので、いままで使ってなかったのね。
   * 今までバタバタして調べきれてなかったため、今更調べてたどり着いたという状態。
-  *
+  * これなら使ってもよさそう。
 ===== 音楽 =====
   * https://it-dummkopfen.itch.io/c64-groovegoat
   * これ使ってみようかしら。