Здравствуйте, AndrewVK, Вы писали:
ВВ>>А такая абстракция как отсутствие прямого доступа к памяти не помешает в реализации движка, как думаешь? AVK>Так он присутствует.
Где присутствует? То, что отдельные функции и даже отдельные библиотеки, и даже такие важные вещи как расчет физики, можно реализовать с использованием управляемой среды, не теряя в эффективности практически, я не отрицаю.
Но вот как написать целиком и полностью 3D-движок только с использованием управляемой среды я уже представляю с трудом. Возможно, я недостаточно знаком с предметной областью. Можно вот как-нибудь напрямую работать с видео-памятью в дотнете?
Здравствуйте, Воронков Василий, Вы писали:
ВВ>>>А такая абстракция как отсутствие прямого доступа к памяти не помешает в реализации движка, как думаешь? AVK>>Так он присутствует.
ВВ>Где присутствует?
В дотнете и языке C# присутствует прямой доступ к памяти.
ВВ> Можно вот как-нибудь напрямую работать с видео-памятью в дотнете?
Напрямую с видеопамятью так просто, как в ДОСе, давно уже не работают. Работают, к примеру, с плоскостями DirectX. Выделяешь плоскость, получаешь ее адрес и вперед. А уж как потом все это видеокарте достанется — забота драйвера.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
Здравствуйте, Pavel Dvorkin, Вы писали:
PD> Спроецируйся назад на 10 лет (1998г) и попробуй предсказать будущее. Я не уверен, что в этом предсказании .Net вообще бы оказалась.
Java в 98 уже три года как была доступна, в 97 уже началась ругачка между Саном и МС по поводу нее, а два года спуста уже была доступна первая бета-версия, так что появление в 2001 году дотнета, вобщем то, предсказать было вполне реально.
PD>1. Сольются ли мобильные девайсы и настольные системы ?
Они уже слились.
PD>2. Сольются ли телевидение и персональные компьютеры ?
Уже слилось.
PD> Останется ли "волновое" телевидение или только цифровое будет ?
Останется. Мир большой.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
Здравствуйте, Воронков Василий, Вы писали:
ВВ>>>Где присутствует? AVK>>В дотнете и языке C# присутствует прямой доступ к памяти.
ВВ>Т.е. мы не отрицаем, что такая красивая абстракция как опосредованный доступ к памяти
Не понимаю. Сейф-режим идет лесом при прямом доступе к памяти, только потому что современное железо не в состоянии обеспечить сейфнутость такого доступа. Все абстракции платформы при этом остаются на своих местах.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Не понимаю. Сейф-режим идет лесом при прямом доступе к памяти, только потому что современное железо не в состоянии обеспечить сейфнутость такого доступа. Все абстракции платформы при этом остаются на своих местах.
А сейф-режим разве это не абстракция платформы? Собственно, почему он сейфом-то называется.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>А сейф-режим разве это не абстракция платформы?
Нет. это признак того, что код можно статически проконтроллировать верификатором. Дополнительных абстракций в саму платформу верификатор не вносит. А IL один и тот же.
ВВ> Собственно, почему он сейфом-то называется.
Потому что может быть верифицирован.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Java в 98 уже три года как была доступна, в 97 уже началась ругачка между Саном и МС по поводу нее, а два года спуста уже была доступна первая бета-версия, так что появление в 2001 году дотнета, вобщем то, предсказать было вполне реально.
Кстати, да. В 98-м была уже доступна "первая попытка дотнета" — J++. И я даже с ней возился, хотя и несколько позже.
Здравствуйте, AndrewVK, Вы писали:
AVK>Нет. это признак того, что код можно статически проконтроллировать верификатором. Дополнительных абстракций в саму платформу верификатор не вносит. А IL один и тот же.
Ну извините. Я же не работаю с указателями, не оперирую понятиями типа "адрес объекта", не удаляю объекты вручную. В CLI даже синтаксис разный:
MyObject* o = new Object;
и
MyObject^ o = gcnew Object();
Причем второй пример более высокоуровневый чем первый.
ВВ>> Собственно, почему он сейфом-то называется. AVK>Потому что может быть верифицирован.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, Константин Б., Вы писали:
КБ>>Тем что быстрее. Функции GetPixel и SetPixel работают очень медленно, т.к. внутри себя вызвают BitBlt.
PD>Можно ссылочку на источник, где говорится, что они вызывают BitBlt ? Куда она копирует ? Где второй HDC ? http://www.rsdn.ru/res/book/mmedia/yuan.xml
>>Напрямую получить весь массив с той же BitBlt гораздо быстрее.
PD>BitBlt все-таки копирует битовую карту , а вовсе не возвращает биты. А получить биты можно, GetBitmapBits / GetDIBIts, но это совсем другая история
Вот копируем на off-screen DC и оттуда забираем биты. Вы что первый раз c GDI работаете?
Здравствуйте, Воронков Василий, Вы писали:
AVK>>Прочитай то, что я процитировал, еще раз. На всякий случай, если непонятно — Mono.Simd это та самая абстракция, которая, якобы, противопоказана. ВВ>А такая абстракция как отсутствие прямого доступа к памяти не помешает в реализации движка, как думаешь?
Нет. Уже много лет никто ничего напрямую в видео память не пишет.
Видюхе просто данные подготавливают, а она сама все рендерит.
Так на порядки быстрее получается чем рендерить при помощи CPU и пиать в видео память.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, gandjustas, Вы писали:
G>>Такое барахло как этот код сумрования я бы вообще в продакшн ен пустил. PD>Чудненько. Можешь еще заявить, что суммирование вообще есть барахло, а поэтому его и не надо делать. Или придумай другой способ суммирования.
Пустая риторика, низачот.
G>>>>Я думаю считать все пиксели в память а потом суммировать будет лучше. PD>>>А я так думаю, что введение лишнего массива без всякого обоснования не есть лучшее. G>>Добро пожаловать в настоящее, копромис время-память уже давно сместился в сторону времени, память теперь никто не жалеет. Ну может кроме тебя. PD>И поэтому надо без всякого смысла создавать новый массив и тратить время на его заполнение. Когда выбор идет между временем и памятью — это имеет смысл и решение может быть и в ту и в другую пользу. Когда же увеличивают и то и другое без всякого смысла — это уже иначе называется.
Напряги свои знания WinAPI, может впомнишь что есть функция считывание всего битмапа из DC, что будет гораздо быстрее считывания отдельных пикселей.
PD>>>Программа не изменится. Изменятся выводы, так как их нельзя делать на данных, которые не позволяют делать эти выводы. В общем,см. курс матстатистики — сравнение двух средних и т.д. G>>Это нельяз делать потому что нельзя... смешно. PD>Да не смешно, а очень грустно, что элементарные понятия из матстатистики для тебя тайна за семью печатями.
Меня эти понятия. Мне достаточно сравнить два числа.
Если тебе для сравнения двух чисел надо привлекать матстатистику, то мне тебя очень жаль.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Здравствуйте, AndrewVK, Вы писали:
ВВ>>>А такая абстракция как отсутствие прямого доступа к памяти не помешает в реализации движка, как думаешь? AVK>>Так он присутствует.
ВВ>Где присутствует? То, что отдельные функции и даже отдельные библиотеки, и даже такие важные вещи как расчет физики, можно реализовать с использованием управляемой среды, не теряя в эффективности практически, я не отрицаю. ВВ>Но вот как написать целиком и полностью 3D-движок только с использованием управляемой среды я уже представляю с трудом. Возможно, я недостаточно знаком с предметной областью. Можно вот как-нибудь напрямую работать с видео-памятью в дотнете?
А можно работать напрямую с видеопамятью хоть где-нибудь под Windows? Ответ — нет.
Да и наибольшие тормоза в графических движках вызывает не отрисовка и текстутрирование (они уже давно выполняются на видеокарте), а отсечение невидимых поверхностей, расчет столкновений итп.
Используя более высокий уровень абстракциии можно написать код, который будет компилироваться в язык шейдеров и выполняться на видеокарте или на CPU, если видеокатра не поддерживает. .NET также позволяет достаточно просто распараллелить вычисления на несколько процессоров.
Не ждите появления завтра сумер-мега управляемого 3d-движка на .NET, большенство технологий которые нужны для написания движка еще "сырые", ни в одном большом проекте пока не будут использоваться. Также многие игростудии пока что испытывают страх перед управляемыми платформами в 3d движках.
Здравствуйте, gandjustas, Вы писали:
G>А можно работать напрямую с видеопамятью хоть где-нибудь под Windows? Ответ — нет.
Это я уже понял. Ступанул.
G>Да и наибольшие тормоза в графических движках вызывает не отрисовка и текстутрирование (они уже давно выполняются на видеокарте), а отсечение невидимых поверхностей, расчет столкновений итп.
Мне вот кажется, что требования к потреблении памяти — как обычной, так и видео — в 3Д движках должны более жесткие, чем в других приложениях. Посмотрите на системные требования игрушек, ужаснуться можно. Сколько всякого добра им приходится кэшировать в ОЗУ. И тут дополнительный "оверхед", который вносит дотнет, может сыграть не самую лучшую роль.
minorlogic,
M>Довольно стандартная фича например для C++, это я недоразобрался или в плюсах есть потдержка функциональных фичей ? это не наезд , но например boost iterator adaptors именно так и работают.
Чтобы компиляторы грязных C++ или Java имели возможность полноценного применения дефорестейшна, компилятор должен знать, когда вызывается функция над коллекцией и имеет ли она или нет побочные эффекты. Это весьма трудная задача для компилятора, если конечно язык не содержит явного описания операции над коллекциями. А вот например, система типов Хаскеля позволяет выяснить как первое, так и второе.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Мне вот кажется, что требования к потреблении памяти — как обычной, так и видео — в 3Д движках должны более жесткие, чем в других приложениях. Посмотрите на системные требования игрушек, ужаснуться можно. Сколько всякого добра им приходится кэшировать в ОЗУ. И тут дополнительный "оверхед", который вносит дотнет, может сыграть не самую лучшую роль.
Или наоборот — на фоне их и так немалых требований к ОЗУ оверхед от дотнета будет просто незаметен
Такая вот диалектика, как про грязного мужика и баню
P.S. где-то тут на форуме видел ссылку на разрабатываемый эффективный и качественный (по уверениям разработчиков) 3D-движок для дотнета. Который еще в бете, но скоро зарелизят. И пока что можно его бесплатно скачать-посмотреть.
Незнаю насколько он управляеый, а насколько просто обертка над нативом, но это не важно. Будет движок — можно ожидать появления игр, где дотнет будет основной средой.
Если первые проекты окажутся достаточно удачными — будут и другие.
Не так много людей готовы рискнуть деньгами на необычной для данного направления технологии. Но рано или поздно находятся. И если у них все удается, то и остальные подтягиваются.
Здравствуйте, gandjustas, Вы писали:
G>А можно работать напрямую с видеопамятью хоть где-нибудь под Windows? Ответ — нет.
Ответ да. DirectDraw создаешь поверхность в видеопамяти и вперед.
G>Да и наибольшие тормоза в графических движках вызывает не отрисовка и текстутрирование (они уже давно выполняются на видеокарте), а отсечение невидимых поверхностей, расчет столкновений итп.
Угу и часто эти алгоритмы требуют много памяти и оптимизации доступа к этой памяти с учетом кеша и т. п. что проще делать в средах без GC.
G>Используя более высокий уровень абстракциии можно написать код, который будет компилироваться в язык шейдеров и выполняться на видеокарте или на CPU, если видеокатра не поддерживает. .NET также позволяет достаточно просто распараллелить вычисления на несколько процессоров.
Для шейдеров не нужны и бесполезны более высокие уровни абстракций, слишком короткие и ограниченые "программы" они пока подерживают, и существующих сиобразных языков сейчас более чем достаточно.
G>Не ждите появления завтра сумер-мега управляемого 3d-движка на .NET, большенство технологий которые нужны для написания движка еще "сырые", ни в одном большом проекте пока не будут использоваться. Также многие игростудии пока что испытывают страх перед управляемыми платформами в 3d движках.
Игростудии пишут сейчас игры в основном для приставок, а там до сих пор всего 256 (512 вместе с видео) метров памяти на борту. Кроме того большая часть приставок не контролируются ms и там NET еще долго не появится.
Здравствуйте, fmiracle, Вы писали:
F>Или наоборот — на фоне их и так немалых требований к ОЗУ оверхед от дотнета будет просто незаметен
Нет проблема в том что в той же приставке всего 256 метров памяти, а игра требует гораздо большего объема и в таких условиях ручное управление на порядки эффективнее чем GC
F>Такая вот диалектика, как про грязного мужика и баню
Угу только не в бане а очень тесной душевой кабине
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, gandjustas, Вы писали:
G>>А можно работать напрямую с видеопамятью хоть где-нибудь под Windows? Ответ — нет. FR>Ответ да. DirectDraw создаешь поверхность в видеопамяти и вперед.
А причем тут 3d?
G>>Да и наибольшие тормоза в графических движках вызывает не отрисовка и текстутрирование (они уже давно выполняются на видеокарте), а отсечение невидимых поверхностей, расчет столкновений итп. FR>Угу и часто эти алгоритмы требуют много памяти и оптимизации доступа к этой памяти с учетом кеша и т. п. что проще делать в средах без GC.
Бред. Все эти оптимизации дадут максимум 20%, при этом оптимизация алгоритма может в разы увеличить скорость.
G>>Используя более высокий уровень абстракциии можно написать код, который будет компилироваться в язык шейдеров и выполняться на видеокарте или на CPU, если видеокатра не поддерживает. .NET также позволяет достаточно просто распараллелить вычисления на несколько процессоров. FR>Для шейдеров не нужны и бесполезны более высокие уровни абстракций, слишком короткие и ограниченые "программы" они пока подерживают, и существующих сиобразных языков сейчас более чем достаточно.
Ключевое слово "пока" — выделено.
Уже сейчас есть возможность написать на F# код, который будет выполняться как на CPU, так и на видеокарте. В неуправляемой среде можно сделать такое?
G>>Не ждите появления завтра сумер-мега управляемого 3d-движка на .NET, большенство технологий которые нужны для написания движка еще "сырые", ни в одном большом проекте пока не будут использоваться. Также многие игростудии пока что испытывают страх перед управляемыми платформами в 3d движках.
FR>Игростудии пишут сейчас игры в основном для приставок, а там до сих пор всего 256 (512 вместе с видео) метров памяти на борту. Кроме того большая часть приставок не контролируются ms и там NET еще долго не появится.
Для большенства приставок и DirectX нету, там вообще другие "законы".
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Мне вот кажется, что требования к потреблении памяти — как обычной, так и видео — в 3Д движках должны более жесткие, чем в других приложениях. Посмотрите на системные требования игрушек, ужаснуться можно. Сколько всякого добра им приходится кэшировать в ОЗУ. И тут дополнительный "оверхед", который вносит дотнет, может сыграть не самую лучшую роль.
.NET вносит очень малый оверхед по памяти в больших приложениях.
Кстати создатели движков на C++ часто используют кастомные аллокаторы, которые работают быстрее, но при этом вносят дополнительный оверхед по памяти.
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
