ローザ・ルクセンブルク

　ローザ・ルクセンブルクという革命家を知ってるだろうか。レーニンとだいたい同じ時期に活動していた共産主義革命家だ。レーニンと同じくマルクス主義を奉じていたが、ロシア革命とソ連の成立には徹底的に批判をしていた。

　現代、いや20世紀初頭から、共産主義＝マルクス・レーニン主義と同一化され、共産主義とは、企業の国有化、前衛党理論、民主集中制があたりまえとなって、だからこそ資本主義、自由主義の敵になっていった。ソ連崩壊後に左派が「あれはスターリン専制がわるかったのだ、レーニンまではよかった」あるいは、「マルクスは正しかったがレーニンが歪めだ」みたいな抗弁をして笑われたりもしたのだが、現実問題として、20世紀に成立した共産主義国はすべてレーニンの子孫だったのだから、マルクスが正しかったかどうかなど確認しようがない。

　社会主義と共産主義は、そもそも18世紀の啓蒙主義からのフランス革命を経て、より民衆の利益を図る思想として様々な人によって唱えられた。その中でマルクスがもっとも論理的なシステムを構築し、最初のインターナショナルを築くことになる。ジャコバン派やブランキスト、無政府主義、さまざまな派閥があって、共産主義は分裂しまくった。普仏戦争末期に、パリに出現したパリ・コミューン政府はおそらくもっともはやい共産主義政府であろう。これは結社、言論の自由をうたい、普通選挙を実現していたが、プロイセンとフランス保守政府の弾圧で潰えた。マルクスはこのパリコミューンを目の当たりにし共産主義の正義を構築した。

　ローザ・ルクセンブルクは、ポーランド出身の女性で、偽装結婚でプロイセンの国籍を得た革命家である。第一次大戦前後のドイツで活動していた。彼女は、第一次大戦前夜、戦争回避のためのゼネストを呼びかけていた。労働者が各国で一斉にストライキを起こせば戦争自体が不可能になると考えたのだ。しかし各国は結局ナショナリズムに走り、労働者の組合組織も戦争に協力した。

　レーニンは「前衛党」という概念を提出し、共産主義革命のためには、前衛党が専制的に民衆を導かねばならないとした。ローザはこの前衛党論に反対した。彼女はロシア革命後の、憲法制定議会がボルシェビキによって解散させられたことを批判し、資本主義の「搾取者」にも選挙権を与えるべきと主張した。なんだろう。驚くほどの自由主義、民主主義ではないか。ローザ・ルクセンブルクのマルクス主義がもし勝っていたなら、共産主義とは理想的な民主主義になりえたのではないだろうか。

　現実には、レーニンがすべての共産国の規範になり、前衛党によって思想・表現の自由は弾圧されていった。ローザはドイツ革命に失敗し、銃床で撲殺され、ナチスによって墓を暴かれるハメになる。

.NETの WebBrowserコントロールでajaxが動作しない場合

　僕は「なろうReader」というWindows用アプリケーションを公開している。これは「小説家になろう」「カクヨム」「アルファポリス」という三つの小説投稿サイトに対応した、小説読み上げソフトだ。基本的にWebBrowserコントロールを貼り付けたFormに各小説投稿サイトのURLを適用し、読み込まれたページからテキストを抽出して音声で読み上げるものだ。なので投稿サイトにアクセスして操作する部分は普通にIEのコンポーネントに任せている。

　最近「小説家になろう」が、サイトの改修を行い、これまで通常リンクでページ遷移を伴っていた、ブックマーク登録/解除と、しおりの更新処理を、その場で完結するajaxを使った処理に変更した。そしたらこれが「なろうReader」で動作しなくなってしまったのだ。ブックマーク登録やしおりのリンクをクリックしても何も起きない。WebBrowserコントロールはIEと同じ動作をすると思ってたので、動作しないのはなぜだろうと悩んだ。

　ソースを見てみると、

<a href="javascript:void(0)" >しおりを挿む</a>
<input type="hidden" name="siori_url" value="http://syosetu.com/favnovelmain/ichiupdateajax/useridfavncode/639697_475037/no/48/?token=dfc11e44e54805f3825e1a4ab26e319d">

のようになっている。なので、"webbrowser control ajax void(0)"で検索した所、
WebBrowser control - behavior with links having href='javascript:void(0)'
という質問が見つかった。

　結局のところ、セキュリティのために無効化されているWebBrowserコントロールの、Script URL Migration機能を有効にすればいいらしい。これは、コントロールが初期化される前に、レジストリに書き込む必要がある。

Private Sub SetBrowserFratureControlKey(feature As String, appName As String, value As Integer)
        Dim key = Registry.CurrentUser.CreateSubKey(String.Concat("Software\Microsoft\Internet Explorer\Main\FeatureControl\", feature), RegistryKeyPermissionCheck.ReadWriteSubTree)
        key.SetValue(appName, CType(value, UInt32), RegistryValueKind.DWord)
End Sub
Private Sub SetBrowserFeatureControl()
        Dim filename = System.IO.Path.GetFileName(Process.GetCurrentProcess().MainModule.FileName)

        SetBrowserFratureControlKey("FEATURE_SCRIPTURL_MITIGATION", filename, 1)
End Sub

このように、"FEATURE_SCRIPTURL_MITIGATION"を1にするサブルーチンを書き、
Form1_Load()の中でSetBrowserFeatureControl()を呼べばいい。

雨漏りコントの衰退

www.youtube.com

　「８時だヨ！全員集合」や「ドリフ大爆笑」などの番組で、雨漏りコントは定番ネタだった。雨が降り出すと家の中のあちこちに雨水が落ちてきて、そこにタライ、バケツ、鍋などを次々置いていく。それぞれ「カン」「ピチャン」「コン」などと音がしてどんどん賑やかになっていくというもの。このネタはバブル時代以降ほぼ見られなくなっていく。

　おそらく民家の屋根が老朽化して雨漏りが起きるという事態が、リアリティを感じられなくなったということなのだと思う。家の中で何箇所も雨が漏れてきて、それをあわてて受けるみたいな状況。もちろんコントだからおおげさに描かれているのだけど、あれは1970年代にはそこそこ見聞きする話だったのだ。僕の話をすると、まさに1970年代我が家の茶の間で、雨漏りをタライや鍋で受けていた経験がある。我が家は大正8年に建った瓦葺平屋であり、戦前は地主でそこそこ儲かってたが、戦後の農地解放後祖父がいろいろな事業に手を出すも没落し、家を修繕するのも難しい状況で半端に広い家屋を抱えていた。なのでまさに小学校入学の頃はコントのような雨漏りを体験したものだ。

　親父が一念発起して屋根職人を雇い、瓦とトタン部分の葺き替えをしたため、小学校中学年以降は雨漏りのない生活を実現できたのだが、この工事中、屋根職人見習いの若者がすげえ音を立てて屋根から転がり落ち、途中で端をまるめていないトタンを掴んだせいで手のひら血まみれになってタライにいれた水で手の血を洗っていた記憶が残っている。

こういう、なんてことない昔のコントから、日本の歴史を垣間見るというのもおもしろいんじゃないかな？

openMSXで、V9990に画像を出力してみる

V9990のエミュレーションが組み込まれたMSXエミュレーター

オープンソースのMSXエミュレーター、openMSXには、各種拡張カートリッジのエミュレーターが予め用意されている。その中の、V9990搭載グラフィックカード、GFX9000のエクステンションを有効にすることで、V9990対応ソフトを動かすことができる。

　msx-sdcc@Wikiに簡単な解説とサンプルコードがあったので、ありがたくパク…参考にさせてもらうことにする。

www28.atwiki.jpwww28.atwiki.jp

512x424ドット、32768色モードを使いたい

　ただ、これそのままやっても面白くないので、画面モードを512x424のインターレースモードで高解像度の画像表示に挑戦してみた。なにしろ256x212ではいまどきかなり凸凹して見えてしまうので…

　で、実際画面モードを希望のものにするにはどうしたらいいかとなると、上記サイトの情報だけでは全く足りないので。
MSX Banzai! - The MSX Worshipping Shrine - V9990 Programmers Manual

をチェック。うーん、MSX2 テクニカルハンドブックを思い出す詳しい説明だ。ただ問題は英語だということなのだけど…

　どうやら、V9990の場合は、インターレースモードで２プレーンに分けて描画する必要はなく、普通の縦424ピクセルの画像としてVRAMに上から書き込んでいけばうまいことインターレース表示してくれるらしいので、そのようにする。

　以前の記事で書いた、z88dkを使用し、以下のようなコードを書く。
juangotoh.hatenablog.com

#include <stdio.h>

unsigned char inp(unsigned char addr);
void outp(unsigned char addr, unsigned char data);
void V9990Reg(unsigned char reg, unsigned char data);
void V9990Memadr(unsigned long addr,unsigned char rw);

unsigned char inp(unsigned char addr)
{
    #asm
    
    ld hl,2
    add hl,sp   ;skip return address
    ld c,(hl)   ; c=addr (LSB)
    in a,(c)
    ld h,0
    ld l,a      ; hl = return parameter

    #endasm
}

void outp(unsigned char addr, unsigned char data)
{
    #asm

    ld hl,2
    add hl,sp
    ld a,(hl)   ;a=data
    inc hl
    inc hl
    ld c,(hl)   ;c=addr
    out (c),a

    #endasm

}

void V9990Reg(unsigned char reg, unsigned char data){
	outp(0x64,reg);
	outp(0x63,data);
}

void V9990Memadr(unsigned long addr,unsigned char rw){
	unsigned char hi,mi,lo;

	lo=addr & 0xff;
	mi=(addr >> 8) & 0x3f;
	hi=(addr >> 14) & 0x7;


	if (rw) {
		/* R#3 VRAM READ ADDRESS REGISTER */
		outp(0x64,0x3);
	}else{
		/* R#0 VRAM WRITE ADDRESS REGISTER */
		outp(0x64,0x0);
	}

	/* SET ADDRESS */
	outp(0x63,lo);
	outp(0x63,mi);
	outp(0x63,hi);

}

void main(void){
	long i;
    unsigned char col[3];
    FILE *fp;
    int c;
    int cIndex=0;


	
    // R#6 SCREEN MODE 512x424 16bit/pixel
    V9990Reg(0x6,0x97);

    // R#7 ENABLE INTERLACE
	V9990Reg(0x7,0x85);

	// R#8 ENABLE SCREEN
	V9990Reg(0x8,0x82);

	// SET VRAM ADDRESS(r=0,w=1) 
	V9990Memadr(0x0,1);
    if ((fp = fopen("A004.RAW", "rb")) == NULL ) {
		//puts("file not found\n");
		return 1;
	}
    fseek(fp,0,SEEK_SET);
    while((c=fgetc(fp)) !=EOF){
        unsigned char d1,d2,tmp;
        if (feof(fp)) break;
        col[cIndex]=c;
        cIndex++;
        if (cIndex >2){
            // col[0]=R col[1]=G col[2]=B
            cIndex =0;
            d2 = (col[1] >>1) & 0x7c;
            tmp=col[0] >>6;
            d2 |= tmp;
            d1 = ((col[0] <<2) & 0xE0) | (col[2] >>3);
            
            outp(0x60,d1);
            outp(0x60,d2);
            
        }

    }
    fclose(fp);

}

これをMSX－DOS用にコンパイルし、できたコマンドと同じディレクトリに"A004.RAW"という画像ファイルを置く。
　これはあらかじめPhotoshopで512x424ピクセルにした、RGB各8bit、つまり24bitカラーのRAW画像だ。RAW画像というのは、ひたすらピクセルデータが左上から右下まで隙間なく並んだ、全く圧縮されておらず、一切メタデータを含まない画像で、普通こんなものを使う用途はあまりない。なにしろ画像ファイルに縦横のドット数とかRGBの並び順とかの、表示に必要な情報が一切含まれていない。ただ、予め必要な情報を自分が持っているなら、プログラムから読み出すのに一番簡単なフォーマットである。
V9990の16bitカラーモードは、1ピクセルに2バイト使用し、RGB各5bitとなっており、その並びは
0GGGGGRR RRRBBBBB
となっている。リトルエンディアンで格納されるので、RRRBBBBBの方を先に書き込む必要がある。もとのRAW画像は、
RRRRRRRR GGGGGGGG BBBBBBBB
の順で並んでいるので、３バイト読み込んでは、下位3ビットをクリアし、左右にずらした上で合成し、2バイトにまとめなないといけないのでちょっとだけめんどい。

結果

　実行してみると、まあ呆れるほど遅い。そりゃ１バイトずつ愚直に読み込んでは表示してるんだから遅いわなあ。結果が以下の画像。

あー、縦方向の解像度全く出てない。もちろん1/60秒ごとにチラチラ切り替わる画面をスクリーンショットでうまく取り込めないという問題はあるのだけど、これ実際見てるとわかるのだけど、openMSXのインターレースモードって、エミュレーターの画面上で全く同じ位置に奇数ラインと偶数ラインが描かれてて、それを切り換え表示してる感じなんだよね。本来テレビのインターレースモードは、走査線の奇数偶数で上下にずれて隙間を埋めてるから、それで解像度上がるのだけど、同じ位置で混ざって表示されるんじゃインターレース使う意味がない。実機とエミュレーターの違いが出てしまった感じかあ。

　まあとにかく、32,768色、横512ドットモードの画面のサンプルということで。

余談

　V9990、640x400とか、640x480とかの画面モードがあるのだけど、これらのモードだと最大16色しか出ないんだよね。時代的にMS-DOSで動くPC－9801シリーズのアプリが移植できればOK的なモードだったのかなあ。

Kiwi：68008+V9990+SID音源×２という「あの頃ほしかった系」コンピューター

www.ist-schlau.de

　以前たまたま見つけたドイツのサイトだが、自作コンピューターの説明と販売を行っている。販売ページを見ると、基板と部品のセットで€333.33。ただし追加部品がいくつか必要になる。基板には表面実装LSIのみ実装済みで、他のものはすべて自分ではんだ付けする必要があり、まあそれなりに覚悟がいるキットだ。このコンピューター、なんとも「あー、昔こういう仕様のパソコンがあったらよかったなあ」的なスペックなのである。

CPUが68008

　モトローラの16ビットCPU、68000の8ビットバス版。これはできたら8ビットバスバージョンじゃなく、完全な68000であってほしいところだけど、自作となるとこの辺が妥当なところか。とにかくm68kアーキテクチャである。フラットな4MBメモリマップが使える。ホビーパソコンとしてこれはうれしい。

VDPがV9990

　あの、MSX3用に開発されたV9990 VDPである。開発の遅れから、実際には採用されず。これが使われたパソコンは存在しない。なのでカーナビとかパチンコ用に使われたらしい。VGA解像度で家庭用テレビに出力でき、32768色発色。MSX2+やturboRのV9958より格段に高速。

音源がSID×2

　コモドール64で使用されたSID音源を二個搭載。欧米のチップチューンでいまだ人気の音源チップである。まあC64が流行らなかった日本から見ると、ヤマハのFM音源チップとかの方がうれしいけど。

各種インターフェース

　RS232C、パラレルポート、PS/2キーボード及びマウス端子、ATARI方式のジョイスティックポート、IDE/ATA ハードディスク＆フロッピーインターフェースを装備。EPROMにIDEからのブートローダを格納している。グラフィックを扱えるBASICも用意しているようだ。

雑感

　MSX好きにとっては、V9990搭載というのがすごい魅力的だ。RAM 4MBは現代のパソコンから考えると少ないが、Macintosh Plusの最大メモリが4MBだったことを考えると十分である。適切な開発環境を整えることができれば結構使えると思う。ちなみにVRAM512KBはメインメモリとは別に確保されている。

　€333.33という価格は、おそらくApple Iの$666.66を意識していると思われる。ギャラリーページを見ると、この作者、スティーブ・ウォズニアックに会いに行ってるようだ。

　基板と部品のセットには、メモリとSIDチップが含まれておらず、これは別売りになっているが、SIDに関してはSIDのICパッケージサイズのボードにマイコンチップを乗せたエミュレーションボードであるNano SwinSIDがラインナップされている。C64の音源であるSIDは部品単体で入手が難しいこともあってこういう代替品が作られているようだ。

デモ動画

www.youtube.com

有名なAmigaのデモを移植したもの。

www.youtube.com

2Dアクションゲーム。

パソコンにおける80系 VS 68系の時代

　1974年に、Intelの8080とモトローラの6800という8ビットCPUが登場した。8080が、電卓用4ビットCPU 、4004から8008を経て進化したのに対し、6800はミニコンのアーキテクチャ(DEC PDP-11をモデルにしたといわれている)を縮小して設計されたらしい。つまり8080は電卓が進化したCPU。6800はミニコンが退化したCPUといえる。Intel 8080とその後継アーキテクチャを80系、モトローラ6800とその後継アーキテクチャを68系と呼び、これらが戦いを繰り広げた時代があった。

　特徴として、8080はレジスタが多めで、数値をいくつも代入してちゃっちゃと計算するのに向いていた。それに対し6800は直行性の高い命令で、一貫性の高いプログラムを作成するのに向いていた。誤解を恐れずいうなら、8080はとにかく実用性重視。6800は理念重視といえるのではないだろうか。高度な電卓VS簡易化されたコンピューターだったのだ。この場合、すでにミニコンや大型コンピューターを使っていた技術者からは、よく似たアーキテクチャの6800は評判が高かったはずだが、インテルはいちはやく評価ボードやCPUを安価に配布し、初期の段階でわりとシェアを取ってしまう。マイコンの歴史に残るAltair8800など、当時インテルが市販していたCPU単体の価格と変わらない値段で筐体とマザーボード込みのコンピューターセットを販売できた。これはIntelがこういう企業に対し、極めて格安でCPUを卸していたからに他ならない。

　ここで、80 VS 68の第一ラウンドは80の勝利に終わるのだが、ここで成功したのはIntelではなかった。IntelからスピンアウトしたZilogが、Z80という、8080互換で、さらに便利な命令や裏レジスタを完備たCPUを発売。横から商売をかっさらっていく。
　日本では、日立Basic Masterが6800を採用。シャープ MZ-80と、NEC PC-8001がZ80を採用していた。その後、モトローラは6800を大幅に改良した6809を発売する。6809は究極の8ビットCPUと呼ばれ、日立のほか、富士通が採用して一定の支持を得る。しかしこれは6800との互換性がなかったし、登場時期も遅すぎた。「究極の8ビット」というのは、要するに「8ビット時代の最後を飾る」という意味になってしまう。

　なお、日本でパソコンへの採用例はほぼないのだが、米国では6502がかなりのシェアを得た。これはモトローラからスピンアウトしたモステクノロジーが開発したCPUで、6800をさらに簡易化したような製品だ。プログラムカウンタ以外のレジスタがすべて8ビットであり、命令数も少ないが、その分高速で動作した。つまりプログラムはより複雑になる。のちのRISCにちょっと似ている。モステクノロジーはこのCPUをすげえ安く市販した。8080が3万円位した時代に2000円位で売り出したらしい。これに注目したのがスティーブ・ウォズニアックで、彼が作ったのがApple I。後継のApple IIも6502を使っていたので、アメリカを席巻したパソコンが6502を採用したということになる。コモドール社もPET-2001でこの6502を採用し、のちのコモドール64でも使われた。英国でもエイコーン社がBBC Microに6502を採用。世界的に安価なパソコンは6502という流れがあった。なぜか日本ではパソコンにおける採用例がない。これは日本で初期にパソコンを製造したのが半導体メーカーばかりで、これらがモトローラやインテル、ザイログと提携して自社で互換チップを製造していたこともあるのだろう。初期の日本のパソコンは基本自社製のCPUを搭載していたはず。製造ライセンスを買った後の製造原価で考えるならどれも大差なく、ならば高機能なZ80や6809となったのではないか。
　それに対して米国などでパソコン市場を立ち上げたのは、自社に半導体工場なんか持たない新興企業だった。大量に外部から購入する部品として、安価な6502は魅力的だったと思われる。
　6502を68系に含めるのなら、案外日本以外ではいい勝負をしていたかもしれない。日本においては、ファミコンが6502に機能を追加したカスタムCPUを採用し、その後PCエンジンやスーパーファミコン（16ビット化された65816のカスタム）などに採用された。セガのSC-1000などがZ80を採用していたのに勝ったので、ゲーム機市場では80系の負けといえたかも。

　16ビットでは、Intelが8086、モトローラが68000を出した。8086はこれまた8080を大きく拡張したアーキテクチャで、機械語に互換性はなかったものの、再アセンブルすれば今までのプログラムがそのまま動くようにできていた。そういう設計のため、16ビットCPUとしてはメモリが64kB単位で区切られたり、非常にせせこましくなっていた。それに対して68000は、リニアな16MBメモリマップを実現し、たくさん装備された汎用レジスタは32ビットで自由自在に使えるなど、どう考えても68000の勝ちだろってな仕上がりだった。しかし、6800や6809との互換性とかは特に考えられていなかった。この時代、IBM-PCが8086の8ビットバス版の8088を採用し、AppleのLisa、Macintosh。アタリのST。コモドールのAmigaが68000を採用した。後者はどれもビットマップディスプレイを効率的に扱う必要上、68000の方が率直にOSやアプリケーションを書くことができる利点があった。しかし、IBM-PCやその互換機が主流となり、ここでも68系は敗退する。
なお、8ビットパソコン市場でIntelのパイを奪ったザイログは、16ビットのZ8000が思ったより速くならず、エラーも出たりして16ビットパソコン市場ではさっぱり採用例がなかった。アーケードゲームとかでいくつか採用されたようだけど。

アタリやコモドールがドロップアウトして、唯一の68系陣営となったアップルは、IBMのPowerPCを採用し、これにモトローラを巻き込む。PowerPCの時代を68系と言っていいのかどうか、全然アーキテクチャ違うし難しいところだけど、最終的にモトローラのCPU採用をやめたIntel Mac登場の2006年を持って、1974年から続いたパソコン市場の80系 VS 68系の戦いは幕を閉じたと考えていいのだろう。

Win2Dを使って２Dゲームを作る場合のメモ的な何か

　別にゲーム作る予定があるわけではないのだけど、ちょっと興味を持ったので調べてみた。Win2Dには、SpriteBatchという、昔のゲーム機やホビーパソコンで使われた「スプライト」に似た機能がある。まあこれ自体はDirect3DやDirect2Dに以前からあって、XNAなどでも便利に使われてたものだけど、UWPアプリ用のDirect2DライブラリであるWin2Dの発表時には含まれておらず、あとからサポートされた。なので、SpriteBatch関連のAPIは、Windows10 November update以降でしか使えないとなっている。

　Win2Dが描画を行うコントロールは、主にCanvasControlと、CanvasAnimatedControlだ。後者は前者にアニメーションのための機能を付けえくわえたものと考えていい。具体的には、一定間隔（デフォルトでは1/60秒間隔)で画面の更新が強制的に行われるようになっており、そのためのイベントハンドラが使える。ここにキャラクターの移動などの処理を描けば、無理なくアクションやシューティングゲームのためのゲームループが作成できるわけだ。というわけで、とりあえずXAMLに

xmlns:canvas="using:Microsoft.Graphics.Canvas.UI.Xaml"

と書いてから、Gridの下に

<canvas:CanvasAnimatedControl x:Name ="canvas" Margin="10" Update="canvas_Update" Draw="CanvasControl_Draw" CreateResources="OnCreateResources"  ClearColor="Black"/>

などのように書いて、CanvasAnimatedControlを作成する。CreateResourcesはリソース作成時に呼ばれるので、スプライト用の画像データを読み込むなどするために登録したほうがいい。Updateは1/60秒ごとに呼び出されるアップデートイベントで、これが呼ばれた直後にDrawメソッドも呼び出されるので、Invaridate()とか呼んで無理やり描画イベントを起こす必要もない。

　CanvasのDrawメソッドが呼び出されるとき、引数に

Microsoft.Graphics.Canvas.UI.Xaml.CanvasAnimatedDrawEventArgs args

が入るので、

CanvasSpriteBatch  batch = args.DrawingSession.CreateSpriteBatch();

としてSpriteBatchを作成する。これがなにかというと、Canvasに乗ったレイヤーのようなものだ。スプライトと言っても、ビットマップのキャラクターを登録したら、あとは座標を指定するだけで動き回ってくれるようなものではなく、毎回更新のたびに全スプライトをこのSpriteBatchの上に書き込む必要がある。CanvasSpriteBatchクラスのDrawメソッドを使うのだが、これはあらかじめ用意したキャラクター単一のビットマップ、もしくは歩きパターンなどを複数並べた大きなビットマップ（SpriteSheet)の任意の矩形領域からSpriteBatchに転送することになる。単一ビットマップを使う場合は、CanvasBitmap.Draw()メソッド、SpriteSheetを使う場合はCanvasBitmap.DrawFromSpriteSheet()メソッドを使う。どちらも用途に応じて多くのオーバーロード関数が用意されている。「Draw」となってるから、この時点で画面に表示されそうな気がするが、これはあくまでオフスクリーンで画面を作っている段階で、実際のCanvasへの描画は

batch.Dispose();

で行われる。「え？」と思うでしょ。実際ドキュメントには
Finalizes the sprite batch and submits it to the CanvasDrawingSession.
と書いてあるのでこの理解で正しいはず。まあ、シューティングゲームとかで考えても、敵が数十機出たり、弾幕とで数百個のビットマップをSpriteBatchに書き込むことになる場合もあるのだろうけど、おそらくそのへんうまいことやってくれてあんまし遅くならないんじゃないかな。なんせDirectX系だし（甘いか？）

　それにしてもWin2D、日本語での解説がなかなか見つからないうえに、本家のドキュメントもあまりにシンプルでいろいろ試してみないとわからない。引数の説明がほぼなかったり、まあDirect2Dのドキュメントの該当部分読めってことなんだろうけど…

　とりあえず黒背景で自機を動かしてショットを打つところまでは作ってみた。SEやBGMはネットで拾ってきたフリー素材。

UWP, Win2Dでシューティングっぽいゲームパッドの入力とスプライト移動のテスト。まあ、ゲーム作るの面倒なのでこれ以上はやらないと思う。SEとBGMはネット上のフリー素材。 pic.twitter.com/FaOFtiWEFM

— 後藤寿庵 (@juangotoh) 2017年6月18日

　なお、自機の画像は背景透過のアルファ付きPNGで用意した。2コマしかないが、一応これがSpriteSheetということになる。