Так, вроде объяснили люди добрые, что это стандартный (в т.ч. по ISO) формат векторной графики, и вроде очень хороший.
Ну что тут можно сказать - что ж плохого в том, чтобы в ББ иметь SVG-View? Очень было бы даже хорошо. Только где волонтёров найти... Вон, в "коллективной разработке" народ даже простые таблицы зафигачить не раскачался...

Ответ на »сообщение 6014« (mud-eng)
___________________________

Вот такая вот мыслишка. Хотел на forum.oberoncore разместить в разделе "Коллективная разработка", но там такая тишь да благодать... Одним термоядерным ударом закинуть ББ на вершину сразу в нескольких сегментах. Много всяких прожектов было озвучено вокруг и для ББ. Предлагаю еще один, по-настоящему улетный.

Не сочтите за серость и дремучий провинциализм... Но что це такое буде - SVG?

Вот такая вот мыслишка. Хотел на forum.oberoncore разместить в разделе "Коллективная разработка", но там такая тишь да благодать... Одним термоядерным ударом закинуть ББ на вершину сразу в нескольких сегментах. Много всяких прожектов было озвучено вокруг и для ББ. Предлагаю еще один, по-настоящему улетный.
SVG.
Насколько я владею ситуацией, такого еще не предлагалось. Для начала, "хотя-бы", сделать отображение (SVGView), поддерживающее стандарт SVG. Но отображение не простое, а золотое - с "врожденной" поддержкой "бесконечного" размера отображения, с "встроенными" полосами прокрутки. Затем, следующий шаг, на основе SVGView сделать визуальный редактор документов SVG. С перетаскиванием/растяжением мышкой, с контекстными меню для объектов и т.д. и т.п. Сразу получаете и мощнейший редактор научных и всевозможных других текстов. Про другие области возможного применения даже и не говорю: образования не хватает. И не надо делать "правильно", надо делать, "чтобы работало". Есть уже библиотеки? Значит использовать их по полной. В хвост и в гриву. Если что-то получится, то потом можно будет сделать и "правильно". Не сочтите за поучение, это так, выплеск эмоций.
Что здесь лично меня особенно вдохновляет, так это то, что идейка хорошо вписыватся в концепцию ББ, в его АД, и не выглядит "припекой с боку". Органично расширяет его возможности. Что скажете, господа хорошие?
Да, есть у меня идейки по доведению до ума реализации концепции АД в ББ, но вы сначал хорошенько посмейтесь над этой, SVG-идеей, а там поглядим.

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

Ответ на »сообщение 6009« (Илья Ермаков)
___________________________
Вы бы, прежде чем такие утверждения делать, хотя бы изучили ситуацию с разработкой многопоточных приложений на С/С++.
www.rapidmind.net
Спасибо за интересную ссылку. Из неё понял, что ребята как раз таки отказались от "многопоточных приложений" (обосновав это именно так, что "параллельное программирование опасно и сложно" - ну ещё бы! Про что я и сказал - "колдыбание с семафорами и мьютексами", а на высокоуровневость фантазии не хватает...), а предложили библиотеку и рантайм для мелкогранулярного распараллеливания отдельных фрагментов вычислительного потока. Не сомневаюсь, что на вычислительных задачах это помогает задействовать больше одного ядра. Но причём здесь параллельное программирование, как создание параллельно и распределённо функционирующих задач (ориентированных не на линейные вычисления, а на нечто более "управляющее")?
Кроме того, такой fine-grained automated параллелизм требует очень сложной прослойки - и компилятора, и рантайма, и оптимизатора (думаю, намного похлеще, чем тот же Хаскелл). Мне страшно представить работу поверх всей этой штуки - полный недетерминизм и непрозрачность... Даже для вычислительных задач (Вы вот у Info21 спросите, насколько затрудняет контроль над процессом вычислений - например, над точностью - обычная, непараллелизующая оптимизация, и почему предпочтительнее использовать компилятор вообще без оптимизатора).
А теперь вспомним, что нет ни одного компилятора С++, не содержашего ошибок. И помножим эти ошибки на ошибки, безусловно, сушествующие в этом толстенном RapidMind. Спасибо, С++ Builder мы уже нюхали :-)

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

Ответ на »сообщение 6009« (Илья Ермаков)
___________________________
>>> А С/С++-сники пускай себе с семафорами и мьютексами колдыбаются, как в каменном веке :-Р
Вы бы, прежде чем такие утверждения делать, хотя бы изучили ситуацию с разработкой многопоточных приложений на С/С++.
www.rapidmind.net

Ну дайте уж, дайте побрюзжать :-)
А то уже сколько месяцев сплошная политкорректность :-)

Всё равно сишники костылями занимаются... Потому что изначально отвергли один из основных принципов программирования: выстраивание иерархии абстракций (и все следствия - принцип высокоуровневости, компактности - "Калашникова", основные критерии хорошего ЯВУ и т.п.). А теперь пытаются на каждую конретную дырку искать конкретную затычку.

Ответ на »сообщение 6009« (Илья Ермаков)
___________________________
>>> А С/С++-сники пускай себе с семафорами и мьютексами колдыбаются, как в каменном веке :-Р
Вы бы, прежде чем такие утверждения делать, хотя бы изучили ситуацию с разработкой многопоточных приложений на С/С++.
www.rapidmind.net

P.S. Сейчас понемногу занимаюсь изучением упомянутого мной движка, буду начинать портировать.

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

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

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

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

Производительность это далеко не самое главное.
Есть игры типа MUD, где всё происходит в текстовом режиме.
И играют в них с азартом и поныне.
(В последнее время узнал многое о мире игр.
Литобзор и опрос свидетелей провожу :)
Это интересно по насыщенности идеями).

Меня больше волнует вопрос о диагностике ошибок.
Так как предполагается наплыв чайников, это бы надо провентилировать.
Если в структуру игродрома внедрён дефектный модуль,
то среда игры должна аккуратно обработать это.
Причём так, чтобы игровой процесс не нарушать.

Динамической подгрузке модулей даёшь динамический дебаггер!

На днях сайт - площадку для игродрома замутим.
С викидвижком и форумом. Уже есть хостер.
По крайней мере дизайнер себя в грудь кулаком стучал :)
Но кто верит пьяному дизайнеру? :)