Здравствуйте, FR, Вы писали:
M>>DOOM III (насколько я читал обзоры этой игры и интервью с Кармаком)
FR>Кармак как подсел на OpenGL после Q2 так с него и не слазает
Оне не подсел. Он просто фанател с него. И на на Ку2, а еще на Ку1. Он в те времена целую обличительную оду для D3D написал. Правда ларчик открывался просто. Он просто С-шник. И плюсы не использует. А D3D — это ООП, хотя и кривоватый. Все было ОК, до третьего дума. К этому времени разница в ОпенЖЛ от АТИ и Нвидиа стала настолько большой, что он изматерился. Не удевлюсь если следующая игра будет на D3D. К тому же DX они один фиг вроде испльзуют.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>>>К тому есть несколько предпосылок. Приемущества по сравнению с питомном хотя бы то что результат получается намного быстрее. Если не забивать на производительность, то можно добиваться практически тех же результатов что и на плюсах. По оценкам тех что это уже делал проигрыш составляет 10-20% максимум.
FR>>Быстрее по скорости работы кода или скорости разработки? По скорости разработки вряд ли.
VD>Разработка быстрее в разы. Проигрыш в скорости кода в 10-20 процентов.
Вот не верю я про разы(хотя много раз уже слышал), в общем придется самому всеръез
изучать C# для проверки.
FR>>RAD тут не нужен, а уровень питона как ЯВУ думаю даже повыше чем C#
VD>Я так не думаю. Может на Питоне и быстро писать, но на Шарпе как миниум не медленнее. К тому же поддержка нманого лучше и осваивать язык проще.
насчет проще думаю это спорно, хотя спорить не буду, слишком плохо знаю шарп.
FR>>Если по коду то сомневаюсь что низкий уровень будет так мало проигрывать C++.
VD>И зря. Скачай готовые игры и убедись сам. Или тесты из DX.
тесты из DX9SDK на шарпе у меня работают в среднем в полтора раза медленее таких же
плюсовых.
VD>>>2. Шапр более высокоуровневый и на нем банально проще писать и отлаживаться.
FR>>И сложнее за счет этого оптимизировать.
VD>Наоборот. Оптимизировать нужно алгоритмы, а раз они проще модифицируются и пишутся, то и оптимизировать их проще. Один рефакторинг что стоит. Плюсам это и не снилось.
не понимаю почему проще.
FR>>А на питоне тоже очень легко и писать и отлаживатся
VD>Возможно. Но скорость нетипизированного языка делает его малопригодным для написания критичного ко времени кода. И будеш ты вынужден сифонить между плюсами и Питоном.
Ну все не так плохо, один jit для питона уже появился.
К тому же питон типизированный язык, но не со статической а с динамической типизацией.
VD>>>3. Не нужно делать многих рутинных действий вроде сериализации, контроля ссылок, и т.п.
FR>>это уже вопрос разделения, если логика на питоне то с сериализацией и остальным у него FR>>не хуже чем у C#
VD>Но и не лучше. При этом ты получаешь практически идентичную плюсам скорость, богатую IDE, качественный отладчик, кучу библиотек, удобный интероп и прекрасную поддержку. Сила Шарпа проявляется в комплексе. По отдельности вроде ничего особенного, но в комплексе очень даже.
Ты в рекламном агенстве раньше не работал
VD>>>4. Простота и скорость компиялции позволяют использовать в качестве скриптов тот же Шарп. По сути это означает что от скриптом можно отказаться вовсе. Ведь уровень Шрпа почти идентичен скриптам, а производительность намного выше.
FR>>У скриптов тоже есть способы поднять скорость.
VD>Есть то они есть. Но интерпретация всегда будет на порядок (десятичный) медленнее коапиляции. А если еще скрипт нетипизировн (что бывает очень часто), то и больше. Тут Вольхаудн как-то сделал интерпретатор вычисления форумул на С++. Я создал аналог на дотнете, но компилируемый и разница составла 20 раз. Причем код у Вольфхаунда был близок к оптимальному, и его интерпретатор использовал исключительно флоаты, так что проблем с типами небыло.
А ссылку можно?
Интересно посмотреть.
VD>Скорость же дотнетного кода очень близка к лучшим компиляторам С++. И даже превышает некоторые компиляторы. Так что получается типизированный скрипт, с отличной IDE, отладчиком, и скоростью С++. По-моему, заманчиво. Не находишь?
VD>>>5. Компонентая ориентация. В дотнете вообще нет проблем с динамической загрузкой. Это позволяет очень легко и красиво подключать внешние модули (плагины, энжыны и т.п.).
FR>>Игры не относятся к программам нуждающимся в компонетной архитектуре, а с остальным питон хорошо справляется.
VD>Еще как нужнаются. Сейчас игра без модов и плагинов уже и не игра. Разве что Пакмены разные... К тому же компонентный подход позволяет кроме этого еще и упростить интеграцию различных подсистем. Например, модуль рендеринга может подключаться через извесный интерфейс. Это поволяет развивать и отлаживать его пока другая часть команды работает над другими подсистемаии. Причем в отличии от разных КОМ-ов и доморощенных компонентных моделй используемых сейчас в пердовых продуктах компонентная модель дотнета обходится практически даром (и по потерям скорости, и по усилиям необходимым для ее использования).
Что мешает подключать на не шарпе модуль рендеринга через известный интерфейс?
FR>>А вообще я думаю что C# вполне годится для написания игр, и в этом он ни чем ни хуже Java или FR>>питона
VD>Я тоже так думаю. Более того упрощенный интероп даже способствет этому. Причем первые ласточки уже есть. Пока это еще не иминитые конторы. Но со временем, я думаю, что и именитые поймут, что выбрасывать деньги на ветер просто глупо.
VD>Что касается С++, то весь кай дотнета, что в нем очень легко интегрировать в проект сразу несколько языков. Без проблем можно интегрировать и С++. А будет Питон для дотнета, то и его тоже. Хоть функцинальные языки.
Питон для дотнета уже есть, но сильно коммерческий.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, FR, Вы писали:
FR>>Я не спорю есть игры написаные на Delphi и VB, будут и на C#,
VD>Я что-то не слышал, чтобы на ВБ были портированы движки игр, или что на нем создавались бы дважки с нуля. Скорости у него явно нехватало.
про движки не знаю, но видел достаточно сложные игры.
FR>>но не FR>>думаю что C# будет конкурентом в этой отрасли С++. Например Java ничем FR>>ни хуже для этих целей чем C#, но для больших игр не прижилась.
VD>А я вот почти уверен, что Шарп займет нехилые позиции в этой области. Просто нужно время на преодаление консерватизма в умах разработчиков.
видно будет
VD>Что касается Явы, то думаю все же Шарп имеет некоторые приемущества перед ней. Это и лучшая оптимизация, и интероп, и возможность очень легко включать в прокт код С++-код. В общем, как я уже говорил комплексность.
FR>>хотелось бы ссылку подтверждающую, на главной странице довольно тумано FR>>все написано, а качать исходники неохота.
VD>А может просто скачать и глянуть? Он вроде опенсорсный...
я в CVS залез, точно портировали.
LSL>>>Да, на плюсах. Вот тут как раз обёртка. Но не роль скриптового языка !
FR>>
VD>А что сешного? В общем-то по барабану полностью ли написан движок или есть качественная обертка. Ведь твоя задача писать прикладной код. И она успешно решается. Правда у оберток обычно производительность несколько хуже...
да так, не понятно зачем отказыватся от почетного звания скриптового языка
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, VladD2, Вы писали:
VD>>Что касается С++, то весь кай дотнета, что в нем очень легко интегрировать в проект сразу несколько языков. Без проблем можно интегрировать и С++. А будет Питон для дотнета, то и его тоже. Хоть функцинальные языки.
FR>Питон для дотнета уже есть, но сильно коммерческий.
Да, я немного погорячился. в памяти были слова Кармака из приведенного ниже интервью, где он сетовал на разнообразие архитектур различных видеокарт, чтоя невольно ассоциировал это с тем, что человеку приходится этим заниматься руками. Каюсь, был неправ.
Неожиданно для многих, Кармак также выступил в защиту обобщений сложных программных интерфейсов приложений, которые могут самостоятельно подвергать декомпозиции графические алгоритмы и оптимизировать себя под техническое обеспечение. Джон высказал свою горечь о присутствии на рынке стольких карт от различных производителей, ATi, nVidia, 3DLabs, Matrox и других, каждая из которых обладает своей уникальной архитектурой. Некотрые имеют 2 конвеера, некотрые – 4, а некотрые – 8. Ручная оптимизация движка под каждую из этих архитектур отнимает много времяни и отвлекает от разработки непосредственно движка и игры. Если бы движки писались с использованием програмных интерфейсов приложений, которые бы автоматически «декомпозировались» под конкретную технику, то можно было бы избежать гор монотонной работы. И пока многие с сожалением высказываются о недостаточной гибкости и широте низко-уровневых настроек и оптимизаций, Кармак проводит аналогию с разницей программирования на «assembly» и «С». Кто програмирует игры в «assembly» сегодня? Да, на «С» не добраться до столь мелких настроек, но зато в освободившееся время можно заняться более важными оптимизациями.
M>>>движки игр (не надстройки над DirectX и OpenGL, а общающиеся напрямую с карточкой) __>>Таких движков на PC нет: все общаются с карточкой только через DirectX и/или OpenGL.
LSL>А как же Software rasterization ? Кажется, в Q2 такое есть...
Так когда этот движок писали еще и ускорителей толком не было.
Мы же говорим о настоящем моменте (и C#): сейчас для комерческих 3D-игр для PC это уже давно не актуально — железо порвет любой
Software rasterization.
Здравствуйте, mikа, Вы писали:
V>>(я его не юзаю, например, у меня и мест в программе нет, где бы такое случилось... давно уже юзаю набор смартпоинтеров собственного изготовления и забыл про эти вещи раз и навсегда)
M>Точно! Смарт Поинтеры. А чем они лучше тех же ссылок, которые сами освобождают область памяти?
Твои managed хендлеры (именно хендлеры, это не ссылки, просто им дали имя ссылок, чтобы легче понимать было), ничем не лучше. Это просто разные способы учета ресурсов.
Я писал в разное время разные менеджеры памяти. Так вот что характерно, что легко удается получить очень большую скорость выделения памяти, быстрее даже, чем это делает дотнетовский менеджер. Однако, операция возврата памяти обратно менеджеру всегда получалась довольно долгой (я даже играл с такой вещью, как "отложенный возврат", т.е. просто ставил куски памяти в очередь на возврат, и вызывал периодически системную ф-ию для обработки этой очереди).
Подход дотнета очень похож. В нем операция возврата памяти еще более длительная и сложная, но она очень удачно отложена.
------
принципы GC можно использовать и в С++ без проблем (давно есть open-source разработки на эту тему).
Правда, ВСЯ программа должна быть написана именно ориентируясь на этот GC, и мы в итоге получаем слабую связь (или сложности) с использованием унаследованного кода.
------
В отличие от дотнета, где у меня нет выбора, на С++ я могу произвольно выбирать способ слежения за ресурсами, и у меня есть шанс выбрать наиболее удачный для каждого конкретного случая. (использование разных стратегий менеджмента ресурсов для разных объектов в одной программе — обычное дело).
Я понимаю, что "когда я пишу на дотнете, я сосредоточен ТОЛЬКО на решаемой задаче", это похвально, разумеется. Но если учесть вышесказанное про задачу (!!! именно бывает такая задача) взять максимум от железки, то ты должен именно взять от нее максимум.
-----
Самое парадоксальное что ПОЧТИ ВСЕ задачи требуют взять максимум от железки, и гораздо проще перечислить задачи, где этого НЕ требуется.
Например:
— GUI (Forms или Веб), ибо ЛЮБАЯ современная система способна справится с той скоростью, с которой юзер кликает на устройства ввода.
— ORM, ибо область применения, где он ВОСТРЕБОВАН — это именно предыдущий пункт.
Здравствуйте, vdimas, Вы писали:
V>Я писал в разное время разные менеджеры памяти. Так вот что характерно, что легко удается получить очень большую скорость выделения памяти, быстрее даже, чем это делает дотнетовский менеджер. Однако, операция возврата памяти обратно менеджеру всегда получалась довольно долгой (я даже играл с такой вещью, как "отложенный возврат", т.е. просто ставил куски памяти в очередь на возврат, и вызывал периодически системную ф-ию для обработки этой очереди).
У меня есть менеджер памяти который и выделяет быстро и удаляет тоже. Более того не использует дополнительной памяти на выделяемый блок. Используется в реальном проекте (все летает). Причем задача может считать несколько суток выделяя и освобождая большие обьемы. Хип в таких условиях фрагментируется и начинает тормозить.
Вот куски функций по которым можно оценииь скорость работы:
// выделяет быстро
block* alloc_() {
block *p = cur_->free;
if ( p ) {
cur_->free = p->next;
cur_->used_n++;
return p;
}
// сюда заходим редко
chunk *c = first_;
for ( ; c; c = c->next ) {
p = c->free;
if ( p ) {
cur_ = c;
cur_->free = p->next;
cur_->used_n++;
return p;
}
}
// сюда еще реже
c = chunk_alloc_();
if ( c ) {
p = c->free;
cur_ = c;
cur_->free = p->next;
cur_->used_n++;
return p;
}
return (block*)Tr::out_of_mem();
}
// а освобождает не-децки быстроvoid free_( void *p ) {
block *pb = (block*)p;
chunk *c = (chunk*)((size_t)p & (size_t)chunk_mask_);
pb->next = c->free;
c->free = pb;
c->used_n--;
}
P.S. Если надо могу подбросить, в С++ форуме уже выкладывал
Здравствуйте, FR, Вы писали:
FR>Вот не верю я про разы(хотя много раз уже слышал), в общем придется самому всеръез FR>изучать C# для проверки.
Да, уж. Только открою один сикрет. Нужно пережить первые несколько месяцев когда все непревычано. Кстати, ту по теме вчера появилось Первый месяц с .Net :)
.
FR>насчет проще думаю это спорно, хотя спорить не буду, слишком плохо знаю шарп.
Точно проще. Тут опять таки складываются несколько факторов:
1. Очень неплохая документация интегрированная в МСДН.
2. Куча книг от очень хороших авторов (Рихтер, Дон Бокс).
3. Одна из лучших IDE (да и не одна). Обеспечивающая кучу визардов, комплит ворд, описание функций илассов, рефакторинг и т.п.
4. Очень быстрый компилятор шарпа (да и плюсы заметно быстрее компилировать начинают).
5. Куча форумов с очень высоким уровнем.
6. Куча статей (я лично штук 10 написал ).
7. Очень легкая в освоении библиотека.
6. Похожесть на многие передовые средства разработки (Дельфисы и плюсовики частенько спорят о конрях).
В общем, всего и не перечислишь.
FR>тесты из DX9SDK на шарпе у меня работают в среднем в полтора раза медленее таких же FR>плюсовых.
Очень и очень страно. Я своими глазами видел, что скорость у них идентична.
VD>>Наоборот. Оптимизировать нужно алгоритмы, а раз они проще модифицируются и пишутся, то и оптимизировать их проще. Один рефакторинг что стоит. Плюсам это и не снилось.
FR>не понимаю почему проще.
Дык кода меньше. Код боле легок в чтении. Есть тулзы для рефакторинга (очень доступные). Очень хорошо работает ителисенс (комплит ворд, хинты к фукнциям, ...), автодокументация кода. В общем, море разных мелочей вместе вылевающихся в ощущение, что вместо программирования пишешь текст в конфе.
FR>Ну все не так плохо, один jit для питона уже появился.
Ну, ты сам как считашь, может этот джит потягаться по скорости создаваемого кода с тем же VC 7.x?
Кстати, у нас тут на сайте лежат тесты. Если не влом, воспроизведи на Питоне и померяем его относительную производительность.
FR>К тому же питон типизированный язык, но не со статической а с динамической типизацией.
Динамическая — это в рантайме? Если так, то для скорости это приговор. Это неменуемо выливается в интерпретацию (проверку типов в рантайме). А она принципиально медленее. Конечно отдельные операции можно оптимизировать, но в общем производительность получается не ахти. Хотя, повторюсь, нужно мерить.
FR>Ты в рекламном агенстве раньше не работал
Нет.
Просто делюсь тем что мне самому нравится.
FR>А ссылку можно? FR>Интересно посмотреть.
.
FR>Что мешает подключать на не шарпе модуль рендеринга через известный интерфейс?
Объем кода требуемый для этого. На том же С++ для динамического подключения модулей нужно создать свой фрэймворк. Учитывая, что в С++ вообще нет ничего по работе с исполняемыми модулями, то такой фрэймворк для каждой платформы прийдется писать занова. Можно конечно воспльзоваться COM-ом. Но сним один фиг траха на порядок больше. А на шарпе подключение модуля будет выглядеть примерно так:
// В основном модуля описываем интерфейс который
// обязан реализовать плагинinterface IMyPlagin
{
void DoWork();
}
И где-то при загрузке создаем объект и запрашиваем у него этот интерфейс:
...
// Загружаем длл-у (по дотнетовски - сборку).
Assembly assembly = Assembly.LoadFrom("имя сборки, например читаемое из ини-файла");
// Создаем тип. В принципе можно помечать нужные типы атрибутами
// и создавать их все. Это позволит избежать завязки на конкретные имена.
IMyPlagin myPlagin = (IMyPlagin)assembly.CreateInstance("Некоторое имя класса");
// Вызываем метод плагина
myPlagin.DoWork();
FR>Питон для дотнета уже есть, но сильно коммерческий.
Здорово звучит "Сильно коммерческий".
Интересно, а какой-нить версии для некомерческого использования у них нет?
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Kluev, Вы писали: K>Вот куски функций по которым можно оценииь скорость работы:
Я правильно понимаю, что ты умеешь работать исключительно с блоками фиксированного размера? В таком случае действительно не имеет смысла говорить о фрагментации.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, WolfHound, Вы писали:
VD>В общем, для обучения на сегодна Шарп, по-моему, самое оно. А плюсы всегда были сложноваты.
Да вообщем профессия "программист" — не обещает легких путей... Если боишься трудностей, то
тогда, ИМХО, в мир программирования лучше не соваться.
Ну а вообще, про ту версию шарпа, которую я видел... мне оччень не понравилась. От невозможности
писать объявление класса и его реализацию в разных файлах мне стало плохо . Правда говорят, что
в какой-то там новой версии это делать можно. В общем я думаю, что время покажет, кто прав.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Kluev, Вы писали: K>>Вот куски функций по которым можно оценииь скорость работы: S>Я правильно понимаю, что ты умеешь работать исключительно с блоками фиксированного размера? В таком случае действительно не имеет смысла говорить о фрагментации.
С набором размеров. Одна часть выделяет большие блоки, которые затем "режутся" под конкретные размеры.
Как правило используемый набор типов в С++ ограничен, а множество их сайзоф-ов еще меньше, поэтому можно получить очень неплохие результаты. А для векторов у нас отдельный распределитель.
З.Ы. Сейчас у хипов одна из главных проблем нехватка адрессного пространства, именно адрессов, а не физической памяти. С переходом на 64 бита когда адрессов будет очень много, можно за счет резервирования адрессного пространства получить очень мощные оптимизации, такие что new-delete приблизятся к распределению на стеке. У меня уже руки чешутся написать 64-битный распределитель
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, FR, Вы писали:
FR>>Вот не верю я про разы(хотя много раз уже слышал), в общем придется самому всеръез FR>>изучать C# для проверки.
VD>Да, уж. Только открою один сикрет. Нужно пережить первые несколько месяцев когда все непревычано. Кстати, ту по теме вчера появилось Первый месяц с .Net :)
Это с любым новым языком так, я вот ocaml уже пару раз пытался освоить,
но не идет и все. А тот же питон почти сразу пошел.
FR>>насчет проще думаю это спорно, хотя спорить не буду, слишком плохо знаю шарп.
VD>Точно проще. Тут опять таки складываются несколько факторов: VD>1. Очень неплохая документация интегрированная в МСДН.
У питона тоже хорошая документация.
VD>2. Куча книг от очень хороших авторов (Рихтер, Дон Бокс).
Аналогично, в последнее время стало немало и переведенных книг.
VD>3. Одна из лучших IDE (да и не одна). Обеспечивающая кучу визардов, комплит ворд, описание функций илассов, рефакторинг и т.п.
Часто командная строка интерпретатора удобнее всего что ты описал
VD>4. Очень быстрый компилятор шарпа (да и плюсы заметно быстрее компилировать начинают).
Что-то я не заметил что VC7.1 быстрее компилирует чем VC6
VD>5. Куча форумов с очень высоким уровнем.
тоже самое
VD>6. Куча статей (я лично штук 10 написал ).
тоже хватает
VD>7. Очень легкая в освоении библиотека.
ну у Питона как и у си тоже вся сила в библиотеках
VD>6. Похожесть на многие передовые средства разработки (Дельфисы и плюсовики частенько спорят о конрях).
VD>В общем, всего и не перечислишь.
FR>>тесты из DX9SDK на шарпе у меня работают в среднем в полтора раза медленее таких же FR>>плюсовых.
VD>Очень и очень страно. Я своими глазами видел, что скорость у них идентична.
сейчас еще раз проверил 30% отставание точно есть, на некторых до двух раз.
да я скачал еще этот портированный на шарп OGRE, вообще интересно их сайт читать,
практически твоими словами описывают преимущества шарпа и там же заявляют
что портированная версия быстрее чем плюсовый оригинал, в общем потестировал,
шарп отстает на те же 30% — 50%, так что доверие к их рекламе сильно подорвано
VD>>>Наоборот. Оптимизировать нужно алгоритмы, а раз они проще модифицируются и пишутся, то и оптимизировать их проще. Один рефакторинг что стоит. Плюсам это и не снилось.
FR>>не понимаю почему проще.
VD>Дык кода меньше. Код боле легок в чтении. Есть тулзы для рефакторинга (очень доступные). Очень хорошо работает ителисенс (комплит ворд, хинты к фукнциям, ...), автодокументация кода. В общем, море разных мелочей вместе вылевающихся в ощущение, что вместо программирования пишешь текст в конфе.
На питоне кода тоже в разы меньше чем на плюсах. И автодокументация встроенна в язык
Да и на плюсах тот же doxygen отлично все документирует.
FR>>Ну все не так плохо, один jit для питона уже появился.
VD>Ну, ты сам как считашь, может этот джит потягаться по скорости создаваемого кода с тем же VC 7.x?
скорее всего нет, но его более чем достаточно для скрипта.
VD>Кстати, у нас тут на сайте лежат тесты. Если не влом, воспроизведи на Питоне и померяем его относительную производительность.
если честно я отношусь к таким тестам с большим недоверием, но если будет свободное время
сделаю.
FR>>К тому же питон типизированный язык, но не со статической а с динамической типизацией.
VD>Динамическая — это в рантайме? Если так, то для скорости это приговор. Это неменуемо выливается в интерпретацию (проверку типов в рантайме). А она принципиально медленее. Конечно отдельные операции можно оптимизировать, но в общем производительность получается не ахти. Хотя, повторюсь, нужно мерить.
Питон как и java и C# использует виртуальную машину. То есть компиляция в байт код и потом исполнение.
А проверки да большей частью в runtime (мне это тоже не нравится)
FR>>Ты в рекламном агенстве раньше не работал
VD>Нет. VD>Просто делюсь тем что мне самому нравится.
FR>>А ссылку можно? FR>>Интересно посмотреть.
VD>Ёлы, палы, какждый второй ссылки требует. Я уже задолбался. Вот минут 10 искал: Re: Частые вычисления по неопределенной формуле!!!
смотрю
FR>>Что мешает подключать на не шарпе модуль рендеринга через известный интерфейс?
VD>Объем кода требуемый для этого. На том же С++ для динамического подключения модулей нужно создать свой фрэймворк. Учитывая, что в С++ вообще нет ничего по работе с исполняемыми модулями, то такой фрэймворк для каждой платформы прийдется писать занова. Можно конечно воспльзоваться COM-ом. Но сним один фиг траха на порядок больше. А на шарпе подключение модуля будет выглядеть примерно так:
А на питоне import MyModule
все грузится дмнамически, притом можно переопределить механизм загрузки
FR>>Питон для дотнета уже есть, но сильно коммерческий.
VD>Здорово звучит "Сильно коммерческий". VD>Интересно, а какой-нить версии для некомерческого использования у них нет?
Здравствуйте, VladD2, Вы писали:
LSL>>>Да, на плюсах. Вот тут как раз обёртка. Но не роль скриптового языка !
FR>>
VD>А что сешного? В общем-то по барабану полностью ли написан движок или есть качественная обертка. Ведь твоя задача писать прикладной код. И она успешно решается. Правда у оберток обычно производительность несколько хуже...
Да. Managed DirectX — DirectX API для .NET, тоже обёртка (довольно тонкая) над Native DirectX...
Интересно, что будет дальше, в Longhorn, в WGF. Осталось ждать бета-версию.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, LSL, Вы писали:
LSL>>А как же Software rasterization ? Кажется, в Q2 такое есть...
VD>А он с железом тоже не общается. Насколько я понимаю он через Direct Draw графику выводит. Ну, а сам рендеринг в памяти.
Графика выводится через собственные алгоритмы на ассемблере. Т.е. сторонние API не используются.
VD>Кстати, Q2 портирован под дотнет и показывает очень неплохие результаты. Правда сделано это простой перекомпиляцие на МС++, т.е. без шарпа.
