OOП, продолжение.

[АлЁша]

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

Есть пример, когда "узким местом" в исполнении становится ООП? Мне кажется очень небольшой выигрыш в 99% задач.

Думаю хороший движок современной 3D-игрушки невозможно сделать чисто в ООП.
ЗЫ я не спец по игрушкам, поэтому спорить не собираюсь, просто имхо

[Pitty]

Сообщение от АлЁша

Думаю хороший движок современной 3d-игрушки невозможно сделать чисто в ООП.
ЗЫ я не спец по игрушкам, поэтому спорить не собираюсь, просто имхо

Вы. наверное, будете удивлены, но на Igf за 2007 год было несколько докладов об объектных моделях для 3д игр. Особливо там интеловцы распинались по поводу своей парадигмы (фабрики) для многопоточных игр, точнее для игр, которые должны использовать несколько ядер. Они предлагают разработчику игр использовать их модель в которой разработчик создает "действия" и инфраструктура сама эти действия синхронизирует, диспетчеризирует и т.д. Судя по графикам - выигрыш опупенный.

[Messiah]

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

[АлЁша]

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

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

Т.е. они получается фактически предлагают готовый движок в составе своей фабрики? Не думаю, что это идеальный универсальный вариант, особенно если учесть, что разработчик Майкрософт А как нужные графики выводить, это мы проходили :D Хотя честно говоря не слышал про эту фабрику, и объективно сказать не могу, так, общие рассуждения вслух :D

[Slyer]

Сообщение от АлЁша

Думаю хороший движок современной 3d-игрушки невозможно сделать чисто в ООП.
ЗЫ я не спец по игрушкам, поэтому спорить не собираюсь, просто имхо

Движок современной игрушки - это практически всегда чистое ООП. =)

[Pitty]

Насчёт робота.
Мне кажется, оба метода: функциональный и объектный, имеют право на существование в этом случае. Удобство функционально - не надо создавать лишней инфраструктуры, удобство ООП - маштабируемость, но тогда приходится заранее продумывать все будущие ходы, чего сделать, в принципе, не возможно.
Например, движение. Базовая функция: AsyncResult BeginMoveTo(float X, Float Y, Float Z, Float Velocity)
Которая в свою очередь вызывает несколько функций: определение текущих координат, определение возможности проезда к нужным координатам/построение пути. Как только задан путь, вызывается функция AddMovingTask, которой передается путь, и она возвращает в свою очередь объект AsuncResult (ну еще колбэк нужен). В то же время существует бесконечный цикл, назовем его диспетчер задач, который, получив задание начинает его в цикле выбирать. При этом, вполне чётко можно проследить модульность: если изменится базовый алгоритм движения, необходимо будет изменить только тело функции DoStep, которая вызывается диспетчером. Если мы найдем более совершенный алгоритм нахождения пути - поменять только алгоритм метода поиска пути....
Мне кажется, как раз в этом случае создание объектной модели было бы излишним. Если вы строите робота-игрушку, у вас и аппаратные средства будут соответствующие, если вы строите боевого робота - там уже тем более будет не хватать аппаратных средств, т.к. скорость реакции и точность расчёта повышаются в несколько раз (да и количество задач тоже). По моим данным, в роботостроении мало применяется ООП. (Правда они немного устарели, года на 3-4).
Кстати, это пример чисто теоретический или Вы имеете практические намерения? В)
Не знаю, почему вы так обозлились на конечные автоматы: ведь практически реализуемый автомат всегда можно реализовать/оптимизировать, причём есть автоматические алгоритмы для таких вещей (универсальные).

[Messiah]

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

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

Ой, ой...не к ночи ещё помянуть граф-схемы, автоматы Мили и Мура и теорему Баранова... и графы иже с ними.

[АлЁша]

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

Движок современной игрушки - это практически всегда чистое ООП. =)

Именно поэтому я и писал: "хороший" движок. А то, что практически все нынешние движки сделаны в ООП и обуславливает то, что они все требуют топового "железа", да и на нем притормаживают, если по максимуму.

[Pitty]

Сообщение от АлЁша

Именно поэтому я и писал: "хороший" движок. А то, что практически все нынешние движки сделаны в ООП и обуславливает то, что они все требуют топового "железа", да и на нем притормаживают, если по максимуму.

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

[Vulzscht]

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

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

влезу с небольшим оффтопом: самая лучшая игрушка - /bin/bash - требования минимальны, поле деятельности - необъемлемое, знаний требуется тоже немало, мозги поддерживает в актуальном состоянии для решения любых задач
кому непонятно - хоть консоль винды возьмите, правда графический режим убьется там только с консолью, а под юниксами - милое дело, иксы убил и вперед )))