[過去ﾛｸﾞ] スーファミのプログラム (455ﾚｽ)

スーファミのプログラム http://mevius.5ch.net/test/read.cgi/gamedev/1095063252/

上下前次1-新
通常表示 512ﾊﾞｲﾄ分割 ﾚｽ栞
抽出解除 ﾚｽ栞

---

このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ

---

444: 名前は開発中のものです。 [sage] 2016/08/07(日) 19:46:07.53 ID:BFS2eMZo >>410 >>443 聖剣３やったことないけど 例え以下の制約を打破できたとしても、高度過ぎてやりたくないというのが本音だろう。 アセンブリ言語主流で、C言語すら使われていないだろうし。 スポットライトや空間に開いた穴みたいな効果を出すには、 BGに（全画面規模で？）、マスクだとかウインドウを転送しなきゃならないと思う。 画面を表示しながらVRAMに転送するには、 1回あたり垂直帰線期間（VBlank）の1ミリ秒間程度の短い時間内しかできない。 VBlank以外の最中に裏画面に描画して、表画面とすりかえるなんて、無理なはず。 演出に使うスプライトを展開しないといけないかもしれない。 http://game14.2ch.net/test/read.cgi/gameurawaza/1146439237/272 おおげさに書いたここまでの処理、たいしたことはない。1〜数フレームあれば完了するだろう。 ただ、この状況でプレーヤーに動かれたらプログラムは糞面倒になる。 演出のBGのスクロール値、すべての表示中のスプライトの座標を再計算することになるだろう。 美的な破綻や、アニメーションの管理も難しくなるだろう（敵が動いて当たってないじゃん！などの発生）。 乗除算すらまともにない最大3.58MHz動作のCPUだ。 プレーヤーが動くということは、マップの展開や転送、地形やイベントオブジェクトとの当たり判定、 敵の発生？（乱数など）、スプライトを画面外に追いやる処理なども発生する可能性がある。 http://mevius.5ch.net/test/read.cgi/gamedev/1095063252/444

---

ﾒﾓ帳

(0/65535文字)

---

上下前次1-新書関写板覧索設栞歴

---

ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ

---

Google検索

Wikipedia

---

ぬこの手 ぬこTOP 0.017s