‘プログラミング’のエントリ

Android開発。タイトル→ワード選択→30問打つ→結果表示の一覧の流れはできるようになった。が,いくつか懸案が。

今考えている方式は,IMEを使ってひらがなを打ち込むという仕様。しかし,これで何度もプレイしてるとIMEにひらがなの学習結果が大量に作られてしまう。IMEの学習を一時的にオフにする方法もなさそうだし,どうするかなあ。漢字打ちにすればある程度解決するだろうけど,Android以外との対戦とか混合Webランキングが意味なくなっちゃう。

ATOKだと「・」が打てない。他にもIMEによっては打てない文字がありそうなので調査が必要。

# と思ったらキーボードの日本語のモード「/」を打つと「・」になるっぽい。

ゲームアプリはみんなそうなんだろうけど,常に30FPSくらいで動いているので電池の減りが早そう。特にホームボタンを押してバックグラウンドにいった場合,そのまま気付かないと電池が0に,なんてこともあるかも。

入力方式は完全にはやりたいことを実現するのは難しそう。自作IMEは特許問題があるので避けるとして,IMEを使う方法は内蔵キーボードは防げそうだがbluetoothは防げない。いろいろなIMEを試してみたがIMEによって予測変換が出たり出なかったり。ネットランキングやるのに必要な公平性を確保するのが困難。てなわけでネットランキングはなんとなくでやるしかないか。

開発自体はとりあえずワードを選択するところまでできた。WindowsとAndroidの考え方の違いからUIを作り直しているので時間がかかる。

そういえばJavaのパッケージ名をどうするか。Javaはパッケージ名をドメイン名にするのだが,みんな真面目にドメインとってるのかなあ。以前ぱじ氏と取っていたドメイン名を復活させようかな。


Android開発で久々にEclipseを触っているのだが,Visual Studioで便利な部分が結構入っている。AndroidもWPFに近いし。どっちがどっちを取り込んでいるのか,いろいろ追求していくと似通ってくるのか,興味深い。

さらに調べていくと特開2009-266236でアップルからフリック入力に関する特許が出願(未請求)となっている。2009年4月出願てことはあと1年待ってから一気に訴えていく作戦なのだろうか。どっちみちhanabi入力が拒絶されているから請求しても成立しないだろうけど。Weather Typingフリック版は1年後とかじゃ遅いよねえ。

# ちなみに特許専門家ではないのであまり本気にしないで下さい。

結局IMEを使う方法はいろんな問題点があり,解決は難しい。ここはウェザタイらしく自作IMEの可能性を調べる。自作IMEはなんとかなるとしても1つ問題が。フリック入力って特許取られてるんじゃない? ということで調べてみると,知らぬいさんのページとNewton アロハ通信さんに詳しく書いてある。これによると原型の特許→Hanabi→iPhone→Androidと移っていて,結局のところグレーゾーンっぽい。でも普通にいろんなソフトで使われているところを見ると決定的な特許はないってことなのかなあ。Appleが特許取得してたらAndroidには許可しなさそうなイメージがあるし。タイピングソフトでQwerty+携帯キーボードのみだと魅力半減ですよね。

いろいろ技術的な課題を調査。課題1としてAndroidでタイピングソフトを作るとしたら基本的にIMEを使うことになる。そうすると入力確定とか変換中の文字列が表示されるとかいろいろな問題が発生する。IMEによって動作違うし。IMEを自作すれば解決だけどさすがにそこまでは。

課題2として,外付けキーボードの存在。フリック入力と外付けキーボードではどうしても速度が違うので分けるか,最低限禁止としたいところ。いろいろ調査したところちゃんと見分ける方法はなさそう。実際Bluetoothのキーボードを付けたり外したりしても通知はこない。

AndroidのOSのソースを見つつもう少し調査してみるか。

Androidウェザタイを目指して調査。まずは市場調査ということでAndroidタイピングソフトを試してみる。が,比べるほど多くは公開されてない。公開されているのもテキストボックスに入力するタイプなのでウェザタイとはちょっとイメージが違う。

入力について・・・ソフトウェアキーボードから直接入力は難しいのか,ってことで調べてみると,エディタ用のインターフェースで何とかなりそう。対戦について・・・まずは対戦なしのネットランキングのみで作ってみて,次の段階でBluetooth対戦,そしてWiFi対戦+ロビーですかね。3G回戦での対戦も調べてみたけど,例えばDoCoMoのSPモードだとプライベートIPという噂だし,Androidだと一般ユーザ向けになるからロビー対戦は敷居が高い。

とりあえずそのままタイトル画面だけ作ってみた。

20100403

ActiveMonitorを自分で使っていて問題があったところを更新。しばらく動作していると輝度が変わらなくなる問題とマウスをはじっこより外に移動させると不安定になる問題を修正。VMWareでモニタ4台とかやってみようと思ったけどWmiMonitorIDが取れなくて例外をはく。まあいいか。

しばらくノート+外付けのマルチディスプレイにしているが,使わないときはサブディスプレイの輝度を落とせたらなあ,とか思った。つまりマウスがあるディスプレイだけ明るくて他のディスプレイは暗いという。で検索してみたけどそんなソフトは皆無だったので作ってみた。

最初,Win32 APIのSetMonitorBrightnessでできると思ってC++で作ってみたのだが,外付けのナナオはOKなもののDELLノートのディスプレイがGetMonitorCapabilitiesで失敗を返す。ヘルプだとDDC/CIに対応してないとダメって書いてあるので多分ダメなんだろう。

次にWMIのWmiMonitorBrightnessでできそうなのでC#で作ってみた。こっちだとDELLノートのディスプレイはコントロールできるが逆に外付けのナナオは不可。WmiMonitorIDはちゃんと2台分返してくるのだがWmiMonitorBrightnessは1つしか返ってこない。

結局,外付けの方は暗くならなくてもいいや的な感じでマウスのフックとかタスクトレイアイコンとか作って完成。まともなテストはしてないけど一応公開。ActiveMonitor

ちょっと前までVector+MicrosoftでWindows 7 アプリ投稿キャンペーンというのをやっていた。Windows 7の機能を使ったアプリケーションを登録するとMSのページで紹介されるというもので,そんなの開発者しかチェックしないよね的な気がしながらPurentroをポチっておいた。最終的に150件という多いのか少ないのか分からない件数が集まってますね。でキャンペーンプレゼント当選のお知らせが届いていたのだが,既にプレゼントのページが消されているので何がもらえるのか分からない。

Android調査。NDKを使うとネイティブアプリケーションを作れるのだが,その中にSocketも含まれていたのでWeatherTyping移植できるかも? とか思ったのだが,やってみるとPermission Denied。どうやらルートっぽい権限がないと動かせないらしい。ルート化して動かして下さいなんてアプリ怪しすぎるし。Windows Phoneもそうだけど,PDAのときと違って一般人を対象にしているせいか制約がきつい。

ぱじ氏が飽きたとのことなのでロビー第1サーバは終了。そろそろウェザタイロビーの役割も終わってきた感じだし第2サーバだけでいいかな。

CNETのdownload.comに登録したら他のサイトからも「登録しましたが何か?」的なメールが届いた。日本でもVectorに登録するといろいろ登録されるのでこの辺は同じか。

Softpedia。Purentro。紹介用にコメントとかスクリーンショットもちゃんと書いてる。なんかついでにWorld Testerも登録されてた。わざわざDenasuページからひろってきてるのか。

Brothersoft。Purentro。これはCNETそのままパクってる感じ。

他にアラビア語のサイトとかあったけどよく分からない。

Purentro。折角英語版を作ったので海外サイトに登録しよう! てなわけでググってみるとCNETのdownload.comが最大手らしい。登録方法が非常に分かりにくいが,upload.comという別サイトで登録するようだ。適当に英語で説明を書いて申請したところ,アカウント登録に1日,作者登録に1日,ソフト登録に1日で完了。CNETのPurentroページ。とりあえずサポート掲示板を英語対応しておいた。

なんか気が向いたのでWPF練習用にファイル検索ツールを作り始めた。これ公開していいんだろうか。

「MIDI プレイヤー & 練習ソフト Purentro Ver.1.0」を公開。新作キーボード練習ソフト! といってもMIDIキーボードだけど・・・。

今回はマニュアルにおまけ情報を書けなかったのでここに書いてしまおう。


このプロジェクトは,元々10年前に某鳥の名前のファミレスでMIDIキーボード練習ソフト作ろーみたいな話があって,いつの間にか立ち消えになったもの。1年くらい前からひっそり再開して作っていたのだが,とりあえず作りたかったものができたので公開してみた。

内容としては,.midファイルを読み込んで楽譜を表示し,MIDIキーボードがあれば練習にも使えるというソフト。ということでこれを使う人はだいぶ限られそうなので環境とか何も考えずに作っている。XPは動くけど非サポート扱いにしたし,.NET 4.0必須だし,ディスプレイの解像度は1920×1200以上じゃないと厳しいし。要は自分の環境に最適化したという話。


技術的な話も。まず,マニュアルにも言い訳を書いているが,MIDIファイルは楽譜ファイルじゃないのでちょっと複雑なMIDIファイルだとお手上げ。発音のタイミングが音符の位置からずれまくるし,1つのトラックに複数のパートがあると見分けが付かないし,世にある楽譜化ソフトも相当苦労しているはずだけど,完璧なものはないですね。この辺の苦労をはっぱさんと語れたのが今回最大の収穫。そういえばはっぱさんからはiPadでやったらいいよとかメモ書き機能があるといいよとかアドバイスをもらった。次バージョンがあれば考えてみよう。音楽は何も知らないのでそういう人が近くにいると心強いですね。

あとはWPFですかね。最初はC++ Direct Drawで作ってたけど,斜め線が引けなくてDirect3Dに切り替えて,その後きれいに拡大縮小をしたくてC# WPFに切り替えた。以前Silverlightを少し触っていたときはあまり感じなかったけど,WPFを本格的にやってみるとかなり面白い。これだけの開発環境が揃っているといろいろ作りたくなってくる。Windows PhoneはSilverlight(=WPFの軽量版みたいなもの)なので,いろいろやってみたいかも。


ところでPurentroって未だに意味がわからないんですけど,どういう意味ですか?>ぱじ

いろいろあってスマートフォン開発環境を構築。Windows PhoneとAndroidとiPhone/iPad。とりあえず日本だとこの3つを押さえればいいのかな。

Windows PhoneはWindows Phone SDKを入れるとVisual StudioでSilverlight for Windows PhoneとXNA Game Studio 4.0プロジェクトを作成できるようになる。Silverlightで作ればいいのでものすごく簡単。

AndroidはWindowsにAndroid SDKを入れるとJavaで開発ができる。Eclipseを使うと割と楽に開発できる。さらにCygwinとNDKを入れると,CのソースをARM用にクロスコンパイルし,JNIで呼び出すことが可能。

iPhone/iPadはMac必須。iOS SDKをダウンロードしようとするとComing soonみたいなページにとばされてなかなかダウンロードできなかったが,なんとか構築環境。iOS SDKを入れてXcode上で開発ができる。Objective-Cなんだけど,普通のC言語でも動くのか,なあ。

結局C#/Java/Objective-Cなので共通で動くものを作ろうとするとPure C言語で作っておいてC#に移植/JNI/C言語でやることになるのかな。


ここまできて,問題は何を作るか,なんだけど。とりあえず練習として,Windows Phone 7が日本で発売されるまでにWeather Typingロビークライアントを作ってみるのもいいかな。今作っているMIDIプレイヤーはマニュアル作ったら完成なのでその間に何を作るか決めよう。

WPFで使っている自作DLLの名称を変更したのだが,どうしてもリソースファイルを旧名称でアクセスしてしまい,Not Foundになる。GrepしてみるとPropertiesResources.Designer.csとSettings.Designer.csの中に旧名称が残っている。この2つはTool Generatedで変更するなと書いてあるのだが,生成元のソースはどこにもない。確かにこのファイルを消してプロジェクトを開き直すと再生成されるのだが・・・。

てことで悩んだ結果,VSSからとってきていることが判明。いつのVisual Studioからか知らないけど,ファイルが足りなかったら勝手にVSSからとってくるようになってたのか。VSSに接続しないようにするとResources.Designer.csもSettings.Designer.csも生成されずにビルドエラーになるので,とりあえず再生成はされないと断定して直接いじることにした。

WPFで7セグメントLED(時計とかのデジタル数字)を表示したい箇所があっていろいろ調べていたのだが,なかなかいい案が見つからない。今使用しているPCにはAscenderFonts製Quartz MSってフォントが入っているけどどこでも入っているのか,どこに何を払えばプログラムに同梱できるのかよく分からないし,カスタムコントロールで画像を表示するのもつまらない。ってことでフォント自作。フリーではfontforgeってのが有名らしく,使ってみた。キーボードショートカット使うと落ちまくりつつもなんとか「0~9:/」だけを含むフォントが完成。WPFのプロジェクトにつっこんでおけばそのままリソースとして使える。フォントのインストールは不要。

たいしたものではないので公開しておこう。何にどう使ってもOKですが,何か問題があってもサポートはしません。

2010092301

ダウンロード

MIDIキーボードタイピングソフトができてきたところでそろそろテスト工程に入る。まずはXP実機で試してみる。以前VMWareで実験したときはエラーが出て実行できなかったが,実機というか.NET4.0にしたおかげか実行はできた。ただ,設定ファイルにハッシュアルゴリズムSHA256を使っていたのがXPではサポートされていないらしく設定ファイルを読むところでエラーになった。とりあえずセキュリティ的に重要なわけではないのでSHA1で我慢しておくか。

C#でMIDIキーボード入力をやってみる。midiInOpenにコールバックを登録しておけば,midiInStart/midiInStopでメッセージを受け取れる。

{
    [DllImport("winmm.dll")]
    public static extern uint midiOutOpen(
        ref IntPtr phmo,
        uint uDeviceID,
        IntPtr dwCallback,
        IntPtr dwInstance,
        uint fdwOpen);

    public delegate void CallBackDelegate(
        IntPtr hdrvr,
        uint uMsg,
        uint dwUser,
        uint dw1,
        uint dw2);
}

public class MIDIIn
{
    private Win32MIDI.CallBackDelegate _callback = null;

    public void Open()
    {
        _callback = new Win32MIDI.CallBackDelegate(CallBack);

        Win32MIDI.midiInOpen(
            ref _midiin,
            _mididevice,
            (IntPtr)Marshal.GetFunctionPointerForDelegate(_callback),
            (IntPtr)0,
            Win32MIDI.CALLBACK_FUNCTION);
    }

    private void CallBack(IntPtr hdrvr, uint uMsg, uint dwUser, uint dw1, uint dw2)
    {
        int state = (int)dw1 & 0xff;
        int data1 = (int)dw1 >> 8 & 0xff;
        int data2 = (int)dw1 >> 16 & 0xff;
    }
}

最初,C++で実装するときと同じようにCallBackをstaticメソッドにしていたのだが,インスタンスのメンバ変数を使いたくて,midiInOpenのdwInstanceにthisを渡すことを考えていた。でもthisをIntPtrに変換する方法というか変換していいのかを調べても何も情報は見つからない。最終的に「GetFunctionPointerForDelegateはthisポインタをうまいこと扱ってくれる」というような記述を見つけて,思いきってstaticを取ったらそのまま動いた。C++の発想だとstaticにしないと動かないのでメンバ関数をそのまま渡すというのは思いつきもしなかった。こんな感じで半日を無駄にしてしまった。

その後は順調に進んで,キーボード練習ソフトっぽいものはできあがった。そろそろもばもば(?)に投げてみよう。

Visual Studio 2010でWPF(というか.NET)のソースコードレベルデバッグをする方法。MSのブログに載っている2008の方法と同じだが,Tools-OptionsでDebugging-GeneralからEnable source server supportをONにし,Symbolsの一番上に「http://referencesource.microsoft.com/symbols」を追加する。なお,「http://msdl.microsoft.com/download/symbols」とは違うPDBファイルらしいので,既に設定している場合はダウンロード済みのシンボルを一旦削除する必要があるっぽい。

ちなみにWPFのソースコード自体はAvailable Source Code Componentsから落とせる。

Google マップなんかでホイールを回すとズームする機能。あれって現在マウスが指している位置はそのままで拡大率だけが変わるのだが,同じことを実装しようとすると意外に難しい。忘れそうなのでメモ。

2010090801

図は拡大率R1から拡大率R2に変更したときの例。大きな四角はマップ全体で,中の四角はビューポート。拡大率R1でマウスカーソルが絶対座標(Ax, Ay) 相対座標(Rx,Ry)にいるとき,拡大率をR2にした場合を考える。このとき,ビューのスクロール位置(Sx, Sy)をうまくいじってやれば,ビューからの相対座標(Rx,Ry)を変えずに拡大をすることができる。(Sx, Sy)の求め方は以下の通り。

(Sx', Sy') = (Ax', Ay') - (Rx, Ry)
           = (Ax, Ay) * R2 / R1 - (Rx, Ry)

でここからがWPFの場合だが,OnMouseWheelの中で以下のように実装してみた。_view(ScrollViewerなど)の中に_map(Canvasなど)を入れている前提。_viewへのGetPositionとスクロール位置はR1倍した値になり,_viewの中身へのGetPositionは拡大する前の値になるので上の式と若干異なっている。

private void OnMouseWheel(object sender, System.Windows.Input.MouseWheelEventArgs e)
{
    double a_x = e.GetPosition(_map).X;
    double a_y = e.GetPosition(_map).Y;
    double r_x = e.GetPosition(_view).X;
    double r_y = e.GetPosition(_view).Y;

    R_2 = R1 + e.Delta;

    _view.ScrollToHorizontalOffset(a_x * R_2 - r_x);
    _view.ScrollToVerticalOffset(a_y * R_2 - r_y);
}

シャドールームさんのところでいくつかタイピングゲームの複数入力の方法について話題が出ていたのでWeather Typingのやり方を少しだけ書いてみる。 Weather Tytpingの自動ローマ字入力はオートマトンを使っている。シャドールームさんで紹介されてたHow To Become A Typerさんが「Tsuikyo 2.0 – 鎚鏡弐」で書いているのと同じ方法ですかね。以下の絵は,いつかタイピングソフトの作り方ページを作るときのために作ったネタだけど,多分今後も作らないだろうし,丁度良いので載せてみる。 2010090401

図は「しゃ」という問題文があったときの例。まず「しゃ」という問題がきたら,あらかじめ上のようなオートマトンを作成しておく。作り方はなんでもいいけど「しゃ」と上のオートマトンをテーブルで用意しておいてもいい。で画面に表示する文字列を作るときは,現在の設定に従ってオートマトンを処理する。例えば「CよりはSを使う」「SHよりはSYを使う」「LYAやXYAは使わない」設定であればS→1→7→Eを通って「SHA」を表示する。次にゲーム中ユーザ入力がきた場合,設定と画面表示を更新しながらオートマトンを処理していく。例えば「CILYA」と入力したときは2へ行って「SよりはCを使う」設定に変更。3→5へ行って「LYAやXYAを使う」設定に変更。最後に9→Eへ行って完了。上の矢印以外の入力が来たらミス扱い。 上の例は「しゃ」だが,問題文が長くなったらオートマトンをつなげていくだけ。例えば「しゃしゃ」だったら上のを2個つなぐだけでOK。「ん」「っ」が入ってくるとだいぶややこしくなるが,基本的には上のやり方でやればいい感じの自動入力ができる。 なお,TODでは多分「SHよりはSYを使う」のような系統立てた入力設定ではなく「SHAよりはSYAを使う」「SHUよりはSYUを使う」みたいな細かい入力設定になっているっぽい。「ん」の扱いも変。Weather TypingはTODを超えることを目指して作っていたので,この辺はTODより改善できているはず。

楽譜表示のUI部分が完成。だいぶWPFに詳しくなった気がする。あとは楽譜表示に戻って8vaとか未実装な部分を実装すればとりあえずは完成か。


てことでWPF関連。プロジェクトを.NET 3.5ベースにしているとうまくいかないけど.NET 4.0ベースにしたらうまくいったケースがあったのでメモ。.NET 4.0はWindows 7デフォルトで入っていないが,Windows Updateに重要な更新で出てくるし,大丈夫でしょう。


1つ目。CheckBoxにbool型のプロパティをtwoway Bindingしている状況で,ある条件のときはsetterで何もせずに返すようなコードを書いた。チェック操作をしたけどチェックできませんでした,みたいなことをしたいのである。

XAML
<CheckBox IsChecked="{Binding IsDisplay, Mode=twoway}">
C#
 bool IsDisplay
 {
     set
     {
         if(xxx)
         {
             return;
         }
         _isdisplay = value;
         PropertyChanged(this, new PropertyChangedEventArgs("IsDisplay"));
     }
     get
     {
         return _isdisplay;
     }
 }

この状態でチェックボックスをオフからオンに変えようとすると,プロパティはfalseのままなのにUIはtrueになってしまって状態が食い違う感じになってしまう。で結局プロジェクトを.NET 4.0ベースにするとうまくチェックがキャンセルされた。


2つ目。以下のようにListBoxでテキストラベルとそれ以外を配置しているようなケースで,テキストラベルを可変長(Width=”100*”とか)にしている場合,ウィンドウを1度でも広げていれば問題はないのだが,ウィンドウ表示時に画面を狭くしていると,レイアウトが崩れてしまう。

2010082501

2010082502

これも結局プロジェクトを.NET 4.0ベースにするとレイアウトが崩れなくなった。

MIDI楽譜表示。UIはだいたいできてきた。今こんな感じ。

20100724


C++からC#への移行も兼ねてWPFで作ってるのだが,WPFで実装していくと,作った覚えのない部分が勝手に実装されていたりするのが気持ちいい。例えば下のプログレスバーは演奏箇所にBindingしているので演奏が進むと勝手にバーが進むようになっている。で,それとは別に楽譜の中にある赤いカーソルは,演奏している場所に合わせて描画している。こうしておくとプログレスバーを動かすとリアルタイムに赤いカーソルが動くようになる。そんなコードは作り込んでないのに勝手に動くのが素晴らしい。

とはいえ,今までのWin32プログラミングと比べて,どれだけコードをかかずにやりたいことを実現させるか,みたいなのに時間を使ってしまうので無駄に手間がかかってるような。


先週は右側のトラック表示部分をドラッグして並べ替えられるようにしていた。先月のMSDN Magazineにいい感じの記事があったので,それを参考に実装はできたのだが,ItemContainerGeneratorとか深い部分はまだ分かってない感じ。

最後にはまったのがドラッグ時のアニメーション。StoryboardのDurationにmillisecondを指定しても,アニメーションが途中で終わってしまって困ったのだが,StoryboardのDurationではなくてDoubleAnimationとかのDurationに指定しないといけないのか。Storyboardは0.3秒とかでもDoubleAnimationがデフォルトの1秒になってて途中で切れていたっぽい。

UIが完成したらもう一度楽譜に戻って未実装部分を作り込んで,とりあえず楽譜表示は完成か。

ディスプレイ購入後,しばらくマルチディスプレイで使っている。で思ったのだが,複数のPCを使用しているときにもマルチディスプレイ的な操作がしたい。つまりメインのPCが右にあってサブPCが左にあったら,メインPCでマウスカーソルを左にはみ出させるとサブPCのマウスが動いて,さらにメインPCのキーボードでサブPCが操作できる感じ。技術的にも難しくはなさそうだったので2時間でプロトを作ってみた。SetWindowsHookExとSocket通信でなんとなく動くところまではいった。

で,ちゃんと作り始める前にネットで検索してみる。するとやっぱり同じ事考えている人はいますね。Avalonさんの「DOKODEMO」がまさにやりたかったことだった。というわけで開発は断念。今は真ん中ディスプレイ,右にメインノート,左にサブノートの環境なのだが,かなり快適になった。3台以上もOKだし,PC切替機なんか昔のテクノロジって感じになっちゃいますね。

マルチディスプレイと違う点としては,ウィンドウをドラッグできないこととオブジェクトをドラッグアンドドロップできないこと,か。テキストはクリップボード共有ができるのでいいのだが,ファイルのドラッグアンドドロップは無理かなあ。裏で共有フォルダ経由にするとかそれこそSocketで送ってしまうとか。もしこれができるとかなり便利な気がする。

Expression 4とSilverlight 4 Toolsがリリースされていたので入れてみた。これで.NET 3.5から.NET 4.0に移行できる,んだけどそうするとデフォルトで動かなくなってしまうのだろうか。

なんかお金が振り込まれていたのでキーボードとディスプレイを購入してみた。ノートPCを使ってるんだけど,姿勢が前屈みになるのがずっと気になっていてようやく購入という感じ。床に座ってたときから比べると,デスク・チェア→キーボード→ディスプレイとずいぶん環境がよくなった。

ディスプレイについては高くてもいいものないかなあ,といろいろ探していたのだが,最近はいい液晶ディスプレイってないんですね。24インチだとでかすぎとか今のノートがWUXGAだから同じくらいの解像度,っていうともう選択肢がない。で結局ナナオにしてみたのだが,いい感じ。DELLノートと大分色合いが違うっていうか白ってこんなに白かったのか。

元がノートなので簡単にマルチディスプレイにできるのだが,ノートと外部ディスプレイの組合せだとちょっと使いづらい。

掲示板のDirectPlay初期化の件。エラー処理を除くと以下のようなコードになっていて,Initializeで止まっていると思われる。多分DirectPlayを使用するゲームは全て動かないのだろう。Dumpを送ってもらえば何か分かるかも知れないが,何百MBとかだし,DirectPlayが原因と分かってMSに聞いたとしてももはやサポート外で答えてくれない気もする。

LogOut(_T("DirectPlay: 初期化開始"));

::CoCreateInstance(CLSID_DirectPlay8Peer, NULL, CLSCTX_INPROC_SERVER, IID_IDirectPlay8Peer, (LPVOID *)&m_pDirectPlay);

m_pDirectPlay->Initialize(this, MessageHandlerStatic, 0);

LogOut(_T("DirectPlay: 初期化完了"));

WPFのローカリゼーション。どうもMS的にはLocBamlを使う方法を推奨している感じがするが,リソースDLLをビルドしてからバイナリを編集するというのはちょっと気持ち悪い。ということでresxを使うことに。これで合ってるか分からないけどとりあえず最小限のやり方。

  • 最初から入っているResources.resxと同じようにResources.ja-JP.resxを作成し,Propertiesに入れておく。
  • 英語と日本語で同じNameのリソースを作成。
  • .csファイルからはProperties.Resources.XXXで参照する。
  • .xamlファイルからは「xmlns:s="clr-namespace:project.Properties"」のようにネームスペースを参照しておき,{x:Static s:Resources.XXX}として参照する。

なおこれだと言語はOSの表示言語に従うことになる。切り替えたい場合はThread.CurrentThread.CurrentUICultureで切り替えればいいはず。試してないけど。


ここまで作成したものをXPで試してみたが,xmlparseでエラーが発生し,起動できなかった。しばらく調べてみたが原因不明。まあXPは対象外にする予定だからまあいいか。

ゴールデンウィ。なんだか特命でアセンブラ書いてたりする。アセンブラを読むのは割と日常だが,書くのはPC-6001のZ80以来なので懐かしい。とりあえずブートの仕方をネットで探して組んでいるが,特に参考になるのがウイルスのコードだったりして複雑な気分。


長期休暇で実家にいるので久々にテレビと新聞を見ているわけだが,もはやネットな人とテレビな人では完全に住む世界が違う感じですね。きっしー(誰)の宮崎県が大変なことになってるけどどこもやってないし。仮に報道規制だとしても,ネットな人はいくらでも調べられるわけで,どんどん情報格差が広がってますね。

# 情報規制はデマらしい。つまりテレビ業界は口蹄疫なんて報道する価値なしと判断してたってことですね。