Здравствуйте, VladD2, Вы писали:

J>>>Я всего ее кода не видел, только маленький кусок, но что я увидел там: она была написала на С++, и более того, стратегии AI для игры за разные страны (там у разных стран разные строения, оружие, стоимость ресурсов и прочее, поэтому по-разному надо действовать) были тоже написаны на С++ и упрятаны в DLL-ки с названиями стран (т.е. если ты хотел играть против, скажем, Австрии, то просто подгружалась соответствующая DLL-ка и начинала против тебя играть). На моей тогдашней слабенькой машинке все летало.

E>>Предполагаю, что такой подход использовали именно из-за того, что там такое огромное кол-во юнитов на поле одновременно. Возможно, скриптовый движок не потянул такое кол-во выполняемых одновременно скриптов.
E>>IMHO если юнитов поменьше (у нас, например, обычно не больше 20), то лучше все-таки писать скрипты. Тогда можно будет переложить работу с программистов на дизайнеров миссий, что во многих отношениях правильно.

VD>Ребяты (с). Создать 64К простых юнитов не проблема. Представляй каждого из них простой структурой лежащей в массиве и нет проблем.

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

VD>Скрипты этого скорее всего не позволят, но ведь кроме скриптов и С++ есть еще кое какие языки.

VD>Мне вот интересно что даст скрипт по сравнению с тем же Немерле?

В играх скрипт по сравнению с С++ и другими языками дает обычно два приемущества:
1) в скриптах как правило не пишется архитектурно сложного кода, поэтому их пишут не программисты, а дизайнеры миссий/уровней/карт, которые в силу специфики своей работы скриптовыми языками владеют, а С++ и Немерле — нет.
2) когда логика поведения юнитов написана на скриптах, дизайнер может менять ее без перекомпиляции кода. На самом деле ему вообще не нужны исходники игры, хватит исполняемых файлов.

Здравствуйте, eugene0, Вы писали:

E>Мы тут пытаемся использовать тот самый PhysX
Привет, коллега!

E>Дело в том, что физический движок весьма сложен в настройке, да и багов в нем предостаточно.
Не столько сложен, сколько сыроват. Работал с Havok 2 — тот гораздо стабильнее. Впрочем и в нем тогда с ragdoll была проблема, которую даже с их саппортом решить не удалось.

E>Между тем, есть отличные игры, которые без нее неплохо обходятся. Посмотрите, например, на Call of Duty.
Главное в игре — геймплей. Все остальное — призвано помогать улучшать этот геймплей. ИМХО...

Здравствуйте, konsoletyper, Вы писали:

E>>Между тем, есть отличные игры, которые без нее неплохо обходятся. Посмотрите, например, на Call of Duty.

K>Контрпример — Silent Storm.

Еще есть Half-Life 2. Без динамики твердых тел в ней все было бы намного скучнее

Здравствуйте, IT, Вы писали:

IT>>>Шаблоны и исключения появились намного позже, уже в 90-х.

E>>впервые появилась в компиляторах фирм DEC и IBM в начале 1992.

IT>Я же говорю в 90-х.

И?
Вторая версия C++ появилась как раз во время работы над ARM, а это период с 1988 по 1990-й. И как раз в это время шаблоны и исключения появились в языке. Реализации вышли позже, но для C++ это обычное дело.

Так что я не вижу противоречий по сравнению с тем, что я говорил здесь

Автор: eao197
Дата: 06.02.07

E>>А Cfront, в котором шаблоны появились впервые, был как раз препроцессором.

IT>Cfront вообще кто-нибудь использовал в коммерческих разработках?

По словам Страуструпа, Cfront активно использовался в разработках самой AT&T.

IT>>>А мозг на что человеку даден? Нужно было подумать им немного.

E>>Я вот не могу себе представить другого способа для этого, кроме компиляции не в объектный код, а в код какой-нибудь виртуальной машины. С последующей трансляций в конкретный нативный код.

IT>Можно и так. Turbo Pascal, например, великолепно справлялся с этой задачей в тоже самое время. Ещё тогда же было семейство компиляторов, не помню название, для которых эта задача решалась не для одного, а для множества языков. Так что решить эту задачу было можно, было бы желание.

Ну не было у меня возможности переносить объектные файлы Turbo Pascal 3.0 с Robotron 1715 и CP/M на Turbo Pascal 5.0 на IBM XT и MS-DOS. И не знаю я про существование Turbo Pascal для SPARC-овых или MIPS-овых архитектур. Например, можно ли было tpu-файлы из Turbo Pascal на Маках использовать?

Здравствуйте, eao197, Вы писали:

IT>>>>Шаблоны и исключения появились намного позже, уже в 90-х.

C++ 1.x — одиночное наследование, реализован в Zortech C++ 1.0
C++ 2.0 — множественное наследование, реализован в Zortech C++ 2.0 и Turbo C++ 1.0 (май 90-го)
С++ 2.1 — templates & exceptions

хотя я могу ошибаться и возможно exceptions появились только в 3.0. Во всяком случае, Borland C++ 92-го года реализовывал только шаблоны

Здравствуйте, eao197, Вы писали:


E>>>А Cfront, в котором шаблоны появились впервые, был как раз препроцессором.

IT>>Cfront вообще кто-нибудь использовал в коммерческих разработках?

E>По словам Страуструпа, Cfront активно использовался в разработках самой AT&T.

По моему в том же дизайне и эволюции сказано, что CFront был основой для многих коммерческих компиляторов.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, dr.Chaos, Вы писали:

DC>>Да хотя бы то, что возможностей у языка не меньше, а библиотек просто море + это проверенный инструмент.

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

Каких возможностей не хватает в С++ : сопоставления с образцом? — В движках всегда switch'a хватало; Замыканий? — да могу я их сделать функторами; как собственно и ФВП ; да это не будет так красиво, и кратко как в ОКамле или Немерле.
Только объясни мне где в алгоритмах в движке их применять. Я, если честно, не вижу сильного выигрыша от их применения.

Кстати, пункта три. Какие именно ты ложью назвал? .

DC>>А теперь все таки ответьте на мой вопрос. Что кардинально изменит Немерле или ОКамл. Не просто уменьшат многословность, а именно дадут?

VD>Просто позволят решать более сложные задачи, или решать те же задачи меньшими силами.

Вот блин опять абстракция, я про движок графический спрашиваю. То что в физическом движке ФП будет возможно лучше использовать, я соглашусь, но ты мне объясни где я выиграю в 3D движке???

Здравствуйте, eugene0, Вы писали:
E>Создать столько юнитов, конечно, не проблема. Но представь себе, что каждый из этих юнитов есть интерпретатор или виртуальная машинка, выполняющая скрипт и все это одновременно.
Это, как бы это сказать, наивный подход. Можно моделировать юниты процессами ОС, получая чудовищные накладные расходы, и кричать: вот, вот тормоза! ату их! скрипты — сосуд!
Можно понять, что 64к однотипных юнитов выполняют ровно один и тот же скрипт, а состояние у каждого весьма примитивное, и применить некоторые хитрые оптимизации. Я в свое время изобретал такую штуку для оптимизации виртуальных вызовов на Delphi. Т.е. вся одновременность там очень ограниченная, контекст очень дешевый, и пробежаться в цикле по 64к структурок стоит практически нуль.
А можно замоделировать их на каком-нибудь эрланге, и он сделает все то же, что в предыдущем пункте, только гораздо дешевле в плане ручного труда.

E>В играх скрипт по сравнению с С++ и другими языками дает обычно два приемущества:
E>1) в скриптах как правило не пишется архитектурно сложного кода, поэтому их пишут не программисты, а дизайнеры миссий/уровней/карт, которые в силу специфики своей работы скриптовыми языками владеют, а С++ и Немерле — нет.
Это очень странная специфика, если честно. Про с++ я еще понимаю — это очень требовательный язык. Хотя я и на его основе бы смог, скорее всего, наколбасить псевдоязык для дизайнеров с предельно упрощенным синтаксисом. А уж Nemerle с его супергибкими способностями и вовсе можно было бы замаскировать практически под Лого (который, скорее всего, и нужен для игровых скриптов).
E>2) когда логика поведения юнитов написана на скриптах, дизайнер может менять ее без перекомпиляции кода. На самом деле ему вообще не нужны исходники игры, хватит исполняемых файлов.
В 21 веке понятие "перекомпиляция" существенным образом изменило свой смысл. Насколько я знаю, современные 3d игрушки работают с предкомпилированными описаниями уровней, которые готовятся довольно долго (чтобы сэкономить время на загрузке карты). Поэтому можно считать, что логика просто проходит через какой-то конвеер, на одном конце которого — исходник, а на другом — нативный код. К слову, в управляемых языках даже полный конвеер очень быстр, благодаря чему работают всякие .*sp с compile-on-demand. Поэтому особенного выигрыша от интерпретации получить не удастся.

Здравствуйте, VladD2, Вы писали:
VD>Так чем же тогда собственно определяется использование С++ хотя бы в области симуляции?
Да тем, Влад, и определяется. Инерцией. У меня лично переход на ASP.NET для разработки веб приложений занял примерно два года, и только теперь я понимаю, что такое хорошее веб приложение и как его правильно писать. Причем наше приложение еще не удовлетворяет этим моим представлениям — потому, что значительная его часть писалась до того, как я всё понял. И еще не факт, что то, что я понял суть истина.

Так и гейм девелопмент: менеджеру продукта приходится на старте выбирать из шага в неизвестность, которая теоретически может дать какой-то выигрышь, и движения в уже известную сторону. Разработчик не знает заранее, сколько времени у него займет изучение Nemerle; архитектор не знает, сколько времени у него уйдет на изобретение DSL, подходящего для конкретной области, менеджер не знает, какие грабли встретятся при поиске и использовании сторонних разработок. А продюсер требует показать бизнес план.

Вот народ и ездит на чем умеет. Они дожидаются, пока:
— кто-то рискнет попробовать написать реальную игру на Nemerle и разорится (из-за недооценки трудностей, или из-за того, что архитектор только через полгода поймет, что DSL должен был быть устроен совсем не так, а уже поздно)
— кто-то учтет предыдущий негативный опыт и доведет таки игру до конца, показав, что Nemerle не хуже плюсов
— кто-то учтет позитивный опыт и сварганит фреймворк, который таки будет мегаудобным и станет стандартом де-факто
— кто-то на основе этого фреймворка напишет и издаст книгу Painless Game Develompent, которая станет бестселлером типа Абрашевского труда
— к моменту выхода книги будет доступно два-три конкурирующих фреймворка, которые будут непрерывно мериться разными органами, а ведущие блоггеры будут это комментировать.

Вот тогда-то инерционный менеджмент и решит, что "ну, вот и нам пора".

Здравствуйте, BulatZiganshin, Вы писали:

IT>>>>>Шаблоны и исключения появились намного позже, уже в 90-х.

BZ>C++ 1.x — одиночное наследование, реализован в Zortech C++ 1.0

Если я правильно помню и понимаю "Дизайн и эволюцию языка C++", то возможности C++ 2.0 реализовывались в период с 1987 по 1990 год в компиляторе Cfront. Страуструп вроде как сетовал на то, что с выпуском версии 2.0 они очень затянули как раз из-за того, что у них были сложности с реализацией шаблонов -- первая реализация, отсюда и все грабли.

Поэтому, когда в 1988-м появился первый Zortech с поддержкой C++ 1.x, то в AT&T возможности C++ 2.0 уже были частично доступны в Cfront. А вот был ли этот Cfront доступен еще кому-то вне AT&T -- не знаю.

BZ>C++ 2.0 — множественное наследование, реализован в Zortech C++ 2.0 и Turbo C++ 1.0 (май 90-го)
BZ>С++ 2.1 — templates & exceptions

BZ>хотя я могу ошибаться и возможно exceptions появились только в 3.0. Во всяком случае, Borland C++ 92-го года реализовывал только шаблоны

Как утверждает Wikipedia, Borland выпускал две линейки C++ компиляторов: Turbo C++ и Borland C++.

Я видел и пользовался только Turbo C++ 1.0, затем Borland C++ 2.0, 3.1, 4.0 и 4.5. Turbo C++ 3.0 прошел мимо меня

Я не уверен на счет шаблонов в Borland C++ 3.1. В Borland C++ 2.0 их точно не было.
Я начал экспериментировать с шаблонами и исключениями только после того, как в 95-м мне в руки попал Borland C++ 4.0 и 4.5. Причем, если не ошибаюсь, шаблоны появились именно в Borland C++ 4.0, а в Borland C++ 4.5 -- исключения.

К тому же не знаю, как в крупных городах, но к нам в провинцию в то время инструменты попадали с серьезным запозданием

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, dr.Chaos, Вы писали:

DC>>Переносимость на уровне исходников, это и есть основной приоритет комитета.

VD>К сожалению они добились полностью протевоположенного результата.
Какого? Переносимости на уровне исходников нет? . Ты открыл мне глаза. Только как я компилюсь каждый деть с одним кодом под Win/AIX, может я что-то неправильно делаю??

DC>>Влад в чем заключается мой самообман? В том, что ОС и Драйверы на управляемых языках экспериментальные? Или в том что на данный момент подавляющее большинство ОС и драйверов написано на С++ и/или С?

VD>Самообман то что все перечисленное тобой удобнее писать на С++. Порой вынуждены писать на С/С++ — да. Но никак не удобнее. А вынуждеды по банальной причине — сама ОС написана на С и все интерфейсы у нее тоже в С-формате. Вот и получается, что иногда тебе "удобнее" писать на С++ только лишь потому, что иначе ты не можешь. Хотя на саомо деле можешь, но многие даже в свою голову это уложить не могут.

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

DC>>Т.е С++ говно полюбому? Да Влад это как мантра.

VD>С++ марально устарел еще 5, а то и больше лет назад. Это здравый логический вывод.
В чем его моральная старость? Кто кроме С++ дает такие возможности с обобщенным программированием при строгой типизации? Java, .Net?
VD>На мантру скорее похоже бездумное повторение слов роде твоих.
Каких именно слов? То, что это достаточно хороший инструме
DC>>А если компания его использует уже 10-15 лет? Зачем при налаженном процессе переходить куда-то?

VD>Затем, что конкуретны не стоят на месте. И то что сходило с рук 10 лет может не сойти сегодни и завтра.
Влад кто из производителей движков/ОС/драйверов переходит на Немерле/ОКамл/...


VD>Первые 3D-игры были написаны на С без скриптов и разных вольностей. В них и 3D-то как такового не было.
Тогда и акселераторов то не было.
VD>Второе покоеление уже писалось с использованием скриптов и С++.
Использование скриптов ИМХО еще позже появилось.
VD>Следующие должны писаться уже без С++, да и без скриптов. Технологии резко двинулись вперед и мы имеем все что имели и в скриптах, и в С++ (причем без их проблем) в одном флаконе.

Кому должны и где имеем? Где 3Д библиотеки для Немерле/ОКамл/... которые удовлетворяют разработчиков движков?

DC>>Нет, просто на С++ тонны кода,

VD>Серьезно? Ой не верится, что весь этот код будет использоватья в новых проектах. К тому же технологии на сегодня позволяют полжить код в библиотеки и использовать их в другом окружении.

Да никто не запрещают, многие так и делают . Кстати весьма правильно делают. Кесарю — кесарево.

DC>> возможности его не сильно хуже существующих управляемых языков.

VD>Вот это уже загиб еще тот. Они не то что бы хуже. По сравнению с лучшеми представителями они катастрофически хуже.

Какие поименно? — причем в разрезе применения для ОС/драйверов/графических движков.

VD>Собственно повторять не охота. Скачай все же презентацию. Погляди ее. С чем ты там собственно не согласен?

DC>> Понимаешь чтобы вытеснить С++ нужно предложить что-то намного лучшее. Для Java и .Net снижают стоимость разработки, и порог вхождения низкий, специалистов проще найти. Но только для некоторых областей!!! Где собственно С++ наиболее плох для применения.

VD>Уверяю тебя просто эти области еще не расскачались. Плюс не только Java и .Net существуют в мире. Есть ОКамл, например. Там где Java и .Net могут оказаться не применимы он может дать очень неплохой эффект. У него только одна схожая с С++ проблема — он не поддерживает компонентности. Но он имет существенные приемущества перед С++, так как он типобезопасный, управляет памятью автоматичкски и значительно более выразительный (обладает более мощьными конструкциями).

Я с этим и не спорил никогда.

Здравствуйте, AndreiF, Вы писали:

AF>Качество — это когда программа делает свою работу правильно, не падает и не рушится. А скорость — это отдельный параметр, и к качеству никакого отношения не имеет.

А самолет, который я описал, движется ? Да. Летает со скоростью 100 км/час. И даже, может, и не падает. Жрет горючее как 100 Боингов, но летает

Ну и счастливого полета на этом качественном самолете. В соседнюю деревню, За рогами и копытами.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, dr.Chaos, Вы писали:

DC>>Влад, я мощьности на свой комп ставлю не для микрософта и ее ОС, а для того чтоб прикладное ПО там быстрее бегало.

VD>Ясно. Каждому свое. Я же использую более быстрое железо и более новую ОС чтобы повысить комфорт своей работы, улучшить свое настроение и получить больше фукнциональности. Вот скажем, меня устраивает функционал моего сотового (и темболее домашнего) телефона, и я даже не думаю о том, чтобы купить новый телефон, чтобы на нем что-то там быстрее работало.

Влад я не хочу менять комп, ради того чтобы Виста там смогла!! работать. Предоставляемые удобства весьма сомнительныно выше чем у Линукса

DC>>[оффтопик]
DC>>Меня если честно удручает такое положение, я всерьез задумался над переходом на KUbuntu. Я понимаю что мне дал XP — большую стабильность, у меня он стоит уже 4 года, при этом синих экранов вообще не вспомню, подвисаний не больше 3-5 в год, учитывая то, что ставил я много всяких программ. Что мне даст виста? 3D интерфейс который мне не нужен? Какие принципиальные удобства я получу? Исправление собственных багов ценой моих денег и ресурсов моего компа?
DC>>[/оффтопик]

VD>Ты? Видимо некаких. Я же их уже получил. Незнаю насколько Виста стоит своих денег, но ОС получилась очень удобной. Это первая версия Эксплорера (не IE, а простого) которой я могу пользоваться не протирая монитор от слюней.

VD>Кстати, а зачем ты используешь ХРюшу? Ведь до этого была В2к. Тоже вполне себе ничего ОС. А до этого была просто NT. И она была очень ничего... по тем временам.

Потому как драйверов под них не найдешь, да и на 64 разрядный камень нет сборки. Кроме того под NT нормально игры не запускаются, он не для этого разрабатывался.

DC>>. А по сложности задачи? Движок в том или ином виде содержит в себе рендерер. Он правда заточен на другое.

VD>Больше такую глупость никому не говори.

Читай выделенное.для рендеринга просто используется как ты правильно заметил дополнительный специализированный процессор.

DC>>Сколько в комитете людей от компаний занимающих производством движков?

VD>Довольно много. Там, кстатити, и МС представлен. Только толку — 0. И стандарта тоже нет. Его уже года 4 отодвигают, и отодвигают. Уже не толко Java с C# появилась, но и следующее поколение проклевывается.

MC там представлен я не сомневаюсь, только MC не производитель движков.

DC>>Ты сказал, что стандарт ничего не изменит. Т.е. этот стандарт бред, несуразица

VD>Я сказал, что с точки зрения этой презентации (а стло быть всей разработки игр класса Анрыла) новый стандарт практически ничего не даст. Причем то что помогло бы разработчиком игр было бы одновременно полезным и для большинства других пользователей языка. Но это не путь С++, по всей видимости.

Оооо. Сколько оговорок появилось для простой фразы — Ничего не изменит.

DC>>Достаточно хорош — это означает, что любую задачу можно решить используя высокоуровневые конструкции и современные приемы проектирования, при этом добиться максимальной эффективности.

VD>Любую задачу потенциально можно решить на ассемблере или скажем на С. Но это:
VD>1. Не разумно в большинстве случаев.
VD>2. Требует больеш ресурсов и усилий чем может реально быть в распоряжении компании.

С и Асм не предоставляют столько высокоуровневых абстракций для проектирования. Мало того на С++ действительно неразумно решать многие задачи, т.к. появились специализированные инструменты.

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

VD>Ага. Но тут есть одна радостная вещь. Те кто окажется прозорливее и свалят вовремя получат ощутимое конкурентное приемущество.

Я и не сомневаюсь, только до этого, как ты сам оценил 5-10 лет.

DC>>Возможно, время покажет.

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

С++-шники не у дел не останутся . Они просто перейдут в другие области.

Здравствуйте, CreatorCray, Вы писали:

E>>Мы тут пытаемся использовать тот самый PhysX
CC>Привет, коллега!


E>>Дело в том, что физический движок весьма сложен в настройке, да и багов в нем предостаточно.
CC>Не столько сложен, сколько сыроват. Работал с Havok 2 — тот гораздо стабильнее. Впрочем и в нем тогда с ragdoll была проблема, которую даже с их саппортом решить не удалось.
Хавок денег стоит, насколько мне известно. Нам их не дадут

E>>Между тем, есть отличные игры, которые без нее неплохо обходятся. Посмотрите, например, на Call of Duty.
CC>Главное в игре — геймплей. Все остальное — призвано помогать улучшать этот геймплей. ИМХО...
В принципе я согласен. Но когда гранаты проваливаются сквозь землю, а трупы дергаются эпилептически — это

VladD2 wrote:
> Это не совсем так. Если сам Фортран хостится на дотнете, то проблем не
> будет:
> http://www.codeproject.com/dotnet/intro_fortran.asp
Ха! Он же торрррмозить будет.

Классчический Фортран работает ОЧЕНЬ быстро из-за огромных возможностей
по оптимизации (отсутствие aliasing'а, рекурсии, встроенные многомерные
массивы и комплексные числа, простой язык). .NETовый JIT таких
возможностей и близко не имеет.

Здравствуйте, dr.Chaos, Вы писали:

VD>>С++ марально устарел еще 5, а то и больше лет назад. Это здравый логический вывод.
DC>В чем его моральная старость? Кто кроме С++ дает такие возможности с обобщенным программированием при строгой типизации? Java, .Net?

Eiffel с 80-х годов. оттуда кстати оно и было в C++ перенесено у меня есть на 25 кил письмо автора этого языка где-то 87-го года, где он критикует C++. можешь считать добавление exceptions/templates работой над ошибками

вообще C++ вырос из "высокоуровневого ассемблера" и на нынешнем уровне его применение имхо оправдано только когда нужна максимальная производительность. а все добавления последних 10-15 лет — это просто эмуляция возможностей более высокоуровневых языков, от умных указателей до лямбд.

я к примеру пишу многопоточную программу, проблем с синхронизацией практически не возникает, а если и возникают — достаточно добавить операцию withLocking при создании переменной и withLock при её использовании. а почему так просто? потому, что язык функциональный, изменяемых данных (а тем более разделяемых при этом между разными нитями) раз-два и обчёлся. в C++ же вокруг этой проблемы три километра геморроя, вплоть до написания thread-safe конструкторов копирования отсюда и результат — я думаю о реализации логики задачи, вы — боретесь с трудностями и при этом продолжаете верить, что после C++ ничего лучше уже не будет

Здравствуйте, Sinclair, Вы писали:

E>>Создать столько юнитов, конечно, не проблема. Но представь себе, что каждый из этих юнитов есть интерпретатор или виртуальная машинка, выполняющая скрипт и все это одновременно.
S>Это, как бы это сказать, наивный подход. Можно моделировать юниты процессами ОС, получая чудовищные накладные расходы, и кричать: вот, вот тормоза! ату их! скрипты — сосуд!
Я что-то писал про процессы или потоки?

S>Можно понять, что 64к однотипных юнитов выполняют ровно один и тот же скрипт, а состояние у каждого весьма примитивное, и применить некоторые хитрые оптимизации. Я в свое время изобретал такую штуку для оптимизации виртуальных вызовов на Delphi. Т.е. вся одновременность там очень ограниченная, контекст очень дешевый, и пробежаться в цикле по 64к структурок стоит практически нуль.
S>А можно замоделировать их на каком-нибудь эрланге, и он сделает все то же, что в предыдущем пункте, только гораздо дешевле в плане ручного труда.

На ум приходят всякие доводы за и против, но на самом деле все это ни к чему. Если ты посмотришь немного выше по ветке, я всего лишь предположил, почему в вышеупомянутых казаках логика поведения юнитов полностью захардкодена, а не написана на скриптах. Таких причин может быть очень много, от более или менее разумных до "тимлид сказал". Я к команде разработчиков той игры отношения не имею, поэтому совершенно не в курсе, почему они так сделали.

E>>В играх скрипт по сравнению с С++ и другими языками дает обычно два приемущества:
E>>1) в скриптах как правило не пишется архитектурно сложного кода, поэтому их пишут не программисты, а дизайнеры миссий/уровней/карт, которые в силу специфики своей работы скриптовыми языками владеют, а С++ и Немерле — нет.
S>Это очень странная специфика, если честно. Про с++ я еще понимаю — это очень требовательный язык. Хотя я и на его основе бы смог, скорее всего, наколбасить псевдоязык для дизайнеров с предельно упрощенным синтаксисом.
S> А уж Nemerle с его супергибкими способностями и вовсе можно было бы замаскировать практически под Лого (который, скорее всего, и нужен для игровых скриптов).
Зачем что-то колбасить? Вот LUA, вот python. Для того, чтобы делать что-то новое, нужно, чтобы это новое было чем-то лучше, чем готовое и многократно использованное и оттестированное старое. Чем вот эти псевдоязыки были бы лучше?

E>>2) когда логика поведения юнитов написана на скриптах, дизайнер может менять ее без перекомпиляции кода. На самом деле ему вообще не нужны исходники игры, хватит исполняемых файлов.
S>В 21 веке понятие "перекомпиляция" существенным образом изменило свой смысл. Насколько я знаю, современные 3d игрушки работают с предкомпилированными описаниями уровней, которые готовятся довольно долго (чтобы сэкономить время на загрузке карты). Поэтому можно считать, что логика просто проходит через какой-то конвеер, на одном конце которого — исходник, а на другом — нативный код. К слову, в управляемых языках даже полный конвеер очень быстр, благодаря чему работают всякие .*sp с compile-on-demand. Поэтому особенного выигрыша от интерпретации получить не удастся.

За все современные игрушки не скажу, а у нас дела обстоят следующим образом. Есть некий самодельный инструмент — редактор уровней, главный инструмент дизайнеров. В нем можно рассмотреть игровой мир со всех сторон, подвигать объекты, поменять их свойства. Еще там же можно давать объектам на выполнение различные скрипты, тут же их править, запускать снова.
Дизайнер может действовать так: он строит сцену из готовых объектов, настрайвает их свойства, пишет скрипты. Это обычно происходит в режиме "на паузе". После этого он сохраняет сцену, запускает ее и смотрит, что получилось. Обычно, сначала что-нибудь идет не так, как хотелось. Тогда дизайнер перегружает сцену, подправляет ее немного (передвигает неправильно стоящий объект, правит скрипт и т.д.), сохраняет, смотрит, что получилось. И т.д. и т.п.
При этом никаких длительных перерывов в его работе нет, из редактора он не выходит. Если бы вместо скриптов была захардкоденная логика, ему пришлось бы выходить, править, перекомпилировать как минимум тот модуль, который он поправил.
Вот о чем я пытался сказать выше. Насколько мне известо, разработка уровней организована таким образом не только у нас.

Здравствуйте, BulatZiganshin, Вы писали:

VD>>>С++ марально устарел еще 5, а то и больше лет назад. Это здравый логический вывод.
DC>>В чем его моральная старость? Кто кроме С++ дает такие возможности с обобщенным программированием при строгой типизации? Java, .Net?

BZ>Eiffel с 80-х годов. оттуда кстати оно и было в C++ перенесено у меня есть на 25 кил письмо автора этого языка где-то 87-го года, где он критикует C++. можешь считать добавление exceptions/templates работой над ошибками

Eiffel появился в 86-м. Да и его generic-и больше похожи на нынешние generic-и в Java, чем на шаблоны C++. И шаблоны в C++ пришли вовсе не из Eiffel, а из Ada и Clu.

BZ>я к примеру пишу многопоточную программу, проблем с синхронизацией практически не возникает, а если и возникают — достаточно добавить операцию withLocking при создании переменной и withLock при её использовании. а почему так просто? потому, что язык функциональный, изменяемых данных (а тем более разделяемых при этом между разными нитями) раз-два и обчёлся. в C++ же вокруг этой проблемы три километра геморроя, вплоть до написания thread-safe конструкторов копирования отсюда и результат — я думаю о реализации логики задачи, вы — боретесь с трудностями и при этом продолжаете верить, что после C++ ничего лучше уже не будет

Я постоянно пишу многопоточные программы на C++ и проблем с синхронизаций практически не возникает. Потому что специально заточенным для этого инструментом пользуюсь. Так что функциональность или императивность языка здесь дело далеко не принципиальное.

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

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, dr.Chaos, Вы писали:
DC>>Ну уж нет, Си явно выражал концепцию структурного программирования, т.е. вводил новые абстракции что ли.
S>С действительно компактнее ассемблера, чем и рулит. С++ компактнее С. Новые абстракции не нужны сами по себе — они оправданы только тем, что сокращают запись. Тензорное исчисление само по себе ничего нового не дает по сравнению с обычной алгеброй. Просто более компактная запись длинных уравнений.

Не только. Новые абстракции нужны для разбиения на части модели. Это локально снижает сложность.

Здравствуйте, BulatZiganshin, Вы писали:

BZ>преимущества Хаскела — очень строгая типизация, отлавливающая большинство ошибок с типами, и лёгкость конструирования алгоримтов из составных частей. я не представляю себе потребности игр, но вот к примеру печать простых чисел:

Жаль у меня нет куска кода для оптимизации сцены при преобразовании во внутренний формат движка . Могли бы провести эксперимент .