a5k - FPGAに移植された Another World / Out of This World

 (github.com/sylefeb)
1 ポイント 投稿者 GN⁺ 2023-07-16 | 1件のコメント | WhatsAppで共有
  • Another World / Out of This World の VM、blitter、rasterizer を標準 CPU なしで FPGA ハードウェアとして実装した個人的オマージュプロジェクト
  • 中核設計は、VM を実際のカスタムプロセッサとして作り、フレームバッファ間のコピー・塗りつぶしを担当する blitter、ポリゴンを描画する rasterizer、ディスプレイ更新をまとめた SoC で構成される
  • Lattice UP5K の 128KB SPRAM は 4ビット 320x200 のフレームバッファ 4枚に適合し、各 SPRAM ブロック 32KB が 1枚のフレームバッファに対応するメモリ配置となっている
  • ゲームデータはストレージに含まれておらず、BANK01〜BANK0D と MEMLIST.BIN を GAMEDATA フォルダにコピーすることで、データパッケージと bitstream を利用できる
  • 実行方法はシミュレーションと実機ボードの両方に対応
    • シミュレーションは Silice をインストール後、make simul1 でイントロを実行可能
    • ハードウェアは icebreaker + VGA PMOD、mch2022 badge、ULX3S HDMI をサポート
    • 事前ビルド済みの bitstream は含まれているが、ゲームデータは別途必要
  • VM 実行では SPI メモリから命令とオペランドを取得し、待ち時間を減らすために 64バイトを小さな BRAM キャッシュへ先読みする方式を採用
  • グラフィックス経路では、4枚のフレームバッファ、double buffering、vblank 区間でのアクセス制限、blitter と rasterizer のフレームバッファアクセス仲裁を用いる
  • rasterizer は Another World の凸ポリゴンを水平 span として描画し、透明効果のために既存ピクセル値を読み取って変更したり、別のソースフレームバッファからピクセルをコピーしたりできる
  • テキストレンダリングと part 6 の一部背景は、残り LUT 予算の都合で、ROM に事前レンダリングしたピクセルバッファを保存し、op_drawString 経路でコピーする方式で処理している
  • 明示されている制限と残作業として、サウンド・音楽の未実装、part ごとの個別 bitstream とデータパックが必要、ゲーム全編のプレイ検証未完了、原作より速いタイミングの調整、part 間の接続方法の検討が挙げられる
  • ライセンスは、Silice 設計が MIT License、ドキュメントが CC BY-NC-SA 4.0、修正された C++ ポートは既存の GPL を維持し、ゲームデータは著作権保護の対象

関連記事

1件のコメント

 
GN⁺ 2023-07-16
Hacker Newsの意見
  • 子どもの頃に Sega Genesis で Out of this World を遊んだとき、これ以上グラフィックが良くなることはないと思っていた。
    Sega であんな完全アニメーションのカットシーンを見たのは初めてで、本当にすごかった。もちろんグラフィックはその後さらに進化したが、Another World は今でも芸術作品として十分に通用すると感じる。スタイルが際立っていて、1年ほど前に遊び直したときもなお印象的だった。
    パズルのかなりの部分は試行錯誤に近く、ゲームも極端に短いが、それでも変えたいところはない。Another World のファンなら Flashback: The Quest for Identity も勧めたい。似たような映画的な雰囲気があり、最初はそれほどでもなかったが、この10年ほどでだんだん好きになってきた
    • Flashback は本当に大好き。サイバーパンクな世界観が好みに合うし、背景も美しく、物語もすばらしい。
      それでも Another World は芸術作品だ。ゲームポスターが油絵のように見えて、本当に美しい [1]
      [1] http://www.anotherworld.fr/download/AnotherWorld_Poster.jpg
    • Flashback が好きすぎて エキスパート難易度 で最後までクリアしようとしたが、終盤あたりで詰まり、slime man を倒せなかった
    • Genesis 版はかなり遅れて出たほうだった。1991年の発売直後に Amiga 版 を遊んだが、完全に衝撃的で、それまであんなゲームは見たことがなかった
    • Sega では Flashback を先に知ってすぐ気に入った。後で Out of this World を遊んだときは没入するまで少し時間がかかったが、どちらもすばらしい芸術作品だ
    • Flashback は Delphine Software の作品で、探偵ゲーム Cruise for a Corpse でも同じポリゴン技術の一部が使われていた
  • あわせて見る価値のある資料:
    cyxx による Amstrad CPC 向け Infernal Runner のリバースエンジニアリングと JavaScript 移植版。Another World の作者による作品で、どちらも仮想マシン構造を活用している: https://github.com/cyxx/infernal_js
    Norbert Kehrer による The Virtual Machine Architecture of Infernal Runner の発表。ドイツ語での発表だが英語スライド付き: https://media.ccc.de/v/vcfb20_-146-en-202010111400-_th...
    The Story of Another World on the Amiga | MVG: https://www.youtube.com/watch?v=0iz9PJbs5rE
    Another World の Nintendo 64 移植版: https://github.com/jnmartin84/aw64
    Another World の PlayStation 1 移植版: https://github.com/fgsfdsfgs/rawpsx
  • HDL が紛らわしいなら、これは作者の カスタム言語: https://github.com/sylefeb/Silice/tree/master
    Verilog にコンパイルするコンパイラを提供しており、その結果を既存の設計フローに組み込める
  • イントロは幻想的だった。PC スピーカー しかなく、サウンドカードがなくてもそうだった。
    最初の行動から泳いで逃げなければならず、その後すぐライオンのような生き物から脱出しなければならないのは、史上最も過酷なゲーム体験のひとつだ。このゲームは1分遊んだだけでも一生記憶に残る
    • 数分、多くても数時間くらいしか遊んでおらず、ほとんど進めなかった気がするが、その イントロと最初の脱出 は今でも記憶に焼き付いている。
      当時としては、このゲームの劇的なカメラ演出は本当にタイトルどおり別世界のようだった
    • このゲームを実際に遊んだことはないが、ビデオゲーム雑誌のおまけに付いていた販促用 VHS テープ の2分間のシーンだけで、30年間ずっと頭に残っている。
      表紙のアートもすばらしい
    • ライオンみたいなやつから新しい友達に助けられた直後に出てくるゲーム内の「セリフ」も絶対に忘れられない。
      konanaka beetzai! motsuubo! /wave
    • イントロだけでなく、ゲーム全体がフロッピーディスク1枚 に収まっていたことにも衝撃を受けた
    • 1分ほど遊んで詰まった記憶がまったく同じ。25年後にもう一度遊んで最後までクリアしたが、反応速度の壁 さえ越えれば、すばらしく記憶に残るゲームだ
  • Another World のオリジナル開発者による GDC 回顧講演 があるが、GDC の講演の中でもかなり良い部類だ:
    https://www.youtube.com/watch?v=JFaOYYSxSEA
    記憶では開発ツールの一部も紹介されていて、仮想マシンのバイトコード上でアニメーションを1行ずつ直接修正し、ステップ実行する様子も出てくる
  • 90年代に ゲーム全体用の仮想マシン がどれくらい一般的だったのか気になる。自分より古いゲームだが、当時の PC では仮想マシン層の性能損失は大きくなかったのだろうか?
    • Amiga、x86(DOS)、Mac、そして数多くの機種で同じソフトウェアを動かせることのほうが、はるかに重要だった。
      現在は80年代の爆発的成長期より機種数が少ない。今でも大半の「ソフトウェア」は、ウェブブラウザが解釈する JavaScript だと見ることもできる。80年代にも移植性の問題はあり、むしろ当時は自前でインタプリタを作らなければならなかったぶん、さらに難しかった。
      多くの、あるいはおそらく大半のビデオゲームは、Doom や高性能 3D グラフィックス以前には 仮想マシン で書かれていたように思う。コンソールゲームは性能上の理由から C やアセンブリだった可能性が高い

当時の「コンピューター」ゲームは、IBM PCが標準になる前、あるいは少なくともPCが勝ち、Microsoftが支配する前の時代だった。Amiga、PC-98、IBM PC、Macなど、何が勝つかわからない状況では、仮想マシンを作るのは合理的で、SCUMMがまさに思い浮かぶ

  • とはいえ、この種の特化型仮想マシンで Elite のようなものを作っていたわけではなかった。
    移植性も重要だったが、ムーアの法則が全速力で進み、プラットフォームの寿命がカゲロウのように短かった当時は、仮想マシンには圧縮効果もあった。完全にコンパイルされたバイナリは、ディスクやテープの容量、RAMをあまりにも多く消費し得た。
    一方で、ごく小さな仮想マシンなら、その場で解釈するための専用言語を作ることができ、1KBごとに節約しなければならない状況で容量を大きく削減できた。print "Hello world!" と基本的なコンパイル済みバイナリのサイズ差を思い浮かべればよい。テキストアドベンチャーはどれだけ高速でも、X KBに収まらなければ意味がなかった
  • アセンブリ言語全盛期には、業務用ソフトウェアでも仮想マシンは一般的だった。複数システムを対象にする標準準拠のCコンパイラがまだ存在しないか、あっても非常に高価だった時代で、異なるシステム間への移植が容易になった
  • Infocom Z-Machine、Wizardryのインタプリタ型Pascalコード、SCUMM、Sierra AGIとSCI、Another World、Horrorsoftのゲームなど、初期の仮想マシンの勘所は、作っていたゲームが主に「コンテンツ配信装置」だったことをよく理解していた点にある。
    テキストやグラフィック資産が多く、計算は比較的単純だった。オーサリング上の制約は、ハードウェアとは入出力とデータ圧縮の面でのみ結びついており、インタプリタが実行するコードはたいてい、一度だけ実行される「シーン初期化」と少しのアニメーションタイマーだった。
    反対側の発想は、アーケードゲーム、そしてその後のDoomやQuakeのような作品によく現れている。ゲームがシミュレーションする内容がハードウェアにはるかに密接で、シーン定義は「ここにモンスターを置き、あそこに体力アイテムを置く」程度で、スクリプトロジックというよりマップデータに近くなる
  • 「ゲーム全体の仮想マシン」をどう捉えるかによる。Infocomのアドベンチャーゲームはすべてのゲームコードを仮想マシン上で動かしていたし、SierraやLucasArtsのグラフィックアドベンチャーもそうだった。
    もちろん後者2つは、一部でネイティブのグラフィック基本演算を使っていた
  • Only Amiga makes it possible が、30年後にFPGAへ置き換えられる感じだ
  • 「[透明度]はラスタライザに複雑さを加える。[色値の]1ビットだけを反転させるには、その位置のピクセルの以前の値を知る必要がある」という部分は、Amigaのようなプレーナーグラフィックスを使うことで得られる3つの利点の1つに近い。
    ビットプレーンを使えば、ビデオメモリを再読込する必要がない。最上位ビットは透明効果専用だと仮定して、そのままスパンを描画すればよい。
    残り2つの利点は、プレーン同士を相対的に動かして見事なモアレ効果を作れること、そして8色（ピクセルあたり3ビット）や32色（ピクセルあたり5ビット）のように、バイトやニブルにぴったり合わない中途半端な色深度でメモリとバス帯域幅の効率がよいことだ
  • このスレッドのおかげで、結局このゲームを自力でクリアすることはないだろうと認めて、YouTubeでプレイ動画を見た。22分だった。自分はライオンを一度通り過ぎたくらいまでしか行けなかった気がする