MacOSX 上で Nebula Device 2 の build に挑戦中(4)

相変わらずの bus error 10

どうもテクスチャを有効にすると bus error 10 が出てしまうみたいなので、 shaders と renderpass を簡単な物に変更してみました。

void main(void)
{
 gl_TexCoord[0] = gl_MultiTexCoord0;
 gl_Position = ftransform();
}
uniform sampler2D DiffMap0;
void main(void)
{
 vec3 color = texture2D(DiffMap0, gl_TexCoord[0].st).xyz;
 gl_FragColor.rgb = color;
 gl_FragColor.a = 1.0;
}
<?xml version="1.0" encoding="utf-8" ?>
<RenderPath name="glsl" shaderPath="renderpath:glsl">
  <Shaders>
    <Shader name="passes" file="shaders:passes.fx" />
    <Shader name="phases" file="shaders:phases.fx" />
    <Shader name="static" file="shaders:shaders.fx" />
    <Shader name="stencil_plane" file="shaders:stencil_plane.fx" />
    <Shader name="gui3d" file="shaders:gui.fx" />
    <Shader name="water" file="shaders:water.fx" />
    <!-- ASIM -->
    <Shader name="underwaterground" file ="shaders:asim.fx" />
    <Shader name="underwater" file ="shaders:asim.fx" />
  </Shaders>

  <Float4 name="ShadowColor" value="0.0 0.0 0.0 0.25" />
  <Float4 name="FogDistances" value="10.0 100.0 0.0 0.0" />
  <Float4 name="FogColor" value="0.5 0.5 0.5 1.0" />

  <Section name="default">
    <Pass name="color" shader="passes" technique="tPassColor" clearColor="0.0 0.0 0.0 1.0" clearDepth="1.0" clearStencil="0">
      <Phase name="opaque" shader="phases" technique="tPhaseOpaque" sort="FrontToBack" lightMode="FFP">
        <Sequence shader="static" technique="tStatic" />
      </Phase>
    </Pass>

    <Pass name="gui" drawGui="Yes"/>

  </Section>
</RenderPath>

ここまで単純にすれば動作するかな?と思いきや、やっぱり bus error 10 …

nMesh2 が怪しそう…

デバッグを続けていくと、どうやら nGLServer2::DrawIndexedNS あたりに原因がありそうなことがわかりました。

nGLServer2::DrawIndexedNS は、名前のようにインデックスバッファを指定して、プリミティブ(nMesh2)の描画)を行う関数なのですが、どうも glDrawElements を呼び出すとおかしくなるようです。

無理矢理な動作確認…

そんなわけで、直接ポリゴンを描画してみたらどうだろうか?というわけで、またもや無理矢理シェーダー設定を追加してみました。

glEnable(GL_TEXTURE_2D);
glTexEnvf(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_REPLACE);
glActiveTexture(GL_TEXTURE0); // change active texture unit to number 0
glBindTexture(GL_TEXTURE_2D, 3 );

glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);
glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP);
glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP);
glUseProgramObjectARB(7);
glUniform1iARB(0, 0);
glColor3d(0.2, 0.2, 1.0);

glBegin(GL_QUADS);
glTexCoord2d(0.0, 1.0);
glVertex3d(-10.0, -10.0, 0.0);
glTexCoord2d(1.0, 1.0);
glVertex3d( 10.0, -10.0, 0.0);
glTexCoord2d(1.0, 0.0);
glVertex3d( 10.0,  10.0, 0.0);
glTexCoord2d(0.0, 0.0);
glVertex3d(-10.0,  10.0, 0.0);
glEnd();

tex 表示されました。(色がおかしいけど…)

どうやら、 nMesh2 関係が正しく動作していないみたい。

MacOSX 上で Nebula Device 2 の build に挑戦中(3)

OpenGL の初期化と nMesh の描画までは出来るようになりました。

n2_1 こんな感じ。

本当は Diff0 + Bump0 が設定されているので、バンプマップされたドーナツが表示されるはずなのですが、そもそも nTexture2 が読み込まれていないみたい…

 

irrlicht を build(2)

irrlicht-1.8 の build について前の記事で書いたのですが、修正作業を自分で忘れてしまいそうなのでこちらに書き直すことにしました。

irrlicht-1.8 をむりやり build する方法

COpenGLExtensionHandler.h 2390行目

glProgramParameteriEXT((long GLuint)program, pname, value);

glProgramParameteriEXT((long)program, pname, value);

CIrrDeviceMacOSX.h 22 〜 24行目

class NSWindow;
class NSOpenGLContext;
class NSBitmapImageRep;

//class NSWindow;
//class NSOpenGLContext;
//class NSBitmapImageRep;

CIrrDeviceMacOSX.h 228 ~ 231行目

NSWindow *Window;
CGLContextObj CGLContext;
NSOpenGLContext *OGLContext;
NSBitmapImageRep *SoftwareDriverTarget;

void *Window;
CGLContextObj CGLContext;
void *OGLContext;
void *SoftwareDriverTarget;

CIrrDeviceMacOSX.mm 902行目

NSRect driverFrame = [Window contentRectForFrameRect:[Window frame]];

NSRect driverFrame = [(NSWindow*)Window contentRectForFrameRect:[(NSWindow*)Window frame]];

CIrrDeviceMacOSX.mm 1279行目

p = [Window convertScreenToBase:p];

p = [(NSWindow)Window convertScreenToBase:p];

CIrrDeviceMacOSX.mm 1319行目

p = [Window convertBaseToScreen:p];

p = [(NSWindow*)Window convertBaseToScreen:p];

CIrrDeviceMacOSX.mm 1518行目

s32([SoftwareDriverTarget size].width) != surface->getDimension().Width ||
s32([SoftwareDriverTarget size].height) != surface->getDimension().Height;

s32([(NSBitmapImageRep*)SoftwareDriverTarget size].width) != surface->getDimension().Width ||
s32([(NSBitmapImageRep*)SoftwareDriverTarget size].height) != surface->getDimension().Height;

 

こんな感じで build を通しました。

irrlicht を build(1)

Nebula Device 2 が思うように build 出来なかったので、気分転換に irrlicht を build することにしました。2013-01-22時点での最新版は 1.8 のようですが、Mountain Lion ではコンパイルエラーが出てしまうようです。

かなり強引な方法ですが、OpenGL を初期化して動作させているコードを確認するのが目的なので以下の様な変更をしました。

CIrrDeviceMacOSX.h

まず、エラーが出ている直接原因である CIrrDeviceMacOSX.h を開いて、

class NSWindow;
class NSOpenGLContext;
class NSBitmapImageRep;

の箇所をコメントアウトします。

上記箇所をコメントアウトすると class 前方参照が無くなってしまうため、ひとまず void* にしてしまいます。

//NSWindow *Window;
void* Window;
//NSOpenGLContext *OGLContext;
void* OGLContext;
//NSBitmapImageRep *SoftwareDriverTarget;
void* SoftwareDriverTarget;

こんな感じ。

あとは、これらの変数を参照している場所で cast を行いました。

ir1 ir2 ir3

そんなこんなで動きました。

Nebula Device 2 の描画順序について

SceneNode内でソートしないようにするにはどうすれば良いのかと以前から気にしていたのですが、偶然見つけたのでメモ。

場所は nsceneserver_main.cc 内でした。

nSceneServer::RenderScene()
  nSceneServer::SortNodes()
    qsort(indexPtr, numIndices, sizeof(ushort), (int(__cdecl*)(const void*, const void*))CompareNodes);
      nSceneServer::CompareNodes(const ushort* i1, const ushort* i2)

Nebula Device 2 は、描画順序に以下の様なルールで処理されます。

描画は XML で定義された render path 順に処理される。

使用するシェーダーによっては、レンダリングされた結果を読み取りたい場合があったり、デバッグ用のメニュー表示を行うために、 render path の順番はとても重要です。

ひとつの path は、その中で定義されたシェーダー順で描画される。

アルファ値を使用した描画をZ値を参照しながら描画をするときに前後関係によってはおかしくなる時があります。ですので、ひとつの path に列挙された順に描画されます。

SceneNodeはプライオリティが高いものほど手前に描画される。

表現方法によっては、本来みえないはずのものが見えた方が望ましい場合があります。(例えば、壁の向こう側が透けて見えるとか)そういった本来の前後関係をどうしても無視したい場合は、プライオリティの値を大きくすることで一時的に手前にする事が出来ます。

同じプライオリティの場合はカメラからの距離に応じて描画順序が並び替えられる。

不透明な物の後ろに配置された物は見えなくなります。描画される空間がどんなに広くても、それをディスプレイ越しに見る限りは、結局は見えている物がすべてとなります。

そこで

  • 全く見えないのはそもそも描画しない。
  • 一部分しか見えない物は、見えている部分だけを描画する。

といった方法で、必要な物だけを描画します。

手前のものから描くことで、そこに隠れているもの自体を描画しないようにします。

説明が長くなってしまいましたが、こんな感じで便利な機能が内蔵されているのですが、 2D の描画を行う際にはこの処理が問題となります。

Nebula Device 2 では nRpPhase に None, FrontToBack, BackToFront というのが選べるのですが、一時的にソートしないようにするにはどこをいじれば良いのかわからなかったので…

MacOSX 上で Nebula Device 2 の build に挑戦中(2)

nglviewer の build までは漕ぎ着けたけど、 OpenGL の初期化をしていないため「 OpenGL の関数が使用できない」という状態です。

$ nglviewer
nIpcServer: listening on port 12067...
startup.tcl: OnStartup called
nGLServer2::DeviceOpen()

Device information
Vendor: (null)
Renderer: (null)
Version: (null)

Supported GL extensions:

Init OpenGL extensitions:
[-] GL_ARB_shading_language_100

[-] GL_ARB_vertex_program

[-] GL_ARB_fragment_program

[-] GL_ARB_shader_objects

[-] GL_ARB_vertex_shader

[-] GL_ARB_vertex_buffer_object

[-] GL_ARB_texture_compression

[-] GL_EXT_texture_compression_s3tc

[-] GL_ARB_texture_cube_map

[-] GL_ARB_multitexture

[-] GL_ARB_occlusion_query

*** NEBULA ASSERTION ***
programmer says: nGLServer2::DeviceOpen(): GL_ARB_shader_objects extention not supported!
expression: N_GL_EXTENSION_SUPPORTED(GL_ARB_shader_objects)
file: ../../code/contrib/nopengl/src/opengl/nglserver2_device.cc
line: 164
Abort trap: 6

そもそも glGetString 自体が動作していないという事から、ディスプレイの初期化すら出来ていない状態です。

ディスプレイの初期化が出来ると、ハードウェアの情報が取得出来るので、

GL_VENDOR … ATI Technologies Inc.
GL_RENDERER … ATI Radeon HD 4670 OpenGL Engine
GL_VERSION … 2.1 ATI-8.0.61

といった情報が取得出来るはずです。(これはうちの環境が iMac 21.5-inch, Late 2009 だからです。)

nOpenGL 部分が win32 向けに用意されているのと、自分が X11 上で OpenGL アプリケーションを開発したことがないため、 windows から X11 への差し替えをどうやればいいのか判断出来ない状態となりました。

irrlicht でも参考にしてみるかな。

 

MacOSX 上で Nebula Device 2 の build に挑戦中(1)

Nebula Device 2 は update.py を使用してビルド環境を生成する仕組みになっています。

例えば、

python update.py -build makefile nebula2libs nebula2tools nopengl

という指定をする事で、 makefile を使用するビルド環境を用意する事が出来ます。

Nebula Device 2 の描画システムは標準で DirectX9 を使用するのですが、gfx2 ライブラリを自分で用意することで他のシステム上に移植することが出来るようになっています。

幸いなことに OpenGL 用のモジュールが nebula2/code/contrib/nopengl に含まれているので、これを使用することで MacOSX 上でも Nebula Device 2 が動くようになりそうです。

実を言うと update.py で生成する Makefile に OSTYPE=darwin と指定する事で、 MacOS 上でのビルドが行えるようになっているのですが、 Nebula Device 2 自体が古いため、想定されているシステムは darwin8.0 ( MacOSX 10.4 ) までとなります。

ここは頑張らずに linux ( X11 + OpenGL ) の環境で build に挑戦してみることにします。

ソースコードの入手

まずは SourceForge からソースコードを入手します。

svn co https://nebuladevice.svn.sourceforge.net/svnroot/nebuladevice/trunk NebulaDevice2

あとは build するだけ…というわけにはいかず、依存するライブラリも用意する必要があります。

必要なものは以下のものとなります。

  • libogg
  • libvorbis
  • libtheora
  • sqlite
  • XQuartz

というわけで、まずはこれらを build する必要があります。

それぞれの build に関しては、以下のように -m32 を指定しておきます。( Nebula Device 2 内に 32bit 環境前提のコードが含まれている為。)

export CFLAGS="-m32"
export CPPFLAGS="${CFLAGS}"
export CXXFLAGS="${CFLAGS}"

…先は長そう。

BLADES of TIME を買いました

だいぶ前に ubisoft[1. 開発は Gajin Entertainment] から X-BLADES というゲームが発売されたのですが、BLADES of TIME はそれの続編となります。

bt_01 キャラクターに前作の面影はないです。

bt_02 bt_03 bt_04

前作はアニメっぽい方向付けがされたキャラクターデザインだったのですけど、やっぱり受け入れられなかったのか、アニメっぽい表現はやめてしまったようです。

screenshot_01 screenshot_03 前作のスクリーンショット。

私が購入したのはMac版なので英語のみかと思っていたのですが、ボイス部分だけは多言語対応しているようで、アユミ(主人公)のセリフがちゃんと釘宮理恵さんの声になりました。(表示は英語のままです)

絵は綺麗になったのですけど、なんとなく敵攻撃時のヒット感が乏しいような…自分の環境だとフレームレートが安定していないからかもしれませんけど。

インドネシア料理

以前に食べた サテ や ナシゴレン が気に入って、インドネシア料理の店を探したところ SuraBaya というお店を見つけて、何度か食べに行きました。

自分はあんまり辛い料理は受け付けないのですけど、ここの味付けはちょっと辛いぐらいでおいしく食べることが出来ました。

自分の定番料理はこんな感じ。

  • 若鶏のサテ
  • 空芯菜炒めジャワスタイル
  • 魚の唐揚ブラードソース
  • ナシゴレン・スペシャル
  • チキン・ジャワカレー

サテは説明だけみると、「ピーナッツソースのついた鶏肉」と書かれているので、なんかおかしな味なんじゃないかと思われそうですが、全くそんなことはないです。

個人的に気をつけた方が良いと思うのはテンペを使用した料理です。

wikipedia から引用ここから

インドネシアのジャワ島発祥である。日本では「インドネシアの納豆」と呼ばれることもあるが、固められて乾いたブロック状である。味は淡白であり納豆にやや似ているが、よほど発酵が進んだもの以外は臭気や苦味はほとんど無く、糸を引くこともなく、クセがないので食べやすい。インドネシアでは広く料理食材として使われており、最近は欧米や日本でも健康食品としてクローズアップされており、日本では製造もされている。

wikipedia から引用ここまで

クセがないので食べやすいかなぁ…自分が食べた事があるテンペは SuraBaya のものだけなのですが、一口だけならともかく、最後まで食べることが出来ませんでした。

ゲーム向きのマップ作成ツール

2Dゲームを作成するには、プレイヤーが動かすキャラクターや敵キャラクターの画像を用意する必要がありますが、それとあわせてそれらのキャラクターが活躍する舞台を用意してあげたいところです。

ゲームによっては、単なる一枚絵の場合もあるのですが、ゲームによっては見た目以上の情報が必要となります。

例えば、

  • 通過出来る
  • 触るとライフが減る
  • アイテムの隠し場所
  • ここまで来たらゴール

といったものがあります。

こういった情報を埋め込むには、手作業で頑張っても良いのですけど、見た目を確認しながらゲームに必要な情報を埋め込めるツールがあると便利です。

というわけで、 Tiled Map Editor というのを見つけたので使用してみました。

tmx こんな画面です。(メニューがさりげなく日本語化されていて嬉しい)

ブロック単位で画像を貼付けていく事が出来るだけでなく、オブジェクト毎にちょっとした値を書き込んでおく事も出来ます。出力は XML, CSV, JSON に対応してして、レイヤーを一枚の画像として出力する事も出来るので、わりと使えそう。

 

 

Nebula Device 2 のビルド方法 (win32)

The Nebula Device 2 というゲーム開発用ライブラリがあります。かなり古いライブラリで更新がとまっている[1. 後継ライブラリとして http://code.google.com/p/nebuladevice/ があります。]のですが、内部仕様が好みで使っています。

自分用のメモとして以下にビルド方法を記述してみたりして。

以下のソフトウェアをインストール

  • VisualStudio 2008
  • DirectX SDK June 2010
  • Python 2.7
  • wxPython
  • ドキュメントの生成を行う場合は、追加で以下も必要です。
    • doxygen
    • HTMLHELP Workshop

SourceForge からソースをチェックアウト

svn co https://nebuladevice.svn.sourceforge.net/svnroot/nebuladevice/trunk

依存するファイルを追加でダウンロード

Nebula Device 2 は幾つか依存するライブラリ[1. ogg と sqlite3]があります。自前で持ってきても良いのですが、SourceForge から以下の名前でダウンロードする事が出来ます。

  • nebula-vc8-deps-20070409.zip
  • mangalore が必要な場合は、追加で以下も必要です。
    • mangalore-vc8-deps-20070407.zip

nebula2/buildsys3/generators に vstudio9 用の設定を追加する。

_WIN32_WINNT=WINVER; を vcproj に書き出さないようにするためと、Visual Studio 2008 でも build が行える様に、以下の Python コードを追加で配置します。

[wpdm_file id=12]

update.py を実行

python update.py

みたいな感じで実行すると、 Nebula 2 Build System が立ち上がりますので、 vstudio9 を選択した後に、ビルドしたいものにチェックを入れます。

基本部分だけなら nebula2libs, nebula2tools のみにチェックを入れてから、 RUN ボタンを押します。

VisualStudio に DirectX SDK のパスを追加

  • #include <dxerr9.h> の箇所を #include <dxerr.h> に変更。
  • DXGetErrorString9 を DXGetErrorString に変更。

ソリューションを開いてビルド

正常にビルドが完了していれば、 build/vstudio9/inter フォルダにライブラリが生成され、 bin フォルダに実行ファイルが生成されます。

Windows の環境設定

VMWare 上に OS を導入した後、自分は以下の様なソフトウェアを導入しています。

VisualStudio 2008 Professional

そんなの入れて使いこなせてるの?みたいな気もしますけど、まずはこれを入れています。DirectX の開発や Python モジュールの作成であれば Express Edition でも良いのですが、ごく稀に Crystal Reports を使用する事もあります。

DirectX SDK June 2010

手持ちのライブラリが DirectX 9.0 ベースですので、こちらも必要になります。

Windows8 では、個別提供はされずに Platform SDK に纏められて提供されるようです。

Altap Salamander

愛用している二画面ファイラーです。

EmEditor

スクリプトの作成は大抵このエディタを使用しています。

Python 2.7.2

スクリプトを書く際は大抵 Python 言語を使用しています。世の中は Python 3 系なのかもしれませんが、手元のライブラリや組み込みで使用している Stackless が 2.7.2 なので、バージョンを合わせています。

  • ちなみにインストールしているライブラリは以下のような感じです。
    • setuptools
    • Python Image Library
    • PyOpenGL
    • wxPython

 

以前であれば、デザイン関係のツールとして CorelDraw もインストールしていたのですけど、現在は Mac に移行してしまったので、 Windows 環境にはプログラム関係がインストールされています。

VMWare Fusion5 に Windows7 をインストール

自宅で使用している PC は iMac 一台だけなのですけど、DirectX のアプリケーションを開発する時には Windows 環境が必要となります。

intel Mac であれば Boot Camp を使用することで Windows を導入する事が出来ますが、再起動が必要となるため、自分は VMWare を使用しています。

VMWare はエミュレータですので、 Boot Camp に比べると当然重くなってしまうのですが、いまのところ作成しているアプリケーションは動作してくれているので愛用しています。重いといっても、自分が使用するには十分な性能が出ています。

vmware_score エクスペリエンス インデックス は 4.7 でした。

OS のインストールよりも、その後の環境設定の方が大変だったり。

 

コミックマーケット83 を終えて

今回のイベントでは幾つか新しい試みをしてみました。

サークルスペースを整頓して一覧性を向上させてみる

サークルを立ち上げた頃は、カンペンケースとめがねふきだけだったのが、今ではカードケースやスポーツタオルを取り扱うようになりました。机の上が賑やかになるのは嬉しいのですけど、ちょっとごちゃごちゃしすぎかもしれないな…と感じていました。

そこで今回はコルクボードを購入して、サークルスペースに立てかけてみました。

以前よりも見やすくなったと思うのですけど、ボード上のレイアウト自体はもうちょっと考えた方が良いかもしれません。

無料ペーパーを配ってみる

x1 なんというコレジャナイ感…

試しに作ってみたのですけど失敗だったかも。何よりもペーパーに見えない。

さすがにこの体裁(クリアファイルにまとめて、ビニールのパッケージに封入)だとペーパーとして認められないようで、見本誌の提出も必要となりました。

Pages で作成したものを Kinko’s で出力するとこうなります、という事がわかっただけでも良かったかな。

こちらのペーパーは元々無料で配ったものですので PDF 版をダウンロード出来る様にしておきました。

mizu_paper_c83a mizunagi_2012.pdf

こちらの PDF は会場で配った物よりも1ページ多かったりします。どうという事のないページではあるのですけど、どうしても Kinko’s で 3ページ目[1. レヴィとまどか]を印刷するのが恥ずかしくて印刷対象から除外してしまいました。

 

あとは自分でもバカなんじゃないかと思えるぐらいに暗算が出来ないのをなんとかしたいところ。(脳トレでもすればいいのだろうか)

 

あけましておめでとうございます

あけましておめでとうございます。

 

無事に2012年を終え、新しく2013年を迎える事が出来ました。

2013年は巳年、ヘビと言えばナハトヴァール。ナハトヴァールと言えばリインフォース・アインス…と、無理矢理なのはネタに繋げてみたりして。

自分はというと、朝5:00起きだからなのか疲れていたからなのかわかりませんが、10時間ぐらい寝てしまいました。

 

そんなわけで今年もよろしくお願い致します。

 

コミックマーケット83 参加情報(2)

現在、当日無料配布するペーパー(というよりも冊子?)をまとめています。

 

kinko’s で印刷したのですが、以前は使用する事が出来たトレーシングペーパーが使えなくなっていました。店舗にもよるそうなのですが、出力機の変更に伴って利用出来なくなってしまったとの事…残念。

というわけで、こんな感じになりました。実際にはB5クリアファイルに納めたものをビニールパックに封入しています。(チャック付きですので、濡れたり汚れて欲しくない物を入れるのにも使えるかも。)

 

表紙が妙に堅苦しいのですが、内容は今年の振り返りとご挨拶となります。

x1 x2 当日配布のペーパー

内容物一覧

  • Page 1 – 表紙
  • Page 2 –  2012年の年賀イラスト( twitpic や deviantART に掲載しています。)
  • Page 3 – デバイスカードケース の制作について。
  • Page 4,5,6 – Pages を使用しての段組み出力(内容はやてちゃんの童話)
  • Page 7 – アインハルトさんのイラスト(本来のペーパー部分)

といった感じになっています。本ではありません[1. 見本誌の提出は必要でしょうけど。]ので、奇数枚(全 7 ページ)構成にしてみました。

 

コミックマーケット83 参加情報(1)

水凪工房は 2012年12月31日(三日目) メ – 22a で参加します。

今年販売した各種グッズを持ち込む予定です。いままではサークルスペースにアイテムを並べていたのですけど、今回は下の様にコルクボードにアイテムを配置した物をたてかける様にしてみました。

 各種グッズ(めがねふきの説明がはやてちゃんのまま…)

新作グッズ(絵柄はメディカルシャマルケースと同じ)は「医療少女メディカルシャマル」のめがねふきです。

 めがねふき ¥300-

それから FragmentalSoft さんの @ぐるぐるリリカル を委託します。リリマジ14、なのはDAYS’ で委託していたものバージョンアップ版となります。

リリマジ14、なのはDAYS’ にて入手済みの方は、今回のバージョンと同等品に出来る パッチ が提供されています。アップデータを提供すると 2012/12/31 にオープンするオンラインランキングサイト(リプレイアップローダー)への投稿が出来る様になります。

http://fragmentalsoft-ranking.halfmoon.jp/guruguru_lyrical/

当日は iPad でプレイ動画を再生します。

 @ぐるぐるリリカル ¥700-

(さらに…)

iPad で動画を連続再生する方法

同人イベントでゲームソフトを説明するには、実際に動いているものを見せるのが手っ取り早いのは間違いありません。ですが、様々な理由から PC を設置する事が出来ない場合があります。そんなとき、長時間の動画再生が可能なタブレット端末はかなり重宝するのではないでしょうか。

手元に iPad が戻ってきたので、動画を連続再生させる為の方法をメモしておきます。

連続再生をさせる方法

  1. まずはアルバムを作成します。アルバムの作成は iPad 上でも Mac 上の iPhoto でもかまいません。
  2. 作成したアルバムに動画を追加していきます。ただし、アルバム内には複数の動画、または画像が含まれるようにします。
  3. iPad の設定から写真を選択し、リピートをオンにします。
  4. iPad の写真アプリからアルバムを選択し、スライドショーを選択します。
  5. あとはずっと再生し続けます。

どうやらアルバム内に複数枚のデータが存在しないと繰り返し再生をせずに終了してしまうようです。

また、実体はスライドショーですので画面に触れる(再生位置を変更したり、早送り等も含みます)と、そこでスライドショーは止まります。

…というわけで、再生中は何があっても触れてはいけません。

 

動画がひとつしかない場合は、適当な画像(例えば真っ黒の画像)を用意してアルバムに追加しておけば、(見かけ上)同じファイルが再生されているように見えます。

 

もしかするとバージョンによって挙動が異なるかもしれません。

動作確認は iPad 初代( iOS 5.1.1 ) で行いました。

RapidMiner で魔導士ランクを予想してみる

魔法少女リリカルなのはの世界では、魔導士の能力を比較する為の基準値として魔導士ランクというのが設定されていて、例えばシャマルさんなら「総合AA+」といった具合に設定されています。

主要な登場人物には大抵設定されているのですが、StrikerS に登場する軌道六課に直接関係しないキャラクターには設定されていなかったりします。(少なくとも手持ちには)

具体的には以下の三人です。

  • クロノ・ハラオウン
  • カリム・グラシア
  • ヴェロッサ・アコーズ

ちょっと気になったので、三人の魔導士ランクを RapidMiner で予想してみる事にしました。

まず、わかる範囲で魔導士ランクが判明しているキャラクターの情報を集めて CSV にします。設定だとリンカーコアが魔力を生み出す源として描かれているようなのですが、はやての場合はスキルを考慮して設定されていたりします。

真面目に分析した方が面白そうなのですが、とりあえず以下の様な情報を集めてみました。

  • 魔法資質
    • 魔力光の色
    • 使用術式
  • 特徴
    • 種族
    • 出身地
    • 瞳の色
    • 性別
  • どのシリーズに登場しているか(レギュラーメンバーかどうかや、主人公補正的な意味あいから…)

nanoha_b01 ひとまず Naive Bayes で組んでみたもの。

いきなりモデルを生成して予想をしてみても良いのですけど、大抵はモデルを生成した後にそのモデルが妥当かどうかを調べたりします。大量にデータを所有していれば「構築用」と「検証用」に分離して利用するのですが、今回はデータ少ないため同じデータを使用しました。

nanoha_b02 Naive Bayes を使用して予想が当たっているかを調べてみたもの。

同じデータを使用しているため、事前に設定されたランクと RapidMiner が弾き出した結果を比較してみるだけなのですが…

あれ、かなり当たってる…というよりも予想以上の的中率。

(魔導士ランクは分類が細かすぎるため、単純化しています。)

ちょっと当たりすぎている気がしますので、評価内容を Weight や Distribution Table で調べた方が良いのかもしれませんが、ひとまずこのままのモデルを使って、三人の魔導士ランクを予想してみます。

nanoha_b03 ヴェロッサ…

結果が出ました。

  • クロノ -> 魔導士ランクS
  • カリム -> 魔導士ランクS
  • ヴェロッサ -> 魔導士ランクB

個人的な感想だと、ヴェロッサは B より上な気がするけど…

 

というわけで、 RapidMiner で遊んでみました。

 

今回使用したデータは以下になります。

CSV

nanoha_rank.csv

第12話「さよならは言わないで」

武装神姫が最終回を迎えました。

最終話は先週から引き続いてヒナの話だったのですが、全話通してもヒナの物語だったんじゃないかと思えました。

放送開始時点でのヒナは「マスターと神姫」という関係のみに価値を見いだしていた、というよりも、自分なりの「(武装)神姫という定義」に忠実であろうとしていたように思えます。名前の通りヒナ[1. 神姫的には初期設定状態]だったわけです。

そして理人や他の神姫と触れ合ううちに少しづつ考え方を変えていき、最終的に仲間というのを意識出来る様になった。[2. アン達は最初からヒナを仲間だと思っているけど、ヒナ自身には実感がなかった(と思う)。] …と、考え過ぎかもしれませんが、そんな物語だったと自分は受け取りました。

記憶がもどったヒナについて

劇中後半、記憶を消去されたヒナの記憶が蘇っていました。その理由は「モニター用の神姫だったからか?」とだけ触れられていて、具体的な事は何も言及されていませんでした。

もっとも、感動的な場面で技術的な解説とかされてもしらけるだけでしょう。それはそれで構わないのですが、個人的には気になりましたのでちょっと考えてみる事にしました。

神姫の記憶について

神姫をロボットとして考えると、その記憶は何らかの記録媒体に納められているのだろう程度には推測出来ます。

例えばHDDやフラッシュメモリの場合、データの消去というのは実際に消去するわけではなく、管理上消えている様に見えるだけです。なので、物理的に読み取る方法(セクター単位での読み込み等)があれば、消したはずのデータを読み込む事が出来る場合もあります。(実際にサルベージ業者やデータ復元ソフトウェアが存在しています。)

だから、実際にヒナの記憶は消えていませんでした。

…と考えたいところなのですが、

データ復元ソフトウェアを悪用すれば、捨てられたHDDから情報を抜き出す事が出来てしまいます。ですので、データを消去するには単に削除した事にするのではなく、別のデータを書き込んでやります。

自分が愛用している BlackBerry を例に挙げると、第三者がデータを物理的な方法で読み取れない様な仕組みが実装されています。動作的には以下の感じです。

コンテンツ保護がオンになっているときに、BlackBerry デバイスで BlackBerry® デバイスの RAM にあるヒープを上書きするために、BlackBerry デバイスでは各ビットの状態を 4 回変更します。BlackBerry デバイスのメモリスクラブプロセスでは次の処理が実行されます。

  1. 各バイトに 0x33 を書き込む(0011 00112)
  2. すべてのバイトを消去して 0x00 にする(0000 00002)
  3. 各バイトに 0xCC を書き込む(1100 11002)
  4. すべてのバイトを消去して 0x00 にする(0000 00002)
  5. 各バイトに 0x55 を書き込む(0101 01012)
  6. すべてのバイトを消去して 0x00 にする(0000 00002)
  7. 各バイトに 0xAA を書き込む(1010 10102)

といった感じで、念入りに上書きされてしまうと手も足も出ません。そこまで念入りにしてないかもしれませんが、何らかの上書きが行われてしまうだけでデータのサルベージはより困難になります。

そもそも現行技術の延長線上に神姫があるわけじゃないかもしれませんけど…

実は設定を上書きしているだけだったりして

と、長い前振りをしたわりにはしょんぼりした仮説ですけど、自分はそう考えました。

結局のところあそこでいう消去というのは、実際には設定の強制上書き、人間的に言えば催眠状態だったのではないでしょうか。数少ない神姫の設定では、 C.S.C を埋め込む事で神姫が生まれ、以後は取り外す事は不可能(外す=神姫の死)ということになっています。

アニメでは C.S.C に関する設定は登場しませんでしたが、単純に記憶を削除してしまうわけにはいかない何かがあるのかもしれません。(というか、そうであってほしい…)

そういった前提を踏まえると、記憶の削除というのは神姫を破壊してしまう事になるため、削除というのは便宜上の意味だけで、実際にはヒナに催眠術をかけていただけだったのではないかと思います。そして記憶が戻ったというのは催眠が解けた状態だったという事だったのではないでしょうか。

…とまぁ、自分なりの落としどころはこんな感じです。

(武装神姫でもなんでもない話になってしまいました。)