用語のバックアップ(No.7)

フレーム †

一般的に1/60秒の時間を表す。テレビは1秒間に６０枚のパラパラ漫画を再生することで動いているのはご承知の通り。秒間に６０枚ということは１コマ1/60秒（約0.016秒）なので、見えないほど速い時間ではない。ゲームではキャラクタの動きを1/60秒毎にスライスしてプログラムされている。

↑

微分 / 積分 †

微分、積分、サインコサインタンジェント、数学は色々難しいし、なんの役に立つのかわからない。微分の計算がわからなくとも概念は知っておこう。１フレームに2.8ドット移動するキャラを考えると、１秒間に2.8x60=168ドットの距離を移動することになる。この時1/60秒単位にスライスしているのは、秒間あたりの移動速度に微分していると言えるし、秒間あたりの移動距離は積分しているといえる。

１秒間に168ドット移動するキャラを１フレームあたりの速度に微分すると
2.8ドットの速度になる

１フレーム2.8ドットの進むレーザーの移動距離は
１フレームあたりの移動速度を積分すると168ドットと算出される

そういうことである。

↑

外積 / 内積 †

外積、内積とは「線と線の平行具合」である。内積の場合、線と線の関係が平行に近いほど０になり、垂直に近いほど１に近づく。外積の場合はその逆で「直交具合」と言える。

ゲームで言うなら「前後に分厚い鎧の敵」へのダメージ計算方法として使える。側面から斬りかかった時のダメージを大きくしたい時に内積を取れば都合がいい。ちなみに英語では、外積とはcross Product、内積とはdot Productという。自分で外積、内積を取るプログラムもシンプルなので使っているうちに覚えられる。

typedef struct Vector2D
{
 Float32 x;
 Float32 y;
} Vector2D;


//ベクトル内積
Float32 DotProduct(Vector2D *vecL, Vector2D *vecR) {
 return vecL->x * vecR->x + vecL->y * vecR->y;
}

//ベクトル外積
Float32 CrossProduct(Vector2D *vecL, Vector2D *vecR) {
 return vecL->x * vecR->y - vecL->y * vecR->x;
}

内積は
・２つのベクトルのなす角度を求める
・線上の最近点を求める
・点が平面の表、裏どちら側にあるか判定
・平面上に点があるか

外積は
・２つのベクトルに垂直なベクトルを求める。
・ポリゴンの向き(法線ベクトル)を求める。
・２つのベクトルが所属する平面において左右の位置関係を知る
・平面上の三角形と点の内外判定

上記の使い方ができるので、レースゲームで壁にぶつかった時の進行方向の補正やクイックスを作る時の塗りつぶすべき壁の判定にも使える。

↑

ポリゴンの表裏判定 †

↑

アーキテクチャ †

コンピュータシステムの論理的構造のこと。難しい言葉だが「つくられかた」と思っていい。「アーキテクチャが異なる」とは「つくられかたが異なる」と読み替えられる。

↑

メモリ †

メモリとは忘れないように石の数で数値を刻むキャンバスみたいなもの。１＋３＋６の計算をするとき、まず１＋３の計算結果を忘れないように４個の石をキャンバスに置いておく。次にその４個の石の横に６個の石を置くことで、全部合わせて１０個であることが見て取れる。メモリはそんな便利な「キャンバスと石」の仕組みを電気信号で再現したもの。

↑

8ビット †

ビットというのはメモリの大きさを表す。たとえば8bitのメモリ空間というのは、８個の石をおけるキャンバスの大きさをあらわす。８個の石がおけるキャンバスって最大８までしか数えられないのでしょうか？いいえ、工夫すれば８個石が置けると２５６個までの数字を数えることが出来る。たとえば３個しか石が置けない３bitのキャンバスを例に取る（ｘは何もなし、oは石、1ビット＝１つの石と思えばいい）下のように０～７の８種類のパターンを作ることができるので、３つの石があれば最大７まで記録することができる。

xxx ・・・0
xxo ・・・1
xox ・・・2
xoo ・・・3
oxx ・・・4
oxo ・・・5
oox ・・・6
ooo ・・・7

↑

バイト †

１バイトというのは8bitのこと。１２個のチョコで１ダースみたいにいうと８つのビットで１バイト。１バイトあれば２５６まで表すことができる。何しろ石が８個もあるからね。２５６パターンあれば表現できるものって何があるか？アルファベットは２６個なので英文字くらいは余裕で表現できそうである。

xxxxxxxo・・・A
xxxxxxoo・・・B
xxxxxoox・・・C

こんな感じで8bitで表現した石のパターンと英文字を関連付ければ文が書けるかもしれない。８バイトあれば８文字の手紙が書けそう。そうやって作られたのがASCII文字（アスキー文字）で「半角文字」って言われている。

↑

スクリプト / プログラム　違い †

明確な違いはないし、無理やり分けると料理本とレシピくらいの違い。レシピ本という言い方と同じく、プログラムファイルは「C言語スクリプト」という言い方もできる。「C言語でプログラムが書かれたスクリプト」である。コンパイルするからプログラム、インタープリターだからスクリプトという見方もあるようだ。

↑

プログラム / プログラマ　違い †

これは違う、説明は不要だと思うが、運動会や発表会の１日の予定や雨の場合の対処法が記されているのがプログラム。プログラマがCPUへの手順や例外の対処法を羅列してるのもプログラム。プログラムを書く人がプログラマ。

↑

機械（マシン）語 / アセンブラ †

C言語とアセンブラと機械語は全く違う。機械語は１６進数で書かれた数字だけの暗号ファイルみたいなもので、コンピューターが理解することができる言葉。とはいえヒトも理解できる一定の法則によって成り立っている。なにしろ機械語はヒトが作った言葉だからね。CPUにより言語体系は異なる。たとえばインテル系のCPUの機械語とARM系CPUの機械語は英語とロシア語くらい違う。どちらも数字だけで構成されたいわゆる「バイナリ」なので同じように見えるが、CPUの受け付ける命令の数や種類を文化とすると、数字の並び方の法則性は文化の違いにより全く異なる。

どんなものかというと

マシン語「FF01FE02」に対して

A系CPU
FF・・・次の数字をメモリに起きなさい
FE・・・メモリに置かれている数字と足し算しなさい
計算結果 01+02 = 03

B系CPU
FF・・・次の数字をメモリに起きなさい
FE・・・メモリに置かれている数字とかけ算しなさい
計算結果 01*02 = 02

ここで出来上がったマシン語コードの塊が.exeなどの「実行ファイル」である。OSやCPUは、この実行ファイルの頭から機械語化されたプログラムを順番に実行する。

↑

アッセンブル †

これをせめて人間が読めるカタチに近づけたのがアセンブラ（アセンブリ言語）なのであるが、当然CPU文化に応じてアセンブリ言語の体型は大きく異る。下図のようにアセンブラはオペランド（OPE）と(DATA)の組み合わせでCPUに命令を与える、これをソフトで「アッセンブル」することでマシン語に変換するのであるが、アセンブラ、アセンブリ言語ともにCPUにより大きく異なるのが特徴である。

アセンブラ(OPE)	(DATA)	マシン語
PUSH	BP	55
MOV	BP，SP	8B EC
SUB	SP，4	83 EC 04
LEA	AX，[BP-2]	8D 46 FE
PUSH	AX	50
MOV	AX，Z4	B8 00 00
PUSH	AX	50

このように命令とマシン語は１対１なので、できあがったマシン語のバイナリデータからアセンブリ言語に変換することも可能である。これを「逆アセンブル」する、といって出来上がった実行ファイルから元のプログラムを割り出すハッキング行為である。

↑

C言語 †

コンピューターにやらせたいことは同じなのにCPU毎に別のプログラムスクリプトを描くのはナンセンスなので、言語体系やできることを統一（規格化）してプログラム・スクリプトを同じものを使って翻訳レベルでプログラムを統一化したのがC言語となる。

つまり標準のC言語で書かれたプログラムを自動的にCPUに応じたアセンブリ言語に変換してもらえれば便利である。

↑

インタープリター / コンパイル †

人間が読めるC言語で書かれたプログラムスクリプトを機械が読める「機械語」に翻訳することを「コンパイル」する、という。

↑

統合開発環境 †

プログラムを組もうと思っても、プログラムを実行ファイルにするまでにはいろんなツールの力を借りる必要がある。
例えばコンパイラと呼ばれるｃ言語のプログラムをファイルごとに機械語に変換してくれる翻訳機（コンパイラ）や、機械語に直されたファイルをくっつけてくれるリンカーなどがそのツールの１つ。

それらのツールは本来別々のツールなので設定を各々してあげなくてはならないのだけど、それらを１つのソフトの中で全部設定できたらとても便利である。そういう意味で最近は統合開発環境としてプログラムを作って、コンパイルして、実行して、ターゲットマシンに転送までしてくれる環境を１つにまとめて出来るようになっているのが主流だ。ヴィジュアルスタジオやｘコードはその代表で、最近だとAndroid-Studioというのも出てきた。
で、これらの統合開発環境の状態を保存しておくことで、次回開発を再開するときに最後に開いていたプログラムや、ターゲットマシン、デバッガの設定などを起動後すぐに復元することができる。

↑

プロジェクトファイル †

統合開発環境の保存ファイルは、ｗindowsだと「*.sln」macだと「*.xcodeproj」という拡張子のファイルで、これがプロジェクトファイルだと思っていればいい。まあグラフィックで言うところ個々のレイヤー情報をまとめて持っているｐSDファイルみたいなものだと思えばいい。

↑

グラフィック関連 †

↑

クランプ、アドレッシングモード †

表示しようとするスプライトのテクスチャを指定にするときにテクスチャの範囲外を指定してしまった時に、端っこの色をひきずって表示するモードのひとつ。
他のモードにミラー（逆さに表示）、ラップ（ゼロに戻って表示）などのモードがある
これらのモードは「アドレッシングモード」と呼ばれる。

↑

アルファブレンディング †

アルファとは半透明のこと。赤いセロファンと緑のセロファンを重ねて上から見れば黒っぽく見える。
こんな感じで半透明を混ぜあわせるからアルファブレンデイング。

０がスケスケ、１００が不透明として、下地を５０％の半透明度、上にかぶせるセロファンを５０％の半透明みたいな感じで混ぜ合わせる。上にかぶせるセロファンの透明度が１００％の場合、下の色は全く見えない。
計算としては、例えばRGBのｒ成分が１００の時、上にかぶせる赤色(100)を５０％で混ぜあわせると
100*0.5 + 100*0.5 = 100 となる。

↑

ブレンドファンクション †

ブレンドの仕方もいろいろある。ただ下の色と上の色を組み合わせる場合だと上の色を７０％とした場合に下の色を３０％とすることで合わせて１００％の普通のブレンディングとなる。
しかし、７０％の下地に対して、７０％の色を加算合成すると、１４０％になる。現実的に１００％以上の色にはならないので全部が白くなっていく。

↑

ワイルドカード †

よくファイル名で使われる「*.bmp」とかいう謎の記号が出てくるが、この米マークは知っての通り「アスタリスク」という。ファイル名に使われるアスタリスクは「ワイルドカード」と言って、「？？？」を表す。よくわからないだろうが「？？？.bmp」と考えればいい。bmpの拡張子を持ったファイル全てを表す。検索するときに便利。a*.bmpをすれば、頭がaで始まるbmpファイルを指定できる

↑

OpenCV †

ビデオカメラに関する汎用プログラミングライブラリ。

↑

grep †

↑

Cocosの流れ †

AndroidのNDKのインストールを行う
　↓
Setup.pyでCocos2dxのインストールをする
　↓
Windows環境ではPythonを動かすためのパイソンのインストールを先に行う
　↓
AndroidNDKのパスを記載する
　↓
ターゲットになるマシンのプロジェクトを立ち上げる
※apple系はapple系のマシンでしかコンパイルできない
※Windows系はWindowsマシンでしかコンパイルできない
　↓
プラットフォームに応じたCocos2Dライブラリをビルドする
　↓
好きなOSやマシンで自分のソースを編集してコンパイルする
　↓
Cocos2Dライブラリとリンクする
　↓
ターゲットマシンに転送する
　↓
動く

※macでｗwindowsは動くが、その逆はできない。ので１つの開発マシンで全ての環境を担おうと思うとmacで開発環境を揃える方がいいような感じ。

↑

演算 / 計算違い †

計算・・・計ったり数えたりすること
演算・・・法則にそって計算すること

演算は計算に含まれる。プログラマが決めた法則によって計算されるプログラムは全て演算。

用語 のバックアップ(No.7)