Персональные страницы

Читать | Комментарии [4]
9 мая 2012

Читать | Комментировать
22 апр. 2012

Пилю потихоньку редактор материалов у себя в движке. Хоть и уверенно, но, блин, адски медленно :D  Буквально по несколько строк в день. Собсно вот такая кака пока получается.

На GUI слишком жестоко не плеваться, я его весь сам пилил, он ещё  жутко кривой и некрасивый. Потом доделаю (с)

Ссылка | Комментировать
17 мая 2012

Так что свидимся в про(е/Э)ктах! ))

Ссылка | Комментировать
15 мар. 2012

Cомнительно конечно подходит но мне нравиться )

В принцепе еще конечно работать и работать над ними..
Еще моделить и текстурить но уже так что то да видно.

1.

2.

3.

Ссылка | Комментарии [4]
12 мар. 2012

Ссылка | Комментировать
10 мар. 2012

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

Вот так вот я организовал структуру своего движка. Давайте я рассмотрю подробней. Начну с папок. Всего создано шесть папок. Первая - _Doc, будет содержать ссылки на используемую документацию по движку (история, лист задач и т.д.). Фишка: обратили внимание на подчеркивание? Так вот, это сделано специально чтобы папка была в самом вверху и не смешивалась с папками движка (папки сортируются по имени).
Application - это уровень приложения. Как вы видите в ней всего один проект с тем же именем. Данный проект - это динамическая библиотека (подробнее о видах библиотек можете прочитать http://ru.wikipedia.org/wiki/Библиотека_(программирование)). Пользователь в идеале должен будет работать только с этой библиотекой.
Папка Core - это основа из схемы. Она содержит 4 проекта. Каждый проект - это статическая библиотека.
Папка Engine - это ядро из схемы. Все проекты из папки, также являются статическими библиотеками.
Папка Framework пуста, потому что пока нет смысла в ней что-то делать.
И папка Test будет хранить приложения для тестирования частей движка.

То есть в итоге у нас одна динамическая библиотека, одинадцать статических которые будут линковаться к динамической. И проект.

Вот мой проект - http://www.gamedev.ru/files/?id=76612

Я не стану пояснять как я создал такой проект, так как это долго. Да и не расчитанно на новичков.

На этом подготовка завершена. Продолжим.

Любое приложение должно с чего-то начинаться. Это называется точкой старта (или входа) приложения. Обычно это или main() или WinMain(), а также все их производные... Но в движке нет точки старта, потому что движок не запускается сам по себе. Точку старта задает пользователь при создании приложения. Но я начну именно с нее проектировать и писать код. Наша точка старта будет в приложении test.

Пользователь должен при старте, создать наследника от класса Application, полиморфировать нужные методы, инициализировать наследник, запустить его на выполнение и затем очистить ресурсы.
То есть получается так:

Поясню. Start - это условный момент запуска приложения. End - это условный момент завершения приложения. WinMain и MyApplication - это уровень приложения. Данные сущности пишутся пользователем. iApplication - это интерфейс из библиотеки Application. Как вы видите, я выделил их цветом согласно схемы из предыдущей статьи. Я так буду поступать и дальше чтобы вам было легче ориентироваться.

Начнем писать код. Для начала создадим класс приложения. Находим Application и пишем:
Application.h

#pragma once

#include "export.h"

class ENGINE_DLL Application
{
public:
  Application();
  virtual ~Application();

  // Инициализация приложения.
  bool Create();

  // выполнение одного кадра
  bool RunOneFrame();

  // Выполнение приложения.
  void Run();

  // Завершение приложения.
  void Shutdown();

  bool IsInit(){return _isinit;}
  bool IsExit() {return _exit;}


protected:
  // пользовательская инициализация
  virtual bool _init() = 0;
  // пользовательский кадр
  virtual bool _frame() = 0;
  // пользовательская очистка
  virtual void _close() = 0;

private:
  bool _isinit;
  bool _exit;
};

Application.cpp

#include "Application.h"

Application::Application() :
  _isinit(false),
  _exit(false)
{
}

Application::~Application()
{
  // чистим за нерадивым программистом
  if (_isinit==true)
    Shutdown();
}

bool Application::Create()
{
  /*
  Инициализация всех систем движка
  */

  // пользовательская инициализация
  if (_init() == false)
    return false;
  // сообщаем что приложение инициализировано
  _isinit=true;
  // сбрасываем флаг сообщающий о выходе
  _exit = false;
  return true;
}


bool Application::RunOneFrame()
{
  // следим чтобы не было попытки рисовать при неудачно инициализации
  if (_isinit == false)
    return false;

  return _frame();
}

void Application::Run()
{
  // Инициализируем
  if(_isinit == false)
    Create();

  // выполняем бесконечный цикл
  while ( _exit==false && _isinit==true )
  {
    _exit = !(RunOneFrame());
  }

  // очищаем ресурсы
  Shutdown();
}

void Application::Shutdown()
{
  _isinit = false;
}

Если вам нужен файл export.h, то он такой:

  #pragma once 

 #ifdef WIN32 
 #ifdef _BUILD_ENGINE 
 #define ENGINE_DLL __declspec(dllexport) 
 #else 
 #define ENGINE_DLL __declspec(dllimport) 
 #endif 
 #else 
 #define ENGINE_DLL 
 #endif 

При этом, где-то в Application должен быть объявлен _BUILD_ENGINE. В проекте на который я дал ссылку выше, все это уже есть.

Теперь вернемся к приложению:
main.cpp

#include <Windows.h>
#include "../Application/Application.h"

class MyApp : public Application
{
private:
protected:
  // пишем пользовательские классы
  virtual bool _init() { return true; }
  virtual bool _frame() { return true; }
  virtual void _close() {}
};

int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, PSTR pScmdline, int iCmdshow)
{
  MyApp app;

  app.Run();

  return 0;
}

Собственно вы уже можете собрать (но не забудьте прилинковать Application). Но запускать не советую - уйдет в бесконечность:) Мы ведь еще условий выхода не написали.

Так, теперь двигаемся дальше. Вспомним для чего нам был нужен Application - для обертывания остальных сущностей. Среди которых главной была Engine. Значит теперь ее нужно создать. Далее, по текущей задаче мы должны создать окно и инициализировать рендер. Значит в модуле рендера появляются два класса - Window и Render. Но так как мы решили что сущность рендера абстрактна, то тогда нужен еще один класс RenderDX11 и WindowWin32, которые будут выполнять реализацию использования в рендере DirectX 11 в окне операционной системы Windows.

Схема усложняется:).
Начнем выполнение с конца. Находим библиотеку рендера и пишем код:
Window.h

#pragma once

#include <string>

class Window
{
public:
  Window();
  virtual ~Window();

  /// Создать окно
  virtual bool createWindow(const std::wstring &caption, unsigned int width, unsigned int height)=0;

  /// Закрыть окно.
  virtual void closeWindow()=0;

  /** Показать/Скрыть окно.
    @param
      value определяет, показывать ли окно (при true) или не показывать.
  */
  virtual void showWindow(bool value)=0;


  /// Вернуть заголовок окна
  virtual const std::wstring& getWindowName() const {return _caption;}

  /// Изменить заголовок окна.
  virtual void setWindowCaption(const std::wstring& _caption)=0;

protected:
  std::wstring _caption;  ///< заголовок окна
  unsigned int _width;  ///< ширина клиентской части окна
  unsigned int _height;  ///< высота клиентской части окна
};

Window.cpp

#include "Window.h"

Window::Window()
{
  _width = 800;
  _height= 600;
  _caption = L"Engine";
}

Window::~Window()
{
}

Теперь нам нужен класс Render. Но тут я хочу сказать вот что - наш рендер должен быть единственным. Реализуем мы это через паттерн синглтон (погуглите, кому интересны подробности, прям по запросу "паттерн синглтон"). Так что сначала надо написать сам паттерн. Переходим к библиотеке Common. и пишем:
macros.h

#pragma once

#include <cassert>

#define Assert(a, b) assert(a && b)

Singleton.h

#pragma once

#include "macros.h"

/** Singleton pattern implemented using templates.
  @remarks
    Using singleton is useful for objects such as engine
    or managers which should have no more than a single
    instance in the whole application.
  @remarks
    If you want to make object of some class singleton you
    have to  derive this class from Singleton class.
  @remarks
    If something goes wrong during singleton object creation,
    deletion or on attempt to access it, assertion arises.
    By "something going wrong" I also mean attempts to create
    more than single object of class marked singleton.
*/
template <typename T>
class Singleton
{
public:
  /** Creates singleton of type T.
  */
  Singleton()
  {
    Assert(!s_pSingleton, "Singleton class already instantiated.");

    #if defined( _MSC_VER ) && _MSC_VER < 1200
      int offset=(int)(T*)1-(int)(Singleton <T>*)(T*)1;
      s_pSingleton=(T*)((int)this+offset);
    #else
      s_pSingleton=static_cast<T*>(this);
    #endif
  }

  virtual ~Singleton()
  {
    Assert(s_pSingleton, "Singleton class not instantiated.");
    s_pSingleton=0;
  }

  /** Returns reference to a singleton.
  */
  static T& getSingleton()
  {
    Assert(s_pSingleton, "Singleton class not instantiated.");
    return(*s_pSingleton);
  }

  /** Returns pointer to a singleton.
  */
  static T* getSingletonPtr()
  {
    return s_pSingleton;
  }

  /// A static pointer to an object of T type.
  /// This is the core member of the singleton. 
  /// As it is declared as static no more than
  /// one object of this type can exist at the time.
  static T* s_pSingleton;
};


template <typename T> T* Singleton <T>::s_pSingleton=0;

Паттерн не мой, поэтому сохранен язык оригинала :-D

Вообщем, я к сожалением на сегодня на этом завершаю:-( Хотел бы написать дальше, но 12 часов - пора спать. Ждите до завтра, будет продолжение. Мы наконец-то создадим окно и инициализируем движок.

Ссылка | Комментарии [43]
5 мар. 2012

Зачем это нужно: как то так получается что мне больше нравится писать механизмы, чем собственно игру. Ведь игра это не только код - это скрипты, ресурсы, графика, сюжет, тексты. Всем этим мне не особо интересно заниматься, а искать людей не имея готовых заготовок сложно и тем более не интересно. То есть когда начинаешь делать игру, обычно получается так что вместо написания кода, занимаешься тысячью и одной сторонними задачами. А вот когда пишешь движок, не отвлекаешься на остальное и только пишешь код. У меня нет цели быть круче крайзиса или анреала. Я просто буду клепать свой милый уютный игровой движок.

В этой статье я буду описывать принятые архитектурные решения. Для начала смотрим на это:

Здесь я простенько изобразил роль движка в игре.

Игровой движок (Game Engine) - это такая сущность на основе которой и можно создать игру. Инструменты (tools) - это сущность которая позволяет облегчить работу с движком и работать в более удобных условиях, чем кодить. И в конце получается игра. При этом и инструменты и игра зависят от движка. То есть нельзя взять редактор от unreal engine и движок от crysis. Но я думаю это и так понятно.

Так вот, давайте теперь представим что каждая из этих сущностей представлена в виде файлов. И нас теперь интересует игровой движок. По каким-то причинам многие делают его монолитным. То есть весь движок, это одна библиотека. Хотя иногда и делят. Но лично меня не устраивает идея монолитности движка, уж очень сложно с монолитом работать. Я просмотрел множество движков, и заметил что среднее число строк чистого кода - 40 тысяч. Если все это писать в одной библиотеки, то получается каша. И тем не менее почему-то пишут в одной  библиотеке.

Много ранее я уже показывал идею разбиения движка на отдельные составляющие. Теперь воспользуюсь этой идеей. Так что у нас стоит задача, разбить сущность "игровой движок" на меньшие сущности.

Будем думать. Яс дело нужно как-то выводить на экран, первая сущность - рендер. Пользователь как-то должен влиять на игру, значит вторая сущность - система ввода. Без звука ныне никуда, третья сущность - звук. И физика, это нынче модно, вот и четвертая сущность. Ну и конечно же, движок, не движок, если не держит мультиплеер, так что пятая сущность - сеть. Так. Теперь есть пять разношерстных сущностей. Мы должны их связать в один движок, который и будет с ними работать. Так что шестая сущность - движок.

Изобразим на схеме:

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

Все, почти идеал :). Но добавим несколько штрихов. Обратимся к рендеру. Хотя я и решил что ограничусь DX 11, но ведь неизвестно что будет в будущем, да и потом неизвестно каким будет DX 12, может тоже совершит революцию и надо будет писать все по другому, как это стало с DX 10. Поэтому сделаем эту сущность как бы абстрактной и создадим дополнительную сущность для рендера DX 11. Также сделаем и с физикой. Я буду использовать physX. И возможно далее все остальные сущности тоже получат наследные сущности.

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

Итог:

Вот как-то так.

Как же мы будем это осуществлять? Application как самый верхний уровень пусть будет в виде динамической библиотеки. А вот все остальные будут статическими. В идеале, пользователь должен подключить только Application к своему приложению, но это как получится, тут влияет специфика статических либ.

Собственно на этом вводная завершена. В следующей статье будет создано окно с дирексом и возможно выведен первый треугольник (или квадрат:) )

Ссылка | Комментарии [13]
4 мар. 2012

Обзор - American McGee's Alice

Обзор - Потерянная Корона/The Lost Crown

Ссылка | Комментировать
27 фев. 2012

Канал

http://www.youtube.com/user/ArhanPes/videos

Группа

http://vk.com/club34615810

Обзор - Шизариум / Sanitarium

Обзор Анабиоз - Сон разума

Обзор Cargo - The Quest For Gravity

Ссылка | Комментировать
12 фев. 2012

1. Flash / Очень много полезных штук для AS3
    3D движки
    3D игровые движки,
    2D игровые движки,
    изометрические движки,
    3D фреймворки для анимации,
    3D физические движки,
    Библиотеки для дополненной реальности,
    Твиннеры (движки для программной анимации).
    Часть 1:    http://romanlovetext.blogspot.com/2012/01/flash-as3.html
    Часть 2:    http://romanlovetext.blogspot.com/2012/01/flash-as3_25.html
2. Софт / Редактор для создания пиксельарта
    http://romanlovetext.blogspot.com/2012/01/blog-post_5321.html

Темы месяца:
1. Много историй от iPhone / iPad разработчиков. (истории успеха)
2. Альтернатива Adobe Flash (Софт)
3. Бесплатная программа для создания флеш анимации. (Софт)
4. Разработка, тестирование, издание для iOS из-под Win (продажа игр)
5. Как создать приложение для Мой мир@Mail.ru за 10 минут на Silverlight 4 (разработка игр)
6. Введение в программирование игр в Windows Phone 7 с помощью XNA Game Studio (Windows Phone, XNA Game Studio) 

Темы недели:
1. Возможности 3D графики Windows Phone
2. 20 бесплатных дополнений для Visual Studio
3. Небольшой вводный курс по Silverlight 4
4. Опыт разработки и продвижения игры в Android Markete
5. Зарплаты программистов — декабрь 2011
6. Работа с заказчиками / 2-а разных подхода
7. Разработка / Топ-5 самых впечатляющих книг, которые должен прочесть каждый разработчик ПО
8. Flash / Обратная разработка коммерческой программы

И многое другое...

Ссылка | Комментарии [5]
26 янв. 2012

Добавляйтесь друг к другу, можно и ко мне: http://vk.com/watkin

Всем спасибо.

Ссылка | Комментарии [24]
20 янв. 2012

Ссылка | Комментировать
6 янв. 2012

ММОРПГ, суть такова.

Зачастую, пользователи — одни из лучших разработчиков.
Дайте пользователям свободу модифицирования игры — и вашу игру улучшат и дополнят.

Пользовательские карты и модификации достигают небывалых высот, потому что они делают то, что пользователям самим интересно. К примеру Dota: пользовательская карта которая стала самостоятельной игрой, и даже более того —  новой кибер-спортивной дисциплиной. Движок WarCraft III и редактор карт — позволяют использовать широкий круг возможностей для создания разнообразных карт.

Можно пойти дальше, и создать игру, в которой пользователи сами создают мир. Тот же Minecraft, только шире.

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

Чтобы пользователям было проще, нужно создать удобный и понятный инструментарий, плагины для программ, чтобы эксплоь в игру своих моделей и новых игровых объектов был как можно более проще.

Так игра лишается своих чётко очерченых границ — делай сколько хочешь. Конечно должна быть модерация ресурсов, чтобы всё было достойно.

Конструктор-песочница

Пользователь получает в своё распоряжение n-километров территорий, и может построить на ней собственный мир.
Пользователь отредактировав свою карту, пересылает эти данные на сервер и карта становятся доступной для всех. Теперь любой игрок пришедший на эту территорию получает новую локацию. Со всеми новыми игровыми моделями, если таковые есть.

Если уже не хватает места, и вы дошли до границы с соседом, проще всего просто увеличить размер территории, ваша область увеличится и граница отодвинется — у вас снова будет место для строительства.

Так старания игроков не будут пропадать даром, всё останется на месте.

Можно взять территорию соседа, если она ему больше не нужна.

Конечно, только самые интересные и сбалансированные территории будут популярны для обследования. Если у вас везде там тролли 80-го уровня стоят и никому не пройти — то ваша территория не будет популярна и к вам никто не будет ходить.

Кстати об игровых очках — на которые можно проводить строительство — не думаю что это хорошая идея. Это граница и барьер для проявления фантазии.

Жанр, стилистика

Для меня это видится как РПГ, фэнтази. О модификациях в игре, я думал смотря на WarCraft III. Поэтому и такое направление мне кажется самым удачным — модифицируя, можно уместить если и не всё, то почти всё.
А также здесь нет чрезмерной сложности в создании контента, это достаточно доступно. Не нужно будет рисовать фотореалистичные текстуры, не понадобятся карты нормалей и прочие-прочие непростые вещи которые подвластны лишь профессионалам.

Возможность модификации усилилась в новом движке и редактора для StarCraft 2. Это именно то, что не даст игре умереть раньше времени и может даже подарить ей вторую жизнь.

Реальность

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

И игра эта конечно полагается на тех пользователей, которые любят чего-нибудь поредактировать и сделать самостоятельно.

Ссылка | Комментарии [8]
2 янв. 2012

Я до сих пор так и не понял как эти мьютексы работают, но они работают.
Написал один класс, который на мой взгляд тянет на подсказку:

#ifndef __shLockVector_H__
#define __shLockVector_H__

#include <vector>
#include <boost/thread/mutex.hpp>

template <typename type> class shLockVector : public std::vector<type>
{
protected:
  boost::mutex  mutex;
public:
  shLockVector ()
  {
    resize(0);
  }
  void set_locked (bool lock)
  {
    lock ? mutex.lock() : mutex.unlock ();
  }
  void lock_push (std::vector<type> &in)
  {
    mutex.lock();
    insert (end (), in.begin(), in.end());
    mutex.unlock ();
  }
  void lock_read (std::vector<type> &out)
  {
    mutex.lock();
    out = *this;
    clear ();
    mutex.unlock ();
  }
};

#endif

Как известно, вектор нельзя читать и писать из разных потоков, может свалиться программа, так что без блокировки не обойтись.
Это наследник от вектора, но можно таким же макаром унаследоваться от любого другого контейнера, и он станет потокобезопасным. Здесь две операции, которые можно использовать для передачи пакетов: lock_push и lock_read, они потокобезопасны. А чтобы использовать обычный функционал контейнера, надо не забывать вызывать set_locked (true) и set_locked (false) вокруг этих операций.

Я решил использовать boost::thread, который вроде как обещают включить в стандарт, так что он будет совсем законной частью stl.
Да и кстати, пользоваться им очень просто:

#include <boost/thread/thread.hpp>
class myThread
{
protected:
public:
  myThread (){}
   ~myThread (){}

  void operator()()
  {
    while(true)
    {

      boost::this_thread::sleep (boost::posix_time::milliseconds (10));
    }
  }
};

Запускаем так:

  myThread  *thread1 = new myThread ();
  boost::thread  bthread1 (*thread1);

Для какой-нибудь подсистемы, которая всегда работает, наподобие цикла рендеринга, физики или подгрузки, по-моему, самое то! Ну а если надо включать/выключать поток, то надо вставлять прерывания. Для моей задачи это не нужно, поэтому я на это дело забью.

Я заметил, что тема потоков для программистов C++ - это вообще тёмное пятно, так что возможно кому-то этот мой пост пригодится. Я убил на это 2 дня поисков по гуглу, мук и тестов.

Ссылка | Комментарии [11]
29 дек. 2011

Ссылка | Комментарии [10]
28 дек. 2011

Движок будет зваться Sapphire Engine и его символом будет синий сапфир... Это название идет с другого моего движка 2D Sapphire. Почему я решил называть свои движки названием драгоценных камней я уже не помню (возможно на это как-то повлияла серия игр про покемонов - там тоже игры называли драгоценными камнями). Сначала был выбор между аметистом и сапфиром, потому что я люблю синий и все с ним связанное... Но аметист не звучит, поэтому я и выбрал сапфир. Собственно Sapphire Engine не является продолжением 2D Sapphire - это разные движки...

Теперь технические решения - я пока плюну на мультиплатформу - движок будет пока использовать только один GAPI - DirectX (точнее два - 9 и 11, но 11 будет потом - текущему проекту он не нужен). Операционной системой будет - Windows. Выбранной IDE будет visual studio 2005 (в первое время я буду использовать microsoft'ские плюшки над c++, так что скорее всего в других IDE оно не соберется - потом исправлю конечно, но сейчас мне нужны эти особенности реализации c++)

Причина почему я пишу движок - меня не устроили существующие движки (а я их просмотрел уже несколько десятков), так что холиварить здесь не нужно (и уж тем более доказывать в стиле - "нафиг писать движок если есть unity/udk или еще что")

Движок до версии 1.0 будет распространятся бесплатно (но не факт что до этой версии). Исходники движка распространятся не будут. Но иногда я буду выкладывать некоторые части кода.

Самое важное что я хочу добиться от движка - красивая картинка при хорошей оптимизации.

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

Вот я набросал первую схему архитектуры движка:

Думаю понятно что она означает. Application - это специальная надстройка которая создает windows окно, а Sapphire Engine - это сборка всех остальных либ, я пока не уверен в надобности этой части или в ее динамической природе.

Теперь вы наверное подумаете что пользователь задолбается прописывать все эти либы в свой проект, но на самом деле решение есть - #pragma comment(lib, "libname.lib") Будет специальный заголовок в котором будут прописаны все пути и линкуемые либы... Остается теоретическая проблема дублирования кода (статические либы будут линковаться в Application, Sapphire Engine и в проект пользователя), но  я не уверен что компилятор эту проблему не решает (всеже каждое приложение линкует кучу одних и тех же стандартных виндовских либ и ниче - проблем ни у кого не вызвало это).

Ссылка | Комментарии [89]
28 дек. 2011