Другие языки программирования и технологии

общие вопросы программирования

на парах когда проходили ассемблер, основы самые, преподаватель отметил что вот такая-то конструкция не подходит для длительных вычислений, т.к. с аналогичной однократно выполняются с разницей в какие-то там тысячные доли секунды, но если попадёт в цикл - время может очень сильно взрасти. Где можно почитать о таких нюансах? Наверно конкретно к определённому языку это не привязано, основные операторы наверно везде одинаково работают. Собираюсь игру свою разрабатывать, ищу движок простенький который модернизирую потом и т.д., да боюсь вот что в похожую ситуацию попаду просто по не знанию мелочей. Как например в такой ситуации поступать: Есть объект X, ему можно включить режим бессмертия, как его быстрее выполнять? можно выдать хп=999999999999999999, и отнимая по 15-20 единиц врядли хп до нуля упадут, или сделать отдельно флаг который при каждом получении урона проверять, если включен - хп не понижать. Ну не конкретно в этой ситуации, а вообще - стоит беспокоиться о таком? или редко случается что неправильно выбранный оператор быстродействие понизит. Видел кстати похожую ситуацию в игре одной, там определённые враги были неуязвимы для огнестрельного оружия, но если потратить с читами пару тысяч патронов (намного больше максимального арсенала) то броня всё-таки пробивалась. Насколько правильно такое?
Если Вы захотите работать над своей задачей не один, а создать команду и сделать хорошую игру, Вам очень желательно знать не только те нюансы, о которых говорит преподаватель, а много других. Более того, делая игру придётся попутно учиться не переставая.
Если Вы будете делать игру один, как получится, то можно не о чём и не заботиться. Но, возможно, что-то лучше и оптимальнее кто-нибудь сделает другой!
Max Ekimov
Max Ekimov
76 473
Лучший ответ
Да нет ничего особенного, современные компиляторы всё достаточно хорошо сами оптимизируют, но, например, оператор ++k выполняется часто быстрее, чем k++, а тот, в свою очередь, быстрее чем k=k+1... Это ловля мух.
Чтобы код был быстродействующим, следует использовать по возможности более простые конструкции, без классов, например, обычный массив, а не vector, и компилятор не .NET. Например, C# создаст гораздо более медленный код, чем C++ с компиляцией в машинные коды. Вообще же гораздо больше зависит обычно от алгоритма, чем от таких мелочей.
Любой оператор в цикле будет работать в N раз дольше, где N число итераций. Алгоритмы с циклами считаются самыми медленными. Делайте бета версию программы, смотрите где узкое место. На это есть отладчики. Увидите 2-3 строки текста где "тормозит". Вот их и перепишите.

Я считаю что каждый объект в игре должен быть унаследован от некого базового. В базовом будет указано количество его жизней. И метод "нанести урон". В наследуемых классах переопределить метод "нанести урон".

Например, для каменной стены в нанесении урона поставить 0, для живых объектов 5. Если сила атаки у всех разная, то в метод нанесения урона передавать силу атаки и множить её на множитель. У не разрушаемых объектов будет 0. Поэтому даже если у них 1000 жизней, при любой их атаке будет отниматься 0.
Андрей Матюхин
Андрей Матюхин
10 716
"Неправильные" операторы рано или поздно встретятся, но "вред" от них для быстродействия куда меньший, чем от запутанных и неоптимальных логических конструкций (логические ошибки и избыточность) . Но и это тоже не проблема, потому что умные разработчики создали профайлеры. С их помощью можно обнаружить самые "тяжелые" участки программы и изменить их. Поэтому не стоит переживать из-за неправильных операторов. Лучше позаботиться о том, чтобы программа была хорошо оттестирована не только на наличие ошибок, но и на скорость работы (если это для неё критично).
не стоит об этом беспокоиться, компилятор об этом позаботится. я сейчас тоже пишу движок, уже сложновато стало ориентироваться, большой зараза получается))
Михаил Лягаев
Михаил Лягаев
1 607
Учись кодить, мелочей много. А они - главное
про подобные нюансы - это верно. пример: пусть один алгоритм требует 10 циклов процессора, второй 100 при схожих результатах. При быстродействии в 1 млрд циклов в сек, первый выполняется за 10 наносекунд, второй за 100 наносекунд, для нас неразличимо. Но, пусть нам надо обрабатывать потоковое видео высокой чёткости 1920×1080, 50 кадров в секунду. округляя вычисления, это 100 млн пикселей в сек. Первый алгоритм справится, получим свой млрд в сек )

Я сам 3Д движок делал в С++, с классами и всяческими наследованиями и, ессно думал что мои алгоритмы самые "рульные". Ну, и что в результате? На Атлон Х2 4400 - в небольшом окошке - с тормозами ). Сразу думается про "Квэйк" и прочие первые 3Д игры.

Так что, мой совет: не стесняйтесь изучать "классические" алгоритмы.