gccでのstatic constなクラス変数の謎挙動

 今日はひたすらアセンブラを追いかけるだけのお話です。ごめんね。

 C++では定数の定義を、defineでなく、static constな変数で行うことが推奨されてるらしいです

// これはC++では(・A・)イクナイ!!
#define VAL (1)
//こっち推奨
const int VAL = 1;

 基本的には、これで問題ないのですが、リンク先によると、この定数がクラス変数の場合、定義と実体の二つに分けないといけないそうです。

//ヘッダファイル側(宣言)
class Test
{
private:
	
protected:
	
public:
	static const int VAL=01234;
};
//ソースファイル側(実体)
//gccでは宣言(ヘッダ)に値を書いても良いけど、VC++等の古いコンパイラだと実体に書かないといけない。
//そのためにenumハックが存在する(上記のリンク先参照)
const int Test:VAL;

 ほえー、なるほど。

 が、しかし。実際には、gccのときは、実体を書かなくても割と大丈夫みたいです。Ubuntu11.04のx86-64のgccで実験してみました(Win32のMingwでも、機械語は違いますが同じ結果でした)。

 以下のソースはgithubからもDLできるよ☆彡 あ、ZIPももちろんあるよ!!

共通のヘッダファイルはこちら。

(Test.h)

#ifndef TEST_H
#define TEST_H

class Test
{
private:
	
protected:
	
public:
	static const int VAL1=1234;
	static const int VAL2=4321;
};

#endif

 特に意味はないです。このTestというクラスの定数を使って、いろいろテストしてみましょう。

 以下test*-*とありますが、これをmakeのビルドターゲットにすると自動でコンパイルとかしてくれます。

make test*-*

(test1-1)実体を定義しないまま、std::coutに入れてみる。

(Test1-1.cc)

#include "./Test.h"
#include <iostream>

int main(int argc, char** argv)
{
	std::cout << "VAL: " << std::hex << Test::VAL1 << std::endl;
	
	return 0;
}

 ヘッダ上のTest::VAL1やTest::VAL2の実体を一切定義していないことに注意していください。

 これをコンパイルして実行すると…

% g++ -o Test1-1.out Test1-1.cc
% ./Test1-1.out 
VAL: 1234

 どうなってるの!?と思って、アセンブラを出力させてみると…

% g++ -S -masm=intel Test1.cc ←こうすると見慣れたINTEL形式で出力してくれます
% cat Test1.s
main:
.LFB963:
	.cfi_startproc
	push	rbp
	.cfi_def_cfa_offset 16
	mov	rbp, rsp
	.cfi_offset 6, -16
	.cfi_def_cfa_register 6
	sub	rsp, 16
	mov	DWORD PTR [rbp-4], edi
	mov	QWORD PTR [rbp-16], rsi
	mov	esi, OFFSET FLAT:.LC0
	mov	edi, OFFSET FLAT:_ZSt4cout
	call	_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc
;---------------------------
	mov	esi, 1234
;---------------------------
	mov	rdi, rax
	call	_ZNSolsEi
	mov	esi, OFFSET FLAT:_ZSt4endlIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_
	mov	rdi, rax
	call	_ZNSolsEPFRSoS_E
	mov	eax, 0
	leave
	.cfi_def_cfa 7, 8
	ret
	.cfi_endproc

 線で囲ったところを見てもらえばわかるとおり、インライン展開されています。ちなみに、1234という数値はこの場所以外一切定義されません。

(test1-2)じゃ、実体を定義したらどうなるの?

 定義を書き加えて

(Test1-2.cc)

//ヘッダファイルとメイン関数の間に追加。
const int Test::VAL1;

 としてアセンブラを出力してみると…。

;実体も定義される
_ZN4Test4VAL1E:
	.long	1234

;(略)

main:
.LFB963:
	.cfi_startproc
	push	rbp
	.cfi_def_cfa_offset 16
	mov	rbp, rsp
	.cfi_offset 6, -16
	.cfi_def_cfa_register 6
	sub	rsp, 16
	mov	DWORD PTR [rbp-4], edi
	mov	QWORD PTR [rbp-16], rsi
	mov	esi, OFFSET FLAT:.LC0
	mov	edi, OFFSET FLAT:_ZSt4cout
	call	_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc
;---------------------------
	mov	esi, 1234
;---------------------------
	mov	rdi, rax
	call	_ZNSolsEi
	mov	esi, OFFSET FLAT:_ZSt4endlIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_
	mov	rdi, rax
	call	_ZNSolsEPFRSoS_E
	mov	eax, 0
	leave
	.cfi_def_cfa 7, 8
	ret
	.cfi_endproc

 Test::VALの値が埋め込みになるのは同じでしたが、それとは独立した実体も定義されました。

 一切最適化オプションをつけなくても、それなりに最適化してくれるみたいです。

(test1-3)ポインタを通す等して、実体が必要な状況をつくってみる

 ポインタを通す場合、アセンブラに直接引数を書くことはできません。メモリ上に一旦置かなければなりません。

(Test1-3.cc)

#include "./Test.h"
#include <iostream>

void outVal(const int* val)
{
	std::cout << "VAL: " << *val << std::endl;
}

int main(int argc, char** argv)
{
	outVal(&Test::VAL1);
	
	return 0;
}

 今度からは面倒なのでビルドターゲットでコンパイルします。†1

% make test1-3
g++ -S -masm=intel Test1-3.cc -o Test1-3.s
g++ -o Test1-3.out Test1-3.cc
/tmp/ccIrdzjI.o: In function `main':
Test1-3.cc:(.text+0x50): undefined reference to `Test::VAL1'
collect2: ld returned 1 exit status
make: *** [test1-3] エラー 1

 案の定実行は失敗ですね。アセンブラコードを見てみると?

;実体は定義されないけど...

;(略)

main:
.LFB964:
	.cfi_startproc
	push	rbp
	.cfi_def_cfa_offset 16
	mov	rbp, rsp
	.cfi_offset 6, -16
	.cfi_def_cfa_register 6
	sub	rsp, 16
	mov	DWORD PTR [rbp-4], edi
	mov	QWORD PTR [rbp-16], rsi
;---------------------------
	mov	edi, OFFSET FLAT:_ZN4Test4VAL1E ;使おうとする
;---------------------------
	call	_Z6outValPKi
	mov	eax, 0
	leave
	.cfi_def_cfa 7, 8
	ret
	.cfi_endproc

 予想通りですね。

(test1-4)でも、最適化を掛けると…。

 でもしかし。同じソースのまま、-O3とかを付けて最適化を掛けると、実行可能です。

make test1-4
g++ -S -masm=intel Test1-3.cc -o Test1-4.s -O3 ;ソースは上と同じTest1-3.cc
g++ -o Test1-4.out Test1-3.cc -O3
./Test1-4.out
VAL: 1234
main:
.LFB1004:
	.cfi_startproc
	push	rbp
	.cfi_def_cfa_offset 16
	mov	edx, 5
	mov	esi, OFFSET FLAT:.LC0
;std::coutへの出力を行う別の関数(outVal)があったのに、インライン展開されてる。
;(展開されてない、outValの実体も別箇所で存在します。)
	mov	edi, OFFSET FLAT:_ZSt4cout
	push	rbx
	.cfi_def_cfa_offset 24
	sub	rsp, 8
	.cfi_def_cfa_offset 32
	.cfi_offset 3, -24
	.cfi_offset 6, -16
	call	_ZSt16__ostream_insertIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_PKS3_l
;----------------------------------
	mov	esi, 1234   ;ハードコーディング。
;----------------------------------
	mov	edi, OFFSET FLAT:_ZSt4cout
	call	_ZNSolsEi
	mov	rbx, rax
	mov	rax, QWORD PTR [rax]
	mov	rax, QWORD PTR [rax-24]
	mov	rbp, QWORD PTR [rbx+240+rax]
	test	rbp, rbp
	je	.L11
	cmp	BYTE PTR [rbp+56], 0
	je	.L9
	movzx	eax, BYTE PTR [rbp+67]

じゃポインタにしないなら良いんだね良かった良かった

 ポインタとして使えないのはdefineでも一緒ですし、だったら同じ条件ですねやったー。

 …と言いたいところだが、(大佐風)微妙にこったことをすると必ず実体の定義が要らなくなるとは限りません。

(test2-1)三項演算子の結果に使う

 三項演算子を使って、フラグによって定数を振り分けたい!ありそうなシチュエーションです。

(Test2.cc)

#include "./Test.h"
#include <iostream>

int main(int argc, char** argv)
{
	int val = argc > 1 ? Test::VAL1 : Test::VAL2;

	std::cout << "VAL: " << val << std::endl;
	
	return 0;
}

 これを最適化なしでコンパイルすると…

% make test2-1
g++ -S -masm=intel Test2.cc -o Test2-1.s
g++ -o Test2-1.out Test2.cc
/tmp/cc87c0Ta.o: In function `main':
Test2.cc:(.text+0x17): undefined reference to `Test::VAL1'
Test2.cc:(.text+0x1f): undefined reference to `Test::VAL2'
collect2: ld returned 1 exit status
make: *** [test2-1] エラー 1

 なんと。駄目でした。アセンブラを読んでみると、

;もちろん実体は定義されてない。

main:
.LFB963:
	.cfi_startproc
	push	rbp
	.cfi_def_cfa_offset 16
	mov	rbp, rsp
	.cfi_offset 6, -16
	.cfi_def_cfa_register 6
	sub	rsp, 32
	mov	DWORD PTR [rbp-20], edi
	mov	QWORD PTR [rbp-32], rsi
;---------------------------------- ここから三項演算子
	cmp	DWORD PTR [rbp-20], 1
	jle	.L2
	mov	eax, DWORD PTR _ZN4Test4VAL1E[rip] ;実体は無いのに
	jmp	.L3
.L2:
	mov	eax, DWORD PTR _ZN4Test4VAL2E[rip] ;使おうとする。
;----------------------------------
.L3:
	mov	DWORD PTR [rbp-4], eax
	mov	esi, OFFSET FLAT:.LC0
	mov	edi, OFFSET FLAT:_ZSt4cout
	call	_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc
	mov	edx, DWORD PTR [rbp-4]
	mov	esi, edx
	mov	rdi, rax
	call	_ZNSolsEi
	mov	esi, OFFSET FLAT:_ZSt4endlIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_
	mov	rdi, rax
	call	_ZNSolsEPFRSoS_E
	mov	eax, 0
	leave
	.cfi_def_cfa 7, 8
	ret
	.cfi_endproc

(test2-2)最適化してみる。

 でも最適化をつけると…

make test2-2
g++ -S -masm=intel Test2.cc -O3 -o Test2-2.s
g++ -o Test2-2.out Test2.cc -O3
./Test2-2.out
VAL: 4321
main:
.LFB1003:
	.cfi_startproc
	push	rbp
	.cfi_def_cfa_offset 16
	mov	eax, 4321
	mov	edx, 5
	mov	esi, OFFSET FLAT:.LC0
	push	rbx
	.cfi_def_cfa_offset 24
	mov	ebx, 1234
	.cfi_offset 3, -24
	.cfi_offset 6, -16
	sub	rsp, 8
	.cfi_def_cfa_offset 32
	cmp	edi, 2
	mov	edi, OFFSET FLAT:_ZSt4cout
;----------------------
	cmovl	ebx, eax ;フラグを見て、条件にあうならeaxをebxへ。ここが三項演算子。
;----------------------
	call	_ZSt16__ostream_insertIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_PKS3_l
	mov	esi, ebx
	mov	edi, OFFSET FLAT:_ZSt4cout
	call	_ZNSolsEi
	mov	rbx, rax
	mov	rax, QWORD PTR [rax]
	mov	rax, QWORD PTR [rax-24]
	mov	rbp, QWORD PTR [rbx+240+rax]
	test	rbp, rbp
	je	.L8
	cmp	BYTE PTR [rbp+56], 0
	je	.L4
	movzx	eax, BYTE PTR [rbp+67]

 まさかの分岐命令…なし…!?cmovlはこちら参考

 また、何度もstd::coutの関数を呼ぶのでなく、出力関数は一度だけのようです。

(test2-3)じゃ素直にif文を使う。

 じゃあ、if文で同じことをしましょう。

(Test2-3.cc)

#include "./Test.h"
#include <iostream>

int main(int argc, char** argv)
{
	int val;
	if(argc > 1){
		val = Test::VAL1;
	}else{
		val = Test::VAL2;
	}

	std::cout << "VAL: " << val << std::endl;
	
	return 0;
}
% make test2-3
g++ -S -masm=intel Test2-3.cc -o Test2-3.s
g++ -o Test2-3.out Test2-3.cc
./Test2-3.out
VAL: 4321

 むむ。成功してしまいました。アセンブラは?

main:
.LFB963:
	.cfi_startproc
	push	rbp
	.cfi_def_cfa_offset 16
	mov	rbp, rsp
	.cfi_offset 6, -16
	.cfi_def_cfa_register 6
	sub	rsp, 32
	mov	DWORD PTR [rbp-20], edi
	mov	QWORD PTR [rbp-32], rsi
	cmp	DWORD PTR [rbp-20], 1
	jle	.L2
	mov	DWORD PTR [rbp-4], 1234
	jmp	.L3
.L2:
	mov	DWORD PTR [rbp-4], 4321
.L3:
	mov	esi, OFFSET FLAT:.LC0
	mov	edi, OFFSET FLAT:_ZSt4cout
	call	_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc
	mov	edx, DWORD PTR [rbp-4]
	mov	esi, edx
	mov	rdi, rax
	call	_ZNSolsEi
	mov	esi, OFFSET FLAT:_ZSt4endlIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_
	mov	rdi, rax
	call	_ZNSolsEPFRSoS_E
	mov	eax, 0
	leave
	.cfi_def_cfa 7, 8
	ret
	.cfi_endproc

 分岐命令で割り振るまでは三項演算子と同じ。でもif文の場合はインラインで定数を書いてくれるみたいですね。

 ちなみに、最適化をかけたときの結果は、三項演算子の時と殆ど同じになりました(test2-4)。

残りのテストの概要

 残りのテストの結果は上記の結果から推測できる面白くない結果だったので概要だけ。

  • test3:三項演算子でも実体が書き加えてあればちゃんと動作します。そりゃそうさね。
  • test4-1:テンポラリな変数に三項演算子を代入するのでなく、そのままstd::coutに突っ込むところに直接書きました。でも駄目でした。
  • test4-2:4-1をコンパイルする際に最適化を掛けると、やっぱり大丈夫でした。

 どうやら、三項演算子はif文に展開されたりするわけではなく、別扱いになっていて、最適化フラグが掛からないときは扱いが少し違う…そんな感じでしょうか。gccのソースは読んでないのでわかりませんが…。

 エミュレータで実体を定義し忘れてたのになぜか動いていたのですが、三項演算子を使ったところでコンパイルエラーでした。なお、実体を定義する前にVC++でビルドしてたので、VC++も同じようにやってくれるみたいですが、最適化の結果どうなるのか、とかは確かめてないです。

けつろん!

  • ちゃんと実体書こう!
  • define替わりに使うならenumハックを検討しよう!

 ほんとC++は黒魔術やでぇ…いえ、仕様通り書かない私が悪いんです。でも動いちゃうのもちょっと困るよ…。

  • †1: といっても、そのmakefileも私が書いたんですが^^;

windows版rsyncとubuntuサーバを使って、開発環境を同期しよう

 私は現在、デスクトップPCとノートパソコンで開発しています。

 こういった時に問題になるのが、開発環境の同期です。同じソフトを何度もインストールしてメンテナンスするのは時間の無駄ですから、できるだけ同期させる必要があります。

 そのために、ここ数年間様々な方法を検討して実際に使ってきました。

方法1:USBメモリ

 PortableApps等を見習って、USBに開発環境一式を入れて使うというアプローチです。ある意味、一番素直ですね。8GB~16GB程度のUSBメモリもそれなりに安価に入手できるようになり、実用性が出ました。

  • メリット
    • “コピー”は存在しないので、同期を考えなくていい。
    • PortableAppsあたりで確立されているノウハウがそのまま使える。
  • デメリット
    • 安いUSBメモリは想像以上に遅い。そして、結構クラッシュする。
    • モバイル環境で、USBメモリが出っ張ってるのはちょっと怖い。USBが物とぶつかった場合、てこの原理でUSBコネクタが破壊されるかもしれない。

 16GBのUSBメモリが2本も壊れてしまったので、この方法は諦めました。今はまた別のUSBメモリ†1を買いましたが、大きなサイズのデータのやり取りに留めています。

方法2:dropbox

 USBメモリを諦めて、同期すると考えた場合、まっさきに思いついた方法です。専用のクライアントをインストールすることで、Windows/Mac OSX/Linuxの各OSで、ファイルを全自動で同期してくれます。

 初期容量が2GBしかありませんが、お金を払うor無駄に頑張ることで、容量を増やすことができます。私は無料で6.1GB手に入れました!(ドヤ

  • メリット
    • 自動でやってくれる
  • デメリット
    • 間違えて消した結果も全自動でミラーリング。ノートPCの不意のクラッシュによってデータが破壊された場合も同様。

 とはいえ自動でシンクロしてくれるのは便利で、現在でも、開発中のソースコードをシンクロさせるのに使っています。gitリポジトリも一緒に同期しているため冗長化されている上に、仮にファイルが紛失しても元のリポジトリから取得してくれば大丈夫なようになっています。

方法3:Bazaarの軽量チェックアウト

 新進気鋭のバージョン管理システムBazaarの、軽量チェックアウト機能を使ってSyncします。

 軽量チェックアウトというのは、SVNと似たような方式で、バージョンの一番新しいものだけが同期されます。ではなぜSVNを使わないとかというと、SVNも最新バージョンだけを同期しますが、最新バージョンのコピーも作成し、結果ファイル数が倍になってしまうのと、全フォルダに.svnというメタ情報を格納したフォルダ(先述の最新バージョンのコピーもここに入ってます)が作成され、これが存外邪魔だからです。

  • メリット
    • バージョン管理システムのリッチな所がすべて使える。
    • 変更点が一目で分かる
  • デメリット
    • クライアント側は最新バージョンだけだが、サーバ側は全バージョンなのでサーバのディスクを逼迫する(注:このsyncサーバはSSDで動いています)
    • 流石に10万ファイルを超えるとbazaarが重い。

 GUIのクライアントが一切使えないのには困ってしまいました…。コマンドラインだけだと正直ちょっとしんどいです。

rsync

 というわけで、rsyncに乗り換えました。これにより、速度の改善とディスクの逼迫を改善したいです。バージョン管理はなくても、たぶんなんとかなります。まだそんなに使っていないので、効果についてはこれから検証!です。

というわけで、実際にrsync環境を作ってみよう。

Ubuntu側のセットアップ

 基本的に公式マニュアルの通りです。玄箱でやっていたあたりからずっとinetdを使って来たのですが、どうやら最近はxinetdが推奨のようですね。

 設定ファイル先頭にこんなのを書き加えるともうちょっとセキュアかも。

use chroot = yes

 一つ引っかかったのは、xinetdだけでなく、システム全体の再起動をしないとうまく接続できない(telnetで叩いてもconnection refusedされる)事くらいでしょうか。どうしてかは分からないのですが、再起動すればうまく動いたのでよしとします。

Windows側のセットアップ

 cygwinをパッケージしたcwRsyncをDLします。インストーラだからインストール…。いえいえ、あり得ないですよね。Universal Extractで解答できます。使い方はこの辺を参考にね

 解答するとbinやdocといったフォルダが含まれるフォルダが出てくるので、そのフォルダを頂戴して”sync”とか適当にリネームして、そのフォルダに色々とsyncのためのスクリプトを書きましょう。

 まず必要なのは、pathを通してくれるようなバッチファイルです。

rem "common.bat"として保存してね。
@echo off
set PATH=%~dp0bin;%PATH%
rem この辺は適当に調整してね。
SET REPOS=ledyba@ledyba.org::windev/
rem cwRsyncはcygwinなので、パスの形式はcygwin形式です。
SET TARGET=/cygdrive/d/software/

 同期のための個々のバッチファイルを書く際は、このファイルをcallすることにしましょう。

 %~dp0に関してはこの辺を参考にしてください。バッチファイルが置かれたフォルダに置き換えられます。結構便利。

ファイルをサーバへバックアップする(push)

call "%~dp0common.bat"
rsync -rzht --progress --stats --chmod=a+rwx --delete %TARGET% %REPOS%
pause

 環境設定のための、先程作成したcommon.batを呼び出して環境を設定した後、rsyncを叩くだけです。

 それぞれのオプションは…

  • “-r”:再帰的にコピー。そうしないと、一番上段だけコピーされて意味が無い。
  • “-z”:圧縮をかける。exeが多いので意味があります。
  • “-h”:それっぽいログを出してくれるようになるので、ちょっとうれしくなります(ぇ
  • “-c”:チェックサムを取り、その結果を用いてコピーするかどうか判断します。
  • “–progress”:転送中の状態を表示します。
  • “–stat”:転送後に結果を表示します。
  • ” –chmod=a+rwx”:ファイル転送時にパーミッションを設定します。
    • これが一番重要です。転送時に、rsyncサーバが、デフォルトでは000でファイル・フォルダを作成してしまい、エラーが起きます。
  • “–delete”:ローカルで削除したファイルを、転送先にも反映させます。

 詳しくはこの辺参照。一番いいのは、それよりもお使いのrsyncの設定を見ることだと思いますが…。

 こんな感じです。特にこったところはありません。

ファイルから更新されたファイルを引き出す(pull)

call "%~dp0common.bat"
rsync -rzhc --progress --stats --delete %REPOS% %TARGET%
pause

 逆の事をしているだけです…。

ファイルが破壊されたかもしれない時用。

 私のノートパソコンは比較的クラッシュしやすい(どうしてだろう…)ので、そのための対策です。

call "%~dp0common.bat"
rsync -rzhc --progress --stats %REPOS% %TARGET%
pause

 –deleteをなくしただけです。こうすると、クライアント側には、クライアント側とサーバ側の和集合が残ります。

 この辺のノウハウはかなり無駄に貯めこんでるので、ちょっとずつ放出していけると良いかもしれませんね。

 みなさんも、リモート環境のノウハウが合ったら、ぜひ教えてくださいね。

 @ryoutenihamuさんに、common.batの存在しているフォルダのパスに空白が含まれている場合を忘れているとご指摘頂きました、ありがとうございます!また、WindowsNT系OSでは、.cmdがバッチファイルの標準拡張子だそうです…(どっちでも動くみたいですけど)。

  • †1: デザインが可愛くてかっこよくて、中々気に入っています。無くしがちなフタ部分もないし。

ミリ秒単位のタイマーと整数だけを使って60FPS固定にするには

 考えてみれば当たり前な方法ですが、ぐぐっても見つからなかったので…。

 世の中に存在する大体のライブラリでは、時間をミリ秒単位で計測することができます。一秒間は1000ミリ秒です。

 また、世の中、特にこの日本に存在するゲームは、大体60FPSで動いています。一秒間に60回画面上の絵が更新されるということです。

 1/60秒は、16.666666666666667秒。1ミリ秒が精度のタイマーでは、正確に測定することはできません。でもゲームスピードを60FPSにしたいなら、なんとか測定しなければなりません。

 そこで、多くのゲームではいろいろな方法でこの問題を解決してきました。

方法1:1/60秒≒16ミリ秒と近似する。

 いろいろと諦めてるのがこの方法です。この方法だと、1000ミリ秒/16ミリ秒=62.5となるので、60FPSより少し早くなってしまいますが、目をつぶります。

 ソースコードはこんな感じ

void gameloop()
{
	uint32_t nextFrame = getNow()+16;//ミリ秒のタイマー関数
	while(ゲームが終わるまで){
		move();//ゲーム内でのキャラクタの移動処理など
		uint32_t now = getNow();
		if(now < nextFrame){
			draw();//描画処理
			now = getNow();
			if(now < nextFrame){ //描画しても時間が余ってたら・・・
				sleep(nextFrame-now);//ミリ秒精度で処理を中断する関数
			}
		}
		nextFrame+=16;
	}
}

方法2:浮動小数点を使う

 sleepも、現在の時間を取得する関数もミリ秒の精度しかありませんが、それらを管理する変数だけは浮動小数点を使う方法です。この方法を使うと、実際には16ミリ秒のフレームと17ミリ秒のフレームが、1:2の割合で現れます。

 ソースコードを見ていただけたほうが早いでしょう。

const float frameInterval = 1000.0f/60; //60FPSの基準時間

void gameloop()
{
	//floatでの管理に変えた
	float nextFrame = getNow()+frameInterval;
	while(ゲームが終わるまで){
		move();//ゲーム内でのキャラクタの移動処理など
		uint32_t now = getNow();
		if(now < nextFrame){
			draw();//描画処理
			now = getNow();
			if(now < nextFrame){ //描画しても時間が余ってたら・・・
				//型変換が必要。。。
				sleep(static_cast<uint32_t>(nextFrame-now));
			}
		}
		nextFrame+=frameInterval;
	}
}

 この方法ではかなり正確に60FPSを達成できますが、「計算の遅いfloat+型変換まで必要、よって遅そう」、「浮動小数点の精度は直感的に分かりづらい」(からなんか気持ち悪い)という精神衛生上の問題が発生します。

 実際には一秒間に60回しか行わないので、パフォーマンス上の問題は無いでしょうし、そもそもミリ秒精度しか測れない以上キッチリ60FPSを測ることも不可能なので、floatの誤差を気にする必要は無いと思いますけど。でもなんか気持ち悪いんです…(ぇ

方法3:vsyncに任せる

 DirectXやらOpenGLやらのゲームライブラリは、システムがモニタに画面を描画するタイミングまで待ってくれたりします。これを垂直同期(vsync)を取るといい、この方法を使うとシステムが画面をディスプレイに描画している最中にゲーム画面を更新する事がなくなるので、画面がガクついたりしなくなります。

 この方法は自分で時間を測る必要もないし†1、画面も綺麗になるしでいいこと尽くめなのですが、ひとつだけ問題があります。「すべてのモニタが60FPSとは限らない」、という点です。75FPSの画面もあれば、50FPSの画面もあります。垂直同期を取るとこういった場合にゲームが早くなったり遅くなったりしてしまいます。。

 また、必ずしもvsyncがサポートされているとは限りません。グラフィックカードの設定でvsyncを無効にすることもできます(OpenGLの場合。DirectXは存じません)。

今回の方法:浮動小数点でなく分数で計算する

 長々と書いてきましたが、やっと今回の本題に入れます。vsyncが一番良いのはそのとおりなのですが、諸々の事情で使えないこともあるとわかりました。ということはやっぱりタイマを用いて制御しなければならないこともあるわけです。。。

 方法2のfloatを用いる方法を継承しつつ、精神衛生上よろしくないfloatを取り除きます。一秒間に1000回回るカウンタを使って一秒間に60回を測る方法…。そう、最小公倍数の6000を基準にして、分数で測ってしまいましょう†2

void gameloop()
{
	//(1/60秒 = 100/6000秒)
	uint32_t nextFrame = getNow()*6 + 100;
	while(ゲームが終わるまで){
		move();//ゲーム内でのキャラクタの移動処理など
		uint32_t now = getNow() * 6;
		if(now < nextFrame){
			draw();//描画処理
			now = getNow() * 6;
			if(now < nextFrame){ //描画しても時間が余ってたら・・・
				sleep((nextFrame-now)/6);
			}
		}
		nextFrame+=100;
	}
}

 問題はタイマーの限界が6倍早く来てしまう点でしょうか…。SDLのSDL_GetTicksなどの32ビット整数を返すタイマでは49日間で0に戻ってしまいますが、6倍するのでだいたい8日でオーバーフローしてしまいます。

応用

 抽象化すると「”一定期間内にn回まわるカウンタ”で”一定期間内にm回まわるカウンタ”をつくる方法」ですので、フレームレート以外でも活用していただけます。

 そもそも今回の内容は、現在開発中のファミコンエミュレータで、サウンドとCPUを同期する方法を考えていて思いつきました。とはいえその内容をそのまま書いても汎用性が低いので、フレームレートに置き換えて記述しています。

  • †1: フレームスキップするなら別です
  • †2: 書いていて中学受験を思い出しました…。