Delphi RPG

[ruN00b]

Ну, в общем, я его попробую, создав новый проект. У меня на новом проекте FPS 64-66, если там алгоритм больше десятой части отъедать не будет, то добавлю.

[Kix.IV]

Кстати, у меня билд обозначает кол-во строк в коде главного окна игры.

Ужас. Я вам рекомендую разделить код на модули, так будет гораздо проще работать. И это поможет избежать многих проблем в будущем.

[ruN00b]

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

Кстати, давно никто не тестировал игру так, чтобы было видно, что человек тестировал ее не менее 5 минут. Может кто-нибудь уделить время игре?

Заметил пару багов: у посоха не отображается префикс (редкий, древний и т.д) и он не продается в магазине.

[Arigato]

Сообщение от ruN00b

Я в каждом модуле знаю, примерно на какой строке что находится.

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

[ROD]

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

[Beermonza]

Сообщение от ROD

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

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

[Arigato]

Сообщение от Beermonza

Объект TTimer не реагирует на интервалы 1,2,3,4 ...15, это бесполезно, только на кратные 16.

Простая программка для теста:

var
  Start: LongWord;
  Count: Int64;

procedure TForm1.FormShow(Sender: TObject);
begin
  Timer1.Enabled := True;
  Count := 0;
  Start := GetTickCount;
end;

procedure TForm1.Timer1Timer(Sender: TObject);
begin
  if GetTickCount - Start >= 10000 then begin
    Timer1.Enabled := False;
    ShowMessage (IntToStr (Count));
  end else Inc (Count);
end;

Ставлю интервал 16, получаю 386, интервал 10 - 639, 1 - 639. То есть между 1 и 10 разницы нет, а вот между 10 и 16 разница в 1,6 раз.

Дальнейшие тесты показали, что при интервале в 15 тоже выдает 639. То есть минимальный интервал, который имеет смысл ставить для таймера - 15.

Построим таблицу результатов:

< 16 - 639
16 - 386
17..31 - 319
32 - 239
33..46 - 213
47 - 187
48..62 - 159
63 - 133
64..77 - 127
78 - 121
79.. - 106

Действительно, вокруг интервалов, кратных 16, происходит реальная смена скорости работы таймера. Но интересно, что смена именно вокруг таких значений, а не конкретно на них, то есть интервалы 46, 47 и 48 дают разные скорости таймера.

[intmain]

Действительно, вокруг интервалов, кратных 16, происходит реальная смена скорости работы таймера

Возможно дело в этом.

Функция timeBeginPeriod(1) призвана повысить разрешение multimedia и waitable timers до 1ms. На самом деле, таймеры обрабатываются планировщиком, и их события не могут возникнуть чаще, чем планировщик получает управление. Понижая quantum до 1ms, мы позволяем планировщику более точно вызывать события таймера.

http://www.dtf.ru/articles/read.php?id=39888&page=2

[Beermonza]

Сообщение от Arigato

Действительно, вокруг интервалов, кратных 16, происходит реальная смена скорости работы таймера. Но интересно, что смена именно вокруг таких значений, а не конкретно на них, то есть интервалы 46, 47 и 48 дают разные скорости таймера.

"Вокруг" из-за того, что интервалы идут "вагончиками", изменение происходит при переходе на следующий "вагончик", внутри которого выполняются операции. И кратность слегка плавает, и из-за версии ОС и из-за приоритета программы. В user32.dll зашиты все ассемблерные коды, можно посмотреть на счёт таймера, но там множество кода и джампов, очень сложно вычленить нужный кусок, поскольку код как монолит, множество входов и выходов.

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

Ещё есть одна интересная вещь. На разных машинах Canvas ведёт себя по-разному. Где-то быстрее, где-то медленнее. И таймеры ведут себя аналогично.

[ruN00b]

Arigato, уж не сомневайтесь, не забуду. У меня давно был один проектик, года четыре так назад, кода в нем было, может, не 8 тысяч, как тут, а где-то 5. Но спустя эти 4 года я забыл там только одну 40-строковую процедурку.

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

Есть один вопрос: как выжать из цикла FOR максимум производительности? А то из-за него у меня FPS в игре 14-15 кадров вместо должных хотя бы 30.