Ответ на »сообщение 6035« (Qr)
___________________________

Если речь o сравнении xds vs Visual C++, то xds может проигрывать процентов 20-30, что действительно очень неплохо. Если же сравнивать ББ и Visual C++, то ББ будет проигрывать уже ФАКТОР 2-3.

Откуда сии факторы-то? У меня вот другие были:

http://www.inr.ac.ru/~blackbox/Oberon.Day/talks/ftkachov.pdf

Вообще неплохо понимать, что оптимизатор может делать, а что нет, чтобы в мистику не впадаться.
И когда факторы цитировать, объяснять за счет чего они взялись -- например, оптимизация floatingpoint-арифметики или вынос из цикла скрытых подвыражений в вычислении индексов 2-мерного массива (когда цикл по второму индексу) и т.п.
Без таких объяснений метать цифры мало смысла.

Ответ на »сообщение 6009« (Илья Ермаков)
Ну вот хоть какое-то число (+/-10%) названо, правда что оно означает пока все еще загадка.
Если речь o сравнении xds vs Visual C++, то xds может проигрывать процентов 20-30, что действительно очень неплохо. Если же сравнивать ББ и Visual C++, то ББ будет проигрывать уже ФАКТОР 2-3. Алгоритмикой будем исправлять? Или может все-же сначала стоит действительно довести ББ до ума в смысле производительности, а народ потом и сам потянется?
___________________________

Ответ на »сообщение 6005« (Александр Феоктистов)
___________________________

+/- 10% НИЧЕГО не решают. Оптимизировать надо на уровне алгоритмики, в любом случае.
Плюс, сейчас на дворе многоядерки уже, и самое главное требование к языку, выходящее на первый план, - хорошая поддержка параллелизма. И она у нас скоро будет (мне, например, игровой проект на ББ интересен в первую очередь тем, чтобы на нём эту поддержку опробовать...) А С/С++-сники пускай себе с семафорами и мьютексами колдыбаются, как в каменном веке :-Р

Ответ на »сообщение 6029« (info21)
___________________________

Ответ на »сообщение 6028« (Илья Ермаков)
___________________________
Надо взять конкретную задачу из типичных, и на ней попробовать.
После двух задач-решений можно уж и обобщать.

Пробовать-то нужно, но сначала нужно сделать прототип для пробований. И хочется как можно удачнее этот прототип продумать "априори", чтобы ближе к центру мишени попасть и меньше перецеливаться потом...

Ответ на »сообщение 6008« (Как слышно? Приём!)
___________________________

Ответ на »сообщение 6005« (Александр Феоктистов)
___________________________
>>> значит за время между фреймами 1/25 секунды нам нужно просчитать ...

Нет, не значит. Почему обязательно каждый кадр обсчитывать?
Есть экстраполяция, есть тупёж в конце концов.
Кстати, слишком умные боты - это жутко.
Забавно, если они тупят и толкаются.
Игрок чувствует мощь своего интеллекта :)

дело не в ботах, или не полностью в них :)
как вам понравится, если интерактивная деталь мира будет действовать не по правилам?
Например, брошеный камень не будет падать, костёр не будет гореть,
а монстр не будет умирать, из-за того, что их не успели обсчитать в этом обороте колеса игровой сансары :)

Ответ на »сообщение 6030« (Mirage)
___________________________


Куда еще-то? AOW/AOW2 весьма известные игрушки. КР так и вовсе едва ли не лучшая отечественная.


Я имел ввиду что-то настолько популярное, что входит в десяток тех, о которых даже я (не геймер) слышал ;) Что такое "казуалки" я тоже не знаю. Ну да ладно, все равно спасибо за информацию.


Что касается больших игр, то всевозможный middleware (всякие движки и т.п.) делается с С/С++ интерфейсом, т.к. больше рынок. А без middleware нынче мало кто делает игры.

Ну интерфейс - не аргумент. Никто не мешает писать на дельфе с C/C++ интерфейсом. ;)

Ответ на »сообщение 6029« (info21)
___________________________

Ответ на »сообщение 6028« (Илья Ермаков)
__________________________
Надо взять конкретную задачу из типичных, и на ней попробовать.
После двух задач-решений можно уж и обобщать.
Здесь, конечно, Базарная площадь, можно и поболтать. Но ........

Дык по конкретной задаче и так заранее предсказывается, насколько она "симметричная" по взаимодействию. Речь о том, является ли для большого множества задач клиент-серверная схема настолько значимой, чтобы поддержать её непосредственно.

Ответ на »сообщение 6023« (pepper)
___________________________

А что-нибудь более популярное? ;)

Куда еще-то? AOW/AOW2 весьма известные игрушки. КР так и вовсе едва ли не лучшая отечественная.
Среди популярных нынче казуальных игрушек написанных на Дельфи много. Причем обычно CPU в казуалках основную работу делает.
Что касается больших игр, то всевозможный middleware (всякие движки и т.п.) делается с С/С++ интерфейсом, т.к. больше рынок. А без middleware нынче мало кто делает игры.

Ответ на »сообщение 6028« (Илья Ермаков)
___________________________

... Однако 50%, если не больше, случаев распределённого взаимодействия, наверное, относится к схеме "клиент-сервер", т.е. "запрос-ожидание ответа". ...

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

(Прошу прощения за занудство.)

Вопрос снят... Скачал и посмотрел примеры.
С сообщениями и их обработкой всё очень красиво, ну прям Оберон :-) Естественно, со скидкой на отсутствие динамической расширяемости (таблица диспетчерирования сообщений строится на базе информации этапа компиляции - параметризация шаблона типом сообщения). Плюс выйти на распределённость этого механизма в С++ очень трудно, если вообще возможно.

Фактически, получился Эрланг на С++.
Тогда у меня такой к Вам вопрос:
Вы ввели только однонаправленные неблокирующие сообщения (т.е. "послал-забыл"). Ответ предполагается отдельным сообщением. Я сам прорабатывал когда-то такую схему (много Блэкбоксов, каждый может послать сообщение определённой процедуре другого, ответ приходит обратным сообщением, между посылкой и приёмом сообщения среда просто ждёт - готова к приёму любого сообщения). Однако 50%, если не больше, случаев распределённого взаимодействия, наверное, относится к схеме "клиент-сервер", т.е. "запрос-ожидание ответа". И фактически блокировку до прихода ответа нам придётся воспроизводить в системе состояния актёра (эта блокировка возникнет не на уровне рантайма, но на уровне логики автомата, просто потому, что она должна возникнуть по логике задачи). Так вот над каким вопросом я думаю - почему тогда не оставить блокирующую посылку сообщения с ожиданием ответа на уровне примитивов? (в эрланге-то ясно почему, ибо язык функциональный, состояния исключены). С другой стороны, это усложнит диспетчерирование потоков, т.к. сейчаc в своей библиотеке между посылкой запроса и приходом ответа Вы можете перекинуть поток на "оживление" любого другого актёра, а в этом случае контекст потока нужно сначала сохранить, потом опять восстановить... Либо вообще не трогать этот поток, но тогда количество одновременно оживляемых клиент-серверных актёров резко снизится...

Ответ на »сообщение 6020« (Стэн)
___________________________

Ответ на »сообщение 6013« (Илья Ермаков)
___________________________
Можно и такие:
http://stanonwork.blogspot.com/2007/11/act-o.html
Кстати, я ее тестировал до более чем 1'000'000 активных объектов, и все очень даже стабильно...

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