最近全然手をつけてないDQ6インターフェース改良パッチですが、ふと思い立ってDQ4^{-}に適用してみたら思いっきり使用領域がかぶっていたのでダメダメでした。他にもオリジナルに適用した場合でも袋の中の種を使用する相手をキャンセルした後に使用すると何も効果がでなかったりとバグっちい動作が残っていてよろしくない感じなので近々修正する予定です。DQ4^{-}対応も宣言したいところですが、どういじられてるか面倒なので調べていない上にアイテムもいろいろと変えられているので1つのパッチで両方に対応するのは現実的ではないというのが今のところの見解。組み込んでしまうのが一番いいんですが2バージョンのメンテナンスはしんどいのであまりやる気にはなりません。
さて、今回はコインを大量に稼ぐモンスターの追加と?マークでのギミック(獲得コイン2倍、5倍、経験値コイン逆、戦闘中のみ)の実装を行います。まずはやることがはっきりしている2倍、5倍、逆を実装します。
- SR: $02A6AF 戦闘終了時処理SR_SR_0001
| 略 | |||
|---|---|---|---|
| 02A6E4 | JSR $E5CA | SR: $02E5CA | すごろく中コイン獲得確変処理 |
| 02A6E7 | NOP | ||
| 02A6E8 | NOP | ||
| 略 |
(2010-06-08コメント欄指摘により大幅変更)
- SR: $02E5CA すごろく中コイン獲得確変処理(新SR)
| 02E5CA | JSL $C3FF09 | SR: $03FF09 | すごろく中かどうか(該当c=on) |
|---|---|---|---|
| 02E5CE | BCC #$22 | if(c==off) goto $02E5F2 | |
| 02E5D0 | LDA $35B5 | A=$35B5 | |
| 02E5D3 | BIT #$0008 | A & #$0008 | 経験値コイン逆フラグがON |
| 02E5D6 | BEQ #$05 | if(z==on) goto $02E5DD | |
| 02E5D8 | JSR $E5FD | SR: $02E5FD | すごろく中経験値<->コイン入れ替え処理 |
| 02E5DB | BRA #$15 | goto $02E5F2 | |
| 02E5DD | BIT #$0010 | A & #$0010 | コイン5倍フラグがON |
| 02E5E0 | BEQ #$05 | if(z==on) goto $02E5E7 | |
| 02E5E2 | LDA #$0005 | A=#$0005 | 倍率指定 |
| 02E5E5 | BRA #$08 | goto $02E5EF | |
| 02E5E7 | BIT #$0020 | A & #$0020 | コイン2倍フラグがON |
| 02E5EA | BEQ #$06 | if(z==on) goto $02E5F2 | |
| 02E5EC | LDA #$0002 | A=#$0002 | 倍率指定 |
| 02E5EF | JSR $E616 | SR: $02E616 | すごろく中戦闘後獲得コイン倍化処理 |
| 02E5F2 | JSL $C907CC | SR: $0907CC 引数:1#$35B5 引数:2#$7E 引数:3#$38 引数:4#$00 引数:5#$00 | RAM上情報変更(OFF) |
| 02E5FC | RTS | return |
- SR: $02E606 すごろく中経験値<->コイン入れ替え処理(新SR)
| 02E5FD | LDA $23DC | A=$23DC | |
|---|---|---|---|
| 02E600 | LDX $23E0 | X=$23E0 | |
| 02E603 | STX $23DC | $23DC=X | |
| 02E606 | STA $23E0 | $23E0=A | |
| 02E609 | LDA $23DE | A=$23DE | |
| 02E60C | LDX $23E2 | X=$23E2 | |
| 02E60F | STX $23DE | $23DE=X | |
| 02E612 | STA $23E2 | $23E2=A | |
| 02E615 | RTS | return |
DPではなくAレジスタ、Xレジスタをバッファとして使用するように変更
- SR: $02E62F すごろく中戦闘後獲得コイン倍化処理(新SR)
| 02E616 | LDX $23E0 | X=$23E0 | |
|---|---|---|---|
| 02E619 | STX $00 | DP($00)=X | |
| 02E61B | LDX $23E2 | X=$23E2 | |
| 02E61E | STX $02 | DP($02)=X | |
| 02E620 | LDX #$0000 | X=#$0000 | |
| 02E623 | JSL $C01107 | SR: $001107 | DP($00,X)(4B)=A(1)*DP($00,X)(3B) |
| 02E627 | LDA $00 | A=DP($00) | |
| 02E629 | STA $23E0 | $23E0=A | |
| 02E62C | LDA $02 | A=DP($02) | |
| 02E62E | STA $23E2 | $23E2=A | |
| 02E631 | RTS | return |
もしかしたらまたチョンボをやってるかもしれないので間違ってたら指摘お願いします。次に、コインをたんまり持っているボーナスモンスター(わらいぶくろ、おどるほうせき、ゴールドマン)をすごろく中に出現させるようにします。エンカウント($08AC7C-)*1に専用のレコードを追加すればいいのですが、エンカウントレベルの設定が問題です。まず、すごろく中のエンカウントがどのように決定されているかを調べる必要があるわけですが、半年近く前の話なのですっかり忘れてしまいました。説明は次回に回します。
*1：拡張パッチでアドレスが移動しています。
コメント
チョンボではないけど
org $02E5E0
BIT #$0010
BEQ Label_1
LDA #$05
BRA Label_2
Label_1: BIT #$0020
BEQ Label_3
LDA #$02
Label_2: JSR 倍化処理
Label_3: JSL $0907CC : dw #$35B5 : db #$7E,#$38,#$00,#$00
RTS
倍化処理:
LDX $23E0
STX $00
LDX $23E2
STX $02
LDX #$0000
～以下同じ～
こんな方が量は減りますね
倍化処理もJSRせずに使うこともできますね
おまけ
GとC切替処理
LDA $23DC
STA $00
LDA $23E0
STA $23DC
LDA $00
STA $23EO
LDA $23DE
STA $00
LDA $23E2
STA $23DE
LDA $00
STA $23E2
よく見たら結構無駄なコードになってますね。BITの使い方がようやくわかりました(バグが怖いのでよくわからない命令は敬遠してたので)。倍加処理のSRはXレジスタを使えばPHA、PLAが要らんということですよね。経験値とGの入れ替えもこっちのほうがいいですね。直しておきます。
あ、書き間違えた
GとCではなくCと経験値だった
あと一部のLDAがLDA.w ではなくLDA.bなっとる
BITはAレジスタの値が変化しないANDですね
なので
BIT:特定Bitの確認
AND:特定Bitの削除
で使い分けると見易かったりするかも
おまけのおまけ
Xインデックスの使用状況よく見ると、これが最適だったっぽ
LDA $23DC
LDX $23E0
STA $23E0
STX $23DC
LDA $23DE
LDX $23E2
STA $23E2
STX $23DE
ANDは主にフラグの確認に使ってたんですが、大抵SRでラップしてたのでBITでなくても事足りていたようです。あと経験値とGの入れ替えの処理は最終的にバッファとしてどこを使うかという話だと思うのですが、実装していたときのことを思い起こすと、AやXは上書きしてしまうとどんな副作用があるかわからないからよくテンポラリバッファとしてよく使用されていたDPのほうが安全という思考回路をたどっていたようです。(PHAやPHXすればいいという話もありますが)ここから先は65816の一般論に基づく疑問なのですが、安全だが多少冗長な実装と危険かもしれないが短いコードのどちらのほうが好ましいんでしょうかね?(もちろん安全で短いのがベストなのは言うまでも無いです)
今回K.Mixの実装をするにあたって、対象がRPGでリアルタイム性はある程度無視できること、さらに拡張パッチをベースにしているのでスペースには多少余裕があるということで冗長でも安全と思われる側に寄せて全般に実装していたのですが、マリオのようなACTでは例えば今回のような実装の違いは致命的な処理遅延につながるんでしょうか?知ってたらでよいので教えてください。
本体：特定の場合に4サイクル
経験値⇔コイン：24サイクル
コイン倍化：7サイクル
両SR(JSR・RTS)解除：12サイクル×２
最大で59サイクルの削減かな
某資料を元に考えると１ラインの1/3を描画するまでの時間位ですかね
この程度なら滅多に差は感じられないでしょうね
但し、あくまで１フレーム1処理を前提としてるからですね
例えば敵スプライトを作るなら
・同時に4体位なら使用する可能は十分あるのでまず4倍の負荷を想定(SMWでは通常のは最大で計10体出現)
・画面に表示するタイル数分のループ処理を行うのでそこに無駄があるなら数倍。その他ループ処理も同様
・ある程度複雑な処理なら処理の記述自体の個人差が大きい
SMBのファイアバーを最適化して作った人を例に出すと
他所で作られたのを使うと処理落ちする場面でも問題なく動作するどころか更に2本位追加できるとか
敵スプライトだと発生すると同条件でずっと発生し続けるからできる限り軽い方がいいでしょうね
私は新SR加えるときはその後ろにLD*や各フラグを使用した物が無いか軽く見てPH*の使用決めてますね
まあ最低限目に見えて減らせる所は減らしてますね