第二次補完
ホワイトアルバムのOPをX680x0で！

６がつ２にち 発動
さしあたってPAKファイルのフォーマット。 データはリトルエンディアンらしい(当然といえば当然)。
 Offset 0
    エントリ数(4バイト)
 Offset 4〜
    ディレクトリエントリ(エントリ数*sizeof(DirectoryEntry)バイト)
      struct DirectoryEntry
      {
        char name[16];
        long size;
        long unknown;
        long offset;
      };
 Offset 4+エントリ数*sizeof(DirectoryEntry)〜
    データ

６がつ３にち 結構面倒だ・・・
パレットファイル(C16)のフォーマット。
 Offset 0
    エントリ数(2バイト)
 Offset 2〜
    パレット(エントリ数*sizeof(Pallet)バイト)
      struct Pallet
      {
        char pal_no;
        char blue;
        char green;
        char red;
      };

６がつ１０にち 準備完了
念願の画像(GRP)フォーマット(試してないので完璧ではないカモ)
 Offset 0
    ファイルサイズ(4バイト)
 Offset 4
    展開後画像データサイズ(4バイト)
 Offset 8〜
    圧縮データ

実にこれだけ。ポインツはOffset 8から圧縮データが始まっている事ね。圧縮については以下。

1.フラグを1バイト読む。
2.フラグを下位から1ビット読む(読んだら捨てる。なくなったら補充)
3.フラグが1の場合4へ、0の場合5へ。
4.1バイト書き出す。2へ戻る。
5.1ワード読み込む。
6.最下位ニブルが$fならばもう1バイト読む。そのニブル(と読み込んだ値)に3足したものがコピーバイト数。
7.読み出した1ワードを右に4ビットシフト(最下位ニブルをデリート)した値がコピー開始のオフセット。
8.コピーして2へ戻る。

コピー用のバッファは0x800バイトの環状バッファを用意してこっちも展開データと同時に更新していけばOK・・・みたい。

出来上がったデータは以下。
 Offset 0
    Xサイズ(2バイト)
 Offset 2
    Yサイズ(2バイト)
 Offset 4〜
    ラスタデータ

MC68000用に作るとこんな感じかな？

６がつ１２にち ローダ完成
なんとなくローダが完成した。ちなみに、上のサンプルも修正。

６がつ１５にち 訃報
X68000のHDD昇天(T-T)
フリーウェアと自作ソフトで構成された我がマシンを復活させるのは至難の技であるため、開発はペンディング決定。
教訓：バックアップは忘れずに

６がつ３０にち 再開するのこと
とりあえず、CCなのが何とか終わったので再開する。
ざくざくと作り、とりあえず由綺が手を振ってるとこまでやる。 つまりアニメーション(高速画面切り替え)部分までを作ったわけだけれど、 ちらつきを恐れた為V-SyncのWaitを挿入したらなんとなく遅いなぁ。 ちなみに、原版の方はとっても速すぎて多分画面に表示されてません(-_-;; あ、スポットライトの部分ね(3枚使ってます。リブレットだと見えるし;;^^)
で、MC68000での動作速度が気になったので実験してみるとバスエラー。 あり？アドレスエラーなら分かるんだけど・・・。

７がつ１にち バスエラーとの死闘(?)
バスエラーの原因を究明するべくデバッガを起動する。 ちなみに、このデバッガは030モードに対応していないのでノーマルモードのデバッグしか出来ないという・・・(対応しているのを私が持っていないって事です)
で、やっぱり出る。エラーメッセージは「$D00000番地にアクセスしたから校則違反よぉ」って感じの内容。 確かに256色モードなので$D00000番地は未実装エリアになるねぇ。うんうん。とか考えながらソースを見る。

    movem.l (a0)+,d1-d4

ふんふん。で、a0レジスタは$CFFFF0ね・・・ん？？なんでエラーになるのん？？

説明しよう！ movem命令はレジスタメモリ間の一括転送命令である。 例の命令の場合a0レジスタの示すアドレスから16バイト分(レジスタ4つ分)をd1,d2,d3,d4レジスタにコピーするという処理が行われるわけである。

というわけで、計算すれば分かる通りa0レジスタは$D00000を指す(ポストインクリメントのため)もののアクセスは行われないはずである。 謎である。
長すぎるのでそろそろ終わる。結局、解決策というか私の取った対策は、

    movem.l (a0)+,d1-d3
    move.l (a0)+,d4

これでエラーが消えた。なんでやねん(T-T)

７がつ２にち メモリが足りない
処理速度から逆算してデコードを最初に行っておかなければならない部分を計算してみるとどうやら6MB程度必要になりそうである。 これでは全然普通のマシンで動くスペックでないので困る。
とりあえず、オプチマイズを試みる・・・が、やる前は「リアル麻雀オプチマイズ」でいけると考えるものの、 環状バッファの事を考えるとかなり厳しい。で、断念。

説明しよう！リアル麻雀オプチマイズとはX68K版スーパーリアル麻雀のアニメ展開で使っていた方法のことで、 各々の連鎖数によってコピールーチンを持つという・・・ つまり、コピー数分の転送命令を列挙して条件分岐をなくすわけでキャッシュレスのマシンにしか意味の無い手段である。 030では確実に遅くなる。こんなんはオプチマイズじゃねーってば。

となると、HDDにテンポラリ作ってガシガシ読み出すぐらいか・・・。 えと・・・最後の縦スクロールが720KBだから、X68Kの読み出し速度を考えると・・・1秒以上かかるぞ、おい(T-T)

７がつ４にち C言語のがやっぱり楽だぞ
処理速度が明らかに足りないのは分かってはいるものの、アセンブラでガリガリ書くにはもう体力が足りなさすぎ(T-T)。 いつでもC言語に移行できるようにサブルーチンをスタック渡しに書き換える。
が、いまんところX68KにCコンパイラがインストールされていない事を思い出し後悔。

７がつ６にち やっと修正が終わるのこと
C関数化(なのか？)がほぼ完了。 スタック渡しにした為、単純にコードサイズは増えたもののとりあえず見通しはよくなったな。 でも、スタック操作ミスると大変なんだよな。 実際、めちゃめちゃバグ出るし(T-T)
とりあえず、ホワイトアウト(っていうのか？)の処理はかかし師範に教えていただき、なんとなく実装。 んー、遅いですね ＜ ギジツ力無さ過ぎ
あとは、エフェクトの走査方向が垂直方向なので水平方向に変更しないといけませんね ＜ 迂闊モノ
メモリはとりあえず気にせず作る事にしよう。さすがに、12MBが尽きる事はないだろうから。

７がつ７にち みしゃきしゃんとうじょう
とりあえず、みしゃきしゃんのとこまでやる。みしゃきしゃんまではできてよかった(*^_^*)
エフェクトの走査方向の件に関してはかかし師範より、

おろかもの！ラスターコピーを使え！

とのありがたいアドバイスをいただきへろろーんと修正。さすがですかかし師範。X68Kにも詳しくていらっしゃる。

とりあえず、説明しよう！ラスターコピーとはテキストVRAMの4ドット単位のラスターを増殖させる機能で、 テキストの高速クリア、テキストのスクロールなどに利用されるものである。 今回の場合、4ラスタ分だけ書き込んでそれを119個コピーするだけでOKという大変らくちんな修正で終わってしまうのだ。
クロックアップしたマシンはまずここでこけてしまう(IOCSの実装ではウェイトがnopだかで入っている為)ので、 結構知っているユーザーも多いはずの機能其の1。

７がつ８にち なんかデコーダが変
とりあえず、「由綺の目が開くところ」と「雪を降らす」という面倒なの2つを残してほぼ実装が終わったんだけど、 どうやら一部のグラフィックにデコードミスが見受けられる。 こゆのは辞書からのコピーミスのはずなのでその線で調べてはいるけどなかなかしっぽを出さない。 全く困ったもんだ。

７がつ１０にち デコーダなおる
結局環状バッファの更新ミスでした。 要するに、環状バッファ内から環状バッファ内へのコピーを行っていた為ポインタの位置によっては正しく更新されなかったと・・・ (展開したデータからコピーするのが正しい)。全く情けない限りです。 ループが増えてしまったのでちょっと遅くなってしまったし(;_;) とりあえず、最新版のデコーダはこれ。Cから直接呼べますです(多分)。 読みにくいとか、変なラベルとか言う突っ込みはウケツケマセン。
あとは、いよいよ目と雪だね。目はいいとして、問題は雪だな、やっぱ。スプライトなんて使った事ねーよ(T-T)

７がつ１１にち 目が終わる
目だ。目をやるぞ！目は多分GADとかいうファイルがあるのでそれに違いない。 どうせ、GRPのデコーダで展開できるはずだ。
というわけで、そのままです。 GRPファイルとしてデコードすると、エントリ数、オフセット、データの順で格納されたGRPファイルの塊です。
つーわけで、バカ正直に1枚ずつ表示してみる。

    うわ、めっちゃおそい・・・

X68Kでは限界なの？半泣きになる。

    ・・・もう一度よく考えてみよう。

というわけで、引っ張っても仕方ないので結論。

    １．ベースグラフィックが5枚あります。
    ２．目パチ用のデータが25枚(GAD内に)あります。
    ３．目パチ用のデータは目の開き方で5種類あります。

そんなわけなので、処理速度は十分ですから。はい。
後は雪。

７がつ１２にち 半透明が欲しい
雪。一番最初に降るやつ。半透明使ってるじゃん(T-T) メッシュだと思ってたから楽勝とか思ってたらまた厄介なものを使ってくれる。
言うまでもなく、X68Kにも半透明はある。あるんだ。そんなことは知っている。
しかしだ、使えないんだよ。 別に、テキストでロゴの表示を手抜きしたことによりプライオリティが変えられない所為じゃない。 X68Kの制限なんだよ。半透明使うときは色数が半分になっちゃうんだよ。仕方ないじゃない・・・。
というわけでちょっとの間、研究するです。今までできた分だけβリリースだす(誰が見るんだ？)。 対応はXVI以降。10MHzのMC68000ではムリです。また、空きメモリが6MB必要です。 メモリチェックしてないので足りないと落ちます。 多分、最初の由綺ちゃんと弥生さんのシーンが一番メモリ喰ってます。

使用法
カレントディレクトリにWAOP.PAKを置いて、CD-ROMをセットしWHITEOP.Xを実行でOK。 雑誌の付録とかでやる場合、曲番がずれる場合があるので-P[n]で指定できる。 また、15KHzモードでやりたい場合は-Lでよし。
WAOP.PAKはホワイトアルバム(またはデモ)をWindowsマシンにインストールしないと入手できません。 なんとかしてWindowsマシンでWAOP.PAKを作成してください(違法コピーはだめよん)。

７がつ１４にち ながいみちのり
減色を調査中。そんな事やってると、目の前でのべ巨匠が仕事で減色してるし。いや、ここでは関係のない話だな。
つーわけで、まず、単純に思い付くのが何色使ってるかって事ですね。で、チェック。

214色です(;_;)

となると、次は同一パレット探しですな。 X68Kで表示する場合6万色に減色しますから、同一パレットが出る可能性があるわけです。 まぁ、214色って時点で負けかなともいえますが・・・
で、結果は・・・

193色です(T-T)

・・・とりあえず、4096色(各プレーンを4ビットずつ)にすれば122色で収まるようなので、そうする。 FM-77AVが出た当時は「うぉー！めっちゃきれいだぜぇ！」って言ってた事を考えると十分である(真剣にとらない事)。

で、半透明の実験・・・したんですよ。 するとですね、透過色(なんか変な言葉だな・・・)がないんですね。あたりまえなんですが。 つまり、黒背景を重ねると明るさが半分になってしまうってわけですよ。そりは困ります。 どうしようねぇ？

７がつ１５にち 人間あきらめが肝心
というわけで、半透明はあきらめます。 テキストで色補強とも考えましたが、それはそれであまりにも不毛なのでやめます。 せっかくなので特殊プライオリティとか使ってこそこそやりたかったんですが、 何も出来そうにない(背景黒だから)ので普通に重ねます。
とりあえず、スプライト下位にするかメッシュにしてスプライト上位にするか・・・。 後の事考えればスプライト上位のがいいやね。

そういえば、一番最初のロゴの出現部分はテキストでマスク掛けてスクロールさせてるあたり、 かなりいい加減なので直しておかないといけませんね。

あと、メモリ効率が悪すぎたのでゴソゴソ直したら5MBで動く事が判明。 テキストVRAMのマスクをなくせばさらに512KB余裕(？)が出来るので、4.5MBか。 とりあえず、目標は4MBかなぁ。HDDに書き出せばなんとでもなるのではあるが・・・。

ついでに、いっておこう。EX68だと動かないんですよね。 タイミングをONTIMEでとってるんだけど、これを使うと止まっちまうんですよ。 まぁ確認するだけの暇とテクニックがないので放っておこう。
SCDとかでスクロールしてるとだんだん遅くなるとか、 サラマンダの3面でだんだん処理が遅くなってって最後は止まってしまうという現象と関係あるのかな？

７がつ１８にち スプライトって難しい
スプライトを使う。 「はじめてだからやさしくしてね」とか、シェルミーみたいなタワ事いいながらパコパコプログラムする。 グラフィックの解凍と展開、エフェクトなんかと同時に処理する様なぐれぇとなプログラムは僕には書けないよ(泣) というわけで、軟弱にもVDisp割り込みを使う事が決定。
しかし、なんやね。割り込みのデバッグというのは何度やっても泣きそうになります。 だれか、いい方法教えてください(泣乞)
というわけで、スプライト。 まずは表示しなくては始まらないのでデバッガで適当にパラメータを書き書き・・・バスエラー。 はにゃ。画面モードがあってないとスプライトメモリはマップされないんですね。メモメモ。
気を取り直して、適当に画面モード設定して表示。 なんか出る。が、場所が変。なんでじゃ？ よく調べると、スプライトレジスタ用にディスプレイ設定用レジスタがある。 んー、X68Kのスプライトはラスタスプライトだからいるんかねぇ？ よくわからん。まぁ、これは設定すればOKなので終わる。とりあえず、メモメモ。
ここまでいけば後は降らせるだけ。とりあえず、落下するだけでいいので作る。 が、ここで問題。乱数が欲しいじゃない？ あんまり知識のない私的には線形合同法ぐらいしか思い付かず実践。 あうぅ、下位ビットだけを使ってたら周期が早すぎて使えないですぅ(泣) 仕方ないので、なんとなくごまかして本日打ち切り。

７がつ２２にち EX68でも動くもん
EX68で動かない理由はIOCSのONTIMEにある事は分かっていた。ってなわけで、ONTIMEを調べる。 ・・・で、確信は持てないけれどONTIMEエントリで割り込みを停止するのだが、これが悪影響を与えていると判断する。
つーわけで、それなりに動くように修正してみた。 開発中なので垂直に雪が「落ちてくる」のはご愛敬(こっちはもう少しかかる)。 当然EX68では音楽は鳴らない(はずだ)。

７がつ２５にち 最近進まない
とりあえず、開発も終盤って事でだれてくる。 雪の落下をサインカーブを描くようにする。当然テーブルを使ってる。 まぁ、大方の予想通りサインカーブが綺麗すぎて不自然。
しょうがないじゃん。

７がつ２７にち 雪雪雪・・・
雪ばっかやってるなぁ。雪の落下パターンを4パターンにした。 あと、最初の雪(タイトルのとこ)と最後の雪(木のとこ)で処理を分けた。
つーわけで、最初の雪はメッシュになるように変更。 ここではぷにんぐさまー！色が怪しい。 メッシュのためにスプライトパターンを書き換えるのだけれど、 この変更をバイトアクセスで処理した為、隣接バイトに影響を与えてパレット番号がおかしくなっていたみたい。 結局、スプライトレジスタはワードアクセスしないといけないらしいということで決着をつける。 メモだな。

のこり
・画面下の方で雪が消えていく(最初の雪)
・雪の大きさがちょっと変わる(最初の雪)
・雪がだんだん大きくなる(最後の雪)
・雪のフェードアウト(最後の雪)
・アニメーションのウェイト
・メモリの節約

７がつ２８にち 最終β
自作ソフトっていいな。いくらβ出しても怒られることないしぃ。 そゆわけで、最終β。
最初の雪で大きさが変わる処理と、メモリの節約が終わってない。あと、タイミングやら、細かいチェックなど。

とりあえず、見て分かる原版との違いについてまとめておこう。
１．解像度が原版640x480x8bitが512x512x8bitに
２．最初の雪が半透明でなくメッシュ
３．最初の雪が画面下で消えていくのが階調落しで実装

しかし、2ヶ月もかかっちまいましたね(泣)

１０がつ１０にち ブリザード消ゆ
030モードで動かすとちゃんと動くのに68000モードで動かすと雪がブリザードになっちゃうんです。 なんででしょう？っつーわけで、調査しました。
・・・バカです。アホです。クズです。こういう奴はプログラム組んではいけないです。

インデックス付きプログラムカウンタ相対のディスプレースメントが8ビットを超えてるです(T-T)

つーか、ソースの先頭に.cpu 68000が無いです。何たるテイタラクといいますか、気付よボケ。
要するに、どノーマルではディスプレースメントが符号付き8ビットなのに対し、030では符号付き16ビット(多分)であるらしい。 .cpu 68000つー指定をしておくと68000コードだよんってことをアセンブラが識別するので上記のような030による拡張等を使用した場合、エラーとなる。 って、そんなん説明せんでも分かるって？ごめ(;_;)

戻る
このホームページのホストは です。 無料ホームページをどうぞ！