Программирование игр, создание игрового движка, OpenGL, DirectX, физика, форум
GameDev.ru / Программирование / Форум / Exceptions в играх (2 стр)

Exceptions в играх (2 стр)

Advanced: Тема повышенной сложности или важная.
Страницы: 1 2 3 4 5 6 7 Следующая »
BatПостоялецwww31 окт. 200615:23#15
исключения нужны для удобства написания программ у них свои + и -, это тоже самое что выбирать между switch по типу и псевдо vtable'ом - вполне вероятно что поиск по индексу окажется медленнее кода сгенерированного на switch, и что с того - все? NO С++!!!
Ghost DragonПостоялецwww31 окт. 200615:24#16
> ну блин что то мне это напоминает - no boost, no stl, no vtables а иначе пепец нашему крутому игровому мегапроекту

два опроса:
1. о каком мегапроекте речь?
2. был ли STL/boost и был ли пепец? :)

BatПостоялецwww31 окт. 200615:27#17
о потенциальном :) мегапроекте которому потенциально сильно повредит использование исключений
x0rasПостоялецwww31 окт. 200615:44#18
cppguru
>Не понял, какие-такие возможности консоли предоставляют в отличие от pc?
Если у тебя валится игра на консоли, то это либа твой баг, либо баг железа. Других вариантов нет. Поэтому

>Тебе интересно посмотреть, а мне неинтересно ждать, пока он работает. Его писал
>не я, и я не лид.
Мне сразу вспомнаются случаи, как сишники "опускают" С++ даже не изучив его...
Если ты работаешь с кривой архитектурой (в частности, с кривым использование исключений), то не нужно в этом обвинять инструмент. Он в этом не виноват.

>Дефолтное поведение? Ещё есть ассерты и лог. Если свалится, то свалится, тут
>есть SEH и колстэк.
Да. Неперехваченное исключение прерывает программу.
А вот с SEH error code будет работать медленнее, чем исключения.

>Ну, что делать с bool надеюсь понятно?
В операторах и конструкторах тоже bool возвращать?

>Я их там и не юзаю. Речь о другом: если ты оставляешь шикарную возможность
>обвалить перфоманс, будь уверен: ей не просто воспользуются, ей уже
>воспользовались.
Даже если так, то насколько я его обвалю?
По результатам наших тестов error code vs. exceptions, error code функции работают на 8%-10% быстрее.
Я не обломаюсь подождать на 6 секунд дольше при загрузке уровня (при полной загрузке в 1 минуту, что довольно долго), ради быстроты и удобства.

constПостоялецwww31 окт. 200615:49#19
x0ras
Ты не обломаешься, а пользователь обломается. Да и в ТРЦ укладываться желательно, и чем меньше задержек, тем лучше.
СчастливчикПостоялецwww31 окт. 200615:55#20
x0ras
>По результатам наших тестов error code vs. exceptions, error code функции работают на 8%-10% быстрее.
Интересно как меряли?
cppguruПостоялецwww31 окт. 200615:56#21
Bat
>о потенциальном :) мегапроекте которому потенциально сильно повредит использование исключений
А я говорю о совершенно реальном проекте, совсем недавно упоминавшемся в новостях на дтф. У кого теперь реальней аргументы?

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

>исключения нужны для удобства написания программ у них свои + и -
Речь о том, что в случае геймдева минусы перевешивают плюсы. Если говорить о текущей реализации в с++.

BatПостоялецwww31 окт. 200616:07#22
возможно, это личное дело каждой команды, но я бы не стал так категорично всем советовать
gonzale$$Новичокwww31 окт. 200616:09#23
cppguru
>...в этом году многие российские компании с корнями выдирали использование буста из движка
Это в связи с чем, пардон?
LevisПостоялецwww31 окт. 200616:10#24
Техника применения исключений не сильно отличается от техники применения боевых гранат. А остальное это религия.
dDIMAНовичокwww31 окт. 200616:18#25
gonzale$$
>cppguru
>>...в этом году многие российские компании с корнями выдирали использование буста из движка
>Это в связи с чем, пардон?
Послушайте Открытый Форум - Программирование с КРИ-2006.
aruslanПостоялецwww31 окт. 200616:18#26
Два момента.
Но - вообще говоря - всё как обычно.  Смешиваем уровни.  И спорим за религию.

Это примерно как решать вопросы библиотеки типов, reflection или десериализации языковыми средствами.
При том, что половина тулзов вообще не на этом языке, да и объектная десериализация в играх нужна лишь ограниченно.
Мы постоянно программируем не на том языке, но это нас не останавливает ;)

И тем не менее - в защиту exception.
Exception safety достигается сравнительно просто.
Более того, я всячески рекомендую всем внимательно смотреть и знать приёмы достижения exception safety.
Это, в конце концов, как раз их тех вопросов профессиональной эрудиции, которые затем вполне распространяются на построение и модели работы с ресурсной и объектной системой, с версионностью и ассетами, со всем persistance layer игры.

Грамотное обеспечение exception safety (так же, как и грамотная параллелизация) не достигается тупой расстановкой try/catch (критических секций и объектов блокировки).
Дизайн должен исходить из этой самой safety (так же, как и, например, параллелизма). 
И половина высказанных в этой ветке возражений характерна как раз для ad hoc реализации.
Результирующий дизайн системы (особенно в условиях различных уровней exception safety внутри системы) будет другим.
Так же, как отличается дизайн в условиях многопроцессорных систем или в условиях unit-тестирования, например. 

Но при слепой safety результирующий код будет безнадёжно дорогим.
Не в смысле тупой стоимости написания кода или скорости/ресурсоёмкости результирующего асма.
А в смысле той дороговизны, которая присуща барьерам изоляции транзакционных изменений.

Он дорог ровно там, где присваивание делается через копирование и swap.
Он дорог каждый раз, когда на микроуровне кода выставляется минибарьер изоляции.
Каждый раз, когда не допускается разрушение объектов при откате транзакции.
Каждый раз, когда не допускается утечек ресурсов или неконтролируемого разрушения среды при сбое.
И здесь важно понимать связь языкового механизма (C++ exception), транзакционных моделей (БД) и конкретной семантики, которую хочется достичь в конкретном случае.

Иными словами, я не за "exceptions в играх на C++", но за применение опыта индустрии в обеспечении целостности.
А говорить "я не умею и не хочу разбираться, поэтому не буду" - несколько непрофессионально.  Имхо.


Что касается применимости в играх, на мой взгляд, тут три момента против exceptions.
Все - как водится - идеологические.
Мгновенность, локальность и аисторичность.
Которые вступают в конфликты и с требованиями платформ (TCR/TRC/Games for Vista), и с типичным архитектурным концептом.

Как я уже неоднократно говорил, подавляющее большинство современного кода в той или иной мере несёт специфический отпечаток немгновенности (как последовательность walk-turn-walk, или как загрузка объекта) и распределенности (как асинхронная загрузка, декомпрессия и подключение, выполняемая на нескольких потоках управления, или как оксюморонная сетевая "синхронизация").

RAII на среднем и высоком уровне не работает в частности из-за немгновенности.
Бесполезно делать RAII my_texture("texture.jpg"), грубо говоря (мы говорим о реальных играх, а не учебных примерах).

Из-за немгновенности и распределенности не работает и связка умный указатель-физический деструктор.
Не стоит мгновенно уничтожать игровой объект по smart ptr, с последующим мгновенным уничтожением рендерных ресурсов.
Особенно когда в это время асинхронно рисует GPU и считается следующий кадр.

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

Итак, они
1. мгновенны (они мгновенно unwind, их мгновенно обрабатывают).
2. локальны (они в одном потоке управления, типично - вообще в callback, и никому от этого не легче).
3. аисторичны (узнав о сбое загрузки объекта, довольно тяжело понять, что дело в нехватке видеопамяти).

Мы, как всегда, программируем не на том языке.
Знаем exceptions, но не используем их.
Пишем на C++, но используем data driven внешнюю объектную модель.
Рассуждаем о виртуальном наследовании, но загружаем через gangload/lip-service.

Наш типичный диалект с полу-STL и недо-boost имеет смысл обозвать "gamedev C++" и начать процесс по его стандартизации.
Потому что потребности индустрии заметно отличаются от тезисов "C++ performance report".

Шутка.

Я ни в коем случе не говорю, что не нужно exceptions.
Просто они мозг разжижают чаще, чем следовало бы.

cppguruПостоялецwww31 окт. 200616:25#27
gonzale$$
>>...в этом году многие российские компании с корнями выдирали использование буста из движка
>Это в связи с чем, пардон?
Code bloat, выражается в нескольких вещах:
  • Взлетает до звёзд время компиляции (это самое меньшее из зол).
  • После некоторого лимита компилятор перестаёт инлайнить функции, даже абсолютно тривиальные (пустое тело).
  • В результате размер exe растёт линейно (или ещё хуже) от количества вызовов функций из буста.
  • Сложность поддержки кода возрастает в разы.

    Правка:
    aruslan
    Респект!

  • gonzale$$Новичокwww31 окт. 200616:38#28
    cppguru

    пасиб

    _WinnieПостоялецwww31 окт. 200617:27#29
    [-]
    Страницы: 1 2 3 4 5 6 7 Следующая »

    / Форум / Программирование игр / Общее

    Тема в архиве.

    2001—2018 © GameDev.ru — Разработка игр