まるくんの趣味プログラミング日記

最初はUnityを使っていたんだけど、業務から離れてしまったので、ゲーム/エミュレーターよろずについて書いていきます。

DirectX11のテクスチャをコンピュートシェーダーで書くときの覚え書き

メモ書きです。あとで清書します。

テクスチャを作成するとき、 DXGI_FORMAT_R32G32B32A32_FLOAT で作成すれば、コンピュートシェーダー、シェーダーリソースビュー、 アンオーダードアクセスビューへのアクセスは全て上手く行くが、 テクスチャの容量が大きくなりすぎる。

一般的には、DXGI_FORMAT_R8G8B8A8_UNORM で作成するのが 望ましいと思われる。コンピュートシェーダーには、 RGBAで32bitで渡せるのが望ましい。

そのためには、下記のフォーマットで組み合わせて作成する必要があった。

テクスチャ:DXGI_FORMAT_R8G8B8A8_UNKNOWN シェーダーリーソースビュー:DXGI_FORMAT_R8G8B8A8_UNORM アンオーダードアクセスビュー:DXGI_FORMAT_R32_UINT

DirectX11 バッドノウハウ 頂点バッファとインデックスバッファ

私はここ数ヶ月の間、DirectX11に地獄のように理不尽な目に逢わされています。 需要は少ないと思いますが、自ら踏んだ地雷をここに貼っていきます。

DirectX11 Bad Knouhow: VertexBuffer / IndexBuffer ...

VertexBufferとかIndexBufferをメインメモリからGPUメモリに転送するとき、何故かmemcpy関数の中で落ちるという、不可解な現象が起きました。 最初は書き換えたサイズだけ転送していたのですが、どうやらそれが原因だったみたい。

// indices upload
    D3D11_MAPPED_SUBRESOURCE ires = {};
    hr = m_context->Map(m_pIndexBuffer 0, D3D11_MAP_WRITE_DISCARD, 0, &ires);
    if (FAILED(hr))
        return;

    void* idxbuf = ires.pData;
    if (idxbuf) {
//      memcpy(idxbuf, idc_buf, sizeof(uint32_t) * m_idc_cnt);          // 書き換えたインデックス数のコピーだとまれに落ちる
        memcpy_s(idxbuf, sizeof(idc_buf), idc_buf, ires.RowPitch);      // msr.RowPitchで全体を書き換えないと落ちる
        m_context->Unmap(m_pIndexBuffer, 0);
    }

MapしたときのRowPitchのサイズでmemcpyしないと、何故かたまに落ちます。 理由はわかりませんが、これで動いているのでまぁよしとしましょう。

Win32用見えないウィンドウ&メッセージループ

Win32 Invisible Window & Message loop

とある案件で、マルチスレッドにする時にメッセージループが挟まってると管理が便利かなと思って作ってみました。

GWの進捗です!

はい、先週で、なんらかの進捗をGW中に出したい旨をお伝えしてましたよね。
進捗はですね……。

OpenALの初期化と解放を実装した』

それだけかよ!
はい、それだけです。申し訳ございませんでした。
他にいろいろやりすぎました……グラフィックスカードの換装、Raspberry PI3でMastodonサーバを立てる試み(ファイルシステムが壊れて失敗)、部屋の「強制」大掃除(これが一番響いた…)。
あとはこのGW,いまいち全体を通して体調が優れず、半分くらい寝てました。季節の変わり目だからかな…。

で、ユーザー生放送による「mz1500em会議(仮)」の練習はいろいろやりました。ニコ生だったり、YouTube Liveだったり…。
予告も無しに告知が突然Twitterで流れるだけなので、見る人は限られ、見てくれる人数は正直少ないです(笑)
でも、進捗の現状やら今後の展望やら、権利関係の話やら…などなど、大まじめにお話をさせていただきました。

可能であれば今後も定期的に生放送をやっていき、そういう形でも情報発信していこうと思いますので、興味のある方はまるくんのTwitterをウォッチしてみてください。
来週こそはサウンドくらい実装したいなぁ。

mz1500emとMacバージョンの素敵な関係

今週も、mz1500emそれ自体にはお見せできる進捗は出せませんでした。申し訳ありません。
自分自身の用件さえ、取りこぼしているような状況です。
そんな中でも、裏側では「仕込み」的なことをやっています。

以前にも書きましたが、mz1500emはMacMZ-700/1500エミュレータのソースがベースになっています。
移植作業の中で、見つけてしまったのです。恥ずかしいポカミスバグを。

とはいえ、そんなに致命的なものでもなかったので、放置していても誰も困らないでしょう(笑)
それはそれとして、Mac版のほうが、古いバージョンのMac OS X(10.5.x-10.6.x)で作られているため、現行OS(El capitan, Sierra)では、ビルドが通らないのです。そっちのほうが大問題です。
Mac版のメンテナンス環境を再構築して、GitHubに登録しておくことが重要ではないかと考えました。

そこでまず試みたのが、古いバージョンのMacOSを、Parallelsなどの仮想マシンにインストールしてみる事です。その結果、
「このバージョンでは、Mac OS X Serverしか対応しておりません」

うわっ、これめっちゃ高価なヤツだ!無理だ!はい次!

次は、mz1500emの開発にいつも使っている、手元の実機(MacBook Pro 15 retina late 2013)に入れてみました。

そもそもインストールできませんでした。

詳しい方に伺ったのですが、仕様として、過去のMacOSは、新型Macの実機にはインストールできないそうです。
そこで次の手段。

古いMac miniを調達ーーー!!どどーん!
はい、いま手元に、Mac OS X 10.5.x (Leopard)が動くMac miniがありまーす!こいつにXCodeをインストールして、元のソースを持ってくれば動作確認できるはずです。
はずなのですが……。
プライベートの時間が少なくて、OSの環境設定までで止まってまーす!

なにせ、まるくんのタスクキューの仕様はLIFOなので、次から次へと降りかかるタスクに埋もれて、最初に手がけるはずだった作業が埋もれてしまいます。
LIFOじゃいかんだろ! 手元にはRaspberry PI 3、Geforce GTX 1050Ti ビデオカード、などなど…にも、手を付けられずに転がっている有様です。
ニコニコ超会議のチケットも無駄になってしまったし…(行けなかった)
ゴールデンウィーク中(5/3~5/7)にはできる限り消化したいです!

はい、ここで唐突なお知らせです。
皆さんは、インターネットの動画サイトで「ユーザー生放送」って見たことありますか?
私はさっき、先日観劇した舞台女優(声優)さんの生放送を「SHOWROOM」で見て、美女3人に眼福眼福こういうの、自分でもできたら面白そうだな。使ってくださる方々と、どういうものを望まれているのかお話したいな、そんな思いが生まれました。
もし見てくれる人がいるなら、GW中にやってみようかなと考えています。放送のための機材の調達も必要になりますし。
ただし、自分は美女ではなく、ただのおっさんなので、SOUND ONLYになるかもしれません。
別に顔出しでも自分はいいけど、みんなはただのおっさんなんてみたくないでしょう?(笑)

もしご要望がありましたら、コメントか、Twitter @marukun か、コメント欄に書いてやってください。
その時には、ご希望の配信サイト(ニコニコ生放送Fresh!、など)を添えていただければと思います。
特になければどちらかになると思いますが、別にツイキャスやLINE LIVEでもかまいません。ただ、ここを読んでくれるような人はLINEが好きでなさそうな気がしたのでw
それでは、よろしくお願いします。

mz1500emのルーツ

今週も何かと慌ただしく、リリースできる進捗はありませんでした。楽しみにして下さっている方々には、申し訳ありません。
今回はmz1500emのルーツをお話したいと思います。

まず大もととして、このブログをお読みの方ならご存じであろう、MZ700Winが存在します。
そこから更に、昔懐かしSHARPPDA「MI-Zaurus」シリーズ向けに移植した、MZ-700/1500 on MI-Zaurus “MZ-Memories”というものが作られました。
Zaurusのアプリ配布形態は、今で言うApp StoreGoogle Playに近いもので(ただしもっと緩い)、公開にはシャープの審査が必要でした。 当時のシャープ様は、その扱いに相当困ったことが想像できますが、当然のようにリジェクトされまして、バイナリでの配布を諦め、ソース配布で自前でビルドしてね!という形に落ち着きました。
流れ流れて、私の仕事はレトロPC/レトロゲーム復刻マンになってしまったので、権利関係のデリケートさ、扱いの難しさが、今さらですがわかるようになりました。現状、個人で続ける限りは、メーカー様の黙認をもって地味に続けていくのが無難なのでしょう。
個人的には、ちゃんとした形で世にだしてやりたいと何度も考えましたが、ハードルは高く。
噂では、けっこう現実的な提案をしたけどやっぱりダメだったという話もあります。噂ですけどね!う・わ・さ!

それはともかく、次はそのMI-Zaurus版のソースを元にして、Mac用の「MZ-1500/700 on Mac OS X “MZ-Memories"」が生まれました。 自分ではけっこううまく出来たと思っていますが、Mac OSのバージョンアップにともない、現代のMac OSではビルドできなくなっていたのです!
最近、仮想環境に古いOSを入れ、ビルド環境の再整備を試みていますが、何故かOSのブートでKernel Panicを起こしてしまい、OSがインストールできません。それがうまくいかずに困っていたのが、今週の流れでした。

そのソースを元に、emscriptenを使い、Webブラウザに移植したのが、今回のmz1500emというわけです。
以前にもJavaアプレットFlashに移植しましたが、どちらも廃れてしまい、今ではJavaFlashも動作しなくなってしまいました。Flashはかろうじてまだ生きていますが、自分の使っている環境ではほぼダメだったため、今回のWebAssembly版を作ったのです。

今まで私の作ってきたエミュレーターには、「エミュレーション精度が適当でもそれらしく動いているように見せる」という設計思想があります。
MZ700Winが生まれたのは、PCのCPUがMMX Pentium 200Mhzとかのころ。今から見たらスマホよりも圧倒的に低いスペックで動かさなければいけなかったのです。

近年のCPU速度の進歩はめざましく、速度にものを言わせて、より精度の高いエミュレーションが可能になっていて、実際、武田俊也さんをはじめ、他の作者の方々が、より高精度のエミュレータを発表されています。
将来的には、私自身でも高精度のエミュレーションに挑戦してみたいと考えます。その時は、何か別の名前になるか、バージョン番号が突然上がるか、そんな事になるでしょう。

現状のMZ700Winも、地味なメンテナンス的バージョンアップを予定しています。
・決めうちだったXInputコントローラーのキーコンフィグ
DirectInputにによるゲーム対応とキーコンフィグ
などです。

現実的にはどうかわかりませんが、構想としてはそんな事を考えているよ!とお伝えしておきますね。

HTML5とWebAssemblyのつなぎ込み (1)

先日公開されたmz1500emの新バージョンは、一見するとキー入力ログがカットされただけに見えます。
でも、ちょっとだけ、今後のUIのつなぎこみに対する仕込みが入っています。

http://alpha.marukun.com/

画面の右上の方をよく見てみて下さい。[Reset]ボタンがありますよね!
これをクリックすると、なんとエミュレータ側にリセットがかかります。
Web UIと、WebAssembly側の接続の第一歩めです。
ただし、現状ではテープイメージが巻き戻らないため、ゲームの再ロードが出来なくなりますので、モニタコマンドで遊んでみてください。
将来は改善しますのでご安心を。

この調子で、出来るだけネイティブアプリと同じような事ができるWebアプリにしていきたいですね。
ただし、ブラウザの場合はセキュリティがあるでしょうから、どこまでできるかまだ不明ですが…。
例えば、手持ちのテープイメージをアップロードさせて動かす…なんて、できるのかなぁ。やりたいなぁ。

私、恥ずかしながらHTML5JavaScriptはまったくの素人です。
そのあたりで、いろいろアドバイスをいただけるとありがたいです。

それでは今日はこのへんで!