Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 26
столкнулся как то с тем, что у многих фкнкций, здоровье и т.п. изменения типа минмакс. т.е. мы всегда присваиваем. вне зависимости поменялось значение или нет. и все варианты отладки в тулсете плохо подходят. нужны кондишенейбл бряки, что в коде.
значит такие программисты писали
это функции. функция это то что всегда возвращает рузультат. описываются декларативно и не программистами. например функции minmax, clamp, lerp и все такое. програмисты не пишут абилки, эффекты и функции изменения параметров статов сущностей.
Это нормальная практика, использовть одну строку, вместо 5 строк if/else.
Тут другой вопрос, почему переменныке не обернули в getter/setter, который скипнет модификацию, если значение не поменялось.
А еще на setter можно брекпоинт поставить и логи в нем напечатать.
Современные дебагеры могут на breakpoint ставить свою проверку и свой скрипт. Т.е. зачастую можно отследить, менялось ли значение, не влезая в код самой проги (актуально, когда перекомпиляция или повторный запуск занимает много времени и требует усилий... Если писать юнит–тесты – надобность в этом сильно уменьшается).
логировать - состояние, статусы, если рпг система все получения еффектов, и наверно чтобы была возможность отключать еффекты
есть еще приколы, помимо поиска пути есть еще высота(она частично физика тоесть коллизия с террейном, тут тоже логировать наверно)
тоесть вы наверно о том случае кто именно отнял здоровье во время Н, при состоянии и статусе П
там же касания могут быть по обьему, в случае получения урона от абилки, еще нюанс, как происходит выбор цели, в одном случае в лог попадает выбранная цель и если игрок наносит урон цели, цель включает состояния,берет в таргет игрока - лог, урон получается -лог, когда детектится или нет урон-лог, смотря какая система - рпг или нет
а если игрок не выбирает, а сразу пускает луч, ну тоже самое таргет, урон, цель взяла в таргет игрока, пустила урон
тоесть нужна система логирования
система боя - потомучто если будет больше 1 нанесения урона надо по очереди наверно их обрабатывать, потом надо как-то убегать тоесть отводить/завершать бой, в том числе и абилками(абилки тоже система)
тоесть это общение обьектов в зависимости от их состояний при взаимодействии
тоесть должна быть приписка по получению урона, урона бывает разный от луча или по истечению времени луч, или физическое касание, но если физическое касание у обьекта, который летит от которого будет получен урон, есть обьект, который изменил своё состояние из-за взаимодействия, соотв по лучу видно обьект такой-то, статусы такие-то завершения нету, значит они покачто взаимодействуют
это конечные автоматы, луч или обьект это как передатчик сообщения для взаимодействия
хорошо более наглядный пример, при прыжке(или при появлении задали высоту 1000 юнитов) кто отнимает высоту у обьекта при падении до уровня высоты
и второй случай, в графе, в мире -+- +++, при нахождении пути мы опираемся на высоту найденную или произойдёт фикс высоты при опр случаях, в идеале граф хранит высоту, но нужна корректировка например будет
и следующий пример при переходе из карты в карту пещеры, там поидее теже ситуации
Статья - роскошь!
у движка должно быть отделено, что движок(вот например как блендере есть отделение и раздел конфигураций, можно и через lua того же добиться(1)), а что запущено аля плейгроунд(редактирование IDE в игре визуальный с возможностью сохранения конфигурации на основе версии движка), имгуй - надо заменить на свой интерфейс плейграунда, тоесть это тестовый билд как раз, есть еще gdb -help, lldb -help
вот ваш код для дебагинга это функционал той части того плейграунда специального
чтобы дизасемблировать свой же код можно просто скомпилировать с флагом -S
1-это нужно для того, чтобы дебажить то что на выбранном уровне и только из этих обьектов, зачем например дебажить отрисовку и всю низкую ситуацию, а это приводит к дебагу типа данных и его состояний только и всего (тоесть это уже движок с каким-нибудь lua rtti)
Я правильно понял что Вы описываете систему, где движок и "плейграунд" (редактор на базе движка) разделены по слоям, с возможностью отладки через gdb/lldb, кастомным интерфейсом вместо ImGui, и использованием Lua для настройки и рефлексии — то есть речь о модульной архитектуре с возможностью сериализации отдельных компонентов? В теории всё верно, на практике зависит от того как развивался движок
да, только это проще можно сделать чем в той таблице какую вы показывали - там всё переусложнено
вот движок варкрафта даёт интерфейс lua
получается дебаг почти в игре в процессе прям
пример блендера, дизайнер не имеет доступ к отрисовке, к апи, он имеет доступ только к УГО и дебажит по своему
тоесть поставили свет, террейн, сказали прилепай, далее поставили камеру, нажали кнопку произошел конфиг, я так себе представляю, и далее при запуске от конфига запустилась сцена, которую выставил дизайнер, и при сейве произошла подготовка манифеста грубо говоря(тоесть альфа билд)
rttr что-то этим можно сделать, что-то от lua получается
А можно переформулировать этот текст? К сожалению, я ничего не понял :(
ну дизайнер не должен иметь доступ к апи отрисовки, он имеет доступ только к компонентам образно, подготовленным в движке или зарегестрированными самим дизайнером
тоесть вопрос как проверить функционал портала? лезть в дебагер если можно в игре проверить на манекене
поэтому мы делаем ту вьюшку окно(пример UCR1lHrfxY01XYSoVJJAi-xQ) и прочее, манифест это просто манифестация записи конфигурации и компановка обьектов в образе, тоесть внешний клиент для запуска
манифест это простейшая компановка образа по типу как в яве, есть и лучше подходы, если формат у студии свой имеется
вы в том примере показали стрелу, так вы хотите ставить брекпойнт на стреле получается? и зачем, если типы в движке становятся подобными примитивами, и отражают только состояния, я хочу сказать что вы в коде хотите найти если обьект (условно тип Б с состоянием ) уже в игре и у него есть флаги, которые проще прочекать в игре прям, тоесть как бы вы скелетную анимацию так же дебажите?
тогда шейдеры тоже надо дебажить
а обьекты вы писали собираются в локальный пул, получается, обьекты уже собраны, надо только прочекать их состояния - логику, зачем брекпойнт - то прям
у меня вам встречный вопрос
Shader shaderText("shaders/vText.glsl","shaders/fText.glsl");
TextV textV;//VAO VBO
CharacterV charV;//структура глифа
createTextureFont(&charV,"DejaVuSansMono.ttf",48);//создание текстуры
configTextbufs(&textV);//настройка вершинного буфера
...
RenderText(&shaderText,&textV,&charV,"TESTFSDFSDFSDF",10, 100,1, glm::vec3(1.0f,1.0f,1.0f), Oproj);
struct Character
{
GLuint TextureID; // ID texture glyph
glm::ivec2 Size; // size glyph
glm::ivec2 Bearing; // offset
GLuint Advance; // step
// ~Character()
// {
// glDeleteTextures(1, &TextureID);
// }
};
struct CharacterV
{
FT_Library ft;
FT_Face face;
std::map<char, Character> Characters;
};
struct TextV
{
GLuint VAOtext, VBOtext;
~TextV()
{
glDeleteBuffers(1, &VAOtext);
glDeleteVertexArrays(1, &VBOtext);
}
};
void createTextureFont(CharacterV *characterv,std::string path,int size);
void configTextbufs(TextV *text);
void RenderText(Shader *shader, TextV *textV, CharacterV *characterv, std::string text, float x, float y, float scale, glm::vec3 color, glm::mat4 &proj);
зачем тут нужен может быть дебагер? ну портанёт он меня в файл Font.h и?
специально для этого примера я разбил логику эту потомучто вершинный буфер, шейдер, инициализация, и отрисовка совсем разные части
а значит дело в логике
вопрос можно расширить, тут писали, допустим баг, пользователь нажимает пробел и прога вылетает. окей там портянка на 30тыщ строк, вы предлагаете через дебугер пропустить код, окей, но в коде там видно же где ошибка вы так не думаете?
тоже самое со скелетной анимацией, почему может не помоч дебагер, в дебагере можно найти место где попадает матрица не того вида, в теории да наверно, но это же этап отладки, а значит первичный запуск скелетки не в движке, а вынесен в мини тест и там можно просто бряку поставить, например если нужна ускоренная своя математика, тоесть это сидеть с дебагером вы предлагаете проверять результаты по дебагеру получается, еслиб всё так просто было, щас еще ссылкой кинусь
А можно переформулировать этот текст?
Лучше не надо, а то может получиться хуже. Пускай за ним нейросеть разбирается и доводит текст до человеческого состояния.
Недавно узнал, что у молодёжи норма писать без заглавных и без точек, т.к. они якобы лишние.Действительно, читать без них не проблема, но сам текст у него какой-то поток сознания. А ещё он не любит Э.
За статью спасибо! Как-то раньше не задумывался как это реализовано, хотя буквально на прошлом курсе ВУЗа про регистры отладки в учебнике сказано было только, что они есть и сколько их))
P.S. не сочтите за тошноту - "страндартному" (чуть-чуть ошибка)
Тут возможно два варианта
А первый вариант как то реализуется без Trap Flag?
Зависит от дебаггера. Например, в том который мы делали, для выполнения 1 инструкции вызывался софтверный эмулятор, т.к. это было быстрее чем переключать режимы процессора ради исполнения 1 команды.
Верю что быстрее, но реализовать эмуляцию произвольной инструкции, скажем, на x86 или ARM с разнообразными расширениями - задачка весьма серьёзная.
задача сложности разработки на поверхности, если писать всё в 1 файле, то попроще на -1 этапе, далее идут слои, архитектура, при написании слоёв и архитектуры свой дебаг режим, а при момент когда игровой обьект попал на сцену, при условии, что платформа - тоесть софт для запуска плейграунда готов, задача я считаю сводится к отладке этого обьекта(тип этого обьекта после слоя отрисовки, к сожалению несет только логику и какие-то позиции), далее пока будет реализовываться архитектура, скорее всего из-за сложности она будет модульная, а в модульную систему ввод модуля вводится не в лоб и отлаживается, по началу же кусок задачи, который в модуле проще отладить в консоле. И сам прототип-модуля можно запустить по брейкпойнтам, тоесть ну не знаю смысл внутрянку в сборе пойнтами дебажить
просто попробуйте наивно начать разрабатывать такого рода проекты, и вы увидите ситуацию надеюсь, как бы там и будет то о чем говорит топик стартер, есть уровень (террайн, и обьекты на нём, и обьекты от еффектов)
на -1 уровень можно без архитектуры сделать при условии, что в дальнейшем можно отрефакторить, при этом, на 1 уровне разного скейла можно и коротенькую игру сандбокс сделать, еще учитывайте, что скелетная анимация может быть(а она тоже будет модулем для этой системы - отсюда следует перед вводом её надо отдебажить, проверить).
при этом если взять команды блендера, да он имеет команды отрисовки, но пользователь же не с ними контактирует, так что емуляция такого рода это индивидуально скорее всего.
что такое тип Инт - число
что такое слой отрисовки - это набор абстракций обеспечивающий отрисовку и тесно соприкасается с вызовами отрисовки и драйверами(тоесть есть 2 случая, обьект рисуется, и обьект активен в 3д мире - это 2 разные ситуации 1 обьекта)
что такое слой обьектов в такого рода системе - это scope только по визуалу, та логика и обьекты с которой взаимодействует первично дизайнер как раз, я может и ошибаюсь, но пока такое вижу
тоесть на уровне scope обьектов условном анриале, можно на блюпринте написать специализированный чекер, который будет чекать обьекты на сцене
тоесть давайте упростим 2 уровня до консоли
в первой задаче мы работаем с геометрией и передачей их в апи (картинки, треугольники такого рода алгоритмы)
во второй части это что-то наподобии массива интов или флоатов и связанными с ними логиками (например всякие поиски, пересечения, передвижение, точка и прочее)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Сам себе breakpoint