コンピュータシステムの論理的構造のこと。難しい言葉だが「つくられかた」と思っていい。「アーキテクチャが異なる」とは「つくられかたが異なる」と読み替えられる。
"管理や構築を複雑なツールに頼るシステムはエンドユーザにとって害になるだろう。 「複雑なシステムを隠そうとすれば、その結局もっと複雑なシステムになってしまうのが落ちだ」。 中身を隠すための抽象化レイヤーは決して良いものではない。その代わりに、隠さないで済むように中身を設計すべきなのだ。" アーロン・グリフィン
↑コレ好き、名言。
メモリとは覚えた数を忘れないように、その数だけ電子の石を置いてメモっておけるシステム。メモる=覚えておく=忘れない=メモリー。1+3+6の計算をするとき、まず1+3の計算結果を忘れないように4個の石をキャンバスに置いておく。次にその4個の石の横に6個の石を置くことで、全部合わせて10個であることが見て取れる。メモリはそんな便利な「キャンバスと石」の仕組みを電気信号で再現したもの。紙と鉛筆なんかよりずっとずっと原始的。
ビットというのはメモリの大きさを表す。たとえば8bitのメモリ空間というのは、8個の石をおけるキャンバスの大きさをあらわす。8個の石がおけるキャンバスって最大8までしか数えることができないように思うけど、工夫すれば256までの数字を表現することが出来る。たとえば3個しか石が置けない3bitのキャンバスを例に取ると下のように0~7の8種類のパターンを作ることができるので、3つの石があれば最大7まで記録することができる。同様の方法で石8個で256パターン、9個アレば512パターン、16個あれば65536パターン作ることができる。
xxx ・・・0
xxo ・・・1
xox ・・・2
xoo ・・・3
oxx ・・・4
oxo ・・・5
oox ・・・6
ooo ・・・7
(xは何もなし、oは石、1ビット=1つの石と思えばいい)
1バイトというのは8bitのこと。12個のチョコで1ダースみたいにいうと8つのビットで1バイト。1バイトあれば256パターンを再現することができる。何しろ石が8個もあるからね。256パターンあれば表現できるものって何があるか?アルファベットは26個なので余裕。さらに大文字小文字に対応して、加えて記号をいれても256種類におさまりそう。
xxxxxxxo・・・1・・・A
xxxxxxoo・・・2・・・B
xxxxxoox・・・3・・・C
こんな感じで「数(8bitで表現した石のパターン)」と英文字を関連付ければ文が書けるかもしれない。8バイト(64ビット)あれば8文字の手紙が書けそう。そうやって作られたのがASCII文字(アスキー文字)で「半角文字」って言われている。全角文字は漢字も含んで256パターンに収まらないから1文字16bit(2バイト)で扱われていて、理論上65536種類の漢字まで対応できる。
明確な違いはないし、プログラムが書かれたファイルは「C言語スクリプト」という言い方もできる。「C言語でプログラムが書かれたスクリプト」である。コンパイルするからプログラム、インタープリターだからスクリプトという見方もあるようだ。
これは違う、説明は不要だと思うが、運動会や発表会の1日の予定や順番、雨の場合の対処法が記されているのがプログラム。プログラマがCPUへの手順や例外の対処法を羅列してるのもプログラム。プログラムを書く人がプログラマ。運動会のプログラムを書く人は先生だな。
C言語とアセンブラと機械語は全く違う。機械語は16進数で書かれた数字だけの暗号ファイルみたいなもので、コンピューターが理解することができる言葉。とはいえヒトも理解できる一定の法則によって成り立っている。なにしろ機械語はヒトが作った言葉だからね。CPUにより言語体系は異なる。たとえばインテル系のCPUの機械語とARM系CPUの機械語は英語とロシア語くらい違う。どちらも数字だけで構成されたいわゆる「バイナリ」なので同じように見えるが、それは日本語以外は全て外国語っていうくらい乱暴なわけかたになる。CPUの受け付ける命令の数や種類を文化とすると、数字の並び方の法則性は文化の違いにより全く異なる。
81-01-80-42みたいな全てが16進数の数字だと見た目にわからないから、数字の一部をADD 00 SUB 42みたいに意味のある言葉に置き換えたものがアセンブラ言語(アセンブリ言語)。当然CPU文化に応じてアセンブリ言語の体型は大きく異る。下図のようにアセンブラはオペランド(OPE)と(DATA)の組み合わせで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 |
このように命令とマシン語は1対1なので、できあがったマシン語のバイナリデータからアセンブリ言語に変換することも可能である。これを「逆アセンブル」する、といって出来上がった実行ファイルから元のプログラムを割り出すハッキング行為である。
コンピューターにやらせたいことは同じなのにCPU毎に別のプログラムスクリプトを描くのはナンセンスである。異なるCPUやハードウェア間でも同じプログラム・スクリプトを使えるように言語体系やできることを統一(規格化)したのがC言語となる。
C言語はそれだけでなく、より人間の言葉に近い考え方や、記述方法でプログラムをかけるので複雑でもわかりやすいプログラムを書くことができる。そのC言語で書かれたプログラムを自動的にCPUに応じたアセンブリ言語やマシン語に翻訳してくれるのがCコンパイラ。人間語を機械語に翻訳してくれる「アプリ」である。
人間が読めるC言語で書かれたプログラムスクリプトを機械が読める「機械語」に翻訳することを「コンパイル」するという。プログラムスクリプトの実行には、最初に全てのプログラムを翻訳してしまう「コンパイル方式」と、都度翻訳しながら実行する「インタープリター式」の2種がある。翻訳済み文書と、同時翻訳の違いのようなもの。前者は先に間違いをすべて直さないと実行できない。後者は間違いがあっても実行できるが、その間違いは、プログラムがその箇所を通るまできづけない。
C言語はコンパイラ言語、PHPはインタープリター形式の言語である。
一般的に事前に翻訳されたコンパイル方式のほうが、その場で同時通訳されるインタープリター方式よりも高速に動作する。
プログラムを組もうと思っても、プログラムを実行ファイルにするまでにはいろんなツールの力を借りる必要がある。例えばプログラムを書くメモ帳などのエディタや、コンパイラや、機械語に直されたファイルをくっつけてくれるリンカー、リンクされたプログラムを実行してデバッグするデバッガなどがそのツールの1つ。
それらのツールは本来別々のツールなので設定を各々してあげなくてはならないのだけど、それらを1つのソフトの中で全部設定してシームレスに使用できたらとても便利である。プログラムを書くエディタから直接コンパイルして、実行して、ターゲットマシンに転送しデバッグまでさせてくれる環境を1つにまとめて出来るようになっているの統合開発環境(IDE)である。WIN用のVisualStudioやmac用のXCodeはその代表で、最近だとAndroid-Studioというのも出てきた。で、これらの統合開発環境の状態を保存しておくことで、次回開発を再開するときに最後に開いていたプログラムや、ターゲットマシン、デバッガの設定などを起動後すぐに復元することができて便利。
最近ではUnityやUnrealEngineなどといったゲーム開発そのものと密接な機能をもつ統合開発環境は、IDEの発展版といえる。
統合開発環境の保存ファイルは、windowsだと「*.sln」macだと「*.xcodeproj」という拡張子のファイルで、これがプロジェクトファイルだと思っていればいい。まあグラフィックで言うところ個々のレイヤー情報をまとめて持っているpSDファイルみたいなものだと思えばいい。
この便利さは神がかっている。プログラムを途中で止めて、ソースを変更して、続きから実行できる。メニューを構築したりするのに、なんどもソース中の座標を変更してリコンパイル、とかしなくていいし、ゲームのバランス調整にも実に便利。VisualStudio系以外では見たことがない。
VC2015ではなぜか1コンパイルに付き1度しかエディットできるチャンスがない。なんか設定ミスってるのかな、と思ったが制限がかかっているらしい。
https://www.infoq.com/jp/news/2015/08/enc-vs2015
ボイド(void)とは何もないことを指す。ポインタはアドレスを示すマーカーみたいな変数。それらが組み合わさってボイドポインター。通常ポインタにはそのマーカーが何を指しているかを示しておかないと、その先何バイトがそのマーカーのさす範囲なのか明確にできないので、「~型のポインタ」という形で扱うのが普通。A型のメモリ領域をB型で指し示すことはできない。しかしボイドポインタは明確な型を持たない分、A型でもB型でもなんでも型として受け入れられる。しかしボイドポインターに代入して、deleteした場合、明確な型がわからないので、デストラクタが呼ばれなくて困る。
いまのC++の標準ですって。boostとかstdとかstlとか複雑になって取り残された僕にはJavaでもなくC#でもなくもう一度あの時愛したC言語に戻るチャンスかもしれないと思ってみてみたら、しばらく見ないうちに「髪型変わった?」っていうレベルじゃなかった、別人じゃん。C++2とかC++8とかがあるわけじゃなくて、2011年に久しぶりに策定されたCの標準化らしい。ANSIとかで定義されてたCの標準化の2011年版だと思えばいい。2014年版のC++14もあるけど、もうそっ閉じ。
C++11から追加された新仕様。
void onConnectedController(Controller* controller, Event* event)
↓
controllerListener->onConnectedController = [&](Controller* controller, Event* event) { };
見慣れたソースから書き直すとこんな感じ。コールバック関数の挙動をひとまとめにかけるのが便利なんですって。関数の中に関数を書くとか、初見で意味がわからないが、関数内にテーブルを定義するのに近いと強引に思い込んで関数の最後はセミコロンで閉じよう「{ ~ };」
関数の中に関数を書いたりするアレ。
test() { test2(){ }; test2(); }
微分、積分、サインコサインタンジェント、数学は色々難しいし、なんの役に立つのかわからない。微分の計算がわからなくとも概念は知っておこう。1フレームに2.8ドット移動するキャラを考えると、1秒間に2.8x60=168ドットの距離を移動することになる。この時1/60秒単位にスライスしているのは、秒間あたりの移動速度に微分していると言えるし、秒間あたりの移動距離は積分しているといえる。
外積、内積とは「2つの線と線の平行具合」である。内積の場合、線と線の関係が平行に近いほど0になり、垂直に近いほど1に近づく。外積の場合はその逆で「直交具合」と言える。
レースゲームなら車が壁にぶつかった時の車体のベクトル(線1)と壁のベクトル(線2)で内積をとって1に近いほど速度を落とす。1っていうことは壁に真正面からぶつかったことになるし、ゼロだとほぼ平行にあたって「擦っただけ」といえる。ちなみに英語では、外積とは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; }
内積は2つのベクトルのなす角度を求めることができるし、平面上に点があるかどうかも判定可能。外積はポリゴンの向き(法線ベクトル)や平面上の三角形と点の内外判定に利用できる。
一般的に1/60秒の時間を表す。テレビは1秒間に60枚のパラパラ漫画を再生することで動いているのはご承知の通り。秒間に60枚ということは1コマ1/60秒(約0.016秒)なので、見えないほど速い時間ではない。ゲームではキャラクタの動きを1/60秒毎にスライスしてプログラムされている。
スプライト表示の際、テクスチャの範囲外を指定してしまった時に、範囲外の表示をどのように表示するか、いくつかあるアドレッシングモードから選ぶことができる。
アルファとは半透明のこと。赤いセロファンと緑のセロファンを重ねて上から見れば黒っぽく見える。こんな感じで半透明を混ぜあわせるからアルファのブレンデイング。
0がスケスケ、100が不透明として、下地を50%の半透明度、上にかぶせるセロファンを50%の半透明みたいな感じで混ぜ合わせる。上にかぶせるセロファンの透明度が100%の場合、下の色は全く見えない。
計算としては、例えばRGBのr成分が100の時、上にかぶせる赤色(100)を50%で混ぜあわせると
100*0.5 + 100*0.5 = 100 となる。
ブレンドの仕方もいろいろある。ただ下の色と上の色を組み合わせる場合だと上の色を70%とした場合に下の色を30%とすることで合わせて100%の普通のブレンディングとなる。
しかし、70%の下地に対して、70%の色を加算合成すると、140%になる。現実的に100%以上の色にはならないので全部が白くなっていく。
よくファイル名で使われる「*.bmp」とかいう謎の記号が出てくるが、この米マークは知っての通り「アスタリスク」という。ファイル名に使われるアスタリスクは「ワイルドカード」と言って、「???」を表す。よくわからないだろうが「???.bmp」と考えればいい。bmpの拡張子を持ったファイル全てを表す。検索するときに便利。a*.bmpをすれば、頭がaで始まるbmpファイルを指定できる
ビデオカメラに関する汎用プログラミングライブラリ。
計算・・・計ったり数えたりすること
演算・・・法則にそって計算すること
演算は計算に含まれる。プログラマが決めた法則によって計算されるプログラムは全て演算。
XMLのパーサーとかJSONのパーサーという風に使う。難しく言うと構文解析器。構造をもったテキストのカッコとかを解釈してデータを取り出すためのプログラム。XMLデータはXMLパーサーを使わないと(作らないと)中のデータを正しく取り出せない。なぜならXMLには不要なカッコがたくさんテキストについているからだ。そいつらを構文解析してデータ化する(パースする)必要があるのだが、色々めんどくさい。
シングルバイト | 1バイト固定 ASCII文字 | char* |
ダブルバイト | 2バイト固定 Shift-JIS(漢字部位) | char* |
マルチバイト | 1~nバイトの可変 Shift-JIS | char* |
ワイド文字 | ユニコード UTF-8とか | wchar_t* |
WindowsAPIの変換関数
MultiByteToWideChar | Shift-JIS > UTF-8 | char* > wchar_t* |
WideCharToMultiByte | UTF-8 > Shift-JIS | wchar_t > char* |
古い標準関数はマルチバイトにしか対応しておらず、新しい関数はワイド文字が標準化してきている。
つまり、Shift-JISからUTF-8へ標準が移ってきているので、UTF-8に対応しきれていないC標準関数などが必然的に廃れていく。
一般的には機械語への翻訳方式の1つ。インタープリターやコンパイルに対しての方式の名前で実行直前にコンパイルする方式。Just - In - Timeの略。
インタープリターと違うところは実行する行に来て都度機械語に翻訳するのではなく、実行直前に全てをコンパイルするところ。
C言語などの事前に全てをコンパイルしておく方式との違いは、実行されるマシン上でマシン環境に合わせたコンパイルが行われるところ。また実行前に時間を食ってしまう最適化は行われない。
エミュレーターにおけるROMの解釈などは他のプラットフォーム用に書かれた機械語の塊(ROM)をJIT方式で翻訳している、といえる。