セガ3D復刻プロジェクト、エミュレータ、コードコンバートなど、ゲームソフトの移植技術に関する解説

り ょ う 🔴 0𝕏33🕊 @azip77

.@bigburn エンガジェットの記事を拝見しました。「セガ3D復刻プロジェクトはエミュレータ路線は放棄して「移植」にかじを切りました。元のプログラムは使わず、」　という記述の根拠が知りたいです。よろしくお願いします。 twitter.com/engadgetjp/sta…

り ょ う 🔴 0𝕏33🕊 @azip77

@hor11 @bigburn インタビューはいつも読ませて頂いています。プログラムをそのまま動かしているものではないが、参考にして同じ動作をするように作り直しているという理解でよろしいでしょうか。多根さんの記事も興味深いもので大変参考になりました。ありがとうございます。

ほりい なおき @hor11

@azip77 @bigburn 参考にというか、元のプログラムを書き換えて、動く形に直す…という感じでしょうか？ ケースバイケースなんで正確を期してお伝えするのは、ちょいこんなん。

ほりい なおき @hor11

@azip77 @bigburn Emulationは移植の一手段だと思います。インタビューで語っている通り、3D復刻は確かにEmulatorによる移植とは言い難い技法でつくられており、Emulationと言い切るのは正確には間違いです。

ほりい なおき @hor11

@azip77 @bigburn 間に合う所はEmulationの手法だったり、間に合わない所は別の方法で…という感じで入り乱れています。その際データ自体は元のゲームに準拠して作成します。故に元のプログラムは可能な限り活かします。そのまま動かせる部分は動かす方向で、作業をします。

多根清史 @bigburn

@hor11 @azip77 3D復刻はEmulation蓄積の延長にありつつ、Emulattionで間に合わない面は別の技術を使い……というニュアンスで「移植にかじを切った」（Emulation比率が下がった）と表現したんですが、なかなか難しいですね。ご教示ありがとうございます

ほりい なおき @hor11

@bigburn @azip77 Emulationで動かしていた元のコードを、動かないので3DSで直接解釈できる形などに書き直し再構成した…という意味を移植とひとくくりにしているのは理解できました。

多根清史 @bigburn

@azip77 @hor11 自分なりに表現に苦労した箇所なので回答に迷いまくってしまいましたが、ほりいさんのフォローのおかげでクリアになりました。亮さんもきっかけを頂き感謝です。

Yosuke Okunari /奥成洋輔 @okunari

@bigburn @hor11 話の流れのついででコメントさせていただきますが、M2xSEGAはPS2セガエイジス2500→Wii VC→PS3/Xbox 360セガエイジスオンライン→3DS VC(GG)→3DS 3D復刻→（PS4&Vita龍オマケ）と休んでないんですよ

多根清史 @bigburn

@okunari @hor11 ああ！PS3と360エイジスオンライン（買った）ありましたね。ずっと走り続けておられてお疲れ様です…。

Yosuke Okunari /奥成洋輔 @okunari

@bigburn @hor11 毎回ちょっとずつ新しいセガの当時の技術を学習して貰っているのでM2さんは日々是勉強なのです。

ほりい なおき @hor11

@okunari @bigburn 時代の10年先を行くセガのテクノロジーを、20年とか後に学んでいく我々です。

後藤 浩昭 / GORRY @gorry5

何度か話しているけど、こういうのの再現手法には大きく分けて「エミュレーション」と「コードコンバート」の２つの技法があって、どっちを選択するのが割に合うかの話なのよね… togetter.com/li/889887

後藤 浩昭 / GORRY @gorry5

エミュレーションは「動作環境そのものの再現」であって、「一度完成すれば使い回しが効きやすい」のが最大の利点。ただし環境が大きくなるほど再現に手間はかかるし、再現動作のための要求ハードリソースは多く必要だし、オリジナル以上のことも普通はできない

後藤 浩昭 / GORRY @gorry5

「コードコンバート」は文字通り「コードを現在の環境で動くように置き換える」ことで、エミュレーションに比べれば再現のコストはずっと小さく、動作リソースも少なく済み、コードを改変してオリジナル要素を追加していくことも比較的容易。ただし大抵は「半自動」止まりで残りの作業をする人が必須

後藤 浩昭 / GORRY @gorry5

違いが出てくるのは「プログラム」のみで、ビデオやサウンド、コントローラなどの「デバイス」はどちらの方式でも「エミュレーション」で賄われるのが今は一般的。ただし「コードコンバート」の場合は、デバイスのエミュレーションコストを下げるためにプログラムを書き換えることもよくある

後藤 浩昭 / GORRY @gorry5

コードコンバートの話をもうちょっとtweetしようかと思ったら、長くなりそうなのでOFF書きしてたら結構な量になった…（苦笑

後藤 浩昭 / GORRY @gorry5

最初は「あるCPUの機械語を人間が手作業で他のCPU用に翻訳」していた…当然時間はかかるが、当時だと量自体が大したことないのでこれでも問題はなかったし、人間がきっちり最適化しないとパフォーマンス不足なことも少なくなかった

後藤 浩昭 / GORRY @gorry5

こういう話はゲーム移植以前に「ホビーとしてワンボードマイコンを作る」時代からあった。もちろんエミュレーションに繋がる話も当然あり、「2MHzの8080で6800をシミュレートして数十kHz相当」的な記事が当時の雑誌にいくつもある

後藤 浩昭 / GORRY @gorry5

なお当時の記事ではこの手の技術を「エミュレート」ではなく「シミュレート」というのが普通。当方もICE（In Circuit Emulator）を知ったのは「CPUシミュレータ」よりずっと後だった

後藤 浩昭 / GORRY @gorry5

CPU速度に余裕が出てくると、比較的単純なテキスト変換でアセンブラソースを置換するだけで（最適化しなくても冗長なコードで）十分になってくる。あとはデバイス（BG/Objや音声など）を移植先のものに書き直し、必要に応じて要所を最適化していくというのが電波のX68移植後期の手法

後藤 浩昭 / GORRY @gorry5

なおこの頃にも「X68000でX1をエミュレーション」的なものはすでにあった。ただそれでも「Z80が数百KHz」とかのレベルで、まだゲーム移植手段として使えるものではなかった