みんな大好きM5Stackで、みんな大好き?ゆみみみっくすのオープニングムービーを動かしたお話!
このところ、レトロPC上でゆみみみっくすのオープニングムービーを動かしているツイートを連続して何件か見た!懐かしいなぁすごいなぁ…と思ってしまったら……自分でもやってみたくなるw
そういえば、過去にBad Apple!!を動かした際、グレースケール版も作ってみようと思って頓挫してた事を思い出した。ビット深度が深いという意味ではグレースケールもカラーも同じようなもんよ…という理不尽すぎる解釈から、いっちょやってみるか!となった(^^)
日曜(サンデー)プログラムの感覚でいるから、1日または長くても2日で作りたい!
そういえばゆみみみっくすは、メガドラCD版をゲームの最後まで終わらせているはずだけど、ストーリーを全く覚えてない…うむむ??
ゲームそっちのけでCinepakの解析をしてたからかな……
とりあえず机上で検討
そもそもムービーをどこから持ってきたら良いのか…というところで、まずはつまづく。
メガCD版のソフトは持っているけれど、動かせる実機がない。
実機があったとしても撮影する機材もない。
今回はYoutubeにあった動画を利用させてもらうことにした(ごめん)。
動画自体が3分34秒あるので、214秒=6420フレームくらいのデータ量になる事が見込まれる。これをどう管理するか…。
データはどう圧縮するのか…。
メガドライブの色は512色中64色が表示可能らしい。…ということは64色で表現しても遜色ないという事か。
SDカードからの読み込み速度も気になるところ。過去の実験で1024KB/秒ほどの読み込み能力があるのは分かっているけれど、あの時の高性能SDカードはいずこへ…orz
うん、検討してみた結果、作ってみないとわからないとなった!(^^;;
↑無計画すぎる
まずは動かしてみる!
仕組み的には、1つの動画ファイルをそのまま再生するのではなく、1枚1枚の絵を高速に表示させる事でアニメーションっぽく見せる。
動画ファイルをjpegに分割するのは、ffmpegコマンドを使えば簡単に出来る。
ffmpeg -i yumimi.mp4 -vf scale=320:-1 data/%04d.jpg
そして出来上がった、おびただしい数のjpegファイル…その数6411枚!
このファイルをどうにか加工してM5Stackへ入れなくてはならない…。
まずはjpegファイルを320x240x24bitのRAWデータに変換して加工しやすいようにする。
jpegファイルは、libjpegというライブラリを利用すればワリと簡単に扱う事が出来る(^-^)
このRAWデータのままだとサイズが225KBもあり、そのままM5Stackに置いとく事も難しい。減色および圧縮の方法を考える。
方法としてはこうだろう。
まずは64色まで減色してみる。
その上で出来上がったデータを圧縮する流れだ。
元絵が64色で描かれているのならば、遜色のない絵ができあがるはずだ。
減色
私の時代(?)にはカラーリダクションとか言ったけど、今はなんて言うんだろ??
そういえば減色ツールなんてエラい昔に仕事で開発したっきりやってなかったっけ…。アルゴリズム含めてすっかり忘れてる(^^;;;
当時のプログラムを見てみるとmediancutなる名前が関数名につけられていた。うーん、苦労した覚えはあるけれども、ソースみてもアルゴリズムが思い出せんw
まぁ動けばいいっしょ!←をぃ
↓こちらが元絵
↓こっちが減色後の絵
ちょっと気になるところはあるけれども、M5Stackの小さな画面で見たらきっと気にならなくなる……はずだ!(^^;;
ちなみに減色後のデータを見るツールも即席で作った!
タイトルがFont Viewerのままになってる辺りで急ぎ加減が分かるw
ツールも含めて土日で作り終わらなければ日曜プログラムとは言えないのだ!!
データ圧縮
データ圧縮については少し困ってしまった(T-T)
Bad Apple!!の時は基本的に白黒しかなかったので、圧縮アルゴリズムはランレングス一択だったのだが、今回は色情報を持っている事からデータが複雑だ!
↑こんな感じの絵は、横方向へのランレングス圧縮が効きにくい。
仕方ないのでいくつかのアルゴリズムを組み合わせた圧縮ツールを作る事にした!要は一番効率の良いアルゴリズムをその場その場で採用するような感じの手法。かつ展開速度を担保するために、ビット単位ではなくバイト単位での圧縮とした。
圧縮後のデータサイズを小さくするため、データのMAXを64KBという制限にした。そのため、320x240のデータを上下分割して、320x120のデータ2つとして扱う。
M5Stackで画面描画を行う際、320x240を一気に描けない制限ともマッチするので、これで良いか、となった。
元絵のデータが320x240(75KB)+パレットデータ64色(128バイト)で76,928バイト。
圧縮後のデータは最低で746バイト、最大で35,772バイトとなった。
そしてすべてのデータを1つのファイルにまとめた事により、127,007,871バイト(121MB)という巨大なアニメデータが完成した!元のmp4が10MB無いのに!(T-T)
1つ前の絵との差分を取れば小さくなるのは分かってたけど、今回はスルー(^^;;
そして出来上がったのがコレ。
日曜プログラムでゆみみみっくす!
— PocketGriffon (@GriffonPocket) 2023年2月26日
SDカードから圧縮されたデータを読み出しながら表示させてるけど、速度が追いつかなーい!
コアは2つともフル稼働。
でも効率はイマイチかも(^^)
音楽鳴らしたいけどどうやるんだろ?#M5Stack pic.twitter.com/bKNyuySFcv
コア0で圧縮データの展開、コア1でSDカードからの読み込みと描画を担当。
コア0の方がちょっとだけヒマな感じ。
描画にはLovyanGFXを活用させて頂いてます!
圧縮データと圧縮を展開したデータは、大きさ的な関係で内部RAMに置けなかったので、(速度の遅い)PSRAMに置いた。
画面の端にノイズが乗る事が多くてチカチカしてしまうので、画面の上下をデータ上で黒に塗りつぶした。
SDカードは高性能なタイプが手元になく、ノーブランドのモノを使用。おそらくブランドのものよりも2割くらい読み込み速度が遅いと思われる…。
ツイートして完了!と思ったけど、なんだかモヤモヤしたものが…。
もっとキレイに作れるのではないか……と思ってしまったのだよ…。
作り直してみる!
プログラマたるもの、気になる事が残っていたら直さないわけにはいかないだろう!
たとえ日曜プログラムであっても避けられない習慣なのである!!
表示領域を280x224にしてるけど、実はこれだと64KBに収まる
コアを2つ使うためにダブルバッファリング化してけど必要?
減色プログラムを改良したい
表示までに掛かる手間を減らしたい
↑で「画面端にノイズが出たので消した」と書いたが、実はデータ上では単に黒い領域として残ったままになっていた。
表示サイズを計算してみたところ、280x224 = 62,720バイトとなり、パレットのデータを含んでも64KB(=65,536バイト)に収まるじゃん!となった。
これをやると……データ生成ツールまですべて作り直しになるんだけど…orz
……うーん…でもやるか!
フォルダも新しく作り直してyumimi2とした!(改造ではなくて新作成!)
この際なので……ノイズが微妙に乗って気になってた減色ツールも改良した!
25年以上前に書いてたツールという事もあり、当時のコンピュータで現実的な速度で動かすために精度を犠牲にしていたところが多々あったのだ。
精度を上げるようにコーディングし直したところ、ノイズが出にくくなった!
そしてツール類を一新した。
前のバージョンでは、減色、圧縮を別のツールにしてて手順も面倒だったが、新しくしたツールでは減色と圧縮を同時に行うようにした。このおかげで6411ファイルの更新に30分くらい掛かっていた作業時間が、19分まで短縮された!
土日しか時間がないから、何度もテストが出来ないのだ(T-T)
コアを1つで実行するようにした。
このおかげでバッファを複数持たなくて済むようになったため、すべてのバッファを内部RAMに入れる事ができるようになった!
複雑なシーケンス制御が無くなった事もあり、68msくらい掛かっていた表示が、35msくらいまで速くなった!(^-^)
ゆみみみっくすの動画プログラムを一新したところ、処理速度が2倍くらいになったよ!
— PocketGriffon (@GriffonPocket) 2023年2月26日
減色を改良したのでニラニラしづらくなった!
何の役にもたたないけど、これぞ自己満足の世界だー(^◇^;)#M5Stack pic.twitter.com/x0ss1HxN6J
そして出来上がったのがこちら↑
ツイートしてみたが、見る側にとってはほとんど何も変わってないという…orz
いいのだ、これぞ日曜プログラムの醍醐味だ!←多分違
おわりに
データの用意から減色、圧縮、実機へ持ってきての表示という作業を、はからずしも2度やってしまったワケだけど、意外に出来ちゃうもんだなーと思った!(^^)
しかも土日の用事もしっかり済ませた上で作業してるので、実質はもっと短い。
このくらいの作業量が老体にはしっくりくるかも!(^^;
あと気になってるのは音楽ですねー……。
M5Stackでどうやったら鳴るんだろ??意識した事すら無かったよ。
ではまた次回!(^-^)ノ