#7DGEN再び、お魚さんの為にも必要です。（２００６－０２／０７）
（注：このＤＧＥＮは１．００です。最新のＤＧＥＮはもっとずっと進んでいます。
スキルがあり、開発をしたい方は開発者に直接コンタクトをとって下さい。
私は開発者とは全く関係のない第三者です。
あくまでこのページの話は実験用途（教育用）です。）
■ＤＧＥＮ１００を忘れた訳ではありません。
パフォーマンスだけ見れば、
ＤＧＥＮ１００ ＞ 管理人版ＤＧＥＮ１００ ＞＞＞ 管理人版お魚
です。
単純にコンパイルしたＤＧＥＮ１００に負けてます。
ましてや
ＤＧＥＮ１２０ ＞＞ ＤＧＥＮ１００
ですから。
遅いエミュ等、速いエミュがあれば無価値。
だからといって本当に価値がないのではありません。
■さて、ＤＧＥＮ１００。
ＰＮＧも読めないし、ＺＩＰも読めない。
これは、ライブラリが形だけリンクされていて、
コンパイルも通るし、実行もできる。でも機能しないって状態。（別館のＲＩＮも全く同じ状態）
恐らくこれらのライブラリを使う為には、ライブラリのソースを弄る必要があるのではないのかと思います。
（ただコンパイルしただけでは駄目）
原因は未だに判りませんが、どうせ使えないライブラリなら、使うのやめちゃえ。
って事で。外してコンパイル。エラーが出たんで、さして（管理人には）関係ない所はコメントアウト。
ステートセーブとか改造コードとかＺＩＰ－ＲＯＭのロードとかその辺だったと思う。
なあんだ。ライブラリ１つもいらないじゃん。（あとでＲＵＫＡ版のＵＮＺＩＰＬＩＢ．Ａをリンクしよう）
それから気がついたのですが、どうも'-lc'はあやしい。これがあると、コンパイルは通るものの、
ＰＳＰに持ってって、実行できなくなる場合がある。（起動に失敗しました）
ＲＩＮのMakeは直したのに、DGENのMakeはそのままだった。
もちろんうっかり、"startup.S"を"startup.s"にリネームしたので、消されてしまった。
（"*.s"のファイルは何処にあっても、コンパイル中断で、問答無用に削除される）
という事もあるのですが。
単純にMakeを書き換えると、'-lc'のせいで、実行できなくなります。
これは、ソースの位置関係が移動して、単純にパスが長くなっただけの状態でこうなります。
ライブラリその他ソースのインクルードはすべてうまくいっていての話です。
（でないとコンパイル通ったとは言わない）
やってみないと、「意味」わからんだろうな。（表面的な意味ではない）
■さて、ＤＧＥＮ１００。（記憶喪失になった訳ではない）
とにかく弄れば弄るほど、パフォーマンスダウンしてます。
それは、どうでもいいちゃあどうでもいい。（現在の状況はとてもそんなレベルではない）
んですが、やはり気になったので。
ＣＰＰ関係は一つのオブジェクトに纏めました。（リンカにリンクさせない）
具体的には、訳判らなくなるので専用のフォルダに集め、（必要な作業ではないがこういう事が大事）
「mdcore_main.cpp」のみとし、あとの物はすべて「mdcore_main.cpp」内でインクルードです。
これで、リンカが噛まなくなります。
要するに、
////////////////////////////////////////////////
/// mdcore_main.c
////////////////////////////////////////////////
#include ＜stdio.h＞
#include ＜stdlib.h＞
#include ＜string.h＞
////////////////////////////////////////////////
#include "./md.h"
////////////////////////////////////////////////
#include "./../emu_config.h"
#include "./../emu_state.h"
#include "./../psp_pad.h"
////////////////////////////////////////////////
#define _USE_FM_CORE
/////////////////////////////////////////////////
static int sound_is_okay = 0;
static md mdcore ;
#include"myfm.cpp"
#include"mem.cpp"
#include"md.cpp"
#include"vdp.cpp"
#include"ras.cpp"
#include"mdfr.cpp"
#include"graph.cpp"
#include"save.cpp"
#include"md-joe.cpp"
/////////////////////////////////////////////////
#ifdef __cplusplus
extern "C" {
#endif
略
って感じです。
＜お昼ご飯でし、つづくよぉ。１２：２３＞
部分的にクラスを破壊してみた所があるんですが、
おそらくここがパフォーマンスダウンしてる原因かな。と思い。
（素直にクラスに入れりゃぁいいんですが）
とりあえず、一つのＯＢＪになった事だし、
改造の都合で取り敢えずＧＬＯＢＡＬ変数にしてたところを、
ＳＴＡＴＩＣ変数に変更してみました。
（それなら、Ｃ的には大丈夫な筈でしょ？、ＣＰＰのクラスのprivateみたいなもんです。）
（注：Ｃ言語初心者様、この場合のＳＴＡＴＩＣは関数内のＳＴＡＴＩＣとは全然関係がないよ。
意味まったく違うんだよ。予約語だけ一緒なんだよ。Ｃ言語判る人なら常識だけどさ）
但し、
グローバル ＜ スタティック ＜ クラス(public) ＜ クラス(private)
かもしれなくて、やっぱ駄目かもしんないです。
（管理人Ｃ＋＋のその辺はよく知らない）
で、結局「ＢＦ０３チェック」の結果は代り映えしないです。
いずれにせよ。パフォーマンスに関しては、
明らかに不要なルーチン（使ってないのにリンクされてる）を削除すると、
何故かパフォーマンスが下がるので、何がボトルネックになっているのか、未だに良く判りません。
（alignだったりして。でもそれなら、最適化オプションの－Ｏ３でなんとかなる筈）
■お魚さんへの（音関係）移行について、
始めから計画してる事なのですが、音関係は一つに纏めてしまおうというのがあります。
というのはＭＤの構造上一箇所でレンダリングしても差し支えないからです。
（つまりＵＰＤＡＴＥＯＮＥは１つしかなくその中でＤＡＣとＳＮとＦＭのレンダリングを行う）
ＹＭの入力クロックは６８０００と同じですし。ＳＮの入力クロックはＺ８０と同じです。
ここはＤＧＥＮが間違ってる（っていうか実装の都合によりわざと間違えている。多分）
ところです。（単純に間違えてるだけって事が判明しました。２００６－０２／０８、０１：２８、追記）
ＤＡＣはキャッシュしないと駄目ですね。（←この表現では意味不明かも）
このＶｅｒのＦＭ．Ｃではなくて、もっと新しいＶｅｒのＦＭ．Ｃから該当部分を抜いてくる必要があります。
（さとうたつゆき様、ＶＥＲのＤＡＣを改造して使うのなら）
ＤＡＣは現在のＤＧＥＮ１００の実装では、外部で実装し、画像レンダー（ラスター）とも連動してます。
さとうたつゆき様のこのＶｅｒのＦＭ．ＣはＤＡＣがバグバグなので、使ってません。
ＹＭとＳＮのクロックが整数倍で同期できるのですから、無理に別々にレンダーして後でＭＩＸｉｎｇしなくても、
初めから同時にレンダーすれば良いのです。
具体的には、音のレンダーがかかる可能性は３ヶ所で、
１．６８０００／Ｚ８０共通ルーチン：ＳＮのレジスタが更新された場合。
２．６８０００／Ｚ８０共通ルーチン：ＹＭのレジスタが更新された場合。
３．フレームの終わりまで達した場合。
これらの場合にそれまで部分をレンダリングすれば、精度的には一番良い方法です。
さらに、メガドラの場合は、
４．ラスターの終わりまで達した場合。
を入れないとまずいかも知れません。これはＤＡＣの都合です。４を入れるか入れないかで、
実装の都合が大きく変わります。しかし、管理人の見解では、（２．３．）をきちんと実装すれば、
４は取っても良い。と思います。（ＤＧＥＮは４．を実装する為にＤＡＣルーチンが別になっている）
上記は理想論です。管理人が５年前に作成した、ＰＣのエミュでは全て実装し、動作を確認しました。
（だからＤＡＣテーブルなんてもんがあるんだよ）
が、ＰＳＰのエミュでは基本的な動作速度が全然違うので、
（ＰＣでいったらＰｅｎ２００クラス、０．２ＧＨｚ程度）
何を入れて何を入れないか、選択に悩む所です。
いっその事、２．３．を取っ払って、４．を入れれば、殆ど影響がない気がします。
そおいえば、ＰＣのエミュでもそうした気がする。（いまソースが行方不明中）
それなら、ほぼ問題出ないよなあ。そおしよ。
って事で、４のみＵＰｄａｔｅＯｎｅが呼ばれる。（場合によっては３．も）
つまり、一箇所ですんじまいますね。
そおしよ。そおしよ。いい案浮かんで良かった。
これなら、多分うまくいくと思います。
ちなみに現状のＤＧＥＮ１００は、
Ａ．ＹＭのレジスタが更新された場合。ＦＭのＵＰＤＡＴＥＯＮＥ（ＤＡＣはフックして渡さない）
Ｂ．ＳＮのレジスタが更新された場合。ＳＮのＵＰＤＡＴＥＯＮＥ
Ｃ．ＤＡＣはフックして別ルーチン。ラスターの具合を見てＤＡＣのみレンダー（う～んちょっち正確な表現ではないな）
Ｄ．フレームの終わりまで達した場合。ＵＰＤＡＴＥＯＮＥ。
Ｅ．どこかで（よくしらん）ＭＩＸ→音だし
となってます。
Ｄ．の実装より、前項４．の実装のほうが厳しそうですが、４４１００Ｈｚで音だしする場合。
１フレームあたり（１秒間６０フレームだから）
４４１００／６０で、７３５回です。
メガドラのＮＴＳＣの場合１フレーム＝＝２６２ラスタですから、
１ラスタあたり２．８回
前項４．の実装ならば、
ＵＰＤＡＴＥＯＮＥのlengthループは、高々３回しか回らないんですよ。（もっと回ると思ったでしょ？）
サブルーチンコールのオーバーヘッドを考えた場合。
仮にＤＡＣもレジスタもそのフレームはまったく更新されなかったとして、
フレームの終わりに更新の場合は１回コール、length=７３５ですんじまうのに対して、
ラスターの終わりに更新の場合は２６２回コール、length最大３ですね。
こんなもったいない事は、ＰＣなら屁でもないですが、ＰＳＰでする訳がない。
ここはＹＭ（ＤＡＣ含む）とＳＮのレジスタが書き換わったかどうかフラグを立てれば済む話です。念のため。
ですから、フラグに変化がなければ、ラスターの終わりでＵＰＤＡＴＥＯＮＥを呼びません。
この方式でも「いつでもラスターの終わりに更新する。という訳ではありません。」念のため。
初めの方に書いたレジスタキャッシュってのは、そおいう意味です。（２００６－１４：００ぐらい）
■ＰＳＰのメガドラエミュで、ＦＭが重い→ＵＰＤＡＴＥＯＮＥが重い。ってのは、事実ですが、
ＵＰＤＡＴＥＯＮＥは４４１００Ｈｚの場合１フレームに７３５回しか回らないので、
「一回一回が、非常に重い。」
という事です。
だから、ＤＧＥＮ１００の初めの状態で、
４４１００用ＵＰＤＡＴＥＯＮＥ
２２０５０用ＵＰＤＡＴＥＯＮＥ
１１０２５用ＵＰＤＡＴＥＯＮＥ
と三つに別れていたのを、一個に纏めても、パフォーマンスさして変わらなかったでしょ？
（詳しくは２００６－０１／２６の日記参照）
それは理屈上殆ど変わらない筈だからです。そこはボトルネックではありませんからね。
（２００６－１４：１０）
■inline についての苦言。
みんな、Ｃ言語のdefineについて知らないみたいだから、特別レクチャー。
「inlineとdefine。最適化ＭＡＸまでかけときゃ、同じじゃないの？違うの？」
違います。運が良ければ、同じになる場合もありますが、ちょっとした事で最適化失敗して違います。
それにＧＣＣは最適化そのレベルまで保証してる訳じゃぁないんだよ。
例：ＤＧＥＮ１００の「ＰＳＰ＿ＳＣＲＥＥＮ．Ｃ」
inlineの場合。
inline void PSP_Screen_WaitVsync ( void )
{
sceDisplayWaitVblankStart() ;
}
inline void PSP_Screen_WaitVsyncFast ( void )
{
sceDisplayWaitVblankStart() ;
}
void PSP_Screen_SetBkColor( int color )
{
psp_screen_bk_color = color ;
}
defineの場合（defineが効くように、位置を変える必要がある。呼ばれる前にdefineされてないと。）
#define PSP_Screen_WaitVsync ( aaa ) ￥
{ ￥
sceDisplayWaitVblankStart(); ￥
}
#define PSP_Screen_WaitVsyncFast ( aaa ) ￥
{ ￥
sceDisplayWaitVblankStart() ; ￥
}
#define PSP_Screen_SetBkColor( color ) ￥
{ ￥
psp_screen_bk_color = color ; ￥
}
一見、どちらも同じ様にみえます。が、違います。特に３番目はどんなに最適化しても、
余計なコードが残るでしょう。colorが本当にintかどうかの型チェックが入りますから、
それは注意してみれば判りますが、プログラマーが型チェックしろと明示してあるので、
外す訳にはいかないからです。
１．２．はvoid,voidだから、同じなんじゃあないの？。同じになるのが理想なんですが、
現在のＧＣＣの最適化技術では、同じになったり、オーバーヘッドが残ったりという状態です。
これは最適化の実装方式がパスの下流になっている為に、起こる現象です。
ＧＣＣは何もＲ４０００の専用のコンパイラ（アッセンブラ）ではありません。
（たとえＲ４０００用にコンパイラをビルトして作成しても。）
平たくいえば、どのＣＰＵにも対応できるよう、最適化はあとでまとめてやる。という方針になってます。
まとめてやる最適化の方針としては、まずそうな所（重いと思われる）から先にやるので、
うまく取れない場合があります。人間がみれば、こことここ全部取ればおしまいじゃんって、
見て直感で直ぐに、判りますが。コンパイラがこなす最適化は「関数のオーバーヘッドを取る」事だけでは、
ありません。「ほかの変数との共通部分をとる」とかいろいろ最適化の手法はあるので、
他の手法の最適化強度（優先順位）が高かった場合には、結局取りきれなくて結果的にゴミが残ります。
よしんばＣなら、なんとかなっても、ＣＰＰは中身はかなり泥臭いですから、どうにもなりませんね。
（外見（そとみ）と中身は違うんだよ。クラスの世話や関数の世話。関数や演算子のオーバーロード等、
やることは幾らでもある。例えばmd::foo()って関数は、内部でＣに変換され、
md->aaa->bbb->ccc->ddd->foo()みたいな感じになって、Ｃコンパイラに渡される。それをＲ４０００の
アッセンブラ（この時点が噂の小文字の[*.s]ファイル）に変換し、最適化が入る。それをアッセンブルして
ＯＢＪを生成し、リンカに渡され、リンカの最適化機能が入り、やっとＡ．ＯＵＴができる。あとは知ってるよね。）
注意点：
１．単純に上記の様に、「define化」すると、Ｃ言語の持つ「型変換機能」が外れる事に注意してください。
２．Ｃ言語のスコープ機能にも、注意する必要があります。スコープが効いたらまずい場合は、例えば、
さらに下記の様に直します。（違うんだよ）
「同じでない」と知識で知っていても、具体的に何処が「同じでない」のか、解説してる所。
あまりみかけない、ですからね。（つまりは、みんな判ってないんだろな）
#define PSP_Screen_WaitVsync ( aaa ) ￥
sceDisplayWaitVblankStart();
#define PSP_Screen_WaitVsyncFast ( aaa ) ￥
sceDisplayWaitVblankStart() ;
#define PSP_Screen_SetBkColor( color ) ￥
psp_screen_bk_color = color ;
普通は、（上と全く同じ記述）
#define PSP_Screen_WaitVsync ( aaa ) sceDisplayWaitVblankStart();
#define PSP_Screen_WaitVsyncFast ( aaa ) sceDisplayWaitVblankStart() ;
#define PSP_Screen_SetBkColor( color ) psp_screen_bk_color = color ;
ちなみに、
inline void PSP_Screen_SetBkFgColor( int bgcolor,int fg_color )
{
psp_screen_bk_color = bg_color ;
psp_screen_fg_color = fg_color ;
}
みたいな関数があった場合。（説明用に作ったんで本物にはないけど）define化は、
#define PSP_Screen_SetBkFgColor( bgcolor, fg_color ) ￥
{ ￥
psp_screen_bk_color = bg_color ; ￥
psp_screen_fg_color = fg_color ; ￥
}
スコープが効いたらまずい場合は、（普通は簡略化してこっち）
#define PSP_Screen_SetBkFgColor( bgcolor, fg_color ) ￥
psp_screen_bk_color = bg_color , ￥
psp_screen_fg_color = fg_color ;
良く注意して見てくれ’；’と’，’が違うだろ。
これは、Ｃ言語の’，’機能で、スコープを使わない時に使う機能だ。
もうひとつdefine化の注意点として、if( 式 )やfor(式；式；式)やwhile(式)に入った場合だ。
if()やwhile()はGCCの場合、コンパイルエラーで気が付くが、
forの場合は、変に辻褄があって、取れないバグになる可能性がある。
上記の場合は、丸括弧でくくったり、最後の”；”を取ったり、いろいろ用途によってあるんだけど、
どっちが判りやすいかは好み。まあ全部最後の”；”は取った方が現実的だな。
例えば、こんな感じ。
#define PSP_Screen_WaitVsync ( aaa ) sceDisplayWaitVblankStart()
#define PSP_Screen_WaitVsyncFast ( aaa ) sceDisplayWaitVblankStart()
#define PSP_Screen_SetBkColor( color ) psp_screen_bk_color = color
#define PSP_Screen_SetBkFgColor( bgcolor, fg_color ) ￥
psp_screen_bk_color = bg_color , ￥
psp_screen_fg_color = fg_color
最後に”；”がないのはバグではない。
■別館に現在の管理人版ＤＧＥＮ１００をあげときました。既にうちのはもちっと進化してますが（２１：１３分）
殆ど同じものです。それで、ＦＳＫＩＰ０、ＶＳＹＮＣなし、サウンド１１０２５Ｈｚ、最大６０ｆｐｓ、Ｇｅ全画面で。
バーニングフォース一面のボス（こいつは奇数フレームと偶数フレームで交互にちらつくので判りやすい）
（単に、ＦＳＫＩＰ０でフレームのチェックをしたいだけなら、ローリングサンダー２のキャラクタ選択画面がお勧め）
で最悪４２ｆｐｓ程度。（ちらつきの画面のみ）でした。
これは平たく言えば「１秒間に４２枚画面を書き換えています。」という事です。（１フレームあたりの動作時間は）
つまり１０００割る４２で、約２３．８[ｍＳｅｃ]で動作しています。本物は６０枚書き換えますから、
１０００割る６０で、約１６．６[ｍＳｅｃ]で動作しています。（この数字、液晶ディスプレイのカタログみたいやな）
２３８割る１６６は約１．４３ですから、このちらついている状態では、
本物の１．５倍程度とろい。という事になります。
つまり、１／３程度の処理時間を削減できれば、結構速く動く事になります。
現状のソースを眺めれば判りますが、これは不可能ではない数字ですね。
アセンブラなど一ヶ所もないし。
主にＣＰＰのクラスの中とＵＰＤＡＴＥＯＮＥの中。それにＣＰＵの中を弄る必要がありますが、
決して不可能ではないです。例えば正規版のＤＧＥＮは、その後画像のバッファを実装したそうで、
それがどの程度、効果があるのかどうかは、やってみなければなんとも言えないですけど、
現実の正規版はこれよりずっと速いですし。
ちなみにＺ８０は手を付けてないどころか、まだソース見てもないです。
６８０００コアの割り算も取ったりしてないですし。（基本的になにも手を付けてないです。
つまり、ＭＵＳＡＳＩ３．３（古版）に入れ替えてみたりして遊んでただけ。）
（ＤＩＶ系命令でもないのに、割り算を使ってる所で、すごく簡単に取れる所がある。
例えば引数が、バイトでくる事が確定していて割る数が大きいのなら、
最悪値を考えて回数引けば済む。
例えば２５６割る２７は最悪でも９回２７を引けば良い）
この辺本当にやりたいのなら、過去日記を読んでね。「ｍ６８ｍａｋｅ．ｃ」と「ｍ６８ｋ_ｉｎ．ｃ」以外は全て
自動生成ファイルですよ。お魚さんの方を別館から落としてもらえば、意味が判ると思います。
