■ ゲーム製作技術板雑談スレ03
2Dシューティング作ってます。
少し変化を付けようと、ボスをBlenderで作ってプリレンダ加工で使おうとしたら、いやぁまあそれなりの精度を確保しようとするとパターン数が青天井で目眩がしてきます。なんてアホな仕様を決定してしまったんだ・・・。
基本設計を完全2Dで施してあるので3Dを混ぜ込むことも出来ないし、そもそも基礎知識すら欠ける状態で3Dを利用するのも無理なので、データを減らす工夫だけで乗り切ろう・・・ここに仮アップして意見聞こうと思ったけど、現状で500MB超えだからなあ・・・。 >>90
テクスチャの圧縮が使えるなら、4分の1とかにできたりするけど、圧縮するとスプライトがすこし汚くなるんだよな
あとはファイルのフォーマットを色数の少ないものに変えるとか、
他にはちょっと大変だけど、一枚絵じゃなくいくつかのパーツに分けてアニメさせるとか 他人のエンジン使ってない人は、最初に必要となるヒープメモリを大容量確保して、ゲームアプリ起動中のnew/delete時に確保したメモリ領域を管理して、ゲーム終了時に一括開放する機構を実装してるのかな
最初にメモリ不足を検知できて、ゲーム起動中はOS場でのメモリ占有が約束されて、断片化もある程度制御できるから、実装するに越したことはないだろうが
最近の非ゲームアプリだと、コンポーネント生成が必要となったときに、その都度必要な分だけOSから確保するような設計になってるのが多い様な気もするんだが 基幹部分を組み直そうとすると、「できるだけ簡潔に」「できるだけ結合度を低く」みたいな意識が強く働いて、ちょっとの機能なのに思った様に進捗が進まん
昔に作った資産（と呼べるかどうかはともかく）の再利用にも時間が掛かる >>94
でもそれやらないと昔の資産の使い方が思い出しにくかったりしない？ >>95
過去資産を再実装するより思い出す方が早いけど、過去資産を結合度の弱い独立ライブラリとして切り出す作業が重い
各種リソース管理が組み合わさる比較的表層の処理（描画など）も簡潔に切り出したいが、もうプロトタイプ実装で済ませて後で考えるかｗ 「やりたくないこと（＝ライブラリのリファクタ）は後回し！」にしたら目に見える成果が増えていって、今の所「アレ」の再開発楽しいわ 下僕のやっかみ憐れ
しかも過疎版の埋没スレでかよｗ とりあえずアレのライブラリ化作業は完了したが、ジオメトリの形状の種類を増やしたいところ
そのネタだけでもゲームを作れそうだが、折角なのでついでにポータル窓も実装したい なるべく最小限かつ簡潔を心掛けてるつもりなんだが、いつの間にかアホみたいにクラスが増えてやがる
しかも一生、一次元配列を操作するコードばかり書いてるし、描画系ライブラリの詠唱ステップが１つでも抜けると半日溶けるし
完成する未来が全く見えんｗ #include <fbxsdk.h>
fbxsdk::FbxManager* p_fbx_manager = fbxsdk::FbxManager::Create();
p_fbx_manager->Destroy();
_CrtDumpMemoryLeaks();
これだけでメモリリーク出まくりなんだがｗ
天下のAutod〇skさんよぉ？一体どういうことだよ？ｗ つうかさ、VS2022から仕様が大きく変わってるじゃねえか
コロコロ仕様変えるなよな全く。価値観押し付けられて服従を強制されてるみたいでイライラするわ 
