Потихоньку завершаю работу с низкоуровневым рендером и пора подумать о организации сцены. Первоначально я горел идеей компонентной системы, но поработав в юнити в ней разочаровался. Идея компонентной системы в том что любой объект может состоять из разного числа компонентов. Но тут возникает первая проблема - идентификация этих компонент. Как узнать что вот этот компонент - колайдер, а вон тот - рендер меш? Вообще в идеальном вакууме, я думаю, компонентная система и не подразумевала что кто-то будет пытаться опознавать компоненты.

Читать | Комментарии [60]

Потихоньку завершаю работу с низкоуровневым рендером и пора подумать о организации сцены. Первоначально я горел идеей компонентной системы, но поработав в юнити в ней разочаровался. Идея компонентной системы в том что любой объект может состоять из разного числа компонентов. Но тут возникает первая проблема - идентификация этих компонент. Как узнать что вот этот компонент - колайдер, а вон тот - рендер меш? Вообще в идеальном вакууме, я думаю, компонентная система и не подразумевала что кто-то будет пытаться опознавать компоненты. Но в реальности это выглядит как-то так (С#)

Collider col = gameObject.GetComponent<Collider>();

или так

Collider col = gameObject.GetComponent("Collider");

Второй вариант ближе к C++... Но искать по имени (да даже если по хешу)... А если одинаковых компонентов несколько? Вообщем это не то что хорошо для реалтайма.

После этого я заметил еще одно свойство с которым столкнулся в юнити. Хоть по идее можно на объект вешать несколько компонентов, но есть уникальные, которые могут быть только в единственном числе:
Transform - этот компонент вообще должен быть у всех объектов (тут кстати уже обсуждали  ранее эту проблему)
Collider - в юнити невозможно добавить два колайдера (попытка через редактор удалит старый, попытка через код приведет к error)
MeshRender - их вроде как можно несколько, но реально ли это вам нужно? Так что тоже всегда по одному на объект
Остальные компоненты - в юнити есть много компонент которые существуют в единственном числе.

А чего же тогда много? Скриптовых компонент - их может быть куча на каждом объекте.

И тут я подхожу к финальной мысли - к той системе, которую я хочу получить.

Есть GameObject, и у него есть свойства

class GameObject
{
     Transform
     Collider*
     MeshRender*

     list<Script*>
};

У каждого GO есть свойство Transform которое определяет его расположение в мире
Еще у них есть несколько указателей на свойства (Collider, MeshRender). они могут быть нулевыми - а значит у данного объекта их нет, то есть не все GO нуждаются в колайдере, и даже есть возможность создать GO которые не будут рисоваться на экран. Свойств этих будет много. Но любой GO не обязан содержать их все. Сейчас вы спросите - а как же возможность добавлять новые свойства? А вот приведите мне такие свойства которые пользователь захочет добавить к ГО, а то у меня идей нет:)
И в конце есть список скриптов (возможно так будут сделаны и еще несколько вещей, например материалы). То есть их может быть много, и именно ими пользователь будет задавать остальные нужные ему свойства.

Таким образом я решу проблему поиска компонентов. Если мне надо будет колайдер, то я напишу так:

Collider *col = gameObject->GetCollider();
if (col)
{
}

Кстати, в юнити это тоже есть - у GO есть несколько сохраненных компонент которые можно использовать примерно также:

Как видите, они тоже могут быть нулевыми как у меня:) Но у меня это будет более явно

Вообщем я просто взял лучшее (на мой взгляд) из компонентной системы и классической системы энтити и смешал

Это по GameObject.

Теперь про сцену
У меня будет World, это класс полностью хранящий все происходящее. Он будет содержать сцены (Scene). Каждая сцена равна сцене из юнити. В любой момент времени может быть только одна сцена... Но их можно смешивать (то есть из двух сцен создать одну, вообщем тоже идея из юнити). На сцене может быть любое число ГО. Также на сцене есть одна камера, потому что я не понимаю этой фичи в юнити с возможностью создать сцену без камеры (и получить черный экран) или создать несколько го с камерами. так что у меня основная камера будет всегда.
Го могут строится иерархию по принципу родитель - ребенок как в юнити, потому что это мне тоже понравилось. Корневого Го не будет. Каждый Го является корнем, и может содержать детей, но может и не содержать.

Ссылка | Комментарии [60]

Гы, в связи с тем что меня вообщем тоже устраивает unity3d, и в ближайшее время я собираюсь проекты пилить на нем, а еще потому что от сапфира я устал, я решил начать новый движок

Но теперь не будет никаких глупых целей и самообмана. Мне просто нравится писать движки, поэтому я буду писать движок в свое удовольствие, только ради движка и самого процесса.

Новый движок я назвал аметистом (Amethyst Engine):) хотел назвать ониксом, но это имя занято юбисофтом.

В отличие от сапфира, я буду теперь более открыто вести разработку, то есть описывать весь процесс (но кратко, ибо время) создания от самого начала. для чего? just for lulz, конечно же. Ну и еще потому что мне в свое время такого не хватало, по началу тупо не понятно с чего начать

Уже есть де записи
http://zeswarchief.blogspot.ru/2013/09/amethyst-engine.html
http://zeswarchief.blogspot.ru/2013/09/amethyst-engine-02.html

Остальные в коментариях

Вообще думал сюда их постить, но если я буду так писать каждый день здесь, меня чего доброго еще забанят, ибо полезной инфы не так уж и много:)
Лучше я буду аппать эту тему, как делал с уроками по DX 11

p.s. если вы спросите что будет теперь с уроками DX 11, то отвечу, наверное пока ничего, так как основную часть я уже рассмотрел, там пошли более сложные темы, для которых у меня тупо не хватает теоретических знаний чтобы толково объяснять, так что вернусь к ним когда чуток еще прокачаюсь в теории.

p.s.2 это не значит что я все пишу с нуля, Core и Math а также еще кой-какая часть кода будут взяты из сапфира

Ссылка | Комментарии [60]

Сидел я тут, размышлял... Недавно в моем движке объявился OGL (теперь у меня два GAPI - DX11 и OGL). Сделал я классически, через виртуальные функции... Но я любитель глупых оптимизаций, поэтому захотелось избавиться от виртуальных функций. Но и делать две разные версии движка не охота, слишком долго собирается. И тут мне пришло простое решение - сделать три вида сборки - GAPI специфичное и мультирендер. Мультирендер позволит на лету менять DX 11 на OGL. Но ведь это не везде а точнее нигде не нужно. Поэтому движок можно будет собрать под отдельный GAPI.

В примере три дефайна - MULTI (мультирендер), OGL и DX11.

Render.h

#ifdef MULTI
class Render
#else
template<class T>
class TRender
#endif
{
public:
#ifdef MULTI
  virtual void Run() = 0;
#else
  void Run()
  {
    m_render->Run();
  }
#endif
private:
#ifndef MULTI
    T *m_render;
#endif
};

#ifdef DX11
typedef TRender<DX11> Render;
#elif OGL
typedef TRender<OGL> Render;
#endif

DX11.h

#ifdef MULTI
class MyFoo : public Foo
#else
class MyFoo
#endif
{
public:
  void Run();
}

Один минус - код страшненький.

Класс Render можно переписать и по другому:

#ifdef MULTI
class Render
#elif DX11
class Render : public DX11
#elif OGL
class Render : public OGL
#endif
{
public:
#ifdef MULTI
  virtual void Run() = 0;
#endif
};

Так наверное даже лучше, нет лишних функций и экономия на целых 4 байта (sic), хотя теперь рендер должен знать о своим потомках (но с другой стороны, сколько их там кроме OGL и DX?). да и не совсем привычно (в одной сборке DX11 и OGL потомки Render, в другой Render потомок DX11 или OGL)

Пишу здесь, так как раньше не смог до такого додуматься:) И как раз проверю, влияют ли виртуальные методы на хоть что-то.

Ссылка | Комментарии [51]

Factory Method (Фабричный метод)

Так вот он какой - виртуальный конструктор:)

На основе этого паттерна делается Abstract Factory.

Далее я рассмотрю 2 варианта реализации паттерна

Обобщенный конструктор

#include <vector>
#include <iostream>

using namespace std;

enum Warrior_ID { Infantryman_ID=0, Archer_ID };

// Иерархия классов игровых персонажей
class Warrior
{
public:
  virtual void info() = 0;     
  virtual ~Warrior() {}
  // Параметризированный статический фабричный метод
  static Warrior* createWarrior( Warrior_ID id );
};

class Infantryman: public Warrior
{
public:
  void info() { 
    cout << "Infantryman" << endl; 
  }
};

class Archer: public Warrior
{
public:
  void info() { 
    cout << "Archer" << endl; 
  }
};

// Реализация параметризированного фабричного метода
Warrior* Warrior::createWarrior( Warrior_ID id )
{
  switch (id)
  {
  case Infantryman_ID:
    return new Infantryman();
  case Archer_ID:
    return new Archer(); 
  }
};


// Создание объектов при помощи параметризированного фабричного метода
int main()
{    
  vector<Warrior*> v;
  v.push_back( Warrior::createWarrior( Infantryman_ID));
  v.push_back( Warrior::createWarrior( Archer_ID));

  for(int i=0; i<v.size(); i++)
    v[i]->info();
}

Недостаток: класс Warrior должен знать обо всех своих наследниках, нехорошо.

Классический метод

#include <vector>
#include <iostream>

using namespace std;

// Иерархия классов игровых персонажей
class Warrior
{
public:
  virtual void info() = 0;     
  virtual ~Warrior() {}
};

class Infantryman: public Warrior
{
public:
  void info() { 
    cout << "Infantryman" << endl; 
  };
};

class Archer: public Warrior
{
public:
  void info() { 
    cout << "Archer" << endl; 
  };     
};

// Фабрики объектов
class Factory
{
public:    
  virtual Warrior* createWarrior() = 0;
  virtual ~Factory() {}
};

class InfantryFactory: public Factory
{
public:    
  Warrior* createWarrior() { 
    return new Infantryman; 
  }
};

class ArchersFactory: public Factory
{
public:    
  Warrior* createWarrior() { 
    return new Archer; 
  }
};

// Создание объектов при помощи фабрик объектов
int main()
{    
  InfantryFactory* infantry_factory = new InfantryFactory;
  ArchersFactory*  archers_factory  = new ArchersFactory ;

  vector<Warrior*> v;
  v.push_back( infantry_factory->createWarrior());
  v.push_back( archers_factory->createWarrior());

  for(int i=0; i<v.size(); i++)
    v[i]->info();
  // ...
}

Недостаток: на каждый Warrior нужна своя конкретная фабрика

Вообщем мне этот паттерн в чистом виде не понравился (хотя Abstract Factory был хорош), поэтому я даже не стал придумывать свои примеры. Да и не сложен этот паттерн.

Ссылки

Ссылка

Продолжаю свое самообразование. Следующий паттерн:

Строитель (Builder)

Реализация

Вот как это выглядит:

Код

Конечно пример спорный, но другого я не смог быстро придумать:)

Теперь определим участников в виде классов.

Продуктом будет подземелье. Оно описывается классом Dungeon.

Мы "сделаем" два конструктора подземелья - лабиринт и улей. Для них нужен будет общий абстрактный класс. Итого:
- IDungeonBuilder - абстрактный строитель
- MazeBuilder - строитель лабиринта
- HiveBuilder - строитель улья

Плюс будет класс Director который и управляет всем процессом.

#include <stdio.h>

enum TypeDungeon
{
  MAZE = 0,
  HIVE,
};

// Продукт
class Dungeon
{
public:
  int room_tileset;
  int corridor_tileset;
  int door_tileset;
  int object_tileset;
};

// Абстрактный строитель
class IDungeonBuilder
{
public:
  virtual void BuildRoom() = 0;
  virtual void BuildCorridor() = 0;
  virtual void BuildDoor() = 0;
  virtual void BuildObject() = 0;
  
  void SetDungeon(Dungeon *dungeon) {m_dungeon = dungeon;}

  Dungeon* GetDungeon(){return m_dungeon;}

protected:
  Dungeon* m_dungeon;
};

// строитель лабиринта
class MazeBuilder : public IDungeonBuilder
{
public:
  void BuildRoom()
  {
    m_dungeon->room_tileset = MAZE;
  }
  void BuildCorridor()
  {
    m_dungeon->corridor_tileset = MAZE;
  }
  void BuildDoor()
  {
    m_dungeon->door_tileset = MAZE;
  }
  void BuildObject()
  {
    m_dungeon->object_tileset = MAZE;
  }
};

// строитель улья
class HiveBuilder : public IDungeonBuilder
{
public:
  void BuildRoom()
  {
    m_dungeon->room_tileset = HIVE;
  }
  void BuildCorridor()
  {
    m_dungeon->corridor_tileset = HIVE;
  }
  void BuildDoor()
  {
    m_dungeon->door_tileset = HIVE;
  }
  void BuildObject()
  {
    m_dungeon->object_tileset = HIVE;
  }
};

// распорядитель
class Director
{
public:
  void SetBuilder(IDungeonBuilder *builder) {m_builder = builder;}

  void SetDungeon(Dungeon *dungeon) {m_dungeon = dungeon;}
  Dungeon* GetDungeon(){return m_dungeon;}
    
  void Construct()
  {
    m_builder->SetDungeon(m_dungeon);
    m_builder->BuildRoom();
    m_builder->BuildCorridor();
    m_builder->BuildDoor();
    m_builder->BuildObject();

  }

private:
  Dungeon *m_dungeon;
  IDungeonBuilder *m_builder;
};

int main()
{
  Dungeon *dung = new Dungeon;
  Director director;

  director.SetDungeon(dung);

  IDungeonBuilder *builder = new MazeBuilder;
  
  director.SetBuilder(builder);
  director.Construct();

  printf("room num type - %d\n", dung->room_tileset);

  delete builder;

  builder = new HiveBuilder;

  director.SetBuilder(builder);
  director.Construct();

  printf("room num type - %d\n", dung->room_tileset);

  delete builder;

  return 0;
}

Ссылки

Ссылка

Решил скрупулезно изучить все паттерны. Причина проста - открыл гоф... закрыл гоф, ибо не осилил беглым чтением. Но это не дело, поэтому поставил себе квест - изучить каждый паттерн досконально:)

Предупреждаю, все что я пишу, это мое личное мнение и мой личный опыт. Это может быть очень далеко или очень близко от истины, но не должно восприниматься как истина. Пишу здесь потому что это моя личная страница.

В качестве источников:
Э. Гамма Р. Хелм Р. Джонсон Дж. Влиссидес - Приемы объектно-ориентированного проектирования. Паттерны проектирования
Фримен Эр., Фримен Эл., Сьерра К., Бейтс Б. - Паттерны проектирования
Википедия
Гугл

Начну с первого патерна в GoF

Abstract Factory (абстрактная фабрика)

Я лично первый раз прочитав такое описание нифига не понял:) И только разобрав код я наконец-то догадался о чем здесь написано.

Реализация

AbstractFactory - абстрактная фабрика, содержит функции для создания абстрактного продукта.

ConcreteFactory - конкретная фабрика. наследуется от AbstractFactory. Реализует методы для создания конкретных продуктов

AbstractProduct - абстрактный продукт, является интерфейсом для конкретных продуктов (то есть конкретные продукты унаследованы от этого класса).

ConcreteProduct - конкретный продукт. наследуется от AbstractProduct.

Одна фабрика может создавать множество разных продуктов.

Вот хорошая диаграмма для понимания

Продолжаю велосипедить.  У меня система рендера (расположенная в библиотеке render.lib) имеет одну четкую задачу - вывод данных на экран... да, да, у всех так, да только не так:)

Я разбил систему рендера на 5 подсистем: device, resource, pipeline, frame, object. Точнее сейчас частично готовы только первые три, две остальные пока только в теории.

Device

Получилась самой простой. В данной системе пока что только один класс RenderDevice, но он является самым основным. Именно с ним работает движок. данный класс делает 4 задачи:
- инициализация DX и других систем рендера
- очищение памяти при выходе
- связывание других систем вместе (чтобы они могли взаимодействовать)
- обработка некоторых событий от окна (изменение окна к примеру). Точнее не так. все эти события уже обработаны в Window, здесь же вызываются методы по мере надобности:

if (m_wnd->IsResize())
      m_render->Resize();

То есть данный класс даже рисовать не умеет:) (нет методов Draw, BeginFrame и прочее)

class RenderDevice
  {
  public:
    bool CreateDevice(const DescRender &desc);
    void Close();

    void Resize();
        
    RenderResource* GetRenderRes() {return renderer_res;}
    RenderPipeline* GetRenderPipeline() {return render_pipeline;}

  private:
    void m_setsize();
    bool m_dxgi();
    bool m_initDX();
    
    DescRender m_desc;
    uint m_width;
    uint m_height;

    ID3D11Device *device;
    ID3D11DeviceContext *devicecontext;
    IDXGISwapChain *swapChain;
    RenderResource *renderer_res;
    RenderPipeline *render_pipeline;
  };

Здесь и далее весь код - сокращенный псевдокод (то есть убираются некоторые моменты)

Resource

Данная подсистема может ввести вас в заблуждение... она не имеет ничего общего с загрузкой и хранением файлов. Это полностью концепция Direct3D, то есть данные ресурсы, это куски памяти уже подготовленные для передачи на видеокарту (то есть кто-то из уже загрузил в память). Сейчас у меня ресурсы разделены на 4 группы - buffer (индексный, вершинный или константный), shader, state(blend, depth, vertexinput, rasterizer, sampler) и texture. Скорее всего будет добавлена еще одна группа - view (viewport, render target, depth stencil buffer)

Все эти ресурсы управляются и хранятся в классе RenderResource. Данный класс позволяет добавлять новые ресурсы возвращая их идентификатор. Но вообще возможно данный класс будет перенесен в ResourceManager

class RenderResource
{
public:
  TextureID AddRenderTarget();  
  TextureID AddRenderDepth();
  SamplerStateID AddSamplerState();
  BlendStateID AddBlendState();  
  DepthStateID AddDepthState();
  RasterizerStateID AddRasterizerState();

  VertexFormatID AddVertexFormat();
  VertexBufferID AddVertexBuffer();
  IndexBufferID AddIndexBuffer();
  
  TextureID AddTexture();  

  ShaderID AddShader();  
private:
  ID3D11Device *device;
  ID3D11DeviceContext *devicecontext;

  Array <Texture> textures;
  Array <Shader> shaders;
  Array <InputLayout> vertexFormats;
  Array <VertexBuffer> vertexBuffers;
  Array <IndexBuffer> indexBuffers;
  Array <SamplerState> samplerStates;
  Array <BlendState> blendStates;
  Array <DepthState> depthStates;
  Array <RasterizerState> rasterizerStates;
};

Pipeline
Данную систему я делал с упором на конвеер DX11. Получилось очень близко. Собственно в данной системе формулируется один DIP. То есть после того как мы добавили ресурсы в RenderResource, здесь мы их прикрепляем к конвееру и затем вызываем команду отрисовки.

class RenderPipeline
{
public:
  void ChangeRenderTarget();

  void Reset();

  void SetTexture();  
  void SetSamplerState();
  void SetShader();
  void SetVertexFormat();
  void SetVertexBuffer();
  void SetIndexBuffer();
  void SetBlendState()
  void SetDepthState();
  void SetRasterizerState();
  void SetShaderConstant();  
  void Apply();

private:
  InputAssemblerStage IA;
  OutputMergerStage OM;
  RasterizerStage RS;
  TempShaderStage TSS;
};

C помощью сетеров заполняем конвеер, и затем рисуем (DIP). Данный класс содержит члены стадий (так как с шейдерами у меня произошла архитектурная проблемка, за них пока только одна стадия TempShaderStage, потом для каждого вида также будет своя). Об стадиях говорить особо не буду, покажу только пример одной из них:

class InputAssemblerStage
{
public:
  void Reset();
  void ApplyState();

  void SetVertexFormat();
  void SetPrimitiveTopology();
  void SetVertexBuffer();
  void SetIndexBuffer();  
private:
  void ChangeVertexFormat();
  void ChangePrimitiveTopology();
  void ChangeVertexBuffer();
  void ChangeVertexBuffer();
  void ChangeIndexBuffer();

  ID3D11DeviceContext *context;
  RenderResource *res;
  
  VertexFormatID currentVertexFormat; 
  VertexFormatID selectedVertexFormat;
  VertexBufferID currentVertexBuffers[MAX_VERTEXSTREAM];
  VertexFormatID selectedVertexBuffers[MAX_VERTEXSTREAM];
  intptr selectedOffsets[MAX_VERTEXSTREAM];
  intptr currentOffsets[MAX_VERTEXSTREAM];
  IndexBufferID currentIndexBuffer;
  IndexBufferID selectedIndexBuffer;

  D3D11_PRIMITIVE_TOPOLOGY currTopology;
  D3D11_PRIMITIVE_TOPOLOGY selectTopology;
};

То есть RenderPipeline получив Set() зовет нужную команду из одного из своих членов.

Frame

Данная система пока не реализована и только в планах. Она будет отвечать за формирование одного кадра (напомню, pipeline формирует только один DIP). В системе будет один главный класс RenderFrame управляющий всеми другими классами Frame. Также будут следующие классы
RenderView - этот класс будет отвечать за конечное место вывода кадра (то есть именно этот класс рисует на экран). Будет содержать мировые матрицы и вьюпорт. Также здесь будет и Present().
RenderPass - по умолчанию будет один проход, рисующий сразу в RenderView. Но можно будет добавить несколько проходов рисования.

Кроме того данная система будет также собирать данные в пакеты (batch) и сортировать

Object

В данной системе будут более высокоуровневые классы - к примеру меши и материалы. Пока данная система даже не планировалась, так что сказать больше нечего. Возможно ее вообще не будет (меши будут в системе scene)

Кстати, недавно понял что две вещи по отношению к движку - мифы.
1 миф - современный движок нельзя написать одному. Unreal Engine 4 (до его анонса) писался одним человеком (его создателем... но слух непроверен). Unigine (кстати меня разочаровал, когда я его увидел, раньше я думал что он круче) был начат одним человеком. И всеми забытая (и кстати недавно ожившая) nebula 3 развивалась (и развивается)  одним человеком (судя по его блогу)
2 миф - движки без проектов нельзя писать... тут есть в лекциях гаймдева одна лекция где описано два подхода и "нет никакого движка, и пишется проект, а общий код переносится в следующие" только один из них. Кроме того оказывается CryEngine 1 является как раз примером такого вот движка в вакууме (анонс в 2000, выпуск в 2002, первая игра - 2004, ощутите разницу, для тех кто скажет что "ну вот они и делали far cry вместе с движком" скажу что движок был написан для презентация NVIDIA, затем на нем собирались делать две другие игры, и только потом far cry)

Нет я конечно даже близко не считаю что смогу до таких результатов дойти (даже не собираюсь - это огромные трудозатраты которые никак не окупятся), просто мотивацию подымаю:)

Выслушаю любые советы и предложения по этой схеме.

Ссылка | Комментарии [54]

Благодаря вики по DX11 (я же писал что вики нужна именно для меня) я смог превозмочь себя и довел таки движок до версии 0.1. При этом я сто-пятсотый раз переписал все с нуля, и на этот раз реально с нуля - больше нет никакого стороннего кода как раньше (вначале брался за основу ngene, потом Hieroglyph3, теперь только мои велосипеды - только хардкор). Это последнее переписывание движка с нуля, на ближайшие годы:) Архитектура идеальна и комфортна для меня, лучше уже не нужно, да и желания больше нет - зачем писать новый движок, если мне и этого будет хватать как когда-то Sapphire2D, так что карьеру движкописателя за ближайшие полгода собираюсь завершить:)

Движок пока не выкладываю, его нужно обточить на реальном проекте, собственно которым и занят.

Напомню, движок затачивается под одно GAPI - DX11

Архитектурно модуль разделен на модули в виде статической библиотеке. Первоначально эту идею описывал здесь - http://www.gamedev.ru/pages/warzes/?id=6030

Новая архитектура
Идею модульности я долго мучал, столкнулся с кучей проблем (решение делать библиотеки динамическими не очень удачно оказалось), и все таки разбил

Вот так можно изобразить текущие системы:

А вот так это выглядит в коде:

Всего в коде 15445 строк чистого кода. С комментариями и прочим мусором почти 20000.

Каждая система четко выполняет свою работу и связана только с нижними системами- результат, добился однонаправленной зависимости в коде, то есть можно взять код common и спокойно юзать без остальных систем. Также и render можно спокойно юзать без Engine, но уже требуется math и common. Это очень удобно в поиске ошибок, а также визуально сокращает код так как каждая система имеет мало кода:
Common - 5927 строк кода
Math - 2311
Audio - 238
GUI - 999
Render - 4996
Engine - 974
Как видите - каждая система сама по себе очень маленькая (Common скорее всего будет разбит на новые системы)

Не зря мучался, даже теперь как-то тяжко смотреть на чужие движки где все смешано в одну кучу:)

Кроме того в этом движке я полностью добил идею разбиения игрового цикла на отдельные сцены (что позволяет легко делать главное меню, несколько игр и т.д. не извращаясь со всякими свитчами и процессами, кстати писал по этой вещи статью, но ее тут так и не опубликовали).

Минимальный код юзающий мой движок (не обращайте внимание на заголовки, еще нет главного заголовка для подключения):
Main.cpp