ドラクエ3驚異のマル秘圧縮術公開！ 内藤かんチャン

[@qwertasdf-ch5zj]

商売的に搭載可能なROMやSRAM容量の中で、データ設計やプログラム容量の兼ね合いでどこまで情報圧縮できるか。 さらにバンク切り替えでどこまで拡張表現できるか。 危険な潜在バグを残してまでやれること全てをやって、ようやくあのドラクエの進化が実現したと思うと震える。

[@Iron_star4]

素晴らしい。圧縮後も7500Bはファミコンにとって巨大であること、展開処理が重い事を考えると、プログラマーとしての矜持は、この方法でまともにドラクエ３が動くようファミコンに実装した、まるっと含めた部分にあると思います。

[@noelShutain]

大変いい内容でした。圧縮の原理を説明するのに実際のグラフィックを利用して説明できるのが強みだと思います。またこういった動画を集めて教材にすべきと思いました。

[@shusugai]

尊敬する中村光一チームがプログラミングで何を成し得たかの片鱗が広く知られるのは嬉しい

[@sptlayzner]

実例つきで非常にわかりやすい解説でした。 途中までの基本部分は聞いたことがありましたが、 その後の、低頻度のものを別扱いにする工夫が興味深いですね。

[@KidoBaneSeisakusho]

往年のベーマガでやってたプログラミング道場みたいになってきましたねう～ん懐かしい

[@YakumoSagiri]

ランレングス圧縮懐かしいですね。 それにハフマン符号に近い符号化を組み合わせているんですね。

[@enjiro]

あの名作がこんな苦労の数々の元出来上がっていることに感動します。 最初の単純な圧縮で終わらせないところが本当にすごいと感じます。職人技、街もダンジョンもそれぞれに適したルールを編み出してより圧縮できる方法を追求してゆくのですね。音楽もきっと・・・。 実演があるおかげで、最高にためになりました。

[@RRX2007]

今でもゲームプログラムやデータは難読化目的も含めて圧縮されてるよ。メモリ上にデータ(プログラムではない)をコピーした時点でも圧縮されていて、必要時に展開して不要時に破棄したりしてる。

[@しいたけヨーグルトン]

固定ハフマン符号化＋ランレングス圧縮 初期のパソコン通信でも用いられた 処理の負荷の小さい初歩的な圧縮技術

[@francescogatti3002]

波打ち際はどうやってるのでしょうか？13:16の山が7マスのときは右端の波打ち際が無くなってるけど、14:55の洞窟の入り口の時は1マスで波打ち際が出現してます。元は4マスなので4マスで置き換えたら波打ち際は変わらなさそうかな？とはなんとなく思いますが、7マスだと切れて1マスだと出現するならどこかで「4マス以下なら波打ち際出現！」みたいな別処理をしていると想像しますが、実際にはどんな感じなんでしょうか？「海と隣接しているなら」みたいな条件だと7マスの時にも波打ち際が出現しそうなものですが、実際には違うみたいなので。

[@ロロロシメシロ]

私もそこが一番気になってました。

[@lala67jp]

画面更新するときウィンドウを開閉してますが、その方法だと左右の2列ずつくらいは更新されないので、そのせいだと思います。

[@Iron_star4]

波打ち際はデータではなく、マップ描画時に海を検知して自動で描いてるぽいです。波打ち際が描画されないケースは、ウィンドウによる再描画範囲の外だからぽいです

[@francescogatti3002]

@@Iron_star4 ありがとうございます。確かにそのようですね。

[@francescogatti3002]

@@lala67jp ありがとうございます。納得しました。

[@Y8L00]

いい内容でした、 昔BASICでプログラムを組んでいた時は圧縮に悩んでそれで2バイト方式に行き着くのが精一杯でしたｗ

[@nyankichi1504]

とてもわかりやすく、勉強になりました！

[@pmakino]

圧縮データを改変するとマップにすぐ反映されるということは、ROM上で圧縮されてるデータをいったんRAMに展開してから利用しているわけではなく圧縮データから直接描画してるわけですよね。それがまた凄い。左右移動の場合は比較的簡単だけど、上下移動の場合は何バイト前後を読めば良いのか算出するの面倒。どうやって計算量を最小化したのか気になる。

[@s009kawa]

違うかもしれませんが 画面上の(ドット単位ではなくマップチップ単位の)y座標ごとに 圧縮データのアドレス(どこから展開をはじめるか)とオフセット(展開後にどれだけ読み飛ばすか)を保持してそうだなあ、と思いました

[@s009kawa]

って問題は上下移動の場合でしたね…よく読んでいませんでした

[@shusugai]

このチャンネルの動画をいくつか見ていると、どうやらマップデータは大きすぎてワークエリアに収まらず、バックアップRAMも利用してたようですね。 あくまでも想像ですが、横1ライン256チップx15行で1画面なので展開すると3840バイトですね。 少なくとも画面内はRAMだったのではないでしょうか。 DQ2では海底火山の入り口やロンダルキア洞窟の入口、DQ3ではガイアの剣を投げ込むと溶岩で変わる地形などはROMから直接画面表示だと不都合がありそうに思えます。

[@ヒイラギ-n6u]

面白いですね～、圧縮の発想が面白いです！発想次第では色んな圧縮方法がありそうですね！

[@sauott]

圧縮は奥が深いですね！ そういえば初代スーパーマリオも各面のレベルデザインを 鬼の圧縮技法を駆使することでマッパー0の 40Kbyteにまで 収める事が出来ているとか聞いたことあります 4年前に発表されたNES新作のMicro Magesも脅威の圧縮技術で40KBを実現しているとか

[@TAKUYA_k]

と、いうデータを作るためのマップエディタを作る（確認用に必然的に表示ルーチンも作る）のに夢中になっていた子どもの頃を思い出しました（笑）

[@tac1606]

すごく面白かったです。 街の圧縮方法もぜひお願いします。

[@manekineko7657]

非常に解りやすいお話でした。 本当に教養番組でしたね。笑

[@gossa1374]

教科書によく載ってるやり方そのままだな。凄い。

[@bictaka29]

たった2文字の組み合わせでここまで出来るとか、昔のプログラマは本当に凄い。

[@ESU01USER]

私、今でもTVゲーム最高のオープニングはドラクエ３です あのオープニングの裏にこんな創意工夫が隠されていたんですね😍

[@lliccho]

いつも楽しく興味深く拝見させて頂いています☺ 子供の頃からずーーーっと気になっていることが一つあります。よかったら教えて頂けると嬉しいです。 フィールドを歩いているのをよーく見ると、数秒ごとにカックン、カックンとスクロールが引っかかるような動作をしていると思います。これは単に勇者がつまづいているのでしょうか？それとも今回の圧縮・展開と関係しているのでしょうか？ どうぞよろしくお願いいたしまーす🙋

[@cs7l4viw]

圧縮は元データをどれだけ減らせるかも重要だが、展開させるプログラムの大きさ（と計算量）も重要。このバランスを得るのが難しいですよね。ところで、「展開」する事を最近は「解凍」とは言わないんでしょうね。古くからPCを使っていると、直感的に「圧縮」の対義語は「解凍」と考えてしまったり。（LHAアーカイバあたりが語源だったかな）

[@tmn001]

おっしゃる通りLHAおよびLZHが語源です。アーカイブへの格納を凍結というそうな。

[@shusugai]

16ビットCPUの時代ぐらいにハングアップとフリーズという言葉の使用頻度が入れ替わり、フリーズが使われることが多くなるにつれて凍結、解凍と混同しないために変化したのかもしれませんね。

[@涼宮アキ]

にゃい藤……にゃんです！何も浮かばなかった感で笑いましたｗ

[@給水大臣ゆうき]

プログラマーじゃないのに最後まで見てしまった。

[@rei.5545]

13:12 付近で長さを変更しても後ろがずれないのは何故なんでしょう？ [追記] 多分行ごとにデータが分かれてますね。$8200 に並んでいるのが先頭アドレスっぽい

[@kliater]

1単位がバイト単位でうまく出来てるのが賢いと思う。

[@stlmix]

おお〜、普通にハフマン＋ランレングスだ

[@素-x2t]

16進数と2進数と10進数を一瞬で変換できるの凄い

[@トト-c9l]

大変勉強になりました。ありがとうございます。

[@zalahm629]

DQ335周年＆ぱふぱふ新発見おめでとうございました！　圧縮の仕方もとてもよくわかりました　　ほんとすごいです

[@そふぃあじろう]

上位３ビットをパターンテーブルにしてさらに最大値の１１１（７）で特殊規則にする。ってこの発想が凄いですね！！ 可変長のシリアルデータみたいだからどうやって展開してるのかも気になるところです

[@おさ企画]

マップデータを順番に読み込んで普通に上位３ビットが111かどうか判定して、分岐処理、あるいは、ワークエリアを確保してるとか。

[@shusugai]

@@おさ企画 画面上に見えてる(見せてる)部分が16x15=240 だから 256-240=16 がワークエリアとして16Bになるのかな？ 上下左右どちらでも1行もしくは1列ずつバッファしてから読み込めますね。 ファミコンは当時としては珍しくCPUとPPU(今で言うGPU)が独立していてしかも描画を担当するPPUが主導権を握っていたハードウェアなので処理落ちが非常に少なかったかなり特殊な設計でした。

[@門徒物知らず]

にゃぁるほど〜、これは非常にわかりやすいです。

[@Ch-uk5rn]

圧縮って訳分かんない関数とか使ってると思ってたけど、オモチャ箱の片付けみたいな感じで面白いですね(伝われ)

[@miblg4198]

いやー楽しかったっす、知恵ってのは凄いなってじみじみ思います。 16分あっという間だった

[@nagoyan_game]

登録者、いつの間にか１万人突破してましたね！ おめでとござます！！ さて。 圧縮術の基礎中の基礎。 可逆とひきゃぎゃく…じゃなくて非可逆があり、音楽や画像などは非可逆で、人間には分からない程度に、データを間引いていること。 同じデータが連続する場合、データを「生」で持たせるのではなく、何が何個、というかたちでデータを持たせること。 これらはその昔、情報処理技術者試験を受ける際に学習しましたが、さらに節約する術もあったんですね。 FCカセットの容量による制約で、バイト単位どころかビット単位で節約するために、様々な工夫をしていたことは、今までも本チャンネルでいろいろと聞いてきましたが、この圧縮が最たるもの、ってことですね。

[@shusugai]

当時の8ビットCPUでも文字コードの8ビットのうち1ビットはフラグとして、残り7ビットはコントロール文字として使うなどしてました。 改行、LF、画面の全クリア、文字の色や装飾は0-127 128-255はアスキー文字や記号、罫線用としてましたね。 その時代の名残でリトルエンディアン、ビッグエンディアンといった悩み事も生まれ、16ビットコードをレガシーとして排除した現在ではそういった問題は考慮する必要がなくなりました。 ユニコードコンソーシアムが文字コードの標準化のルールを定めたお陰で今後は同じ問題は出にくくなりました。

[@inteltel5162]

ストレージを廃棄する時は万力等で非可逆的に圧縮するのも有効そうですね。

[@shirou9237]

分かりやすい！ってか動画の編集めっちゃ手間かかってそう！

[@かめてつ-j7b]

４０代ぐらいのかつての勇者が群がりそうな内容ですな　笑

[@teronog]

ゲーム関係ではないですがプラグラム開発に携わる今では普通に理解できますが、当時少年だった自分だったらもっとわくわくしてのめり込みそうな話だなぁと思って見てました。

[@奥野春樹]

マップの圧縮ってピクロスの数字みたいにしてたのか

[@issismob]

ここまではわかるんだけど　海岸の線とかはどういう仕組みなのか気になっていた。 今回の編集を見てると陸地と海で自動で線が引かれるようになってるのかな。

[@kt2282]

圧縮方法がZIPファイルで聞くような圧縮の仕方とまるで同じだぁ 同じ物が大量に続く場合に強い方法！

[@heromiya]

これはRLE (Run length encoding)、授業で実装したな、懐かしいなと思いながら見てたら、最後に出てきてほっとしました。

[@s190309]

素晴らしい　　でも、このマップだけで圧縮後に約7000b=7kbでしょ？　調べたらファミコン版の容量はDQ1/2/3=64/128/256kBだから、これだけでは収まらないので更に他の手法を使って圧縮されてるんだろうな

[@ichgokan3468]

昔バイナリ編集ソフトを使って ネットに載っているままワケも分からず書き換えて「イケナイ事」していましたが 1Fとか83とかはそんな感じの意味だったんですね 何でこんな2桁のカタマリで動いているのかと思っていましたが 上っ面だけだけど勉強になりました

[@ayu_CREA]

マップ圧縮はいわゆる、ピクロスと同じことをやってたんですね ベースとなる1マス分のドット絵も、もしかして同じ方法で圧縮されて格納してるんですかね？

[@rollegg7188]

ライブラリが無い時代に、こうやってアイデアで容量を減らしていくの凄くて感動します。

[@hypercat128]

なるほど。ランレングス圧縮機能を内蔵していたのか。データを展開するときも、RAMが少ないだけに、苦労があるような気がする。 今のような、汎用の圧縮機能を使えない時期だけに、深い知識が必要な時代だったのだね。 海のチップは、海岸線に応じて何パターンかあるようだが、データとしては１種類で、隣接するチップのIDに応じて表示するものを選んでいるように見えるのも、興味深かった。

[@kt2282]

途中で全体の長さが変わるような変更加えちゃったけど、その場合辻褄合わせはどうしてるんだろう？

[@linus8976]

面白いです。ありがとうございます。

[@hiwata6251]

ものすごく面白かったです。 山が7個の時に、右端の山に海との境界の波打ち際っぽいのが無いように見えますが、これも何か理由があるんでしょうか？

[@minoruisobe7758]

頻出7チップの中に毒の沼地がないってことは、 ネクロゴンドの洞窟手前の沼地とかは一個ずつ置かれてたんですかね 砂地みたいに何かの条件で他のチップと番号共有してるのかな

[@いいをあきよし]

圧縮といえば以前のバージョン違い比較で出てきたぶーちゃん氏とやり取りしてた経験値テーブル。 ・ひとり６バイト ・ファミコン様にやらせると時間がかかる これもやってくれると嬉しいですね。 たった48ビットで２〜９９までの数値をどうやって押し込めたのか？

[@ibubara]

それ僕も気になってました。レベル45以上は必要経験値が固定になるので、実質レベル44までで良いとしても、6バイトというのは驚きです。圧縮というより、必要経験値の計算式のパラメータが6バイト分あるっていうイメージなのかなと想像しています。あるいは、レベル帯ごとの上がりやすさみたいなのが6バイト分のパラメータとして設定されているとか。ぜひ解説してほしいです。

[@ak2channel]

C言語でいうところのビットフィールドか、懐かしいな。

[@柊葵-g5s]

マインクラフトのＭＯＤ作り実況とかも需要ありそう。

[@にゃんじろう-f5c]

なんかの本に、可逆圧縮→布団圧縮袋　非可逆→布団の綿を抜く　って解説してて非可逆の圧縮率たけぇなって思った思い出

[@上條芳雄]

なるほど。当時はROMがとても高価だったため、少ない容量にさまざまな要素を詰め込んでゲームの内容を充実させながら価格を抑えるために圧縮は必須だったわけですね。 ドラクエⅢではバッテリーバックアップがついたついでに組み替え自由なパーティー、カジノ、裏マップなど色々な要素を入れた結果タイトル画面が削られてしまったのは残念でしたが、あの内容で256KBしかない。っていうのは今考えると凄いとしか言いようがありません。

[@KUGYUOJI]

やってることはドラクエ2と同じなんだけど、昔解析したら確かあっちはチップが4bit、残り4bitで長さを表現してたはず。アイデア一つでさらに発展するのは目からウロコ。 塔、洞窟はチップ5bitマスク3bitかな？ロンダルキアの洞窟のようなマスクまみれの詰め込み方はしてないと思いたい。

[@minoruisobe7758]

FC版の1は全部チップ4bit、長さ4bitだった マップデータ書き換えたら町とか洞窟とかも横にずらっと並ぶよ 入ろうとしたら「ここでは　はいれない。」っていう見慣れないメッセージが出てきてビックリした

[@holokirisamurai]

ファミコンで発売された全タイトルの容量が340Mってことを考えると 当時のプログラマーの苦労が透けて見えるな 今だとOPのムービーで余裕で超えそうだもん

[@muu3]

海との境界線のパーツは自動配置なんですかね?

[@Iron_star4]

そうですね。自動配置であって、データとしては持ってないですね。

[@taib0u]

これプログラム勉強してる当時学んで知ってた。学んだのはロックマン２改造してる くわたさん。その人は独学でデータ見て法則を見つけていったそうです。 今でもフィールド書き換えようとした事あるけど自分の実力じゃまだ無理＞＜

[@mtoshiaki8635]

過去最大にデータ圧縮しているのはどのゲームなんでしょうかね？　昔メガドライブのシャイニング＆ザ・ダクネスやシャイニングフォースがすごい圧縮してたような…

[@159andy]

圧縮したデータを展開してそれを一時保存しておくワークエリアがバックアップ領域ににあったのでしょうか？（そのような事を以前言っていた気がします） てことは移動する際に一歩毎に展開するのは効率悪いので、それなりのワークエリアが必要？実際にはどのくらいの大きさだったのか知りたいです

[@jsr7909]

前作DQ2では川辺（海パーツだけど細いところ）には海岸線がなかったので処理が違うのですね。2は海岸線もデータとして持っているんでしょうか。

[@hyu954]

膨大なデータ2Mbit

[@akkyprofile]

1Byteに情報を詰め込む技をみました。すばらしいです。

[@tanatomo]

RADIコミで内藤さんによるRLEの解説を聞いたような記憶が……

[@ヨハンボルシチョフ]

この圧縮方法がなかったらドラクエⅠも発売されることはなかった

[@okim8807]

すごE。 横に同じ地形が続けば続くほどデータの圧縮率が上がってわけか。 天才か。 バイト毎で切れてるから展開（解凍）の計算も比較的楽、と。 今JPG画像が1M、2Mあるのは当たり前だけど、DQ１～４はそれより小さいんだよね。DQ5でようやく1.5M。

[@ヘイコム-o6r]

当時のデータ容量の節約術がすごい。

[@korp0620]

個数を変えると並べるチップの数が変わるけどその時はどうなるんだろう？

[@folosuru9437]

Gif方式みたいだと思いました

[@真珠恵瑠]

99kbに圧縮された3D Action gameあったな。動画も込みだったはず

[@brainbrown]

オススメに上がってきて初めてチャンネル開設してるのを知った(笑 お久しぶりです。お互い、顔に貫禄が出てきましたなぁ(*￣m￣)プッ 物凄く解説が上手。解り易かったです。

[@youtsube09]

海岸線の処理が気になった。

[@敗北王測試用頻道はいぼく]

可逆壓縮就是複製 剪下貼上拼貼 3:51和rpg遊戲製作工具一樣的「タイル」太醫嚕

[@sarasate777]

ということは、マップは横方向に圧縮しやすいようにチップを配置していったんでしょうか？

[@webisuvip]

詳しいことはわからないけどファミコンの描画技術的に横方向の方が都合が良かったんじゃなかったっけか

[@80fire71]

1ビットを使い尽くした先人の偉業に思いを馳せる 暗号通貨のブロックチェインも相当な圧縮を…？

[@LinksBareLeg1]

ランレングス圧縮ってよく出てきますよね。 今だとメモリ容量とかも膨大でこんな制約も無いので、今のゲームはベタで入ってるのが多いのかな？ それともまだ使われているんですかねえ？

[@Iron_star4]

こんなシビアな圧縮はしていないとおもいます。安易なデータの持ち方をすると解析されるので、暗号化する側面が強いかもです

[@LinksBareLeg1]

@@Iron_star4 さん あと思ったのですが、ランレングス圧縮はシンプルだから軽く、ファミコンみたいな低スペックなハードでも展開がし易いのが良いですね。 効率的で分かりやすい圧縮方式だと、ハフマン符号圧縮というのもあって、こちらもよく出てきますね(大学時代授業で少し出た覚え)。 データが常に二進数の0で終わる様に決めておいて、一番数の多い物を0、次に多い物を10、その次が110、更に次が1110と記載する方法です。 ドラクエだと海や草原などに短いバイナリコードが当てられて、毒沼などになるとコードが長くなっていき、お城や村などはすごく長くなりますね。 こっちとランレングスだとどっちの方が圧縮率が高いかなー？ どちらにせよゲームを改造とか解析とかする時、当該データ領域がどこで、どのアルゴリズムで圧縮していてというのが分からないと、難しい様ですね。 前にこのチャンネルで見たゾーのマーさんじゃないですが、某ゲームでグラフィックの表示がちょっとモヤッとする物が1作品見かけて、直せたら良いのにとすごく思ってるので、気になっとります。

[@ayu_CREA]

かつてのCD媒体のゲーム機(CD-ROM2など)は音楽ファイルがそのまま入っていて、ゲーム音楽を音楽CDとしてリッピングできたので、それらはこれに類似した圧縮はされてないんでしょうね ただし、PSは音楽CDとしてリッピングできなかったので圧縮されてるのか、そもそも音楽ファイルの形式が音楽CDのような汎用形式ではなかったのかのどちらかかと思います

[@udon255]

@@ayu_CREA リッピングできない音楽は内蔵音源(24chのADPCM)で鳴らしているものだと思います CD音源だとリピート時に音が途切れたり、再生中はデータのロードができない等のデメリットがあるので

[@moyomon5438]

映像画像音声は一般的な方法で圧縮されてますが、メモリ展開したらベタでしょうね 逆に展開コストもないので、ひょっとしたらグラフィックチップ内では再圧縮してたりするやもしれません

[@toufuji]

ドラクエ3で遊び人が賢者に転職できるの 仕様じゃなくてバグって本当なんですか？

[@shusugai]

それはないはずです。 さとりのしょは公式発表されるまで期間がありましたが、遊び人は発売当初からあるいは取説にも賢者になれるのが特徴と書かれていたような気がします。

[@安斎達也]

しょっちゅう出てくるチップに砂地が入ってないからイシス周辺の容量すごそう！

[@watashi-wa-tawashi]

15:35で氷と砂は共有してるって説明してるで

[@decodeco1025]

チップ1が氷と砂の共有で、どちらを表示するかは緯度によって決めているようです。 赤道に近い緯度なら砂、それ以外なら氷という処理を入れてますね。

[@ichiro.t4755]

わかりやすいですよ。ドラクエは音楽が大御所のあの人だから劣化(非可逆)させられなくて容量が厳しそうなんですけど。実際どうなんですかね？

[@レイクロック兄弟]

すっご

[@D10245N]

ダンジョンが2マス単位構成になっているのも圧縮の為か（1マス単位構成と比べ1/4） それだけ容量がきつくても、アッサラームのぱふぱふ屋、ぼったくり商店、遊び人の遊びとかはしっかり残してくれる。

[@takazoozoo]

ランレングスとハフマン符号やん

[@TsucaPon40]

そもそも圧縮技術がなかったら、少ない容量で長時間の録音は無理じゃなかったかと…。 例えば、MP3で圧縮した場合、128kbpsの場合、64MBのメモリーカードで55分くらいの録音が可能です。 非圧縮リニアPCM（16bit 1,411kbps）の場合、わずか5分くらいの録音でメモリーカードが一杯になってしまいます。

[@satoshiremixed]

83hは2進数で書くと10000011。私の頭での中では1000/0011だと思っていたが、今日の動画では100/00011だった。それって、43h？混乱してきた。。。

[@satoshiremixed]

@@nyaa9088 4bit4bitに分かれているのは単なる「表示」であって、その8bit自体は自由に分割して使えるということ、と理解しました。教えて頂きまして、ありがとうございます。

[@bravex-2]

ビットシフトの問題ですね。 0〜4bitはマップチップ数 5〜7bitはよく使うマップチップID

[@moyomon5438]

人間が読めるように短く83って書いてるだけで、本体はただの10000011ってことですね。 10000011をどう使うかは設計しだい（＝展開）