Разработка

[Maelstrom]

А что не так с ИВАНом? Можно чуть поподробнее, что именно не понравилось?

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

[Bobiczdoh]

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

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

[Максим Кич]

А что не так с ИВАНом? Можно чуть поподробнее, что именно не понравилось?

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

Повторюсь, конечно, но ребята сделавшие Call of Cthulhu умудрились реализовать повреждения по частям теля в шутере(!) и не убить при этом баланс. Так что, дело в реализации, а не в идее.

[ADB]

Эх. Все никак не могу разобраться с графическим движком игры.
Скорее всего я неправильно использую какие-то инструкции OpenGL.
Как только включаю режим постоянной перерисовки, как и должно быть по идее, начинаются жуткие тормоза. Если убираю миникарту и анимацию - бегать начинает быстрее.
В чем же дело....

[Максим Кич]

Эх. Все никак не могу разобраться с графическим движком игры.
Скорее всего я неправильно использую какие-то инструкции OpenGL.
Как только включаю режим постоянной перерисовки, как и должно быть по идее, начинаются жуткие тормоза. Если убираю миникарту и анимацию - бегать начинает быстрее.
В чем же дело....

У тебя при отрисовке тайлов есть проверка выхода за пределы массива?

[ADB]

Есть все проверки. Например, рисуется только тот квадрат, который находится в области видимости.

[ADB]

Возможно, исользование OpenGL, для вывода 2D графмки - не самое лучшее мое решение. Хотелось изучить опенгл, к тому же портируемость!

[ADB]

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

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

[Maelstrom]

постоянное открытие/заккрытие файловых потоков (иногда несколько раз в секунду!), чтобы читать данные о предметах из временной БД на диске и не только.

Ё моёёё, а заносить всё в память при запуске программы никак?

[ADB]

Именно так и надо

[Максим Кич]

Есть все проверки. Например, рисуется только тот квадрат, который находится в области видимости.

Попробуй снять У меня сейчас в процессе перехода на новый движок случилась любопытная ситуация.

Я наконец-то смог собрать из подручных материалов псевдо-ASCII на основе тайлов с возможностью изменения «освещения» тайла в трю-палитре. И, соответственно, сварганил класс с кучей перекрытых функций, которые и должны были выводить тайлы в нужное место тайловой сетки. И там было тупо прописано условие:

if (x<0) or (y<0) or (x>width) or (y>width) then SomethingWentWrong()
else РисуемТайл;

После чего запускаю всю эту радость на компиляцию и офигеваю от 4-5 fps.
Снимаю проверку.
Летает.

[ADB]

Что за?
Не может быть!
Может там еще какие-нибудь подводные камни есть?

[Максим Кич]

Что за?
Не может быть!
Может там еще какие-нибудь подводные камни есть?

А что, сработало? Кстати, использование статических массивов не обязательно зло. Лично я в старой версии от 5 до 10 fps терял на работе с памятью. Помнится, очень ускорила замена
SetLength(VisMatr,0,0) на Finalize(VisMatr). Эта сволочь (VisMatr) была динамическим массивом и использовалась для всех лосей (читай, для каждого источника света + обзор игрока), на каждом кадре. Выигрыш получился чуть ли не вдвое. Но це Делфа. У тебя могут быть другие приколы.

А выход лучше ловить по эксепшинам, хотя я ещё не пробовал, оставил как есть.

[Alchemist]

Попробуй снять У меня сейчас в процессе перехода на новый движок случилась любопытная ситуация.

Я наконец-то смог собрать из подручных материалов псевдо-ASCII на основе тайлов с возможностью изменения «освещения» тайла в трю-палитре. И, соответственно, сварганил класс с кучей перекрытых функций, которые и должны были выводить тайлы в нужное место тайловой сетки. И там было тупо прописано условие:

if (x<0) or (y<0) or (x>width) or (y>width) then SomethingWentWrong()
else РисуемТайл;

После чего запускаю всю эту радость на компиляцию и офигеваю от 4-5 fps.
Снимаю проверку.
Летает.

Могу ошибиться, но большой вопрос - у тебя в вышеприведенном коде случаем width и height - не свойства с методами Get? Может быть что-то тратит производительность именно там?

А что, сработало? Кстати, использование статических массивов не обязательно зло. Лично я в старой версии от 5 до 10 fps терял на работе с памятью. Помнится, очень ускорила замена
SetLength(VisMatr,0,0) на Finalize(VisMatr). Эта сволочь (VisMatr) была динамическим массивом и использовалась для всех лосей (читай, для каждого источника света + обзор игрока), на каждом кадре. Выигрыш получился чуть ли не вдвое. Но це Делфа. У тебя могут быть другие приколы.

Друг мой, используй вместо нативных дельфевых динамических массивов, простое выделение памяти под указатель на массив, классика динамических массивов:

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

type
  TVector = array [0..0] of Integer;
  PVector = ^TVector;

var
  v: PVector;

GetMem(v, len * SizeOf(Integer));
v[10] := 5;
FreeMem(v);

Ибо, нативные динамические массивы - немеряное зло. Если ты покопаешься в исходниках rtl, то обнаружишь причину тормозов

[Dmiry]

v[10] := 5;

Может, лучше так:

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

v^[10] := 5;