マルチコアプログラミングをしてると出てくる用語

ちょっと、

out-of-order対策、メモリバリア、sequential consistency関連はサンプルコードを書いて体で覚えないとダメだ。

【メモ】
・releaseバリア：先行の命令が、バリアを越えて後にリオーダーされるのを禁止。書き込み時に使われて、書き込んだ時点でその前の命令が終わっていることを保証する。
・acquireバリア：後続の命令が、バリアを越えて前にリオーダーされるのを禁止。読み込み時に使われて、読み込んだ時点でその後の命令が行われていないことを保証する。
・Sequentially-consistent：異なるメモリ位置に対する書き込みが、全てのプロセッサから同じ順序で観測されることを保証する。

Android NDKでのglVertexAttributePointerの挙動

頂点カラーのattribute変数に値を渡す時

以下のやり方(VBO利用)はWindowsのOpenGLでは問題なく動く。

glVertexAttributePointer( 1 , 4 , GL_UNSIGNED_BYTE , GL_FALSE , sizeof(vertex) , 0 );

なんか、Android NDKではうまく動かない。。。

normalizedの引数をGL_TRUEにしても変わらなかった。。。

floatはGLESではfloatで渡さないとダメ？

GL_CLAMP

Android版には定義がない！？

変わりに、GL_CLAMP_TO_EDGEはあった。。。

VC++ => gcc 備忘録(1)

デフォルトの警告レベルで、64bit整数値定数を扱う場合

修正前：0xFFFFFFFF00000000

VSだと警告なし

gccだと警告あり

修正前：0xFFFFFFFF00000000LL

最後に"LL"つけましょう

androidのAPIレベルが知りたくなったら

Android API Levels | Android Developers へ

プリプロセッサ展開後の出力

Visual C++

　1.  [プロパティ]-[構成プロパティ]-[C/C++]-[コマンドライン]画面に移動
　2. [追加オプション(D)]欄に「/C /P」を記入
　　 →　/Cはコメント除去 /Pがプリプロセッサ出力の意味
　3. ビルド
　
　プリプロセッサ出力結果が[プロジェクト名].iファイルとして出力される

gcc

　
　gcc -E test.cpp > result.txt 

　結果が、result.txtに出力される

インライン展開メモ

・ デストラクタを持ったクラス（構造体）を値渡しで返す関数だとインライン展開されないことがある 

→　無意味に空のデストラクタを定義するのはやめたほうがいいかも

・ inline よりも __forceinlineの方がやっぱり強力

ある構造体typeのメンバ変数memberのサイズを取得するマクロ

マクロ

#define MEMBER_SIZE_OF(type, member) sizeof(((type*)0)->member)

使用例

#define MEMBER_SIZE_OF(type, member) sizeof(((type*)0)->member

struct TestType
{
    int val;
};
Uint32 valSize = MEMBER_SIZE_OF(TestType,val); // valのサイズ取得

sizeof内の式は実際には評価されないので、NULL参照とかにはなりません。

UTF8+BOM付きのファイルを右クリック新規作成で作れるようにする

基本的に、andoroid、iPhone、Windowsでソースコードを共有したいので、

cppとhファイルの文字コードはUTF8にしています。

しかし、右クリック → [新規作成] → [テキスト ドキュメント]で作成した[新しいテキスト ドキュメント.txt]をテキストエディタで開くと、大体SJISで開かれてSJISで日本語書き込まれるでしょう。

そうなると、SJISとUTF8のソースコードが混在してしまうのでよろしくありません。

なので、今回はBOM付き+UTF8のhファイルを作れるようにします。

テンプレートファイルの作成

まず、新規作成の時にテンプレートとなる、UTF8 + BOM付きのファイルを用意します。

仮に「template.h」というファイル名をつけておきます。

このファイルを、以下のアドレスのフォルダにコピー

C:\Users\ユーザ名\AppData\Roaming\Microsoft\Windows\Templates

注) このフォルダは隠しフォルダなので、隠しフォルダの表示設定をしておいてください。( [コントロールパネル]-[フォルダーオプション]-[表示]で設定可能

レジスタファイルの設定

レジストリエディタを開きます。

1. スタートメニューを押す

2. regeeditと入力

3. レジストリエディタ起動

4. 左ペインから.hの項目を見つけて右クリック→[新規]→[キー]で名前をShellNewにする

5. ShellNewできた

6. ShellNewを右クリック→[新規]→[文字列値]で名前をFileNameにする。FileNameをダブルクリックしてデータの値に「template.h」を入力

7 完了

まとめ

右クリック-[新規作成]-[C++ Header.h]が追加されていると思います。
[C++ Header.h]をクリックすると、template.hと同じ内容のhファイルができます。

これで無事右クリック新規作成で、UTF8+BOM付きのヘッダーファイルをすぐに作成できるようになりましたー。めでたしめでたし。

人を別のサービスから自分のサービスに乗り換えさせる戦略

その唯一の方法は、「障害を取り除くこと」 by Joel on Software

ここでは、コンピュータのソフトウェアという前提で話すけど

これは非常に納得した。

乗り換える上での障害を取り除くこと、大事。それはつまり、ユーザーの声に耳を傾けていることでもあるしね。


・ 金銭的障害
→　乗り換えコストが高いと、それを使おうとは思わないだろう

・ 乗り換える前にできたことが、乗り換え後にできなくなる
→　例えばエディタだと、コード補完機能とか色付けとかね

・ プラットフォームの乗り換えが必要
→ 自分がAndroid端末を使ってて、そのサービスがiPhone端末でしかできません、と言われたらわざわざそこまでしないだろう

・ 乗り換える前のデータが、乗り換え後に使えなくなる
→　以前のデータが無駄にしたくはないだろう。だから、Blogやメーラーだと、インポート機能とエクスポート機能がついてたりしてるよね。

・ 新しいユーザーインタフェースについて学ぶ必要がある
→　乗り換え前のユーザーインタフェースのオプションがあるといいかも(XSIには、Mayaの操作方法で操作できるオプションがある)

・ 要求スペックが高い
→　低スペックでも動けるように

・ 元に戻ることがしにくい
→　一度乗り換えると元には戻れないよ、だと慎重に判断するようになって、気楽には乗り換えてくれないだろう

最後の「元に戻ることがしにくい」というのは、見落としがちな気がした。「出て行く」ことを後押ししているわけではなくて、入り口の敷居を下げること大事。　

　「出て行きやすい」は「入りやすい」でもあるよね。

ジョエルテスト備忘録

とあるゲームプログラマーの場合

1. ソース管理しているか？
→　うちではPerforce使ってます。

2. 1オペレーションでビルドを行えるか？
→　VisualStudio優秀

3. デイリービルドを行っているか？
→　Jenkins優秀

4. バグトラッキングデータベースを持っているか？
→　Mantis使ってるけど、満足はしていない

5. 新しいコードを書くまえにバグを修正するか？
　→　やっぱ適度には必要ですよね


6. 更新可能なスケジュール表を持っているか？
　→　Excelで管理しているけど、何か良いツールで管理したいと思ってる


7. 仕様書を持っているか？
　→　それは当然


8. プログラマは静かな労働環境にあるか？
　→　うちだとゲームだから、どうしても議論は必要だけど「誰にも話しかけられない静寂タイム」があっても良いよね


9. 買える範囲で一番良い開発ツールを使っているか？
　→　Perforce、Coverity、VisualAssistXとか買ってもらってます。


10. テスト担当者はいるか？
　→　チェックチームだけじゃなくて、部内にも数名います。重宝してます。


11. プログラマを採用するときにコードを書かせるか？
　→　これは分からないす


12. 「廊下での使い勝手テスト」を行っているか？
　→　ゲームでもこれは必要だと思う。

趣味ライブラリの機能一覧【スレッド】

スレッド関連で、実装した機能

• スレッド
• 同期プリミティブ
• 条件変数
• スレッドプール
• スレッドプール用ジョブ
• ScopedLock（スコープを抜けると自動でロック解除してくるクラス）

Win32APIでのミューテックス、クリティカルセクション、セマフォの違い

セマフォ	ある処理があって、同時にその処理ができるスレッド数が限られている場合に使用。プロセスをまたいで排他制御可能
ミューテックス	ある処理があって、同時にその処理ができるスレッドが一つだけに限られている場合に使用。プロセスをまたいで排他制御可能
クリティカルセクション	ある処理があって、同時にその処理ができるスレッドが一つだけに限られている場合に使用。プロセスをまたいで排他制御不可能

基本的に処理速度は、クリティカルセクション　＞　ミューテックス。

※ プロセス=タスクマネージャを開いて、プロセス一覧に表示される単位。

チケットの粒度はどのくらい？ チケットを完了にできる人は誰？

どうもです。TECOです。しがないゲームプログラマーです。

突然ですが、現在自分が所属しているプロジェクトではチケット駆動でタスク管理しているのです。

今回、そこにちょっと気になることがあるので書き留めておきます。

前提

プロジェクトのメンバーは数十名である。
プロジェクトは数名規模の複数の班で構成されている。
班には班長がいて、もちろん班長も実作業を抱えている。
まぁ、そこまで険悪な仲ではない。
チケット駆動でタスク管理をしている（Trac、Mantis、Redmineなどを利用）

問題点

うちのプロジェクトでは、タスクをチケット化したら一つのルールがあるのです。

そのチケットを完了にする権利を持っているのはその担当者が所属する班の班長である。

このルールの縛りで仕事をするということは、つまり以下のことを意味します。

チケットが増えるとそれに比例して、班長に「完了にするための作業」が発生してしまう。

つまりは、管理コストが増える！！
するとだ、以下のことが発生！！

チケットが増えれば増えるほど、班長の管理作業時間が増えて実作業時間が減るのだ。

ということは、最悪班長の作業がパンクしそうになるとチケット管理がおろそかになる！？
すると、以下のようなことが起こりかねない。。。

実作業者はチケットの粒度を大きくして班長の「完了にするための作業」を減らす

そんなことになれば、今度は以下の問題が発生する恐れががが

小さな粒度のチケットを発行しづらくなる

すると小さな粒度のタスクは、作業担当者の記憶の中に残っている、付箋に書いて壁に貼ってある、ローカルサーバーで起動している別のタスク管理ツールで管理している、などして作業担当者のタスク作業抜けが起きてないことを神に祈らなければならなくなる。

つまり考えなければならないことは

1.「作業粒度」はどのくらいの粒度で行うのがベストなの？
2. 「チケットを完了にできる権利」は誰が持っているのがベストなの？

それぞれの個人的見解は以下の通り。

1. 5分で終わるようなものからチケット化できるようにする。
2. チケットの内容によって完了にする権利を持ってる人を変える。（作業担当者自身、仕様担当者、班長）

う～ん、でも実際どうするのが良いのだろう。。。

文字コード

Windows、Android、iOS対応のソースコードを書くなら

UTF8(BOM付き)

BOM無しだと、VisualStudioがアウト。

BOM付きも古いgccだとダメだったけど最近のgccだと大丈夫（なはず

サーバー遅延

リアルタイム性を重視しているネットワークゲームのプログラミングは難しいね。

あらゆる遅延を考慮しないとね。

自戒自戒

Syntax Highlighter導入

以前のブログでは、これが導入できなかったのでブログを変えようと思ったのです。

なので、まずはSyntax Highlighterを使ってみる。

サンプル

void testFunc() {
    printf("Hello World");
}

うまく行ったー！！

手順

とりあえずメモっておきやす。

1. http://www.way2blogging.org/2011/03/how-to-add-syntax-highlighterv3-to.html
2. Generate Scripts
3. 言語を選んで、Generate
4. 出力されたスクリプトをコピー
5. Bloggerのダッシュボードからテンプレート
6. htmlの編集
7. <html>～</html>の間に4でコピーしたソースをペースト
8. 新規投稿
9. <pre class="brush:言語名(例:c++）;">ソースコード</pre>
10. 以上

これで以前より格段と書きやすくなったー！！

ではでは

テスト投稿

とりあえずテストテスト