[過去ﾛｸﾞ] 【PCEngine】PCエンジン総合スレ避難所【CD-ROM2】 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
910: 11/17(日)13:11 ID:5G8dRtXR(1) AAS
グラディウスのビッグコアはニアアーケードでもちらつくがグラディウス?のビッグコアは全然ちらつかない
今でも不思議
911: 11/17(日)15:30 ID:Se4QmfsQ(1) AAS
BGに描いてるんじゃないの
912: 11/18(月)00:01 ID:/yyGAuoe(1/6) AAS
R-TYPEの昔からボスはBGに描いてラスターで背景と切り分けて動かすのが定番やね
近年では凄腕による勝手改修ファミコン版で長いレーザーをBGに上書き/消し込みで描画してて驚いたわ
BG書き換えはタイミングによっては処理落ちや画面ノイズのリスクあるから、真っ黒背景限定でラスタースクロール応用して全貫通レーザーに見せかける方が確実かもしれない
横スクロールならではのテク
913: 11/18(月)04:40 ID:/yyGAuoe(2/6) AAS
フォースギアのビッグコアは原作よりクソデカなのにスプライトでゴリ押ししてレーザーも撃たせてた
それでもあまり欠けないのでさすがグラIIスタッフ制作と感動したもんだ
あれがもしSGスペックだったら手が付けられない画面内密度になってただろうと思える
914(1): 11/18(月)10:40 ID:G3KYANL+(1) AAS
MMC5でちらつかないビッグコアと長いレーザーを実現していた実装だとレーザーの表示はMMC5の垂直分割機能を使っているので、それとは別のお話かしら？
動画ﾘﾝｸ[YouTube]
915(1): 11/18(月)14:01 ID:/yyGAuoe(3/6) AAS
>>914
自分が見たのは3年前の手法です
MMC5を使う新手法を開発されてたとは。
BG垂直分割はPCEで真似できないのでパターン書換で分割してるように見せかけるのが限度と思われ
SGなら問題なく描画できそう
916(1): 11/18(月)17:45 ID:245TlY4O(1) AAS
SGでも背景、背景の星、ビッグコア、レーザーをBGで表示すると大変ですな
SGなら問題ないとか簡単に言うなですな
917: 11/18(月)18:04 ID:QnRhnSo4(1) AAS
>>915
３年前の手法ならPCEでも同じ手でいけそうですね
ゆーちゅーぶ watch?v=oFmOED_MyHI
他に行けそうな手法はグラディウスレーザーは背景の後ろに隠れるのでレーザーの起点で0版パレットを書き換えて終点で元に戻すって形式（ＧａｍｅＢｏｙのネメシスと同じ手法）でしょうか
表示中にカラーパレットRAMにデータを書き込むとノイズが発生するそうなので、そのノイズがどのくらい目立つか確認しないと実用可能かは不明ですが（この手法だとHSYNC期間中で書き換えでは無理なのでノイズ発生不可避でしょうから）
918: 11/18(月)20:48 ID:/yyGAuoe(4/6) AAS
>>916
いや、いけると思うよ
伊達にBG2面、スプライト64枚2セット持ってるわけじゃないんで
919: 11/18(月)20:49 ID:/yyGAuoe(5/6) AAS
スプライト使うことで可能なら可能と言わなければ、BG縛りする意味が無い
見た目では分からなければそれでよし
920: 11/18(月)21:23 ID:/yyGAuoe(6/6) AAS
しかしオリジナルのアーケード版グラディウスがBGにレーザー描いてたという話なので、他のオブジェクトはともかくレーザーだけはラスタースクロールなりCG書き換えなり駆使してBGで実現しないと気分的にニアアーケードにならないな
ラスタースクロール使う場合は全ステージで背景の遠景が破綻せず描画できるかというと要塞面で無理くさなのでやはり8bit単位で書き換えるしか。
スプライトでやるにしても横枚数減らすためには毎回複数レーザー重ねた合成SGとして書き換えることになる
敵との当たり判定処理軽くしないと処理落ちキツそうだがワークRAM多いのを盛大に仮想VRAMを使えばなんとかいけるかな
miniでニアアーケード作る時にSGXスペックで描画ルーチンやり直してみてほしかったけど、まあ音楽や見た目の忠実度が上がってるだけでもファンサとして十分だからいいか
6280の処理速度でレーザー書き換えが毎フレーム間に合うのか後で検証してみる
921: 11/19(火)01:35 ID:b9dJ0ubA(1) AAS
エンジン版はスプライト３５枚（7x5）割り当ててるのかな、にしてはレーザーが密集していても消えないので単純な実装ではないよね（スプライト表示だとするとレーザーのパターンを動的定義にして、近いレーザーは統合して表示枚数を減らすみたいな工夫をしていそう）
スプライトとＢＧを色分けしてみた動画あったりしないかしら？
922(1): 11/19(火)20:17 ID:VUbd36X4(1) AAS
エンジン版とアーケード版をよくよく見比べてみて分かった点
まずアーケード、これはスプライトが欠けるという概念が無いハード構成になってる可能性が高い
8×8のスプライトなら少なくとも128枚は出ている状況（特に触手面）が高次周回なら容易に起きるのだが、ひどい処理落ちはあっても、スプライト欠けは一切起きない模様
そしてBG面は前景（ストーンヘンジなど）と遠景（流れる星）で2枚ありそう
レーザーをBGに描くなら自機のワインダーに合わせて毎フレーム上下に描き直すだろう。しかしスプライトが欠けないのなら全部スプライトで撃てば簡単なはず。ところが処理落ちはダブルショットの方がひどいので、当たり判定の負荷などたかが知れてるからダブルはスプライトで撃ってちまちま当たるようにしており、レーザーはBGに描いてかなり広い当たり判定にしてるように見えた。
次にエンジン版、こちらはレーザーもボスもスプライトで描いている。そしてレーザーが多数重なるとボスはチラついてしまうし、ボスがいない時でも長いレーザーを画面横幅いっぱい5本重ねて表示させるといくつかのレーザーは中間部分がちらほら欠ける。おそらく、レーザーの先端と後端はしっかり描画するように優先順位を高くしており、中間はスプライトローテーションの対象になってると思う。
もちろん、触手面であっても自機が欠けることはなく敵と自機弾がチラつくだけの模様。
ちなみに、ご存知のとおりレーザーはボタン連打で細切れに撃つこともできるのだが、アーケード版でこれをやるとBG描き換えをどう処理することになるのかは不明。
今描いたレーザーが次のフレームで、上下はともかく右に8pix動くことだけは決まってるから、全てのレーザーの座標をスタックしておいてワインダーから抜けた（それ以上上下に動かない）ものは単に右、ワインダー対象は上下も考慮して描き直すだけだろうと思う
いくら処理落ちさせても構わないという発想なら、これで重くなっても問題ない。
923(1): 11/19(火)22:17 ID:I2Ji25lf(1) AAS
で？
6280の書き換えの検証はまだか？
924: 11/20(水)00:42 ID:L0hZmdCO(1) AAS
ここって当時のプログラマーが多い印象
そうではなく当時を知らない現役バリバリの人が
子供の頃に遊んだのを懐かしんで検証しているのかな
925: 11/20(水)01:29 ID:AiG2LBOp(1) AAS
プログラムの話なんて出てなくないか？
926: 11/20(水)02:10 ID:DqPEs6wz(1) AAS
ではどの職域の人が書いているのだろう？
当時のドット絵師は大して小難しい事は考えてなかったように思うけれど
自分だけ？（汗タラタラ）
927: 11/20(水)04:08 ID:I4yBjykN(1/5) AAS
まあ6502系のプログラムくらいは趣味の素人でもなんとかなるよ、シンプルだから
6280や6270の情報も探せば必要なものは出てくるし
>>923
SGXで各画面の割り振りとキャラクタライン毎の書き換え量の目星を付けるのに割と真面目に設計しないとならんのでもうしばらく待て（特に触手面で破綻しないようにするのが結構ヤバいことに気付いてしまったので）
ファミコン版でBGレーザー改修された方はガチ勢すぎてプログラム設計の参考にしてはいけない
6280が速いといってもルーチンの書き方次第で遅くもなるから、当たり前に最適化して書けるであろうガチ勢とかろうじて動くようにしか書けない素人では雲泥の差がある
928(1): 11/20(水)04:41 ID:I4yBjykN(2/5) AAS
PCエンジン、普通のプログラマなら処理落ちさせないことを念頭に毎フレームの処理量を制限したり、テストプレイでは処理落ちメーター用意してアウト判定なら遅いルーチン詰めるとかやっていくものだと思う
だけどグラディウスに関してはアーケード版から処理落ち上等という割と大胆な動き方してるため、それでいいなら垂直帰線期間内で画面の書き換え計算（CG、SGパターンの差し替え分を1フレーム分まとめて用意する）と通常処理（操作受付やスクロールや当たり判定など）が間に合わなければ、画面も内部状態も更新しない（まるっと処理落ちさせる。BGMだけ割込で継続）という判断をすれば済む話になるので、どんなに書き換え量が多くてもあまり関係なくなる。
つまりSGXの場合はワークRAMとVRAMが白エンジンより多いから、各VDCでCGやSG差し替えパターンを空きエリアに置いとくのは余裕だし、BATの書き換えは1画面分丸ごとだとしてもスクロールを駆使すれば表示中画面の外側で済ませられるので、画面にノイズ出さずに対応可能だと思う（一回の垂直帰線期間内での書き換え量をざっくり1バンク8kBとして）
ただ自分の低い技術力ではレーザーはファミコン版BG改修手法を真似できても、触手の多関節をどうするか良いアイデアがない
アーケード版は細かいスプライトを単純にたくさん並べてるのかなと思うが、PCEやSGXなら複数の関節をひとつのスプライトに合成しないと横16枚×2ではとても収まらない気がする
触手もBGに描くなら6280がひたすらパターン合成を頑張ればいいのだが…
929(2): 11/20(水)08:27 ID:tiBgYvEx(1/2) AAS
>>922
オブジェクトと背景の描画がハードに投げられるアーキテクチャであればSTGで一番負荷のかかる処理は当たり判定だよ？
ビットマップマシンで描画CPUが背景からオブジェクトから描画しないといけないマシン（98、88、FM、X1等々）であれば描画処理の負荷が段違いだけど
----
アーケードのグラディウスについて
mameのコードをざっと調べたところ、アーケードのグラディウスはスプライト256個で拡大機能ありで水平制限なし、レーザーも普通にスプライトで描画しています
（水平制限あるNEOGEOシステムやTMS9918では水平制限が実装されていることと、ズーム機能があることを考えるとフレームバッファ形式かもしれません）
BGは二枚
一枚目にスコア表示・パワーアップゲージ多重スクロールの星を描画
（星はラスター分割で多重スクロールしています＝同じラインの星の速度は同じで、スコアを固定するので上下スクロールはしない、スコアとゲージのラインには星は流れません、また文字領域の境界で背景面との優先度を入れ替えて星を背景の裏に表示しています）
省1
上下前次1-新書関写板覧索設栞歴
あと 73 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.013s