public struct MEMORYSTATUS
{
public uint dwLength;
public uint dwMemoryLoad;
public uint dwTotalPhys;
public uint dwAvailPhys;
public uint dwTotalPageFile;
public uint dwAvailPageFile;
public uint dwTotalVirtual;
public uint dwAvailVirtual;
}
[DllImport("CoreDll.dll")]
public static extern void GlobalMemoryStatus
(
MEMORYSTATUS lpBuffer
);
public void ShowMemory()
{
// Call the native GlobalMemoryStatus method
// with the defined structure.
MEMORYSTATUS memStatus = new MEMORYSTATUS();
GlobalMemoryStatus(memStatus);
}

らしいのですが、GlobalMemoryStatusを呼んだ時点でアプリが終了します。Exceptionすらも出さずに。
むむ？サンプルの解釈が間違ってるのかな？

2006-05-17

Graphics.DrawImage(Image,Rectangle,Rectangle,GraphicsUnit)の描画条件

.Net

デスクトップ向け.Net Frameworkでは、WidthもしくはHeightがマイナスで、なおかつ左端、上端が描画先のクライアント領域を超えているときには、そもそも描画もなされないようです。
こんな感じ。

aGraphics.DrawImage(aImage,new Rectangle(0,0,100,100),new Rectangle(50,0,-100,100),GraphicsUnit.Pixel);

でも、.Net Compact Frameworkでは描画できるよなぁ。これって、仕様としてはどっちが正しいんだろう？
クリッピング自体は手動でやっても大して難しい物でもないんだけど、何かbitbltのオプションに対して見逃している物があるんだろうかと考えると、自前実装はちょっと怖いなぁ。

2006-05-17

でも

.Net

とりあえず、あきらめて左右、上下端の独自実装。.Net Framework使い始めてからこんなのばっかり(^^;)。

ともあれ、予定していたところまではたどり着きました。

MSILと.Net Framework2.0と、C#のGenericを使ったゲームエンジン
ゲーム部分ソース/リソースはデバイス非依存(.Net Compact Frameworkと.Net Frameworkで共通)

どこまで公開できるかは考えなくてはなりませんが、まずはデモ用のバイナリとアーカイブを用意しましょう。
Windows Mobile5.0を持っている方はそのうちアナウンスしますので見てやって下さい。

2006-05-17

.Net Framework雑感

.Net

アプリケーション本編部分はそこそこ簡潔に書くことが出来ますし、Visual Studio 2005の強力なIDEで快適に開発できます。リモートデバッガが強力なのでデバッグもかなり容易です。
……でもなー、いろんな意味で、Javaにはだいぶ及んでいないなぁ、というのが.Net Frameworkの感想です。

デメリット
- .Net Compact Framework2.0(と、.Net Framework 2.0)は、J2MEPP(と、J2SE)に比べて不自由
- Write Once,Run Anywhereにはほど遠いビルド環境
- リソースハンドリングが妙に複雑で独自仕様が多すぎ
- 結局何かというとネイティブに逃げたがる。共通仕様の内側でもMicrosoft.*名前空間を使わないと何も出来ない。
- 命名規則と名前空間のルールが謎
メリット
- パフォーマンスはすごくいい
- Genericコレクションとボクシング最強(こんなに快適なのはSmalltalk以来)
- Windows Formは便利で、非常に素直な設計(ちょっとでも離れるととたんに面倒(^^;))
- 組み込みでも、デスクトップでもデバッグが楽
- マーシャリング最強。足りない機能はどんどんネイティブを叩けば何でも出来る(デバイス非依存からはどんどん遠のくけど(^^;))
- プリプロセッサマクロ快適＜堕落してるぞ(^^;)

何よりも、「パフォーマンスがすごくいい」ってのがゲーム屋的にはありがたいですね。正直、Windows Mobile上のVMがこんなにパフォーマンスがいいとは思っていなかったので、思ったよりも凝ったことが出来そうです。あ、いや、ハードウェアにおんぶにだっこの描画部分はちょっとおいておいても。
あと、てきとーにちゃちゃっとアプリケーションを作るのにはいい感じですね。これは、ゲームエンジンと平行して作っていたNotepadWMでも感じましたが。むしろ、ゲームエンジンで大変苦労していたところに「もしかして、Windows Formに逆らってるからでは？」と思い直して試しに作ったNotepadWMが予想以上に開発効率が良かったのがびっくりでした。
むしろ、Windows FormのControlだけを使ってゲームを作る……のはほぼ、無理か(^^;)。やってみても罰は当たらなさそうだけど、再描画周りが大変なことになるな。DoubleBufferingプロパティはそんなにきちんとは動いてくれてないみたいだし。

もっとも、Java5もオートボクシングとGenericコレクションと、foreach(これが便利！)はついてるので、Eclipse上で使う分には.Net Frameworkと対して違わないかもしれませんね。yieldがないのは残念だけど。
もう昔のVodafoneの仕事は来ないだろうし、Java5を入れちゃってもいいよなぁ……(Vodafoneの昔のエミュレータはJava5を入れると動かなくなるのです)。

2006-05-17

NetFront 3.3 正式版(http://www.access.co.jp/press/060517.html)

W-ZERO3

あぁぁ、やっと出る。
出たら早速買いましょう。なにせ、かなりNetFrontに依存しているので。先月末の「試用期限」騒動の時に痛感しました。これがないと困ります(^^;)。
しかし、これに付属するJV-Liteって、どんなプロファイルなんだろう？
MIDPのプロファイルはJBlend(だよね、あれ)がすでに載ってるし、J2MEPPだったりするとすごくうれしいなぁ。
でも、JV-LiteのJ2MEPPって今まで製品あったっけ？DreamcastのJV-LiteはPersonal Profile互換だったらしいんだけど(でも、ページにJava アプレットを入れる方法がなかったような……)。

一応、JV-Lite2の製品ページによると(http://www.access.co.jp/products/jv_ce.html)

Foundation Profile (FP)
- Network and I/O library, no GUI
- ROM:2-2.5MB, RAM: 2MB-
Personal Basis Profile (PBP)
- FP + basic graphic library and xlet
- ROM:3-4MB, RAM: 4MB-
Personal Profile (PP)
- PBP + full AWT and applet
- ROM:3.5-5.5MB, RAM: 4MB-

うーん、FPってことはないと思うんだけど。PBPでもまぁ、この際許そう。PPだったらいろいろ出来るなぁ。PP来い来い！

2006-05-17

NetFront3.2に対応したページ

W-ZERO3

Java Appletが使えるみたいですね。ってことは、FPってことはないかな。GUIついてるし。
ただ、単体でVMをたたくのは無理かなぁ。ブラウザ上だとサンドボックスのせいでファイル関係が使えない可能性があるんだよなぁ。
何とか単体で使う方法がないかなぁ。
SunかIBMがJ2MEPPのWindowsCE用VMを出してくれればいいんだけど。いかにもありそうなんだけどなぁ。

2006-05-17

ぼくは航空管制官2

しばらく追いかけられずにいたら、うちのPCのスペックは、最低環境よりもずっと下になっていました(^^;)。
あぁぁ、そりゃそうだな。もう4年もPCの環境変えてないや。せめて「Half Life2」と「Bridge it!」くらいは(どちらも微妙に古い(^^;))動くようにしないと。