O3D Demos and Samples – O3D Plug-in API – Google Code

HTML5 の正式リリースでこういった流れが加速するのでしょうか。

しかしながら、いまだに HTML5 とグラフィックス描画との関連が見えません。もしかすると、そういった用途を想定した DOM オブジェクトが追加になっているのかもしれませんが、よく聞く Canvas というのがそれなのでしょうか。

私が把握しているのはセクションやヘッダーといった、 WEB サイトや文章を作るならあるとうれしいなぁ、というエレメントが追加になっていることくらいなものです。

草案によると…

To draw on the canvas, authors must first obtain a reference to a context using the getContext(contextId) method of the canvas element.

context = canvas.getContext(contextId)
Returns an object that exposes an API for drawing on the canvas.
Returns null if the given context ID is not supported.

…とのことで HTML Canvas 2D Context というオブジェクトを取得することができるようです。リンク先を確認してみましたが、 3×3 の行列を使ったトランスフォームができるようでして、確かに 2D 描画機能としては不足を感じません（でも、表示ツリーみたいなことをやるにはどうすればいいんだろう？）。

また、かなり速度的な疑問を感じますが、 Pixel manipulation によってフレームバッファへアクセスするかのようなことも可能らしいです。一応 data というプロパティへアクセスすることで “Returns the one-dimensional array containing the data.” というお話ですので、関数を呼んで１ピクセル単位で読み書きするよりかは高速になりそうですが、はてさて…

ちなみに、現在 W3C の方でまとまっているのは 2D 関連のみなのか分かりませんが…

Vendors may also define experimental contexts using the syntax vendorname-context, for example, moz-3d.

…とのことです。もし、「 Flash を駆逐したい！」と思われる方がいらっしゃるなら、誰かが頑張って作るかもしれません。

いろいろと分からないことが多いので本を注文してみました。良かったら紹介します。

ちょっと前に、ドラびでおさんというアーティストの方が、ドラムとコンピュータを MIDI ケーブルで繋ぎ、ドラムを叩いてリアルタイムに MAD 映像を操作するというパフォーマンスをされているのをテレビで目にしました。そこで MIDI ケーブルに流れるのは波形ではなく何かの信号なのだと気がつきます。

そこでわかったのが MIDI 機器、特に音源は信号を受信した段階ですぐに音を鳴らすという点です。つまり、曲を演奏しようと思ったら、音を鳴らすタイミングは信号を送る側が調整しなければならないのです。昔の Cakewalk のようなソフトウェアを MIDI シーケンサーと呼んだのはそういった理由からだそうです。ピアノロールで設定したタイミングに合わせて MIDI 信号を送るのが役割だったようです。

…となると当然の疑問が湧いてきます。 MIDI 機器は一度にどれだけの信号を処理できるのでしょうか。処理性能はハードウェアによって異なるでしょうが、ケーブルに流せる量は決まっているはずです（仕様が変わってないとどこかで聞いたような）。

で、調べてみました。規格を見ればわかるだろうとインターネットの世界に繰り出します。

MIDI Glossary

ここによると…

BAUD : A measurement of speed at which serial data is transmitted. MIDI operates at 31.25 kBaud, i.e. data can be transferred at a speed of 31250 bits per second.

…だ、そうで、あんまし転送量は多くないことが分かります。

ノート（音符の情報）の量を送るには十分かもしれませんが、その他の情報をあわせて送る際に問題に遭遇した場合はこのあたりに着目しようと思います。

ちなみに、未確認なのですが USB 接続するととんでもない転送量を実現できるようです。こちらもかなり興味あるのですが、前述の通り、受け側の性能以上のことはできませんのであんまり期待してないです。

MS のコンパイラが吐くコードより Intel のコンパイラの吐くコードの方が品質が高い（当時はコストベースの最適化は Intel のコンパイラが一番性能良かったそうです）のでそっちを使っていたり、やはりハードウェアの環境依存の解決が大変だったり（対応していない命令に”対応している”と返す偽仕様もあったとか）、コンシューマゲーム機向けゲームの開発も大変ですが、こちらはこちらで独特のノウハウが必要ですね。

また、 Windows ではヒートエイジングをやらないそうです。理由は「その前に Windows が落ちるから」だそうです（当時は 9x 系しか無かった）。なんて情けない OS でしょうか…

コンシューマゲーム機向けのゲームの開発には、スタックサイズに強い制限があったり、例外やメタプログラミングの採用に慎重にならざるを得なくなったり、ハードウェアへの深い理解が必要になったり、やってることは組み込み系と同じだなと思っていたのですが、やはり携帯電話みたいなデバイスとは少し違うのかもしれないというのが今の考えです。

世間一般的にはどうなのか大変気になる話題です。組み込み系ではないからといって制御系でもないような気がするのですが、いえ、なぜこのような話になるのかというと、やはりコンシューマゲーム機向けのゲーム開発が簡単に思われているような風潮に恐怖を感じたからです。せめて組み込み系も問題なくやってのけるくらいのスキルは必要だと思います。

Microsoft(R) System Check Tool for PC Games

ひとつだけ、新しい CPU になると名前が取得できないという問題はあるのですが、基本的な数値目標は調べることができます。たとえば VRAM の総容量とか。

ぜひともバージョンアップして欲しいです。

その名も GlobalMemoryStatusEx() 。

総容量と空き容量が取得できますが、使用容量は総容量から空き容量を引き算して求める必要があります。

その名も EnumDisplayDevices() 。

Enum という名前から想像できるとおり、失敗するまで繰り返すことで複数のビデオボードの名前を取得することが可能です。

あれ？どれがメインのビデオボードかわからないような気がする…

現状で最もイメージに近いソースを載せておきます。随時加筆予定です。

#include <stdio.h>

#include <windows.h>

#include <setupapi.h>

#include <devguid.h>

#include <regstr.h>

#include <tchar.h>


#pragma comment(lib, "setupapi.lib")


int main(int argc, char *argv[])
{
  HDEVINFO hDevInfo;
  SP_DEVINFO_DATA DeviceInfoData;
  DWORD i;

  // Create a HDEVINFO with all present devices.
  hDevInfo = SetupDiGetClassDevs(NULL,
                                 0, // Enumerator
                                 0,
                                 DIGCF_PRESENT | DIGCF_ALLCLASSES);
  
  if (hDevInfo == INVALID_HANDLE_VALUE) {
    // Insert error handling here.
    return 1;
  }
       
  // Enumerate through all devices in Set.
  DeviceInfoData.cbSize = sizeof(SP_DEVINFO_DATA);
  for (i = 0; SetupDiEnumDeviceInfo(hDevInfo, i, &DeviceInfoData); i++) {
    DWORD DataT;
    LPTSTR buffer = NULL;
    DWORD buffersize = 0;
           
    //
    // Call function with null to begin with, 
    // then use the returned buffer size (doubled)
    // to Alloc the buffer. Keep calling until
    // success or an unknown failure.
    //
    //  Double the returned buffersize to correct
    //  for underlying legacy CM functions that 
    //  return an incorrect buffersize value on 
    //  DBCS/MBCS systems.
    // 
    while (!SetupDiGetDeviceRegistryProperty(hDevInfo,
                                             &DeviceInfoData,
                                             SPDRP_DEVICEDESC,
                                             &DataT,
                                             (PBYTE)buffer,
                                             buffersize,
                                             &buffersize)) {
      if (GetLastError() ==  ERROR_INSUFFICIENT_BUFFER) {
        // Change the buffer size.
        if (buffer) LocalFree(buffer);
        // Double the size to avoid problems on 
        // W2k MBCS systems per KB 888609. 
        buffer = (LPTSTR)LocalAlloc(LPTR,buffersize * 2);
      } else {
        // Insert error handling here.
        break;
      }
    }
           
    _tprintf(TEXT("Result:[%s]\n"), buffer);
           
    if (buffer) LocalFree(buffer);
  }
       
       
  if (GetLastError() != NO_ERROR &&
      GetLastError() != ERROR_NO_MORE_ITEMS) {
    // Insert error handling here.
    return 1;
  }
       
  //  Cleanup
  SetupDiDestroyDeviceInfoList(hDevInfo);

  return 0;
}

次のリストは今後の課題です。

• ターゲットを絞って取得する方法を見つける
• メインメモリやビデオメモリの容量を取得する方法を見つける
• ハードディスクの容量を取得する方法を見つける

ここまで苦戦するとは思いませんでした。