doom2d.org
https://www.doom2d.org/forum/

Замечания по особенностям поведения кода игры
https://www.doom2d.org/forum/viewtopic.php?f=38&t=3240
Page 1 of 1

Author:  Чёрный Думер [ 17 Sep 2023, 22:03 ]
Post subject:  Замечания по особенностям поведения кода игры

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

Когда я сегодня делал вот эту штуку, то нечаянно напоролся на следующую ситуацию.
Берём и из условия проверки наступления середины анимации смерти авиабазы убираем вот это условие:
Code:
and (FAnim[FCurAnim, FDirection].Counter = 0)

Это проверка на то, что кадр только что сменился. Без неё черепки будут создаваться на всём протяжении кадра, а не только в момент его появления.
Очевидно, что это неправильно. Но если судить сугубо по коду, то помимо этого больше ничего озадачивающего происходить не должно.

Однако если теперь скомпилировать игру, запустить приложенную в вышеупомянутом сообщении карту и сначала убить элементаля любой ловушкой, а затем сделать то же самое с возникшими черепками, то... игра вылетит с вот таким вот выхлопом:
Code:
[4:28:16] !!! Access violation
=====================
  $004AB6FD  TMONSTER__ALIVE,  line 4452 of g_monsters.pas
  $004AC629  G_MONS_FOREACHALIVEAT,  line 4871 of g_monsters.pas
  $004D660A  TR_CLOSETRAP,  line 428 of g_triggers.pas
  $004D8A9D  ACTIVATETRIGGER,  line 1323 of g_triggers.pas
  $004DE8C5  G_TRIGGERS_PRESSR,  line 2934 of g_triggers.pas
  $004BFFAB  TPLAYER__USE,  line 5611 of g_player.pas
  $004BEB67  TPLAYER__UPDATE,  line 5192 of g_player.pas
  $004B3AE6  G_PLAYER_UPDATEALL,  line 1370 of g_player.pas
  $00456EBF  G_GAME_UPDATE,  line 2238 of g_game.pas
  $00480C5F  UPDATE,  line 686 of g_main.pas
  $004E8211  PROCESSMESSAGE,  line 146 of g_window.pas
  $004E8CB9  SDLMAIN,  line 377 of g_window.pas
  $00480B36  MAIN,  line 576 of g_main.pas
  $00401F72  main,  line 238 of Doom2DF.lpr

Я не смог понять, почему такое происходит, исходя из одной лишь логики близлежащего кода.
Может кто-нибудь глянуть? Вдруг это баг какой-нибудь в grid.

Author:  Чёрный Думер [ 02 Jan 2024, 20:56 ]
Post subject:  Re: Замечания по особенностям поведения кода игры

По поводу вышеописанного pss88 прислал мне тогда же в личку вот такое дополнение:
pss88 <18 сен 2023, 07:38> wrote:
По поводу вот этой темы.

У меня тоже такое было, когда я создавал по 1 приколисту в тик, а потом их всех сАгрил.
Так что наверное проблема всё же не в grid'е.

А также сегодня в чате falcon наконец-то прояснил сущность проверок на чётные тики в коде игры:
Георгий, [02.01.2024 21:42] wrote:
Не помню, рассказывал или не.

В д2д, UPS был равен частоте перываний от таймера - 18.2Гц. Соответственно, физика была завязана на это значение.
При переводе физики в реалии ДФ, оказалось, что (с учетом 2х разрешения у спрайтов) двойная скорость обновления координат (х,у спрайта) визуально даёт идентичную д2д физику в результате.

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

Это все видно в g_Obj_Move() (внимание на c := gTime mod (GAME_TICK*2) <> 0;)

т.е. каждый тик обновляем координаты, каждый 2 тик обновляем скорость.

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

Вот такая херня. Там вобще очень много всякой херни в коде, но вот именно эта меня почему-то до сих пор беспокоит.

Да, собственно 2*18==36 UPS, т.е. задержка в 1/36с измеряется.

Dmitry D. Chernov, [02.01.2024 21:56] wrote:
ещё интересно, почему ты решил именно так сделать, а не просто все значения физики на двойку умножить
Георгий, [02.01.2024 22:03] wrote:
Сложно сказать, но вобще мне кажется что просто умножением на 2 там не обойтись т.к. помимо скорости ещё есть ускорение.
Dmitry D. Chernov, [02.01.2024 22:14] wrote:
так без разницы же. это всё равно, что запустить д2д с частотой в 36. там будет шоу бенни хилла, но лишь из-за меньших размеров графики

но вообще да, идеальным решением на мой взгляд было бы отвязать физику от размеров графики как таковой. т.е. считать её как в д2д и просто результаты на масштаб графена умножать

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

можно будет хайрез-пак для дф соорудить тогда (что? да!)
Георгий, [02.01.2024 22:24] wrote:
Это можно легко проверить, чуть подредактировав g_Obj_Move
fgsfdsfgs, [02.01.2024 22:27] wrote:
небось есть карты с панелями 1х1, лол

или на нечетных позициях
Георгий, [02.01.2024 22:32] wrote:
оставить 18 упс но умножить скорости на 2 ?

Думаю это было первое что я сделал, но результат мне не понравился по какой-то причине
Dmitry D. Chernov, [02.01.2024 22:34] wrote:
вероятно потому, что без интерполяции движение рваным получится. а так у тебя получилась эрзац-интерполяция по кадру
Георгий, [02.01.2024 22:34] wrote:
Скорее всего


С первого взгляда для поведения игры это выглядит не слишком критично.
По сути это просто внесение случайности в пользовательский ввод своеобразным образом.
Но нужно вдуматься поглубже.

Author:  Jabberwock [ 02 Jan 2024, 21:55 ]
Post subject:  Re: Замечания по особенностям поведения кода игры

Триггеры и стены 1х1 ВРОДЕ БЫ попадались где-то, иногда их имеет смысл использовать.
Надо проверить самые навороченные карты.

Пока в голову приходит только damned.wad map02. Там таким образом реализованы стенки кубиков с вопросами [?].

Page 1 of 1 All times are UTC + 3 hours
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/