遅めに帰着。
日付が変わった所でちょっとだけ鉄拳7。
遅めに帰着。
あまりの眠さに急速停止。
遅めに帰着。
あまりの眠さに急速停止。
AM中に起床。
掃除したり洗濯したり。
PS4の鉄拳7を予約購入してみたり。コンシューマ向けに割とすぐ出る
かと思ってたのですが、意外と時間がかかった(AC稼働から2年と4ヵ月)
気も。因みに鉄拳6もAC稼働からPS3で出るまで2年弱かかったのですが、
PS3単独だったのがXobx360とのマルチプラットフォームになった事で
1年滑ったので、理由がまたちょっと違うかも知れません。
起きたら午後もいい時間。寝過ぎ。
そういやTV録画でいつの間にか同じ番組をダブル録画している感じになってて
なんでだ？という感じに。そういや同じ番組をW録画しようとする場合は
どっちかキャンセルすれば良い気がするのですがそうなっていないの
は何故だろう？と今更ながら思ったりも。
遅めに帰着。
あまりの眠さに急速停止。
遅めに帰着。
調べ事をして終了。
遅めに帰着。
GDC 2017の
Horizon Zero Dawn関連スライド。
ペイントソフトのようにフィールドをエディットするツールとか、
なんか色々とスゴイです。
遅めに帰着。
Web巡回して終了。
遅めに帰着。
あまりの眠さに急速停止。
何故か起きたら午後もいい時間。寝るの遅くはなかったけどなぁ？
掃除したり洗濯したり。
gdc。ひとまずパッチを当ててのコンパイルテストは大丈夫そう。
コンパイル途中でICEずっこけがあるのと、core/sys/windows下の
ファイルのコンパイルに失敗するのとがあるので、手放しでのビルド
はできませんが、当面はアップデートについていけるかなと。
そういやx86_64-w64-mingw32ターゲットでリンク時に謎の時間がかかる問題が
あったのですが、
大丈夫になっているような気が。
古いバージョンのコンパイラを今試してみてもやっぱり再現するので、
gdcのアップデートか、gccが7になったのか、その両方かが関係しているのかな？
と思ったりも。てか、高々 いちアプリがシステムコールを実行したら
刺さる時と刺さらない時に分かれるのか理解はできませんが。
AM中に起床。
gdc。他のターゲットでのビルドを試そうとしたのですが、何もしないと
自動生成されたMakefileを弄らなくてはならないので、元のMakefile.amで
対処してみたり。でも、autoconfのバージョンが合わない為かズッコケる
ため、本来Makefile.amから自動生成されるMakefile.inを手で直すハメに。
面倒くせぇ。
以前、NAS-HDDを買ったのですが、
電源を操作する手間よりも音の方に慣れてしまったため、ずっと稼働してる
感じになってます。ちょっとファイルを置ければ良いくらいの感じで買ったので
色々できるっぽい事に着目していなかったのですが、フォルダの同期機能
というのがあるのに気づいたり。PCの任意のフォルダ内のファイルを
NAS-HDD上のフォルダに自動で同期させるというものです。
本 へっぽこページの元ファイルは、他よりもバックアップ高めにCC2とかに
コピーしているのですが、気づいた時に手動起動するのも面倒臭いのと、
常時稼働しているのなら自動同期を使うのが楽かもと思い試してみたり。
うん、いいかも。ただ、「誤った編集を少し前のバックアップから戻したい」という
目的では使えないので、定期的なバックアップは必要なのかも。
夕方に散髪に出かけたり。ビッグコミックオリジナルに
庵野秀明氏と細野不二彦氏の対談記事が載っていたのですが、
記事の内容よりも細野不二彦氏が1959年生まれ、庵野秀明氏が
1960年生まれの ほぼ同世代というのにそうなんだっけ？と思ったり。
ギャラリーフェイクを読んでいた当時は、漠然と年齢を重ねている
ベテランの方だと思っていたので意外でした。
gdc。i686-pc-mingw32, i686-w64-mingw32, x86_64-w64-mingw32で
一通りビルドできる感じになったような。x86_64-w64-mingw32ターゲットで
コンパイルできなくなっててあれぇ？だったのですが、一か所差分を取り込み
忘れてただけでした。ひとまずgcc-7.1ベースにパッチを作ってテスト中。
遅めに帰着。
gdc。GCする条件のうちの一部を働かないようにしてズッコケを回避している
のですが、手持ちコードで試している範囲ではメモリリークする感じには
ならなかったり。ちょっとずつプロセスサイズが大きくなるコードはある
のですが、それは前バージョンのgdcでも同じだったので、回避している
コードの影響ではないのかも？とも。
遅めに帰着。
ちょろっとWeb巡回して終了。
遅めに帰着。
Web巡回して終了。
遅めに帰着。
あまりの眠さに急速停止。
遅めに帰着。
Web巡回して終了。
昼頃起床。
gdc。interfaceで何故エラーになるのかやっぱり判らなかったり。
gdcがバグっているのか？
先週、Emacs25.2で美人時計が時々止まるように
なった件。その後で使用しているdeferred
が20150309.2052版と古かったのに気づき、20170331.1759ってのを入れてみてました。
その後、Windowsの再起動が入ったりとあまり長時間起動できてはいないのですが、
いつの間にか変になってる現象は起こっていません。結局原因は不明なままですが、
何かしら関係があったのかも。
昼前起床。
gdc。ひとまずGCの問題は一旦置いといて、core.sys.windows.*下の
一部のコードがコンパイルエラーする原因を調べたり。
エラーの内容は 以下。
interface IOleUILinkContainerW : IUnknown
{
HRESULT QueryInterface(REFIID, PVOID*);
ULONG AddRef();
ULONG Release();
DWORD GetNextLink(DWORD dwLink);
HRESULT SetLinkUpdateOptions(DWORD, DWORD);
HRESULT GetLinkUpdateOptions(DWORD, PDWORD);
HRESULT SetLinkSource(DWORD, LPWSTR, ULONG, PULONG, BOOL);
HRESULT GetLinkSource(DWORD, LPWSTR*, PULONG, LPWSTR*, LPWSTR*, BOOL*, BOOL*);
HRESULT OpenLinkSource(DWORD);
HRESULT UpdateLink(DWORD, BOOL, BOOL);
HRESULT CancelLink(DWORD);
}
oledlg.d:473:1: error: interface win32.oledlg.IOleUILinkContainerW ambiguous virtual function AddRef interface IOleUILinkContainerW : IUnknown ^ 以下多数 :
遅めに帰着。
gdcのgcc-7.1.0対応ブランチのビルドを試したり。色々手を入れて
ひとまずビルドに成功。そしてGCの問題の必要最低限のワークアラウンド
を入れてテストしてみたところ、一つ前のではプロセスがうまく終了
できない場合があったのですが、同じ事をやってもちゃんと終了する
ようになったり。実験で他にも色々入れていた古いバージョンへの
戻し対応が悪さをしていた可能性があったのかも。
遅めに帰着。
あまりの眠さに急速停止。
遅めに帰着。
あまりの眠さに急速停止。
遅めに帰着。
Web巡回して終了。
遅めに帰着。
Web巡回して終了。
AM中に起床。
ぐうたら過ごして終了。社会復帰できるだろうか？(^^;
今日からUSB扇風機を稼働。
gdcがgcc-7.1.0対応された模様。今の所、大きな違いは無いみたい。
昼前起床。
Emacs25.2にしてから美人時計が時々止まるようになったり。
ロックに使っている変数がロックしっぱなしになるのが原因なのですが、
何故ロックしっぱなしになるのかが判らず。どっかで値が化けている可能性が
あるのですが契機が不明。後、ロックしっぱなしになるのをstop→start
しても、何故か実際の時間の1分前の画像が表示されていたり。
画像はある時間のをhttpで取得しているものと思われるのですが、
データの実体はある時間の1分前のデータになっていたり。
どこかに1分前のデータを保持していなくてはこうはならないのですが、
むしろこんなややこしい事になるほうが難しくね？という感じ。
CG描いてみたり。時々CC2を使ってラクガキはしていたものの、
なんか塗りがうまくいかなくては放置するという感じでした。
未だにキャンバスサイズに対するテクスチャの拡大率調節の
要領が得られていない感じです(^^; でも、Web用に縮小すると
弱いテクスチャだと潰れてしまうくらいなので、強く出過ぎない
ところで細かい事は気にしないくらいで良いのかも知れません。
そんな訳で表紙絵を更新してみました。
昼頃起床。
gdc-7のGC調査。
少しずつコードを活かしたり殺したりしながら反応を見たり。
現在のところ sweep()内から実行されるrt_finalizeFromGC()という
関数を実行しないようにし、且つ recover()内のフリーリストを更新するコード(？)
も実行しないようにすれば、試したコード内では
メモリリークする事無くGCが動いている模様。ただ、長時間動かした後
に実行を止めると何故かCPUを使いっぱなしのままプロセスが無くならなかったり。
副作用があるのでこのまま使うのは無理げ。
ゴミ捨てに一瞬起きて、寝て起きたら昼過ぎ。寝過ぎ。
gdc-7のGC調査。
GC内のステップ(prepare(), markALL(), sweep(), recover())のうち、
変数名等から察するにsweep()は大きなメモリブロックを、recover()は
小さなメモリブロックを回収するようなのですが、大きなメモリブロック
を回収すると推測されるsweep()を実行しなければズッコケない事が
判ったり。
その後、テストコード中ではrecover()は実際に何もしていないようなので、
今の所問題無いという感じ。そんな訳でsweep()の中を観察。
classやstructだったりする場合にfinalizerを呼び、その後
開放関数を呼ぶという流れのようなのですが、finalizerを呼ぶとダメだったり、
開放関数を呼んでもダメだったりと、とにかく開放操作を行う事自体がダメ
だったり。開放コードがバグってる疑いもあるのですが、開放して良いか否か
を検査するmarkでそもそも間違えた印を付けている可能性も否定できず。
GCのバグかも知れないし、コンパイラのバグかも知れないし、
MinGWに特化したコードのバグかも知れないのですが、如何せん
Segfaultするのが大分前に仕込まれた爆弾による為、直接破壊の原因が
絞り込めず。
更にその後。
gdbでfinalizeが必要なメモリブロックを調べてみたところ、なんか
開放しちゃダメなんじゃね？という気がしたり。そこで、
finalizeが必要なメモリブロック場合は開放せず、
finalizeが不要なメモリブロックに限り開放を実行するようなコード
に書き換えてみたところ、Segfaultしない感じになったり。
ずっこけ条件がほんの少しだけ絞り込めた気も。
DConf 2017。Youtubeでライブ配信していたのでGCのデバッグを
しながらBGV的に見ていたのですが、GCデバッグの方に意識が行き過ぎて
全然見れてません(^^;
AM中に起床。
5/2付けでgcc-7.1.0がリリースされていました。
gdc-7の一番新しいっぽいのを使ってi686-pc-migw32ターゲットで
クロスビルドをCygwinで行ってみたり。
gcc-6.3.0で突っかかった所に対するパッチは一通り必要そうでしたが、
libphobos/src/std/utf.dのビルドでICEズッコケとなったり。
make[2]: ディレクトリ '/home/TANE/develop/dlang/gcc/gdc_2071_710/GDC-ac0c40aca0638ba0f22e23dd5c03da35ef4f311a/build_i686-pc-mingw32/i686-pc-mingw32/libphobos/src' に入
ります
/bin/sh ../libtool --tag=D --mode=compile /home/TANE/develop/dlang/gcc/gdc_2071_710/GDC-ac0c40aca0638ba0f22e23dd5c03da35ef4f311a/build_i686-pc-mingw32/./gcc/gdc -B/h
ome/TANE/develop/dlang/gcc/gdc_2071_710/GDC-ac0c40aca0638ba0f22e23dd5c03da35ef4f311a/build_i686-pc-mingw32/./gcc/ -L/home/TANE/develop/dlang/gcc/gdc_2071_710/GDC-ac0c4
0aca0638ba0f22e23dd5c03da35ef4f311a/build_i686-pc-mingw32/i686-pc-mingw32/winsup/mingw -L/home/TANE/develop/dlang/gcc/gdc_2071_710/GDC-ac0c40aca0638ba0f22e23dd5c03da35
ef4f311a/build_i686-pc-mingw32/i686-pc-mingw32/winsup/w32api/lib -isystem /home/TANE/develop/dlang/gcc/gdc_2071_710/GDC-ac0c40aca0638ba0f22e23dd5c03da35ef4f311a/gcc-7.
1.0/winsup/mingw/include -isystem /home/TANE/develop/dlang/gcc/gdc_2071_710/GDC-ac0c40aca0638ba0f22e23dd5c03da35ef4f311a/gcc-7.1.0/winsup/w32api/include -B/usr/local/g
dc_2072_710_mingwcross/i686-pc-mingw32/bin/ -B/usr/local/gdc_2072_710_mingwcross/i686-pc-mingw32/lib/ -isystem /usr/local/gdc_2072_710_mingwcross/i686-pc-mingw32/inclu
de -isystem /usr/local/gdc_2072_710_mingwcross/i686-pc-mingw32/sys-include -Wall -g -frelease -O0 -nostdinc -pipe -Wno-deprecated -I ../../../../gcc-7.1.0/libphob
os/src -I ../../../../gcc-7.1.0/libphobos/libdruntime -I ../libdruntime -I . -c -o std/mmfile.lo ../../../../gcc-7.1.0/libphobos/src/std/mmfile.d
libtool: compile: /home/TANE/develop/dlang/gcc/gdc_2071_710/GDC-ac0c40aca0638ba0f22e23dd5c03da35ef4f311a/build_i686-pc-mingw32/./gcc/gdc -B/home/TANE/develop/dlang/gc
c/gdc_2071_710/GDC-ac0c40aca0638ba0f22e23dd5c03da35ef4f311a/build_i686-pc-mingw32/./gcc/ -L/home/TANE/develop/dlang/gcc/gdc_2071_710/GDC-ac0c40aca0638ba0f22e23dd5c03da
35ef4f311a/build_i686-pc-mingw32/i686-pc-mingw32/winsup/mingw -L/home/TANE/develop/dlang/gcc/gdc_2071_710/GDC-ac0c40aca0638ba0f22e23dd5c03da35ef4f311a/build_i686-pc-mi
ngw32/i686-pc-mingw32/winsup/w32api/lib -isystem /home/TANE/develop/dlang/gcc/gdc_2071_710/GDC-ac0c40aca0638ba0f22e23dd5c03da35ef4f311a/gcc-7.1.0/winsup/mingw/include
-isystem /home/TANE/develop/dlang/gcc/gdc_2071_710/GDC-ac0c40aca0638ba0f22e23dd5c03da35ef4f311a/gcc-7.1.0/winsup/w32api/include -B/usr/local/gdc_2072_710_mingwcross/i6
86-pc-mingw32/bin/ -B/usr/local/gdc_2072_710_mingwcross/i686-pc-mingw32/lib/ -isystem /usr/local/gdc_2072_710_mingwcross/i686-pc-mingw32/include -isystem /usr/local/gd
c_2072_710_mingwcross/i686-pc-mingw32/sys-include -Wall -g -frelease -O0 -nostdinc -pipe -Wno-deprecated -I ../../../../gcc-7.1.0/libphobos/src -I ../../../../gcc-7.1.
0/libphobos/libdruntime -I ../libdruntime -I . -c ../../../../gcc-7.1.0/libphobos/src/std/mmfile.d -o std/mmfile.o
/home/TANE/develop/dlang/gcc/gdc_2071_710/GDC-ac0c40aca0638ba0f22e23dd5c03da35ef4f311a/gcc-7.1.0/libphobos/src/std/utf.d: In function '__xopEquals':
/home/TANE/develop/dlang/gcc/gdc_2071_710/GDC-ac0c40aca0638ba0f22e23dd5c03da35ef4f311a/gcc-7.1.0/libphobos/src/std/utf.d:3115:12: internal compiler error: in force_typ
e_die, at dwarf2out.c:25107
static struct ByCodeUnitImpl
^
/home/TANE/develop/dlang/gcc/gdc_2071_710/GDC-ac0c40aca0638ba0f22e23dd5c03da35ef4f311a/gcc-7.1.0/libphobos/src/std/utf.d:3115:12: internal compiler error: Aborted
gdc: internal compiler error: Aborted (program cc1d)
AM中に起床。本日もお休み。
やっぱりgcc-7が来ないなぁ？ GDCの方はgdc-7の準備ができてっぽいですが。
ちょろりお出かけ。
「ONEPIECE(85)」。うまく均衡が崩れたなぁと思ったりも。
でも、ビッグ・マムの方はどうにかなったとしても、ジェルマの方とは
どう片が付くのだろう？まだまだ続きます。
AM中に起床。本日はお休み。
そういえば、Horizonをダウンロード購入した時に
「The Art of Horizon Zero Dawn」ってのも一緒にダウンロード
されていたのを思い出したり。ゲームのコンセプトアートを
収録したボーナスコンテンツだったのですが、ゲームを終えてから観ると
「あぁ、あそこか」という感じで楽しめました。
Horizonのトロフィーを少し眺めてみたり。
ほぼプロローグに相当する「ロストに師事した」の取得率は
今日時点で 96.0% でした。つまり100人のうち4人は、
始めたばかりかアーロイが大人になる前にゲームを辞めているという事になります。
メインストーリー中間点にあたる「古の歴史を知った」の
取得率は 47.8% で、半分の人は辞めたかまだ途中という感じ。
メインストーリークリアに相当する「戦闘機械の脅威を終わらせた」
は26.7% で、4人に1人がクリアしているという感じ。
現時点で最後までやった人は多いと思います。
Guerrilla Games 作品である「Killzone Shadow Fall」では、キャンペーンの
プロローグに相当する「父と子」(指示通りに操作するだけ、死ぬ要素無し)
の取得率は90.6% (以前よりも下がって
ます。恐らくPS-Plus配信されたのでそこで分母だけが拡大されたのかも)です。
そして、実質的なゲーム本編の一番最初のチャプタークリア「シャドー」の
取得率は いきなり59.0% になります。4割は途中でゲームを辞めているものと
考えられます。そして最終ステージクリアに相当する「救国の英雄」
の取得率は 20.3% で、5人に1人しかキャンペーンを最後までやっていない
という感じですが、意外と高い気がしたりも。
でもこれは大分マシな方です。影を操るゲームであるところの「Contrast」
では、「新次元」(影にシフトするとアンロック。ゲーム進行上必ず行う操作)
の取得率は 89.9%、最初のステージクリアに相当する「破れた夢の回転木馬」
の取得率はなんと35.7% です。10人に1人はちょっと触っただけ、3人に2人は
最初のステージをクリアせずにフェードアウトしていると言えます。
因みに、アンチャ4 は今日時点で「練習でクリア！」(レベルによらずゲームクリアに相当)
が41.6% で、こちらはかなり高い感じ。ただしプラチナは敷居が高い為か
0.9% と相当難しい感じになってます(因みに TANEの基準としては 2% 以上なら
頑張って取得可能、1% 以下はほぼムリゲーという感じ)。
トロフィーの取得率は目安のひとつでしかないのですが、
普通にゲームをプレイしていれば取得できるタイプのトロフィー
の取得率を見ていると、少なくとも最後までやっているか否かと、
ゲームが面白いか否かは相関があると見て良いのかな？と考えます。
ゲームのプレイ時間の話。ゲームによりますが、最近のだとクリアだけなら
10～20時間というものが比較的多いのではないかと思います。時間が余っている
人ならともかく、時間の限られた社会人だとそのくらいのボリュームが丁度
良いという人も少なくはないのでは？とも思います。そういうTANEもその一人かも(^^;
このプレイ時間を意図的に抑えた作りというのは他にもメリットが
あるように思います。まず一番大きいと思われるのは「他のタイトルへの機会損失が減る」と
いう点。例えばクリアに1000時間かかるタイトルを漏れなく全員がクリアするまで
遊んだとすると、人に与えられた時間は有限なので他のタイトルで遊ぶ機会は
自動的に無くなってしまいます。次に「制作するにあたってプレイ時間に注力した
コストを掛けられる」という点。1000時間遊べるようにする為にクエストを用意したとしても、
もし全員が20時間しか遊ばないとすると、用意したクエストのうち980時間分の
制作コストは無駄になると考えられます。プレイヤーの人数×プレイ時間
というパイを分け合う感じにした上で、必要な所にコストを掛けた方が、
新しいゲームも作りやすい(==出やすい)感じになり、結果としてプレイヤーへ
還元されると思ったりする訳です。
実際、映画は(インドのを除けば)だいたい2.5時間前後の尺になってます。
そして、長さと面白さは無関係というのは直観的に理解できるのではないかと思うの
ですが、それはゲームも同じでは？というのがTANEの個人的な考えです。