昔の最近の出来事(2015.06)

2015/06/30

遅めに帰着。

調べ事。ボーンムズい。IKもっとムズい。

遅めに帰着。

弱虫ペダルGRをやっと消化。王道って感じの展開でしたが、 直球で良い感じだったと思います。1期から含めてとても面白かったです。

調べ事。

AM中に起床。洗濯したり掃除したり。

そういや 以前作ったリバーシの制作 メモで触れている、ファミベのオセロについてふと検索してみたら 動画を発見できたり (こちら)。 今見ると意外と思考時間短いと思ったりも。 他にもベーマガに載っていたリストを実際に動かした動画が沢山上がってて 覚えているものから初めて見るものまで色々ありました。 有名所ではファミベのよっしん氏の 「ZACNER �U」とか。 レザーとかオプション5個とか多重スクロールとかデカキャラとか、 オーバーテクノロジーな感じです。 他にも「メタルさ!伊藤」 とか初めて見ました。
あと、「CRASH MAZE」は V2用なのに実に良くできたゲームだったと今見ても思えます。

もそもそとコーディング。PMX表示テストで頂点モーフを試してみたり (ボーンはスキニングが難しそうなので(^^;)。 制御自体は頂点データを頂点モーフデータを使って座標移動するだけなのですが、 ちゃんと変形されるのがスゲー。頂点の移動量がデータとして格納されている 訳ですが、頂点移動前と移動後の両方のモデルが無いと、差分抽出できないと 考えられます。どうやってPMXデータ化するんだろう？と疑問に思ったりも。

AM中に起床。休出。

gdcを x86_64-w64-mingw32 ターゲットでクロスビルド。前回はlibphobosの ビルドでコンパイラがICEで落ちまくってましたが、今回はエラー無くビルド 成功。hello worldレベルのコードはコンパイルできましたが、 Winアプリのコードはちょっと問題がありそう。そして、構造体のメンバー関数 呼び出しで変数が化ける問題も i686-pc-mingw32と同じく再現します。 という訳でダメそう。

もそもそとコーディング。今の構造だと実験しにくい感じになってきた のを整理したり。

遅めに帰着。

先日ビルドしたGDC。DMD2.066.1ベース gdcの重大な問題点として、 構造体メンバー関数呼び出しで変数が化けるというのがあるのですが、 それは直っていない模様。

$ cat test_struct.d
import std.stdio;
import std.math;

struct Vec3D
{
  double x,y,z,w ;

  void set(double x, double y, double z){
    this.x = x ;
    this.y = y ;
    this.z = z ;
  }

  Vec3D normalize(){
    writef("a: xyz=(%f %f %f) %s\n", this.x, this.y, this.z, this) ;
    Vec3D retvec ;
    double d ;
    writef("x: xyz=(%f %f %f) %s\n", this.x, this.y, this.z, this) ;
    d=sqrt( this.x*this.x + this.y*this.y + this.z*this.z ) ;
    writef("d=%f\n",d) ;
    if( d>0.0 ){
      retvec.x = this.x/d ;
      retvec.y = this.y/d ;
      retvec.z = this.z/d ;
    }else{
      retvec.x = 0.1 ;
      retvec.y = 0.2 ;
      retvec.z = 0.3 ;
    }
    return(retvec) ;
  }
}

void main()
{
  Vec3D v ;
  v.set(0.8,0.0,0.0) ;
  writef("1: %s\n",v) ;
  v=v.normalize() ;
  writef("2: %s\n",v) ;

  return ;
}

$ i686-pc-mingw32-gdc.exe test_struct.d

$ ./a.exe
1: Vec3D(0.8, 0, 0, nan)
a: xyz=(0.800000 0.000000 0.000000) Vec3D(0.8, 0, 0, nan)
x: xyz=(nan nan nan) Vec3D(nan, nan, nan, nan)
d=nan
2: Vec3D(0.1, 0.2, 0.3, nan)

$ i686-pc-mingw32-gdc.exe -v
Using built-in specs.
COLLECT_GCC=i686-pc-mingw32-gdc
COLLECT_LTO_WRAPPER=/usr/local/gdc031_20661_510_mingwcross/libexec/gcc/i686-pc-mingw32/5.1.0/lto-wrapper.exe
Target: i686-pc-mingw32
Configured with: ../gcc-5.1.0/configure --with-pkgversion='gdc-5 5d95e14a6a' --build=i686-pc-cygwin --host=i686-pc-cygwin --target=i686-pc-mingw32 --enable-languages=d --prefix=/usr/local/gdc031_20661_510_mingwcross --with-sysroot=/usr/i686-pc-mingw32/sys-root --enable-threads --disable-nls --enable-sjlj-exceptions --disable-bootstrap
Thread model: win32
gcc version 5.1.0 (gdc-5 5d95e14a6a)

遅めに帰着。

GDCのビルド。色々直ってそうな予感がしますが、どうなるかはビルド してみてのお楽しみ。

Webで調べ事をしていてたまたま見つけた記事 ( 英語版『ドラクエ』、地域方言を活かしたローカライズの妙味)。 色々な訛りの英語が盛り込こまれているというのを知ったり。 そういや「ぱふぱふ」や「あぶないみずぎ」はどう翻訳されているんだろう？

gdcのビルドに成功。手持ちのWinアプリをビルドしてみたところ特に ずっこける事無く動いたり。明日もう少しテストしてみよう。

遅めに帰着。

ちょろりコーディング。

遅めに帰着。

もそもそとコーディング。

遅めに帰着。

ちょろりコーディング。

AM中に起床。

Emacs突然死問題。6/15から今日まで、途中Windowsのサスペンドなども 含めて動かし続けていましたが、新しくインストールしたCygwin上では 三つ同時起動のどれも死ぬこと無く動いてました。古いCygwinの方の どこかにずっこけ要素があるものと推測。DLL群の再インストールを 検討してみよう。
それにしても、単に違っているファイルを差し替えられれば良いのですが、 rebaseのせいでインストールされたdllは、ファイルの日付やサイズが同じ にも関わらず、diffを取ると中身が違っている事があるのが面倒臭いです。

gdcの方で色々pull requestが取り込まれている模様。

もそもそとコーディング。うーん、なんか違う。

既に終わってますがE3。どこも割りと直近に発売される (2015年内〜2016春)ものの発表が多かったようにも。 個人的には「人喰いの大鷲トリコ」の開発が続けられていたという のに驚いたかも。他にも「シェンムーIII」とか、は？マジで？！という感じ。 以前、GDC2014で鈴木氏が講演した 記事を知りました。この記事の最後に 「『シェンムーIII』は発売されますか？」との質問がいの一番に飛び出した。それに対する鈴木氏の答えは、「機会があれば、作りたいと思っています」とのこと。 とあったのですが、当然(失礼)、無いだろうなと思ってました(^^; ここに来てまさかのって感じです。 クラウドファンディングで寄付(Kickstarterだから投資では無い)を 募っているようです。
据え置き機のゲームはどれも凄まじい絵が出ているように思いますが、 プレイアブル映像は動きが若干不自然に見える点が まだあるように思えます。 将来、「Assassin's Creed Syndicate」の トレーラー映像 (リアルタイムレンダリングでは無い)レベルの絵が、プレイアブルでいけるように なると、「動かせる映画」と言っても全く差し支え無いと思います。 PS5世代くらいでイケるかな？ちょっと無理か？

昼頃起床。

ちょろりお出かけ。

PS4にメディアプレイヤーが来てたり。USBストレージやDLNAのファイルを 再生できる模様。ちょろっと試した所ではPS3ほどの機能は無い感じ。 音楽ファイルはバックグラウンド再生可能なようです。 4K動画ファイルも再生できない模様。再生コントロール(早送りや巻き戻し をスティックで制御とか無し)も普通。PS3では oggも再生できて恐るべし という感じだったのですが一般的な音楽ファイルに限定されている模様。 良くも悪くも PS4のそれはなんとなく普通という印象。

もそもそとコーディング。うーむ判らん。

早めに帰着。

ノイタミナ枠で放送されていた「四月は君の嘘」をやっと消化したり。 最後はまさかそういう事だったのかと思った訳ですが、だからこの タイトルだったのかと納得してみたり。バイオリンもピアノも 音に合わせて ちゃんと弾いている絵になっているのが すげぇと 思いました。

もそもそとコーディング。複数のテクスチャを扱うシェーダーを 実験していて、何故かglGetUniformLocation()を使用したシェーダーへの パラメータ渡しが失敗する場合があって悩んだり。で、あれこれ値を 変えながら試してみた所、以下のような原因らしい？という事が判った ような？

3枚のテクスチャが指定されている事を確認する為に、フラグメント シェーダーは次のようなコードにしていました。

uniform sampler2D tex0;
uniform sampler2D tex1;
uniform sampler2D tex2;

void main()
{
    vec3 color0 = texture2D(tex0, gl_TexCoord[0].st).xyz;
    vec3 color1 = texture2D(tex1, gl_TexCoord[0].st).xyz;
    vec3 color2 = texture2D(tex2, gl_TexCoord[0].st).xyz;

    gl_FragColor.rgb = color0 ;
    gl_FragColor.a   = 1.0 ;
}

遅めに帰着。

もそもそとコーディング。うーむ、判らん。

遅めに帰着。

もそもそとコーディング。変な感じだった原因判明。
GLSLを弄っていたのですが、トゥーンシェーダーのように視線と 頂点法線を使った例が思い通りになってませんでした。 原因から言うと、視点設定と行列モード設定の順番を間違えて いた為でした。この為、視線ベクトルがある場所に設定されているのを 第三者的視点で眺めているような絵になってしまってた為、 なんでだ？という感じでした。

-----間違いコード----------------------------------------------

  int display(int win_w, int win_h){
     glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
     glLoadIdentity();

     glViewport(0, 0, win_w, win_h);
     glMatrixMode(GL_PROJECTION);
     glLoadIdentity();
     gluPerspective(camera.fovy, cast(double)(win_w)/cast(double)(win_h), 0.3, 200.0) ;
     gluLookAt(camera.ex, camera.ey, camera.ez,
               camera.cx, camera.cy, camera.cz,
               0.0,1.0, 0.0) ;
     glMatrixMode(GL_MODELVIEW);   //ここより前にgluLookAt()でカメラ位置を設定

     glClearColor( clr_r, clr_g, clr_b, 0.0 ) ;

     glLoadIdentity();  //これが無いと描画が変になる。でもカメラ位置はMODELVIEW変換の対象にならない。

-----正しいコード----------------------------------------------
  int display(int win_w, int win_h){
     glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
     glLoadIdentity();

     glViewport(0, 0, win_w, win_h);
     glMatrixMode(GL_PROJECTION);
     glLoadIdentity();
     gluPerspective(camera.fovy, cast(double)(win_w)/cast(double)(win_h), 0.3, 200.0) ;
     glMatrixMode(GL_MODELVIEW);

     gluLookAt(camera.ex, camera.ey, camera.ez,
               camera.cx, camera.cy, camera.cz,
               0.0,1.0, 0.0) ;

     glClearColor( clr_r, clr_g, clr_b, 0.0 ) ;

遅めに帰着。

もそもそとコーディング。なんか思ったのと違う感じに。

遅めに帰着。

先日のEmacs起動テストは朝の時点で全てのEmacsが同時に停止 してました。タスクマネージャからプロセスを終了させようとしても、 プロセスを落として良いかを確認するダイアログも出た途端にハング した感じだったり。なんとなくデッドロックしている予感。 explorerも反応しなくなったため電源強制切断で対処。うーむ。 結局、新しいCygwinと普段使いのCygwinの両方でEmacsを立ち上げて テストしていた為、どれが悪いか判らずじまい。

仕方ないのでもう一度。今度は新しいCygwinの方でだけで連続起動テスト を行う事に。さてどうなるか.....

もそもそとコーディング。なんか勘違いをしている気がしてきた。

昼頃起床。

Emacs突然死問題。コンパイルオプティマイズを -O0に下げれば数時間で 死ぬ事は無さそう。という訳で、ライブラリに続き 4.9.2-3に由来する gcc本体についても調べてみた所、パッケージアーカイブが違っている 模様。という訳で、これまでの分も含めて以下のパッケージアーカイブ を再ダウンロードしてみたり。

./release/gcc/gcc-ada/gcc-ada-4.9.2-3.tar.xz
./release/gcc/gcc-core/gcc-core-4.9.2-3.tar.xz
./release/gcc/gcc-fortran/gcc-fortran-4.9.2-3.tar.xz
./release/gcc/gcc-g++/gcc-g++-4.9.2-3.tar.xz
./release/gcc/gcc-java/gcc-java-4.9.2-3.tar.xz
./release/gcc/gcc-objc/gcc-objc-4.9.2-3.tar.xz
./release/gcc/libatomic1/libatomic1-4.9.2-3.tar.xz
./release/gcc/libgcc1/libgcc1-4.9.2-3.tar.xz
./release/gcc/libgcj-common/libgcj-common-4.9.2-3.tar.xz
./release/gcc/libgcj15/libgcj15-4.9.2-3.tar.xz
./release/gcc/libgfortran3/libgfortran3-4.9.2-3.tar.xz
./release/gcc/libgnat4.9/libgnat4.9-4.9.2-3.tar.xz
./release/gcc/libgomp1/libgomp1-4.9.2-3.tar.xz
./release/gcc/libobjc4/libobjc4-4.9.2-3.tar.xz
./release/gcc/libquadmath0/libquadmath0-4.9.2-3.tar.xz
./release/gcc/libssp0/libssp0-4.9.2-3.tar.xz
./release/gcc/libstdc++6/libstdc++6-4.9.2-3.tar.xz

AM中に起床。ちょろり休出。

Emacs+美人時計。3つ稼動でテストしてるのですが、16時間経過後も 死なず。ダメになった時期やdllファイルの日付などから、どうやら そういう事だったと言って良さそう。
しかし、残念ながら seconds-to-time関数でArithmetic range errorになる件は直らず。 でもこちらもアップデートが契機だったので何かあるのかも。

パッケージをダウンロードし直すのには、 既にダウンロードしているファイルを消す(実際にはリネームしたのですが) 必要がありました。ファイル名が同じで中身の違うものがダウンロードされた為、 壊れたパッケージが一時的にサーバーに置かれていたと考えられます。 ファイル名が同じで中身が違うなんて区別付かない のですから(事実、インストーラーはダウンロード不要と判断 していたのですから)、もっと神経使って管理して欲しいなぁと 思います。

新しく入れたCygwinでも Arithmetic range error が再現しました。 インストール状況の問題では無さげ。

パッケージアーカイブの差分を取ってみた所、他にも違っているもの がありました。gcc-4.9.2-3の以下のパッケージに含まれるdllが 2015-02-24付け(最新は2015-03-04付け)のファイルになっていました。

libgcc1-4.9.2-3.tar.xz
libstdc++6-4.9.2-3.tar.xz
libgomp1-4.9.2-3.tar.xz
libssp0-4.9.2-3.tar.xz

遅めに帰着。

新規インストールしたCygwin上で Emacs+美人時計を 二つ動かしていた のですが、日中ずっと死なずに動いてました。
という訳で何が違うか調べてみたり。一つはcyggcc_s-1.dll、もう一つ cygstdc++-6.dllも違っていました。そもそもアーカイブの中身が違っていたので、 ダウンロードしなおして再インストール。先日入れたものとファイルの日付も サイズも同じになったのですが、それぞれ 16進ダンプを取ってdiffしてみたところ、 随分違っててなんじゃこりゃ？って感じ。

ひとまず、Emacs+美人時計 でテスト開始。さてどうなるか。ダメそうな場合は リンクしているdllを全て再インストールしてみる事になるかも知れません。

遅めに帰着。

Emacsで美人時計を動かすと突然死する件。Cygwin本体をクリーンインストール して動かしてみるとどうなるか？というのを試してみたり。 普段使いのCygwinとは別の箇所にインストールしてテスト開始。 さてどうなるか。

ちょろりコーディング。

Cygwin落ちる件、なんとなく関係する物が判ったかも。 クリーンインストールをするとき、既にローカルディスクにダウンロードして あったものをインストールしました。ところがcyggcc_s-1.dllが見つからないとか でインストールに失敗してしまいました。そこで、ダウンロードから新規に 行ってインストールしてみた所、問題無くインストールできました。 ここで、普段使いのCygwinと 新しくインストールしたCygwinとで cyggcc_s-1.dllの日付を比べてみた所、普段使いの方は2015/2/24付けに なってましたが、新しいのは2015/3/4付けになってました。 ズッコケが頻発し始めた頃にアップデートしたのは、 2015/3/4で、丁度そのときに リリースされたばかりのcygwin1.dllがインストールされたと記憶して います。つまり、cyggcc_s-1.dllが2015/2/24付けになっているという事は cyggcc_s-1.dllがアップデートされないまま今に至るという事になります。
まずは新規インストールのCygwinでEmacs+美人時計のテストを行い、 もしずっこける気配が無ければ、普段使いのCygwinのcyggcc_s-1.dllを アップデートしてEmacs+美人時計のテストをしてみるというのが 良さそうに思ったり。
新しいのとdll類を全て比較してみる必要があるかも。もしかすると seconds-to-time関数でArithmetic range errorになるのも関係している かも。

遅めに帰着。

ちょろりコーディング。

画像形式で、ディスプレイ画面に向かって左下を画像の開始原点と するフォーマット(BMPやTGAなど)がありますが、これって何か メリットがあるのだろうか？といつも思います。 世の中が全て左下を開始原点とするのであれば、あまり問題無い のですが、そうでないフォーマットと相互に行き来するような場合は ファイルシステム上でシークが必要だったり、うっかり圧縮されていると 丸々メモリに展開画像をバッファしなくてはならなかったりします。 合理的なメリットは全く無いように思えます。
因みに、Windowsのグラフィックコンテキストは、デフォルトでは 左下が原点になりますが、そもそもウインドウ座標は左上が原点なので、 いまひとつ統一感が無いようにも思えます。

遅めに帰着。

ちょろりコーディング。

そういやEmacsで美人時計を起動せずに使っているのですが、死ぬ気配は ありません。magitとか使っているので子プロセス実行は行われている のですが.....因みにemnekoは起動しているのですが特に問題無く動き 続けています。ぐぅ。

遅めに帰着。

DDSファイル。とりあえずDXT3のみに対応。それっぽく読み込めたり。

AM中に起床。

PMXファイル表示。Webで公開されているモデルをいくつか表示してみてる のですが、PMX自体には使用するテクスチャファイルに特に制限は無い ようで、PNG,BMP,TGAなど割と節操無く使用されているようです。 SPAやSPHはBMPファイルの拡張子を変えたものなのですが、BMPでも Compression==BI_BITFIELDSの本気対応が必要なものだったり DDSとか何それ？みたいな感じだったりしています。 何のライブラリも無いと表示するだけで死ねる感じ。

因みに 拡張子が SPAやSPHでもBMPで読み込めるように画像ロードクラス をいじったら、先日のgdcのバグっぽいものを踏んだという流れです。

それにしても、PMXのデータをいくつか見た感じ、テクスチャには 2048x2048 のサイズが普通に何枚も使われていて、三角ポリゴン数も 25000以上あるという感じです。 以前買った 「ローポリ スーパーテクニック(2008年8月5日初版)」という本によれば、 SD解像度のゲーム機でプレイヤーキャラクターが最大6体 出るゲームだと、プレイヤーは3000ポリゴンくらいで作って相当リッチ という感覚だったようです。SD:FullHDのピクセル数比だと 640*480:1920*1080=6.75倍 てな感じなので、ポリゴン数比やテクスチャサイズ 比にそのまま適用できるかは判りませんが、その比よりは大分大きいんじゃないかな？ と思います。
そういや全然関係無いですが、この本の中でSAIを使ってテクスチャ 作成している例が載っているのに今気づいた(^^; SAIの1.0.0リリースは 2008年2月末なので、普通に実戦使用可能という感じだったのでしょう。

DDSファイルのローダーを作ったり。テスト用にppmファイルに 吐き出す所がバグってるのにしばらく気がつかなくて、おかしな結果 っぽく見えて悩んだり。修行が足りません。
圧縮形式に DTX1〜5 と表現されている場合とBC1〜5と表現されている場合 があって、1:1に対応しているのかと思いきやなんかちょっとずれている らしくて、わけが判らなかったり。GIMPのプラグインのソースを見ると、 DXT1,3,5 は知ってて、これがBC1,2,3に対応している感じになっている ようです。GIMPプラグインはDXT2,4は知らないっぽい。 Webで出てくるページよるとはDXT2,4はDXT2,3のRGB値にアルファ値が 乗算されたもののようです。でもRGB565形式にパックされているものに アルファ値を掛けてしまうと値が妙な事にならないか？と思ったりも。 どっちにしてもバリエーションがあり過ぎて対応が面倒臭いです。

昼前起床。

もそもそとコーディング。

先日のバグっぽいもの。gdcでオプティマイズレベルを上げるとSegfaultで -O0だと大丈夫な事から、コンパイラのバグの線が濃厚。そしてgdbの上で 実行すると再現しない罠。うーむ。

Cygwinアップデート後に Emacsで美人時計。やっぱり落ちました。

gdcのフォーラムで 「What gcc to use for gdc master?」 というのが挙がっていました。最初はgccの対応バージョンが判らなくて ビルドできないというものでしたが、(今日時点の)最後の方にあるように、 OSXでも名前解決できない問題があるようです。アンダースコアを足さなくてはダメなのは 32bit-MinGWのそれと同じなのですが、 「why no ld.exe in 2.066.1 Windows builds?」 との関係に 気づいてー と、こっそり思ったり。

OpenGLであるテクスチャに別のスフィアマッピングしたテクスチャを 合成したいと思ったのですがうまくいかず。
原因判明。glActiveTexture()でテクスチャユニットを指定した時は、 テクスチャユニット毎に glEnable(GL_TEXTURE_2D)を実行しないとダメ だった模様。glActiveTexture(GL_TEXTURE1)でテクスチャを切り替えても ちっとも描画されなかったはそのせいだったようです。
Webの 最初に参考にしたコードではテクスチャユニット毎にEnableにするような コードにはなっていないようだったのですが、ベンダー依存だったりするのかしら？

遅めに帰着。

ちょろりコーディング。うーむ、またstd.regexかgdcのバグっぽいものを踏んで しまっているようだ......

Cygwinを2.0.3にアップデート。MailingListでプロセス生成に関する バグが修正されたようなので、もしかするとEmacsで美人時計を動かしていると 突然死する問題が解消されるかも？と淡く期待。

遅めに帰着。

ちょろりコーディング。

そういや美人時計を起動しないでEmacsを使っているのですが、 数日間起動していて死ぬ気配無し。ぐぅ、なんか負けた気がする。

遅めに帰着。

ちょろりコーディング。

遅めに帰着。

ちょろり調べ事。

あまりの眠さに急速停止。

遅めに帰着。

ちょろりコーディング。