Cheb's Game Engine

[Cheb]

Для чего мне нужна макстмальная производительность сериализации: присоединение клиента к серверу требует передачи полного снапшота мира. Снапшот делается той же сериализацией. В том же потоке, что однопоточная физика: состояние нельзя продвинуть, пока идёт обход графа.
Результат: на время снятия снапшота сервер замирает, отстаёт и не может слать авторитарные события прошлого клиентам (поскольку их валидация - часть логики). А потом ещё вынужден догонять своей физикой реальное время.
Учитывая оптимистичное время создания снапшота - 50 милисекунд при максимальной расчётной сложности мира - это немало. У всех клиентов притормозит, отставая, базовый слой реальности, отчего вырастет нагрузка на цпу (опять же, физика может использовать только *одно* ядро) а лагокомпенсация станет более дёрганой и заметной.
Лагокомпенсация всего мира:
- то, что происходит "само по себе" по воле псевдорандома - происходит абсолютно гладко, без малейших искажений или отставаний.
- то, на что влияет только локальный игрок - происходит абсолютно гладко, без малейших искажений или отставаний
- то, что происходит под воздействием удалённых игроков - может идти дёргано, проявляясь внезапно (напр., ракеты возникающие прямо в воздухе, дырки в стенах, скачущие с места на место, если удалённый игрок подправил прицел, не отпуская зажатую лкм). Если происходит воздействие других игроков на локального - прямое или опосредованное - его движения и результаты его действий тоже могут подёргиваться и перескакивать.

АРГХ, когда я до этого доберусь то
Отлаживать буду сразу на Чероидах.

Добавлено спустя 5 часов 42 минуты 7 секунд:
Пока нет хороших идей, *как* это всё связать с рендером. То, что наблюдатель (игрок) видит как один лагокомпенсированный объект, на деле - чехарда сменяющих друг друга объектов, порождаемых во всплывающих слоях и каждые два-три кадра удаляемых, чтобы смениться новыми "почти такими же". Какого-то единого айди у них в принципе быть не может.
Ставит, знаете ли, крест на многих оптимизациях "хранить на видеокарте и подставлять лишь параметры".
Включая, блин, потенциально всю карту, если на ней происходят массированные изменения ландшафта.
То есть, для меня низкополигональность мира - не просто эстетический выбор, я ограничен бутылочным горлышком наихудшего случая "вся геометрия перезаливается на GPU каждый кадр". Конечно, там могут быть понавтыканы статические или даже анимированные модели, хранящиеся на видеокарте. Но основа должна быть низкополигональная.
Ну и ладно, я с самого начала замышлял ландшафты в стиле второго квейка или первого анрила. Решение использовать редакторы думских карт типа GZDoom Builder - лишь вишенка на торте.

[Cheb]

Страшнобаги в диспетчере памяти - даже не заглядывал ещё, зато удавил одну застарелую O*N^2 (cм. пост от 27 ноября 2016: viewtopic.php?f=9&t=1137&p=83396#p103500 )

сейчас, когда у записей/классов встречается поле типа запись, статический массив или массив, индексируемый перечислиимым типом, они разлагаются на составляющие, и у родительской записи/класса регистрируются поля с именами наподобие
a
b
c.a
c.b
d[eklmn_empty]
d[eklmn_first]
Это просто, надёжно, но пространство имён засирается страшно. Боюсь, на любом реальном применении начнёт тормозить парсинг заголовка потока, а регистрация - занимать совершенно неприличное время

- и вот, наконец, беременная улитка доползла, при сборке в третьем фри паскале теперь применяется специализация TMap:

Код: Выделить всё

function TNameSpace.Ind(i_s: Utf8String; AssumedInd: integer): integer;
var
  i: integer;
begin
  Result:= -1;
  if (AssumedInd >= 0) and (AssumedInd <= High) and (Self[AssumedInd] = i_s)
  then begin
    if Alias[AssumedInd] >= 0 then Result:= Alias[AssumedInd]
                              else Result:= AssumedInd;
  end
  else begin
    {$ifdef cps_use_stl}
    if not Assigned(map) then RegenerateMap;
    if not map.tryGetValue(i_s, Result)
      then Result:= -1
      else if Alias[Result] >= 0 then Result:= Alias[Result]
    {$else}
    for i:= 0 to High do
      if Self[i] = i_s then begin
        if Alias[i] >= 0 then Result:= Alias[i]
                         else Result:= i;
        Break;
      end;
    {$endif}
  end;
end;

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

[Alex2013]

Я в ужосе ... как представлю насколько должен быть совершенен твой проект если даже проблемы решаемые на текущем уровне его развития на столько уровней абстракций выше всего, что я когда либо пытался делать... Да, это называется ЗАВИСТЬ! Но в то же время не плохо так вдохновляет ...

Однако хотелось бы увидеть хоть минимальную демку уровня "пустой автогенерируемый уровень" по которому можно побродить. К черту баги ! Никто не ждет от "свежего кода" сияющего совершенства (его нет и в релизах просто обычно с наступлением дедлайна разрабы затыкают заглушками и пустышками самые "вкусные" и сложные фишки и делают операцию "чудо Франкенштейна на минималках" )

[Cheb]

Тестовая игра - будет. Этой осенью, ориентировочно. Потому что очень хочется наконец подстричь бороду во что-то более практичное.
Сначала надо страшнобаги в платформе выполоть и довести до идеального состояния, какой она была в 2017-м, до большого перетряха.
То, что я привёл - не слой абстракции, а ключевой механизм СУБД (фактически, дублирование RTTI в удобной для меня расширенной форме). Все помнят, что игра - это база данных с красивым интерфейсом, и не имея нормальной СУБД игру нечего даже и начинать делать?

[Alex2013]

Все помнят, что игра - это база данных с красивым интерфейсом, и не имея нормальной СУБД игру нечего даже и начинать делать?

Угу ! "Магия это физика!(с)Писатель техно-фентази ... а религия это бюрократия! (с) "голос из зала" .

То, что я привёл - не слой абстракции, а ключевой механизм СУБД

Я немного не о том ... Даже сам ид NameSpace говорит, что "внутренняя система" изрядно абстрагируется от конкретных данных и работает с разного рода "абстракциями энного порядка" когда "конструкты над конструктами конструктами погоняют ".

Тестовая игра - будет. Этой осенью, ориентировочно.

Это определенно радует!

Потому что очень хочется наконец подстричь бороду во что-то более практичное.

Так почему бы не совместить? Ведь как известно "Нет ничего практичнее хорошей мечты! " и "Нет никого практичнее настоящих романтиков !"

[Cheb]

Ух... Я когда этот код закладывал (в 2006-м) был ещё не очень хорошо знаком с терминологией.
Это "пространство имён" - на самом деле таблица сопоставления имён типов в RTTI целочисленным индексам типов во внутреннем представлении СУБД, а также приведения имён полей к целочисленному. В структуре данных, списки полей записей и классов хранятся в формате (смещение, имя, тип), три целых числа. Такой же формат получается при десериализации. Но если структура данных в файле не совпадает с актуальной (поля добавились, удалились, поменялись местами) - требуется перевод этих целочисленных имён из пространства файла в пространство программы - для чего строятся соответствующие таблицы.

И вот этот поросёночек давал страшное o*N^2 - учитывая, что у меня статический массив из трёхсот элементов засчитывается, как триста полей с именами типа a[a0]..a[a299] - упрощение, чтобы алгоритмы не взорвали мне мосх.
Надо ещё ускорить Ind() кешированием последнего запрошенного и проходом по паре соседних, чтобы при переводе почти идентичных списков даже обращений к map почти не было.

Код: Выделить всё

function TNameSpace.Translate(RegNS: TNameSpace): TAOI;
var
  o: TAOI;
  i: integer;
begin
  o:= TAOI.Create;
  o.Length:= Length;
  For i:= 0 to High do begin
    o[i]:= RegNS.Ind(Self[i], i); //to speed up translation of identic name spaces
//if Mother^.Debug.Verbose then AddLog('---NS tran: %0 %1 %2',[i, Self[i], o[i]]);
  end;
  Result:=o;
end;

Добавлено спустя 12 минут 9 секунд:
З.Ы. Туплю. Не надо ковырять Ind(), у него уже кесть встроенный механизм "предполагаемый айди" для ускорения.
Достаточно было вместо идиотского "индекс моего пространства" слать "следующий того пространства, в который преобразую". У похожих списков, где куча последовательностей совпадает - перескоки будут редки и сложность выродится в o*N. Чего и вам желаю.

Код: Выделить всё

function TNameSpace.Translate(RegNS: TNameSpace): TAOI;
var
  i, prev: integer;
begin
  Result:= TAOI.Create;
  Result.Length:= Length;
  prev:= -1;
  For i:= 0 to High do begin
    prev:= RegNS.Ind(Self[i], prev + 1); // assuming both are similar
      // this trick of trying the next in list must speed things immensely,
      // bringing the performance close to o*n
    Result[i]:= prev;
  end;
end; 

Добавлено спустя 20 часов 38 минут 5 секунд:
Мдя... Как говорил рядовой Снафу - "ситуация нормальная, полный п..ровал".
Оказывается, диспетчер памяти для *каждого* 128-килобайтного чанка выделяет новый блок (50 мегабайт).
Да этот вообще резервным должен быть, одного изначального блока должно хватать, пока я не наворочу что-то истинно выдающееся.

(thread #0) Init database...
(thread #0) ..TChepersyMemoryManagerChunk.NewInstance: block = TChepersyMemoryManagerBlock(09DC81E8h) allocated 16800000h
(thread #0) ..GetActiveChunk(0): created TChepersyMemoryManagerChunk(16800000h)
(thread #0) Database init completed.
(thread #0) The root logic class is TKonkurs2020Logic
(thread #0) ..TChepersyMemoryManagerChunk.NewInstance: block = TChepersyMemoryManagerBlock(09DC8428h) allocated 1A840000h
(thread #0) ..GetActiveChunk(4): created TChepersyMemoryManagerChunk(1A840000h)
(thread #0) Hint: Class TKonkurs2020Logic is alraedy registered (#2).
(thread #0) ..TChepersyMemoryManagerChunk.NewInstance: block = TChepersyMemoryManagerBlock(09DC86F8h) allocated 1E880000h
(thread #0) ..GetActiveChunk(1): created TChepersyMemoryManagerChunk(1E880000h)
(thread #0) Hint: Class TTexture is alraedy registered (#14).
(thread #0) Hint: Class TManagedFbo is alraedy registered (#15).
(thread #0) ..TChepersyMemoryManagerChunk.NewInstance: block = TChepersyMemoryManagerBlock(09DC8EA8h) allocated 228C0000h
(thread #0) ..GetActiveChunk(2): created TChepersyMemoryManagerChunk(228C0000h)
(thread #0) ..TChepersyMemoryManagerChunk.NewInstance: block = TChepersyMemoryManagerBlock(09DC9628h) allocated 26900000h
(thread #0) ..GetActiveChunk(3): created TChepersyMemoryManagerChunk(26900000h)

Добавлено спустя 20 минут 20 секунд:
Какого...

(thread #0) ..GetCurrentActiveBlock..
(thread #0) ..TChepersyMemoryManagerBlock(08CC81E8h).IsFull=True
(thread #0) ..TChepersyMemoryManagerBlock(08CC8428h).IsFull=True
(thread #0) ..TChepersyMemoryManagerBlock(08CC86F8h).IsFull=True
(thread #0) ..TChepersyMemoryManagerBlock.Create: base=1E8A0050h, allocbase=1E8C0000h, numfreechunks=512
(thread #0) ..TChepersyMemoryManagerChunk.NewInstance: block = TChepersyMemoryManagerBlock(08CC8EA8h) allocated 228A0000h
(thread #0) ..GetActiveChunk(2): created TChepersyMemoryManagerChunk(228A0000h)

Добавлено спустя 12 минут 8 секунд:
Вы видите здесь break?
Правильно, я тоже не вижу.
Дурак старый

Код: Выделить всё

function TChepersyMemoryManagerBlock.AllocChunkStorage: pointer;
var num: integer;
begin
  Assert(not IsFull, 'Full block cannot alloc chunk storage.');
  for num:= 0 to High(Occupied) do
    if not Occupied[num] then begin
      Result:= pointer(ptruint(AllocBase) + ptruint(num * CpsMMChunkSize));
      Occupied[num]:= True;
      Dec(NumFreeChunks);
      Inc(NumAllocatedChunks)
    end
end;

Добавлено спустя 6 минут 6 секунд:
..иии, теперь я точно знаю, что где-то запарывается память. Вот радость-то, опять ловить чёрную кошку в тёмной комнате

[Cheb]

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

Вывод: гордиевы узлы не распутывают. Их разрубают.
Выдеру кусок функционала с мясом и буду делать с нуля. Быстрее выйдет.

[Alex2013]

Рад что проект выжил ( вместе с проектировщиком )!
Зы
Если у меня что-то что-то заходит в тупик я обычно просто "откатываю разработку" до условно рабочей ветки (иногда довольно далеко ) и переписываю "загадочный" кусок причем по возможности совсем другим образом. Обычно получается в разы быстрее чем при пребывании "глубоком отрицании" то бишь отладке.

[DYUMON]

Может уже забить. И начать писать с нуля?

[Alex2013]

Может уже забить. И начать писать с нуля?

Ну это уже (ИМХО) перебор....

[Cheb]

Мне некуда откатывать, только вперёд. Добававился новый функционал и понадобились фичи, которых в "последней работающей версии" просто не было.

К сожалению, на работе сейчас занятой сезон, плюс я взялся переписывать один свой старый роман из фанфика по Ранме и Сэйлор Мун в самостоятельное произведение с моими собственными героями и сеттингом. А это - 250 тысяч слов одна только английская версия. Не волнуйтесь, вместе с русским оригиналом (а их надо тщательно синхронизировать и переводить любые добавления) полный объём - чуточку побольше "Властелина колец" но чуточку поменьше "Войны и мира". Этакий, право, пустячок. Я уверен, много времени не уйдёт.

[Alex2013]

Кстати, то что я писал в отношении "Акулы" частично подходит и для твоего Мега Движка.

"по примерам" viewtopic.php?p=162297#p162297
"по утилитам в поставке движка" viewtopic.php?p=162392#p162392

(Уровень у Cheb's Game Engine явно выше и он более прикладной + сразу разрабатывается "главное приложение" chentrah, так что первый спич "по примерам" можно пропустить, но вот второй "по утилитам в поставке движка" частично актуален и для CGE. )

[Cheb]

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

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

[Alex2013]

Планируется редактор моделей и анимаций

Ну так это почтит тоже самое что я предлагаю (редактор карт и сцен для chentrah? не как я понял? неактуален (или мало актуален) вииду генерации ландшафта )? но вот то что я назвал "суб-движок" (ИМХО) актуально и даже более сильно чем для Акулы.
Основные идеи.
1 Генерация мини сюжетов и квестов ( типа "Королева демонов объявляет охоту на снарка..." это генерация, но она на что-то должна опираться )
2 Скрипты поведения, это не просто анимация, а стиль как в варкрафте (Крестьяни "Я тупой- но я сделаю",и сакраментальное "Сэр,вы насрали на мою лошадь !" ) и хорошо бы это была не только текстовка, но и характер "хромой подлец","ловкий лопух","сильный хряк ","честный служака" )
3 Описание скриптовых ституций типа "бежит персонаж,а в пререди пропасть - тормозит заглядывает чешет затылок" .
4 Описание взаимодействия персонажей и "жизнь среды". (Пресловутая система "А-лив" из сталкера разве что чуть попроще )
5 Описание разнообразных "стихийных бедствий" и просто погоды, смены времени суток и сезонов года.
6 Описание процессов разрушения с течением времени и "строительные скрипты".

Разумеется большую часть всего этого можно задать "железно" но если сделать спец. утилиту это сразу даст простор для фантазий!
Зы
Даешь "Chentrah Art OnLine" Кодзима нервно курит !

[debi12345]

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

МСЕ АФАЙК не поллит изменения файлов, а хук на события файловой системы вешает, и все эти бзыки - именно от файловой системы (неучтенные,к которым ИДЕ тупо не готово, события в которой много чем могут вызываться)