コアタイプ¶
Godot には、そのコアを構成する豊富なクラスとテンプレートのセットがあり、すべてがその上に構築されています。
このリファレンスでは、理解を深めるためにそれらをリストしようとします。
定義¶
Godot uses the standard C99 datatypes, such as uint8_t,
uint32_t, int64_t, etc. which are nowadays supported by every
compiler. Reinventing the wheel for those is not fun, as it makes code
more difficult to read.
一般に、大きな構造体や配列を使用しない限り、特定のタスクで最も効率的なデータ型を使用するようには注意が必要です。 int は、必要な場合を除き、ほとんどのコードで使用されます。これは、今日ではすべてのデバイスが少なくとも32ビットバスを持っており、1サイクルでそのような操作を行うことができるので行われます。コードも読みやすくなります。
ファイルまたはメモリサイズの場合は、 size_t が使用され、64ビットであることが保証されます。
Unicode文字の場合、多くのアーキテクチャには4バイトの長いwchar_tがあり、2バイトが必要な場合があるため、wchar_tの代わりにCharTypeが使用されます。ただし、デフォルトでは、これは強制されておらず、CharTypeはwchar_tに直接マップされます。
リファレンス:¶
メモリモデル¶
PCは素晴らしいアーキテクチャです。多くの場合、コンピューターにはギガバイトのRAM、テラバイトのストレージ、ギガヘルツのCPUがあり、アプリケーションがさらにリソースを必要とすると、OSは非アクティブなリソースをスワップアウトします。その他のアーキテクチャ(モバイルやコンソールなど)は、一般的にもっと制限されています。
最も一般的なメモリモデルはヒープです。ヒープは、アプリケーションがメモリの領域を要求し、基盤となるOSがそれをどこかに適合させて返すことを試みます。これは、多くの場合、最適に機能し、柔軟性がありますが、時間が経つと乱用されると、セグメンテーションにつながる可能性があります。
セグメンテーションでは、ほとんどの一般的な割り当てには小さすぎるホールがゆっくりと作成されるため、メモリが浪費されます。ヒープとセグメンテーションについては多くの文献があるため、ここではこのトピックについては詳しく説明しません。最近のオペレーティング・システムはページ・メモリーを使用するため、セグメンテーションの問題は緩和されますが、解決されません。
ただし、多くの調査とテストでは、十分なメモリがある場合、最大ヒープサイズと未使用のメモリの割合に比例して最大割り当てサイズが所定のしきい値を下回っていれば、時間が経過してもセグメンテーションは一定のままで、問題にならないことが示されています。つまり、メモリの10〜20％を空けて、小さな割り当てですべて実行すれば大丈夫です。
Godotは、動的に割り当てることができるすべてのオブジェクトが小さいことを要求します(せいぜい数KB未満)。しかし、割り当てが大きすぎるとどうなりますか(画像やメッシュジオメトリ、大きな配列など)？この場合、Godotには動的メモリプールを使用するオプションがあります。このメモリにアクセスするにはロックする必要があり、割り当てがメモリ不足になると、プールは必要に応じて再配置および圧縮されます。ゲームのニーズに応じて、プログラマは動的メモリプールサイズを構成できます。
メモリの割り当て¶
Godot には、特にデバッグ中にゲーム内のメモリ使用量を追跡するための多くのツールがあります。このため、通常のCおよびC++ライブラリ呼び出しは使用しないでください。代わりに、他にもいくつか用意されています。
Cスタイルの割り当てでは、Godotはいくつかのマクロを提供します:
memalloc()
memrealloc()
memfree()
これらは、標準Cライブラリに含まれる通常のmalloc、realloc、freeと同等です。
C++スタイルの割り当てでは、特別なマクロが提供されます:
memnew( Class / Class(args) )
memdelete( instance )
memnew_arr( Class , amount )
memdelete_arr( pointer to array )
これは、new、delete、new[]およびdelete[]と同じです。
memnew/memdeleteはまた、小さなC++マジックを使用し、オブジェクトが作成された直後に、そして削除される直前にオブジェクトに通知します。
動的メモリの場合、PoolVector<> テンプレートが提供されます。PoolVectorは標準のvectorクラスであり、C++標準ライブラリのvectorに非常に似ています。 PoolVectorバッファーを作成するには、これを使用します:
PoolVector<int> data;
PoolVectorは、[]演算子を使用してアクセスできます。このためのヘルパーがいくつかあります:
PoolVector<int>::Read r = data.read()
int someint = r[4]
PoolVector<int>::Write w = data.write()
w[4] = 22;
これらの操作により、PoolVectorからの高速な読み取り/書き込みが可能になり、範囲外になるまでロックを保持します。ただし、大量のアクセスに対してはread()とwrite()が遅すぎるため、PoolVectorは小さな動的メモリの操作に使用する必要があります。
リファレンス:¶
コンテナ¶
Godot には、一般的なコンテナのセットも用意されています:
Vector
List
Set
Map
C++のテンプレートは多くの場合インライン化され、デバッグシンボルとコードの両方でバイナリサイズがかなり大きくなるため、これらはシンプルで、可能な限り最小限にすることを目指しています。List、Set、およびMapは、次のようにポインターを使用して反復できます:
for(List<int>::Element *E=somelist.front();E;E=E->next()) {
print_line(E->get()); // print the element
}
Vector<> クラスには、いくつかの優れた機能もあります:
書き込み時にコピーするので、変更しない限りコピーを作成する方が安価です。
参照カウンタでアトミック操作を使用して、マルチスレッドをサポートします。
リファレンス:¶
文字列¶
GodotはStringクラスも提供しています。このクラスには、膨大な量の機能、すべての関数(類似ケース操作)での完全なUnicodeサポート、utf8解析/抽出、そして変換と視覚化のためのヘルパーがあります。
リファレンス:¶
StringName¶
StringNameはStringに似ていますが、一意です。文字列からStringNameを作成すると、すべての等しい文字列に対して一意の内部ポインターが作成されます。文字列を比較することは基本的にポインタを比較するため、StringNameは識別子として文字列を使用するのに便利です。
StringName(特に新しい文字列)の作成は遅くなりますが、比較は高速です。
リファレンス:¶
算術型¶
core/mathディレクトリには、いくつかの線形数学タイプがあります。
リファレンス:¶
NodePath¶
これは、シーンツリーにパスを格納し、高速に参照するために使用される特別なデータ型です。
リファレンス:¶
RID¶
RIDはリソースIDです。 サーバーはこれらを使用して、保存されているデータを参照します。 RIDは不透明です。つまり、RIDが参照するデータに直接アクセスすることはできません。 RIDは、さまざまな種類の参照データに対しても一意です。