Dreams Gate and mods based on Vereshagin Engine like Stargate mod
You are not logged in.
Offline
Offline
Роман думает как исправить ошибки в физике по сети ))))
Offline
наверное видео снял коряво )))
в общем, проблема все той же синхронизации данных движения и физики, объекты умудряются проскакивать сквозь объекты и поверхность, но это временные трудности которые возникают лишь по сети ) без сети оно работает как надо ))
основная проблема - логическая )))
на сервер данные об объектах стекаются от разных игроков с разной очередностью, из-за которой и есть основные проблемы.
В итоге просчет физики идет по иному пути, и назад приходят данные что объект должен быть тут или там в итоге он проскакивают через объекты.
два игрока - игрок А кидает ящик - но об этом еще не знает игрок Б, при этом сервер зафиксировал ящик от первого игрока А (ящик 1), и тут же получил данные от игрока Б ( ящик 2 ), в итоге игроку А уйдут верные данные (ящик 1, ящик 2), а игрок Б получит не верные так как у него еще нет информации о ящике от игрока А и у него очередность будет (ящик 2, ящик 1). В итоге при расчете физики очередность нарушена и объекты воздействия поменялись местами.
Казалось бы есть легкое решение проблемы:
- сообщать о запуске ящика всем клиентам, а после у себя его запулить, но тут неизбежны лаги особенно если у других игроков пинг огромный, или он вообще вылетел и завис.
в чем проблема с очередностью:
предположим объект 1 лежит на земле объект 2 падает на него
при очередности 2 1, мы вначале выталкивать будем объект 2 после объект 1 и опять объект 2 так как объект 1 обязан его передвинуть
при очередности 1 2, выталкивать объект 1 и после объект 2
по логике вещей мы должны были считать от земли, но объекты не всегда лежат именно на земле, они на других физических объектах, в зданиях на машинах и тд и даже в космосе, в итоге правильная очередность везде разная.
По этому я планирую разбить зоны физические на сектора и работать с каждым сектором отдельно, установив для каждого свои законы со своей гравитацией )) скоро узнаем что из этого получится
Offline
Эм. Игрок нажимает кнопку "выкинуть", клиент отправляет запрос на сервер <net_object_throw, "box", 1> сервер проверяет наличие у игрока ящика, проверяет может ли он выполнить бросок, отправляет всем клиентам в зоне обзора (в том числе кидающему) событие появления объекта "box" с заданным вектором движения. Отправляет кидающему клиенту информацию, что у него больше нет ящика.
С движением игроков тоже ничего нового, как в cs сделано, просчитывать попадания снарядов с учетом вектора, основанного на пинге игрока в которого снаряд попадает и пинге игрока, запускающего снаряд.
Погрешности, конечно, всегда есть, но вряд ли они заметны невооруженным глазом.
Offline
Эм. Игрок нажимает кнопку "выкинуть", клиент отправляет запрос на сервер <net_object_throw, "box", 1> сервер проверяет наличие у игрока ящика, проверяет может ли он выполнить бросок, отправляет всем клиентам в зоне обзора (в том числе кидающему) событие появления объекта "box" с заданным вектором движения. Отправляет кидающему клиенту информацию, что у него больше нет ящика.
С движением игроков тоже ничего нового, как в cs сделано, просчитывать попадания снарядов с учетом вектора, основанного на пинге игрока в которого снаряд попадает и пинге игрока, запускающего снаряд.
Погрешности, конечно, всегда есть, но вряд ли они заметны невооруженным глазом.
я как раз писал в очень сжатом виде:
Казалось бы есть легкое решение проблемы:
- сообщать о запуске ящика всем клиентам, а после у себя его запулить.
Подробное описание проблемы:
Игра динамическая, данные стекаются к серверам от разных игроков в разных сегментах. На типичных CS - один сервер он все обрабатывает, полностью все запросы, у нас игроки + сервер. Другой подход, где сервер получает результат и начальные данные не всегда напрямую от игрока. После формирует результат. Это делается с той целью чтобы те кто находится в одном городе не грузили канал + не перегружали сервер лишними расчетами так как они в другом городе и мы их просто не видим и не чувствуем, а они саме себе все просчитают. Так как все передвигаются и все движется и вселенная не маленькая не будет строгой привязке сервера к месту, а значит и данные поступающие из разных мест идут в разном порядке с разными интервалами и естественно позициями и скоростями. Может я конечно зря физику раскидываю на игроков, но посмотрим что будет )))) это лишь эксперимент ))))
Offline
Offline
Я бы на игроков физику не сильно раскидывал. Можно, на них кинуть промежуточные расчеты, но главный результат должен получать только сервер. Другими словами, последняя операция в вычислениях всегда за ним. И стоит заменить косинус/синус/тангенс/котангенс таблицами Брадиса или выполнить их приближенное вычисление при помощи умножения/деления и сложения/вычитания. Можно занизить точность до типа Single(4 байта плавающий) и воспользоваться инструкциями sse/sse2/sse3(Prescott). В последнем типе инструкций игра не будет идти на компах выпущенных до 2005 года.
Offline
Offline
Вообще, уже давно, настало время, что обычные процы уступают по вычислениям видеокартам )))) по этому все будет переноситься на видеокарты, особенно требовательные расчеты.
godar SSE оптимизация встроена в компилятор, и обычно прирост дает не более 10-15% а это совсем мало.
я смотрю в сторону OpenCL.
Игра будет всегда использовать ресурсы локальных машин для расчетов. Нужно будет лишь следить за достоверностью информации. Серверу и без этого дел много придется выполнять.
Offline
Тогда остается еще оптимизация пакетов по обьему в байтах. Можно применить алгоритмы сжатия данных без потерь. Например, битовый, ксор-сжатие и т.п - чтобы меньше была заружена сетка и меньше затрачивалось время на передачу данных.
Еще можно установить лимит на количество действий в секунду в одной локальной области. Да, это сделает игру слегка походовой, но если время хода будет маленьким(милисекунды), то это не будет так заметно. Зато у сервера будет время проверить данные.
Насчет OpenCL - сначала думал, что опечатка а потом набрел на это:
OpenCL (от англ. Open Computing Language — открытый язык вычислений) — фреймворк для написания компьютерных программ, связанных с параллельными вычислениями на различных графических (англ. GPU) и центральных процессорах (англ. CPU). В фреймворк OpenCL входят язык программирования, который базируется на стандарте C99, и интерфейс программирования приложений (англ. API). OpenCL обеспечивает параллелизм на уровне инструкций и на уровне данных и является реализацией техники GPGPU. OpenCL является полностью открытым стандартом, его использование не облагается лицензионными отчислениями.
Цель OpenCL состоит в том, чтобы дополнить OpenGL и OpenAL, которые являются открытыми отраслевыми стандартами для трёхмерной компьютерной графики и звука, пользуясь возможностями GPU. OpenCL разрабатывается и поддерживается некоммерческим консорциумом Khronos Group, в который входят много крупных компаний, включая Apple, AMD, Intel, Nvidia, ARM, Sun Microsystems, Sony Computer Entertainment и другие.
Offline
ужас конечно у меня с физикой ))))
Сейчас уже не так заметно что ее колбасит. Но иногда баги вылезают прям запредельные.
На лаги и тормоза внимание не стоит обращать, работает много лишнего.
Offline
Offline
Offline
))) в реальности дело обстоит иначе, у меня fps 120 перед записью через fraps, и восстанавливается опять до 100 с хвостиком после записи.
а про минималку - видеокарты с поддержкой OpenGL 3.3, возможно придется использовать OpenGL 4 (там появился double для VBO, это убирает целый пласт ненужных мат операций с проца)
Offline
Offline
там было GL 2 если не ошибаюсь, но придется тестить, так как ati/nvidia обычно в дровах эмуляцию делают для тех вещей которых нет на картах. Так что оно может запуститься и даже работать, но в каком виде - загадка.
Offline
OpenGL 3.0
11 августа 2008 года Khronos Group представила новую версию спецификации OpenGL.
Поддерживают видеокарты: Radeon серии HD; GeForce 8, 9, GTX 100, GTX 200, GTX 300 и GTX 400 серий.
OpenGL 3.1
24 марта 2009 года Khronos Group анонсировала OpenGL 3.1. В новой версии произведена чистка компонентов, которые были объявлены устаревшими, но оставались в OpenGL 3.0 для сглаживания перехода на новую версию API (устаревшие компоненты возможно в дальнейшем использовать через расширение GL_ARB_compatibility).
OpenGL 3.2
3 августа 2009 года Khronos Group анонсировала OpenGL 3.2. Новая версия продолжает развитие стандарта OpenGL, чтобы дать разработчикам графики кроссплатформенный доступ к передовой функциональности GPU.
Поддерживают видеокарты: Radeon серии HD; GeForce 8000, 9000, GTX серий 200 и 400.
Нововведения:
Поддержка OpenGL Shading Language версии 1.50 (GLSL).
Порядок вершинных компонентов BGRA (GL_ARB_vertex_array_bgra) — теперь в шейдере можно читать 4-компонентные вершинные атрибуты в формате RGBA.
Команды отрисовки теперь позволяют модификацию базового индекса вершины (GL_ARB_draw_elements_base_vertex) — теперь легко можно использовать один набор вершинных буферов (для координат и прочих атрибутов) для хранения множества мешей (меньше переключений буферов — быстрее рендеринг).
Геометрические шейдеры (GL_ARB_geometry_shader4).
OpenGL 3.3
Представлена вместе с OpenGL 4.0 11 марта 2010 года. Позволяет максимально возможно приблизиться к функциональности OpenGL 4.0 на аппаратной базе предыдущего поколения.
OpenGL 4.0
11 марта 2010 года Khronos Group представила финальный вариант спецификации OpenGL 4.0 и языка шейдеров GLSL 4.0. OpenGL 4.0 полностью обратно совместим со старыми расширениями OpenGL, используя режим совместимости введенный в OpenGL 3.2.
Среди нововведений:
Две новые ступени обработки шейдеров, что позволяет перенести обработку тесселяции с центрального процессора на GPU.
Прорисовка данных, сгенерированных OpenGL или такими внешними API, как OpenCL, без участия центрального процессора.
64-битная двойная точность с плавающей запятой операций с шейдерами и ввода-вывода для увеличения точности и качества рендеринга.
Я бы остановился на версии 3,2 - порой у народа бывают видеокарты и постарее августа 2009 года.
Offline
Offline
Offline
(слоупок) А если русским языком сказать?! Какое поколение видео карты нужна !? например: nVidia. У меня серия 8 (EN8600GT MAGIC) Я на этот монстре в БФ3 играл.
http://ru.asus.com/Graphics_Cards/NVIDI … ICHTP512M/
Graphics GPU Features
NVIDIA® GeForce 8600GT
Built for Microsoft® Windows Vista™
NVIDIA SLI™ Technology ready
Full support for Microsoft DirectX10 and Shader Model 4.0 enables stunning and complex special effects
OpenGL®2.0 support
NVIDIA Quantum Technology - Advanced Shader Processors architected for physics computation
Single dual-link DVI outputs support 2560 X 1600 at 60Hz resolution displays
Offline
Offline
ээ... поступает предложение, чтобы пользователь написал свою конфигурацию и по ней ему был подобран клиент игры. То есть если у него 128 бит, то 128 битная версия а если 64 бит, то 64 битная версия и т.п.
Подобрать можно автоматически - то есть пользователь указывает конфигурацию а комп классифтцирует ее и выбирает что пользователь закачивать к себе на комп - Он выбрал видеокарту, сервак распознал по модели что она поддерживает ОпенГЛ 3,2. Значит ему предлагают закачать версию с ОпенГЛ 3,2.
Это нормально что часть глюков на стороне клиента по причине что у него видео слегка слабоватое. Главное чтобы эти глюки не были в расчетах сервака и чтобы это не влияло на игровые моменты. Например, на попадание обьекта в определенное место с нанесением определенного урона.
Есть предложение сделать текстуры не плоскими (псевдообьемными) толщиной в один пиксел а с реальной толщиной - чтобы если обьект оказался наползающим на(в) них, то он это "почувствовал" за счет погрешности и "отполз".
Offline
ээ... поступает предложение, чтобы пользователь написал свою конфигурацию и по ней ему был подобран клиент игры. То есть если у него 128 бит, то 128 битная версия а если 64 бит, то 64 битная версия и т.п.
Даже у кого 32 битный комп, будет работать 128 битная физика.
Например: int128 это набор из двух uint64 пример класса:
#ifndef BASE_INT128_H_
#define BASE_INT128_H_
#include <iostream>
using std::ostream;
using std::cout;
using std::endl;
#include "base/integral_types.h"
#include "base/logging.h"
class uint128 {
public:
uint128();
uint128(uint64 top, uint64 bottom);
#ifndef SWIG
uint128(int bottom);
uint128(uint32 bottom);
#endif
uint128(uint64 bottom);
uint128(const uint128 &val);
void Initialize(uint64 top, uint64 bottom);
bool operator==(const uint128& b) const;
bool operator!=(const uint128& b) const;
uint128& operator=(const uint128& b);
bool operator<(const uint128& b) const;
bool operator>(const uint128& b) const;
bool operator<=(const uint128& b) const;
bool operator>=(const uint128& b) const;
// Logical operators.
uint128 operator~() const;
uint128 operator|(const uint128& b) const;
uint128 operator&(const uint128& b) const;
uint128 operator^(const uint128& b) const;
// Shift operators.
uint128 operator<<(int amount) const;
uint128 operator>>(int amount) const;
// Arithmetic operators.
uint128 operator+(const uint128& b) const;
uint128 operator-(const uint128& b) const;
uint128 operator+=(const uint128& b);
uint128 operator-=(const uint128& b);
uint128 operator++(int);
uint128 operator--(int);
uint128 operator++();
uint128 operator--();
friend uint64 Uint128Low64(const uint128& v);
friend uint64 Uint128High64(const uint128& v);
friend ostream& operator<<(ostream& o, const uint128& b);
private:
// Little-endian memory order optimizations can benefit from
// having lo_ first, hi_ last.
// See util/endian/endian.h and Load128/Store128 for storing a uint128.
uint64 lo_;
uint64 hi_;
// Not implemented, just declared for catching automatic type conversions.
uint128(uint8);
uint128(uint16);
uint128(float v);
uint128(double v);
};
extern const uint128 kuint128max;
extern ostream& operator<<(ostream& o, const uint128& b);
inline uint64 Uint128Low64(const uint128& v) { return v.lo_; }
inline uint64 Uint128High64(const uint128& v) { return v.hi_; }
inline bool uint128::operator==(const uint128& b) const {
return (lo_ == b.lo_) && (hi_ == b.hi_);
}
inline bool uint128::operator!=(const uint128& b) const {
return !(*this == b);
}
inline uint128& uint128::operator=(const uint128& b) {
lo_ = b.lo_;
hi_ = b.hi_;
return *this;
}
inline uint128::uint128(): lo_(0), hi_(0) { }
inline uint128::uint128(uint64 top, uint64 bottom) : lo_(bottom), hi_(top) { }
inline uint128::uint128(const uint128 &v) : lo_(v.lo_), hi_(v.hi_) { }
inline uint128::uint128(uint64 bottom) : lo_(bottom), hi_(0) { }
#ifndef SWIG
inline uint128::uint128(uint32 bottom) : lo_(bottom), hi_(0) { }
inline uint128::uint128(int bottom) : lo_(bottom), hi_(0) {
if (bottom < 0) {
--hi_;
}
}
#endif
inline void uint128::Initialize(uint64 top, uint64 bottom) {
hi_ = top;
lo_ = bottom;
}
#define CMP128(op) \
inline bool uint128::operator op(const uint128& b) const { \
return (hi_ == b.hi_) ? (lo_ op b.lo_) : (hi_ op b.hi_); \
}
CMP128(<)
CMP128(>)
CMP128(>=)
CMP128(<=)
#undef CMP128
inline uint128 uint128::operator~() const {
return uint128(~hi_, ~lo_);
}
#define LOGIC128(op) \
inline uint128 uint128::operator op(const uint128& b) const { \
return uint128(hi_ op b.hi_, lo_ op b.lo_); \
}
LOGIC128(|)
LOGIC128(&)
LOGIC128(^)
#undef LOGIC128
inline uint128 uint128::operator<<(int amount) const {
DCHECK_GE(amount, 0);
// uint64 shifts of >= 64 are undefined, so we will need some special-casing.
if (amount < 64) {
if (amount == 0) {
return *this;
}
uint64 new_hi = (hi_ << amount) | (lo_ >> (64 - amount));
uint64 new_lo = lo_ << amount;
return uint128(new_hi, new_lo);
} else if (amount < 128) {
return uint128(lo_ << (amount - 64), 0);
} else {
return uint128(0, 0);
}
}
inline uint128 uint128::operator>>(int amount) const {
DCHECK_GE(amount, 0);
// uint64 shifts of >= 64 are undefined, so we will need some special-casing.
if (amount < 64) {
if (amount == 0) {
return *this;
}
uint64 new_hi = hi_ >> amount;
uint64 new_lo = (lo_ >> amount) | (hi_ << (64 - amount));
return uint128(new_hi, new_lo);
} else if (amount < 128) {
return uint128(0, hi_ >> (amount - 64));
} else {
return uint128(0, 0);
}
}
inline uint128 uint128::operator+(const uint128& b) const {
return uint128(*this) += b;
}
inline uint128 uint128::operator-(const uint128& b) const {
return uint128(*this) -= b;
}
inline uint128 uint128::operator+=(const uint128& b) {
hi_ += b.hi_;
lo_ += b.lo_;
if (lo_ < b.lo_)
++hi_;
return *this;
}
inline uint128 uint128::operator-=(const uint128& b) {
hi_ -= b.hi_;
if (b.lo_ > lo_)
--hi_;
lo_ -= b.lo_;
return *this;
}
inline uint128 uint128::operator++(int) {
uint128 tmp(*this);
*this += 1;
return tmp;
}
inline uint128 uint128::operator--(int) {
uint128 tmp(*this);
*this -= 1;
return tmp;
}
inline uint128 uint128::operator++() {
*this += 1;
return *this;
}
inline uint128 uint128::operator--() {
*this -= 1;
return *this;
}
#endif // BASE_INT128_H_
Это чтобы было понятно как строится доступ к 128 битам
Offline
Специально заснял с камеры видео как работает физика на ноуте, показывает реальное состояние дел с физикой:
Его конфигурация:
emachines - E642G
AMD Turion II X2 P540 (~2,4 Ghz)
ATI Mobility Radeon HD 5470
3GB RAM
Offline
Offline
Нормально физика работает.
видео заснял как ответ на:
ANABIOS101 wrote:Мне не кажется ?! Что 128 идет лучше и без лагов! А 64 я заметил лагают кубики.
Кажется, в реальности, fps выше и плавнее все идет.
Offline
Offline
Offline
Offline
думаю еще траблы баблы с сетью, или что на это скажет Роман?
физика с Convex тормозит
она как раз отвечает за разные формы в том числе корабли
Offline
Sarmath wrote:думаю еще траблы баблы с сетью, или что на это скажет Роман?
физика с Convex тормозит
Convex я так понял это не ровная фигура?
amatory/Sarmath
Mы все летим на самолете
мы едем в поезде в авто
а вот земля она тоскует
по нежному теплу ступней
Offline
Offline
Думаю со мной многие согласятся тут - не будем подгонять Романа(типо "давай по быстрее демку," мне так уже не раз заявляли, приходилось культурно объяснять)
В конце концов многие увидят не то, что ожидали, я почти уверен, а что у нас на самом деле должно быть? На этот вопрос я постараюсь ответить по мере своей осведомленности:
- У нас осталась та же голая планета и огромные просторы дикой природы.
- У нас наконец то будет оптимизированная физика, то есть могут быть разные предметы, начиная булыжником(грубо говоря) вплоть до межзвездных крейсеров.
- У нас будут корабли, доступны пока только досветовые полеты.
- у нас будет возможность путешествовать не только по одной планете
Но все это не будет законченной версией игры, самое интересное только начинается.
- И самая главная возможность - это конечно же, что мы сами можем совершенствовать и дополнять этот мир и уже решать, какую профессию мы выберем.
Ура товарищи!
amatory/Sarmath
Mы все летим на самолете
мы едем в поезде в авто
а вот земля она тоскует
по нежному теплу ступней
Offline
Переписал большую часть физики.
- Более стабильная физика
- Добавлено обратное взаимодействие между объектами
Offline
Offline