👊🏻 🏴󠁧󠁢󠁳󠁣󠁴󠁿 💥 クロスプラットフォームの3Dゲームエンジンを書いたように 👩🏿‍🎓 🧝🏾 🙌🏾

こんにちは、Habr！私たちの多くは、おそらく「自分でゲームを書いてみませんか」と思ったでしょう。今、私は「Open Tomb 」プロジェクトを実行しています。「Tomb Raider」の最初の5部でプレイするポータブルエンジンを作成する試みです。これはsourceforge.comで入手できます。しかし、私自身の経験からすると、これはゼロから作成されたものであり、この分野の知識はほとんどありません。今でも、多くの知識では不十分であり、より良いことやより正確に何かをするためのモチベーションが足りない場合もありますが、一歩一歩プロジェクトがどのように実現したかを説明する方が良いでしょう。

エンジンを書くようになったきっかけ

物語はかなり前に始まり、Vista 64で素晴らしいロジックパズル「プッシャー」をプレイしたかったという事実から始まりました。しかし、元のゲームは16ビットであり、開始を完全に拒否しました。 Cでクローンを書くことほど良いことはありませんでした（最初はより良い結果につながる最良のソリューションではないこともあります）。しばらくして、 SDL v1.2 + OpenGLプラットフォームでゲームを実装しました。

マップ転送の利便性のために、レベルエディターを追加し、64枚のカードすべてを手動で複製しました。しばらくして、「プッシャー」への関心が薄れ、私はすでに3dfxグラフィックスでトゥームレイダー 1を運転したいと思っていました。そして、多くの人がすでに推測しているように、これを行うための既存の解決策は（むしろ、主観的にさえ）私を本当に喜ばせず、ポートを探し始めました。有名なOpen raiderプロジェクトに加えて、何も見つかりませんでした。私はmingwコンパイラを使用してWindowsでビルドしたことで苦しんだことを今でも覚えています（開発環境、コード::ブロックまたはnetbeansのいずれかを覚えていません）。ビルド結果はまったく私を喜ばせませんでした：約1分間レベルをロードし、最後に黒い画面を表示しました。他の人のコードを選択し、その構造と関数の意味を理解する能力はありませんでした。「より良い」をまとめる試みは停止しました。ただし、オープンエンジンの少なくとも1つを手動でアセンブルするというアイデアを得ました。DieGNU Autotoolsの auto-configではなく、開発環境の自己アセンブルされたデザイナーからです。

したがって、モニターの後ろにかなりの時間を置いた後、一定量のマットなどを置いて、音のないQuake Tenebraeを組み立てました。しかし、彼は働いた！私は他の人のコードをよりよく理解し始め、最終的にコンパイラの組織の少なくとも何かを理解し始めました-それなしでは不可能です。その後、いくつかのマイナーな改善が行われ、いくつかのバグが修正され、サウンドが開始されましたが、プロジェクトはインターネットにアップロードされませんでした（それでも、特にダークプレースエンジンの存在を考慮すると、道徳的に廃止されました）。ただし、 Quake Tenebraeエンジンコードから、ゲーム全体の作業、個々のコンポーネント、およびメモリマネージャーがどのように編成されているかを学びました（非常に単純ではありますが、 realloc関数を追加しましたが、クラッシュすることなく機能しました）。

エンジンを書く

少し慣れると、エンジンをゼロから書き始めることにしました。楽しみと自己啓発のためだけに。エンジンの作成の基礎は次のとおりです。GCC-TDMv4.X.X + msysコンパイラーおよびNetbeans開発環境。ライブラリ： SDL v1.2 + OpenGL 実装された最初の機能は、スクリーンショットを撮り、*。bmpファイルに保存することで、この形式で動作するように自己記述ライブラリを使用していました。コマンド~~チート~~を入力し、テキストを表示するためのコンソールなしでどのエンジンができるかはおそらくないので、次に勉強したのはOpenGLウィンドウにテキストを表示し、 freetype 1 + gltt bunchを選択する方法でした。最初の認識可能なコマンドは終了コマンドであり、その後、フォントサイズ、行などで再生するコマンドです... 参考：文字列を解析し、トークンに順番に分割するためにQuake Iで使用されているコードが好きでした。

char *parse_token(char *data, char *token) { int c; int len; len = 0; token[0] = 0; if(!data) { return NULL; } // skip whitespace skipwhite: while((c = *data) <= ' ') { if(c == 0) return NULL; // end of file; data++; } // skip // comments if (c=='/' && data[1] == '/') { while (*data && *data != '\n') data++; goto skipwhite; } // handle quoted strings specially if (c == '\"') { data++; while (1) { c = *data++; if (c=='\"' || !c) { token[len] = 0; return data; } token[len] = c; len++; } } // parse single characters if (c=='{' || c=='}'|| c==')'|| c=='(' || c=='\'' || c==':') { token[len] = c; len++; token[len] = 0; return data+1; } // parse a regular word do { token[len] = c; data++; len++; c = *data; if (c=='{' || c=='}'|| c==')'|| c=='(' || c=='\'' || c==':') { break; } } while (c>32); token[len] = 0; return data; }

先に進む：スクリプトのサポートが必要になったとき、DOOM 3エンジンの例を使用してIDソフトウェアのようにエンジンを開発するアプローチを使用することにしました。これはHabré=でここで非常によく説明されました。翻訳とそれに興味深いコメントを書いた人）。この記事に感銘を受け、ゲーム内のスクリプト作成のニーズだけでなく、構成ファイルとコンソールコマンドの解析にもLUAをエンジンに実装することにしました（つまり、どこでも統一されたシステムが使用されています）。このアプローチは完全に成果を上げました。

3Dに移りましょう

研究所では、線形代数、行列変換、ベクトル、数値法が好きだったのは幸運でした。これらの基本がなければ、エンジンのプログラミングをゼロから始めるのは非常に無謀です（ただし、これらのセクションを例で研究するために特定の理論的知識ベースがなければ、これはほとんど現実的ではありません）。 A.ボレスコフの著書「OPENGLに基づいた3次元コンピューターゲームのグラフィックス」は、グラフィックスをマスターするのに大いに役立ちました。数学的装置、レンダラーのタイプ、エンジンの構造に慣れるために、私はそれを何度も読み直しました。シーンを構築する原理と種マトリックスと投影マトリックスの目的の概念がなければ、進歩は不可能です。インターネット上のいくつかの資料と単なる文献を研究した後、私はポータルレンダラーを実行することにしました。エンジンに最初に実装されたのは、自由に飛行するカメラと、互いにしか見えないいくつかのポータルでした。

ハードコードの後、3つの部屋のワイヤーフレームシーンが追加されました（さらに2つと廊下）。しかし、そのような原始的な世界を飛び回ることは本当に興味深いのでしょうか...そして、 Open Raiderのリソースレイザーを使用してレベルをレンダリングすることにしました。結果は私を喜ばせ、ここで少なくとも最初の部分で、トゥームレイダーをプレイするためのポートを作成する計画を実装することが最終的に決定されました。オブジェクトを空間に配置するために、OpenGLマトリックスを使用しました。これにより、オブジェクトのローカル座標系の基本ベクトルにアクセスし、1つのコマンドglMultMatrixf （変換）でオブジェクトの位置を設定し、1つのsetFromOpenGLMatrix （変換）コマンドでオブジェクトの方向を設定します少し後で。以下は、上記のリンクのOpenGLマトリックス構造の画像です。

エンジンの変更履歴とバックアップの可能性を維持するために、また自己開発のためだけに、水銀バージョン管理システムを使用することが決定されました。そのアプリケーションにより、コードの記述の進行状況を追跡できるだけでなく、結果をsourceforge.comにアップロードすることも可能になりました。実際のマップからのポータルに関する情報がエンジンに読み込まれ始めたとき、ポータルシステムの実装における膨大な数の欠陥がすぐに表面化したことに注意する必要があります。オブジェクトの消失やクラッシュの処理には多くの時間がかかりましたが、今でもポータルモジュールには重大な修正が必要だと思います。エンジンレンダラーは、カメラの位置と向きに応じて、部屋のポータルを通過し始め、表示されている部屋のみをリストに追加します。次に、レンダラーは、リストからルームとそのコンテンツを描画します。大規模なオープンスペースの場合、このアプローチが最も成功しているわけではないことは明らかですが、プロジェクトの目的には十分です。再帰的ルームトラバーサル関数の例を次に示します。

 ** * The reccursion algorithm: go through the rooms with portal - frustum occlusion test * @portal - we entered to the room through that portal * @frus - frustum that intersects the portal * @return number of added rooms */ int Render_ProcessRoom(struct portal_s *portal, struct frustum_s *frus) { int ret = 0, i; room_p room = portal->dest_room; //    room_p src_room = portal->current_room; //    portal_p p; //      - frustum_p gen_frus; //    if((src_room == NULL) || !src_room->active || (room == NULL) || !room->active) { return 0; } p = room->portals; for(i=0; i<room->portal_count; i++,p++) //      { if((p->dest_room->active) && (p->dest_room != src_room)) //      { gen_frus = Portal_FrustumIntersect(p, frus, &renderer); //  -  .    if(NULL != gen_frus) //        { ret++; Render_AddRoom(p->dest_room); Render_ProcessRoom(p, gen_frus); } } } return ret; }

骨格アニメーションモデル

そして、プロジェクトで最も骨の折れる作業の1つが始まりました。静的オブジェクトを使用した静的ルームのレンダリングは比較的簡単でしたが、アニメーション化された骨格モデルに関しては...最初に気付いたのは、 Open Raiderリソースローダーが骨格モデルに関するすべての必要な情報をロードしないことです。アニメーションのフレーム数が正しく決定されていないため、1つのアニメーションに複数のフレームが同時に含まれています。

これらの問題を解決しようとしている間に、私はトゥームレイダーレベルのフォーマットと、同時に独自のリソースローダーを備えたvtプロジェクトに関するさまざまなドキュメントを見つけました。このプロジェクトには、モデルアニメーションのロードフレームはありませんでしたが、より構造化されたコードが含まれていて、読みやすく、頭に浮かぶのに便利です。そこで、プロジェクトのローダーをvtに置き換えました。たとえば、オープンレイダーでは、トゥームレイダーの 5つの部分すべてに1つの長い関数がロードされ、多数のifとスイッチがゲームのバージョン番号によって切り替わります。これにより、コードの読み取りとエラーの検出が大幅に複雑になります。 vtには5つのモジュールがあり、それぞれがレベルの独自のバージョンを担当していたため、コードは読みやすく、変更は難しくありませんでした。

アニメーションの主な問題は、骨格モデルの骨の回転角度の抽出でした。実際には、スペースを節約するために、コーナーは2〜4バイト単位でバイトコードに格納されていました。最初の2バイトには、ここでどの軸の周りに1ターンがあるか、または3つのコーナー自体があるかどうかに関するフラグが含まれています。 3ターンの場合、フラグとコーナーは4バイトで格納され、1ターンの場合は2バイトのみが使用されます。さらに、すべてのモデル、アニメーション、およびフレームの角度は1つの配列に保存され、オフセットを計算する必要があります。さらに、モデルの個々のフレームのヘッダーはこのバイトコードに保存されたままであり、オフセットとの混乱が重要ですが、フレーム数が誤って読み込まれることを追加しました（後で、フレーム数が30 fpsの「補間」アニメーションに与えられることがわかりましたが、実際には、フレームは、1、1 / 2、1 / 3、1 / 4のファクターを持つfpsの「スナップショット」形式で保存できます。アニメーションフレームローダーの完了後、骨格モデルは裏返しにならず、歪んだポリゴンから混乱に変わりました！次に、ララを「復活」させる必要があります。以下は、骨格モデルを生成する関数のコードであり、デバッグ用のコードのスペルとコメントアウトされたセクションが保存されます。

 void GenSkeletalModel(struct world_s *world, size_t model_num, struct skeletal_model_s *model, class VT_Level *tr) { int i, j, k, l, l_start; tr_moveable_t *tr_moveable; tr_animation_t *tr_animation; uint32_t frame_offset, frame_step; uint16_t *frame, temp1, temp2; ///@FIXME: "frame" set, but not used float ang; btScalar rot[3]; bone_tag_p bone_tag; bone_frame_p bone_frame; mesh_tree_tag_p tree_tag; animation_frame_p anim; tr_moveable = &tr->moveables[model_num]; // original tr structure model->collision_map = (uint16_t*)malloc(model->mesh_count * sizeof(uint16_t)); model->collision_map_size = model->mesh_count; for(i=0;i<model->mesh_count;i++) { model->collision_map[i] = i; } model->mesh_tree = (mesh_tree_tag_p)malloc(model->mesh_count * sizeof(mesh_tree_tag_t)); tree_tag = model->mesh_tree; tree_tag->mesh2 = NULL; for(k=0;k<model->mesh_count;k++,tree_tag++) { tree_tag->mesh = model->mesh_offset + k; tree_tag->mesh2 = NULL; tree_tag->flag = 0x00; vec3_set_zero(tree_tag->offset); if(k == 0) { tree_tag->flag = 0x02; vec3_set_zero(tree_tag->offset); } else { uint32_t *tr_mesh_tree = tr->mesh_tree_data + tr_moveable->mesh_tree_index + (k-1)*4; tree_tag->flag = tr_mesh_tree[0]; tree_tag->offset[0] = (float)((int32_t)tr_mesh_tree[1]); tree_tag->offset[1] = (float)((int32_t)tr_mesh_tree[3]); tree_tag->offset[2] =-(float)((int32_t)tr_mesh_tree[2]); } } /* * ================= now, animation loading ======================== */ if(tr_moveable->animation_index < 0 || tr_moveable->animation_index >= tr->animations_count) { /* * model has no start offset and any animation */ model->animation_count = 1; model->animations = (animation_frame_p)malloc(sizeof(animation_frame_t)); model->animations->frames_count = 1; model->animations->frames = (bone_frame_p)malloc(model->animations->frames_count * sizeof(bone_frame_t)); bone_frame = model->animations->frames; model->animations->id = 0; model->animations->next_anim = NULL; model->animations->next_frame = 0; model->animations->state_change = NULL; model->animations->state_change_count = 0; model->animations->original_frame_rate = 1; bone_frame->bone_tag_count = model->mesh_count; bone_frame->bone_tags = (bone_tag_p)malloc(bone_frame->bone_tag_count * sizeof(bone_tag_t)); vec3_set_zero(bone_frame->pos); vec3_set_zero(bone_frame->move); bone_frame->v_Horizontal = 0.0; bone_frame->v_Vertical = 0.0; bone_frame->command = 0x00; for(k=0;k<bone_frame->bone_tag_count;k++) { tree_tag = model->mesh_tree + k; bone_tag = bone_frame->bone_tags + k; rot[0] = 0.0; rot[1] = 0.0; rot[2] = 0.0; vec4_SetTRRotations(bone_tag->qrotate, rot); vec3_copy(bone_tag->offset, tree_tag->offset); } return; } //Sys_DebugLog(LOG_FILENAME, "model = %d, anims = %d", tr_moveable->object_id, GetNumAnimationsForMoveable(tr, model_num)); model->animation_count = GetNumAnimationsForMoveable(tr, model_num); if(model->animation_count <= 0) { /* * the animation count must be >= 1 */ model->animation_count = 1; } /* * Ok, let us calculate animations; * there is no difficult: * - first 9 words are bounding box and frame offset coordinates. * - 10's word is a rotations count, must be equal to number of meshes in model. * BUT! only in TR1. In TR2 - TR5 after first 9 words begins next section. * - in the next follows rotation's data. one word - one rotation, if rotation is one-axis (one angle). * two words in 3-axis rotations (3 angles). angles are calculated with bit mask. */ model->animations = (animation_frame_p)malloc(model->animation_count * sizeof(animation_frame_t)); anim = model->animations; for(i=0;i<model->animation_count;i++,anim++) { tr_animation = &tr->animations[tr_moveable->animation_index+i]; frame_offset = tr_animation->frame_offset / 2; l_start = 0x09; if(tr->game_version == TR_I || tr->game_version == TR_I_DEMO || tr->game_version == TR_I_UB) { l_start = 0x0A; } frame_step = tr_animation->frame_size; //Sys_DebugLog(LOG_FILENAME, "frame_step = %d", frame_step); anim->id = i; anim->next_anim = NULL; anim->next_frame = 0; anim->original_frame_rate = tr_animation->frame_rate; anim->accel_hi = tr_animation->accel_hi; anim->accel_hi2 = tr_animation->accel_hi2; anim->accel_lo = tr_animation->accel_lo; anim->accel_lo2 = tr_animation->accel_lo2; anim->speed = tr_animation->speed; anim->speed2 = tr_animation->speed2; anim->anim_command = tr_animation->anim_command; anim->num_anim_commands = tr_animation->num_anim_commands; anim->state_id = tr_animation->state_id; anim->unknown = tr_animation->unknown; anim->unknown2 = tr_animation->unknown2; anim->frames_count = GetNumFramesForAnimation(tr, tr_moveable->animation_index+i); //Sys_DebugLog(LOG_FILENAME, "Anim[%d], %d", tr_moveable->animation_index, GetNumFramesForAnimation(tr, tr_moveable->animation_index)); // Parse AnimCommands // Max. amount of AnimCommands is 255, larger numbers are considered as 0. // See http://evpopov.com/dl/TR4format.html#Animations for details. if( (anim->num_anim_commands > 0) && (anim->num_anim_commands <= 255) ) { // Calculate current animation anim command block offset. int16_t *pointer = world->anim_commands + anim->anim_command; for(uint32_t count = 0; count < anim->num_anim_commands; count++, pointer++) { switch(*pointer) { case TR_ANIMCOMMAND_PLAYEFFECT: case TR_ANIMCOMMAND_PLAYSOUND: // Recalculate absolute frame number to relative. ///@FIXED: was unpredictable behavior. *(pointer + 1) -= tr_animation->frame_start; pointer += 2; break; case TR_ANIMCOMMAND_SETPOSITION: // Parse through 3 operands. pointer += 3; break; case TR_ANIMCOMMAND_JUMPDISTANCE: // Parse through 2 operands. pointer += 2; break; default: // All other commands have no operands. break; } } } if(anim->frames_count <= 0) { /* * number of animations must be >= 1, because frame contains base model offset */ anim->frames_count = 1; } anim->frames = (bone_frame_p)malloc(anim->frames_count * sizeof(bone_frame_t)); /* * let us begin to load animations */ bone_frame = anim->frames; frame = tr->frame_data + frame_offset; for(j=0;j<anim->frames_count;j++,bone_frame++,frame_offset+=frame_step) { frame = tr->frame_data + frame_offset; bone_frame->bone_tag_count = model->mesh_count; bone_frame->bone_tags = (bone_tag_p)malloc(model->mesh_count * sizeof(bone_tag_t)); vec3_set_zero(bone_frame->pos); vec3_set_zero(bone_frame->move); bone_frame->v_Horizontal = 0.0; bone_frame->v_Vertical = 0.0; bone_frame->command = 0x00; GetBFrameBB_Pos(tr, frame_offset, bone_frame); if(frame_offset < 0 || frame_offset >= tr->frame_data_size) { //Con_Printf("Bad frame offset"); for(k=0;k<bone_frame->bone_tag_count;k++) { tree_tag = model->mesh_tree + k; bone_tag = bone_frame->bone_tags + k; rot[0] = 0.0; rot[1] = 0.0; rot[2] = 0.0; vec4_SetTRRotations(bone_tag->qrotate, rot); vec3_copy(bone_tag->offset, tree_tag->offset); } } else { l = l_start; for(k=0;k<bone_frame->bone_tag_count;k++) { tree_tag = model->mesh_tree + k; bone_tag = bone_frame->bone_tags + k; rot[0] = 0.0; rot[1] = 0.0; rot[2] = 0.0; vec4_SetTRRotations(bone_tag->qrotate, rot); vec3_copy(bone_tag->offset, tree_tag->offset); switch(tr->game_version) { case TR_I: /* TR_I */ case TR_I_UB: case TR_I_DEMO: temp2 = tr->frame_data[frame_offset + l]; l ++; temp1 = tr->frame_data[frame_offset + l]; l ++; rot[0] = (float)((temp1 & 0x3ff0) >> 4); rot[2] =-(float)(((temp1 & 0x000f) << 6) | ((temp2 & 0xfc00) >> 10)); rot[1] = (float)(temp2 & 0x03ff); rot[0] *= 360.0 / 1024.0; rot[1] *= 360.0 / 1024.0; rot[2] *= 360.0 / 1024.0; vec4_SetTRRotations(bone_tag->qrotate, rot); break; default: /* TR_II + */ temp1 = tr->frame_data[frame_offset + l]; l ++; if(tr->game_version >= TR_IV) { ang = (float)(temp1 & 0x0fff); ang *= 360.0 / 4096.0; } else { ang = (float)(temp1 & 0x03ff); ang *= 360.0 / 1024.0; } switch (temp1 & 0xc000) { case 0x4000: // x only rot[0] = ang; rot[1] = 0; rot[2] = 0; vec4_SetTRRotations(bone_tag->qrotate, rot); break; case 0x8000: // y only rot[0] = 0; rot[1] = 0; rot[2] =-ang; vec4_SetTRRotations(bone_tag->qrotate, rot); break; case 0xc000: // z only rot[0] = 0; rot[1] = ang; rot[2] = 0; vec4_SetTRRotations(bone_tag->qrotate, rot); break; default: // all three temp2 = tr->frame_data[frame_offset + l]; rot[0] = (float)((temp1 & 0x3ff0) >> 4); rot[2] =-(float)(((temp1 & 0x000f) << 6) | ((temp2 & 0xfc00) >> 10)); rot[1] = (float)(temp2 & 0x03ff); rot[0] *= 360.0 / 1024.0; rot[1] *= 360.0 / 1024.0; rot[2] *= 360.0 / 1024.0; vec4_SetTRRotations(bone_tag->qrotate, rot); l ++; break; }; break; }; } } } } /* * Animations interpolation to 1/30 sec like in original. Needed for correct state change works. */ SkeletalModel_InterpolateFrames(model); GenerateAnimCommandsTransform(model); /* * state change's loading */ #if LOG_ANIM_DISPATCHES if(model->animation_count > 1) { Sys_DebugLog(LOG_FILENAME, "MODEL[%d], anims = %d", model_num, model->animation_count); } #endif anim = model->animations; for(i=0;i<model->animation_count;i++,anim++) { anim->state_change_count = 0; anim->state_change = NULL; tr_animation = &tr->animations[tr_moveable->animation_index+i]; j = (int)tr_animation->next_animation - (int)tr_moveable->animation_index; j &= 0x7fff; if(j >= 0 && j < model->animation_count) { anim->next_anim = model->animations + j; anim->next_frame = tr_animation->next_frame - tr->animations[tr_animation->next_animation].frame_start; anim->next_frame %= anim->next_anim->frames_count; if(anim->next_frame < 0) { anim->next_frame = 0; } #if LOG_ANIM_DISPATCHES Sys_DebugLog(LOG_FILENAME, "ANIM[%d], next_anim = %d, next_frame = %d", i, anim->next_anim->id, anim->next_frame); #endif } else { anim->next_anim = NULL; anim->next_frame = 0; } anim->state_change_count = 0; anim->state_change = NULL; if((tr_animation->num_state_changes > 0) && (model->animation_count > 1)) { state_change_p sch_p; #if LOG_ANIM_DISPATCHES Sys_DebugLog(LOG_FILENAME, "ANIM[%d], next_anim = %d, next_frame = %d", i, (anim->next_anim)?(anim->next_anim->id):(-1), anim->next_frame); #endif anim->state_change_count = tr_animation->num_state_changes; sch_p = anim->state_change = (state_change_p)malloc(tr_animation->num_state_changes * sizeof(state_change_t)); for(j=0;j<tr_animation->num_state_changes;j++,sch_p++) { tr_state_change_t *tr_sch; tr_sch = &tr->state_changes[j+tr_animation->state_change_offset]; sch_p->id = tr_sch->state_id; sch_p->anim_dispath = NULL; sch_p->anim_dispath_count = 0; for(l=0;l<tr_sch->num_anim_dispatches;l++) { tr_anim_dispatch_t *tr_adisp = &tr->anim_dispatches[tr_sch->anim_dispatch+l]; int next_anim = tr_adisp->next_animation & 0x7fff; int next_anim_ind = next_anim - (tr_moveable->animation_index & 0x7fff); if((next_anim_ind >= 0) &&(next_anim_ind < model->animation_count)) { sch_p->anim_dispath_count++; sch_p->anim_dispath = (anim_dispath_p)realloc(sch_p->anim_dispath, sch_p->anim_dispath_count * sizeof(anim_dispath_t)); anim_dispath_p adsp = sch_p->anim_dispath + sch_p->anim_dispath_count - 1; int next_frames_count = model->animations[next_anim - tr_moveable->animation_index].frames_count; int next_frame = tr_adisp->next_frame - tr->animations[next_anim].frame_start; int low = tr_adisp->low - tr_animation->frame_start; int high = tr_adisp->high - tr_animation->frame_start; adsp->frame_low = low % anim->frames_count; adsp->frame_high = (high - 1) % anim->frames_count; adsp->next_anim = next_anim - tr_moveable->animation_index; adsp->next_frame = next_frame % next_frames_count; #if LOG_ANIM_DISPATCHES Sys_DebugLog(LOG_FILENAME, "anim_disp[%d], frames_count = %d: interval[%d.. %d], next_anim = %d, next_frame = %d", l, anim->frames_count, adsp->frame_low, adsp->frame_high, adsp->next_anim, adsp->next_frame); #endif } } } } } }

おでかけ

骨格モデルが機能し始めたとき、物理学の存在を必要とするレベリングと「復活」に進むことがすでに可能でした。そもそも、トピックに精通し、既成の製品の選択により徹底的にアプローチするために、独自の物理エンジンを作成することが決定されました。キャラクターコントローラーを作成するために最初に必要なことは、高さを決定することです。最初に、（重心アルゴリズムに基づいて）三角形と光線の交差を決定する関数が記述されました。その後、移動セグメント、三角形と球、三角形と三角形の交点を決定するなどの基本的な方法が追加されました。このアプローチは、インパルスベースの物理エンジンに固有の、いわゆる「トンネル効果」（高速のため、高速のオブジェクトが衝突することなく互いに飛行できる場合）の出現の可能性を排除することに注意する必要があります。

そのため、ララはあらゆるサイズのステップをすべて通過しても、レベルを駆け抜けますが、マップから脱落することはありません！プロジェクトがそのような状態にあったとき、アナトリー・ルムテは、少なくとも誰かがトゥームレイダーの最初の部分に興味を持っているのはクールだと私に書いた。このようにして、プロジェクトへの関心が再び現れ始めたおかげで、通信が始まりました。 tombraiderforums.comに登録した後（Anatolyは、 Tomb raiderの第4部のエンジンを改善する彼のプロジェクトで、かなり長い間そこにいました）。彼のおかげで、私のエンジンとコードの多くの改善に関するトピックがこのフォーラムに登場しました：サウンドマネージャー、状態制御システムの変更（以前はアニメーション番号による切り替えがあり、現在は状態番号による）。プロジェクトに興味のある人々の存在は、プロジェクトを開発する動機付けになります。

物理学+レンダラー最適化

物理学を使用し、最適化が不十分であっても、fpsはいくつかの場所で低下し始めました。さまざまなオープンソースの物理エンジンを長い間選ぶことで、弾丸が選ばれました。最初にしたことは、部屋が交差する場合に衝突フィルターを追加することでした。実際には、元のレベルの設計では、1つの場所で2つ以上の完全に異なる部屋の交差が許可されますが、1つの部屋のオブジェクトは別の部屋のオブジェクトに影響を与えません。レンダリングと同様。現在、私はキャラクターのコントローラーに思いをはせようとしています：壁を通過する可能性を排除し（壁に点を接する多くのアニメーションで発生します）、壁や天井にクリッピングが発生した場合のキャラクターの反応と動作を完了します。

OpenGLに戻ります。最初、エンジンでは、 glVertex3fv （...）などを使用してポリゴンが描画されました。このアプローチのパフォーマンスとエンジンの速度について1つ言えることがあります。それはありません。そのため、 VBO （頂点バッファーオブジェクト）に関連する部分を調べた後、最適化を行い、ポリゴンの頂点のデータをビデオメモリにできるだけ格納し、一度にメッシュを描画し始めました。速度が著しく向上しました。ただし、1つのメッシュテクスチャが異なるピクセル配列にある可能性があるため、OpenGLテクスチャの切り替えは必要以上に頻繁に行われ、多くの異なるオブジェクトのテクスチャをピクセルの1つの配列に保存できるという事実により、アンチエイリアシングをオンにすると「アーティファクト」が作成されました。 tombraiderforums.comの Cochraneはレンダラーの最適化を引き受け、テクスチャ間の境界線を持つテクスチャアトラスを作成しました。この革新により、すべてのレベルのテクスチャが1〜2個のOpenGLテクスチャに保存され、スムージングによって「アーティファクト」が表示されることはありません。さらに、彼はMacOSに移植しました。

エンジンに何をどのように取り組むかのアイデアがなかったとき、コードのエラーを探し、その構造を修正し、接続されたライブラリを変更しました。したがって、「再配置」はSDL1からSDL2に、 freetype1 + glttからfreetype2 + ftglに実行されました。同様に、 slerp球面補間を使用して、アニメーションにアンチエイリアスを追加するというアイデアを思いつきました。ここで追加したいことは、特に「アーチ」（asin、acos、atanなど）に関しては、数学アルゴリズムに注意してください。サインを失うと、スケルトンが歪んでねじれたキラーフレームが多くなります。 bulletのソースコードでslerpの実装を確認することをお勧めします。アンチエイリアスを追加した後、滑らかでないアニメーションを見ることができなくなりました。さらに、 Tomb raiderですが、サウンドをロードして再生する必要があり、致命的な沈黙の中でレベルを実行することはあまりありません。

音を追加する

サウンドを使用するには、 SDLAudio + SDLMixerを使用するだけでは完全に不十分であり、オーディオストリーム変換アルゴリズムに入り、バイクを作成してエフェクトを作成することは悪い考えです。 Anatolyと相談した後、 OpenALを使用することが決定されました。できるだけ多くのプラットフォーム固有のコードがSDLに転送されるという事実に導かれたので、 OpenALの SDL_backendを書くことほど良いものは思いつきませんでした。しかし、それは機能し、ツールをエンジンに追加し、アナトリーは必要に応じて、必要に応じて、そして必要な効果で全員にプレイさせました。

そして今、ゲーム世界のあらゆる種類のレバー、トラップ、その他のトリガーを復活させる時が来ました。実際、ここでの開発はロジックに従って行われました。何かを実装する必要があります。これに必要なツール、それらの実装方法。スクリプトに使用される主な機能は、数値IDでオブジェクトへのポインターを取得することです。これにより、LUA関数はすべての必要なオブジェクトを処理できます。オブジェクトを動的に追加および削除し、IDでオブジェクトにすばやくアクセスするために、赤黒木を使用しました。理論的には、テーブルのハッシュを使用できますが、個人的な好みはおそらくここでうまくいきました。

その結果、スクリプトシステムにより、オブジェクトとアニメーションを使用したほぼすべての操作の実行、タスク（およびそれらに基づくタイマー）の作成、オブジェクトの選択、うなり声とボタンの押下、ドアの開閉などが可能になりました。tombraiderforums.comコミュニティの人々の努力のおかげで、あるレベルから別のレベルへの移動、必要なスクリプトとスクリーンセーバーのロード、光源に関する情報のロード、OS Lunuxでビルドするための頂点カラー調整とcmakeスクリプトに基づくシンプルなライトマップの実装を担当するgameflow_managerが追加されました。

あとがき

最後に、サードパーティのリソースを使用すると、テストが簡単になり、コンテンツの作成に負担をかける必要がありませんが、これによりエンジンのアーキテクチャに制限が課されるか、起動時にフォーマットを変換してひどい松葉杖を作らないようにする必要があることに注意してくださいゲームエンジン。そして、オリジナルのトゥームレイダーには多くの松葉杖があります。プロジェクトの

今後の計画は単純です。1）既存のバグ、特に物理学のバグを修正し、キャラクターコントローラーの機能を拡張します。2）マップ上の敵を「復活」させ、AIと武器を追加します。3）メッシュを切り替えるための骨格モデルのアニメーション管理システムを拡張します。

4）スクリプトシステムの機能を拡張し、キーレベルのスクリプトを作成して、通常のゲームを体験できるようにします。

5）ゲーム内のグラフィックスを改善し、効果を追加しますが、ここではより資格のあるOpenGLプログラマーの助けを期待しています。

最後に、エンジンの例を含むいくつかのビデオ：

ご清聴ありがとうございました！

クロスプラットフォームの3Dゲームエンジンを書いたように