Да, допущения, конечно, грубые, но обращаешь внимание на них только тогда, когда этими дырами кто-то воспользуется. Предлагаю отправить письмо разработчикам на эту тему.
Кстати по поводу sealed — они еще и помогают компилятору выдавать более оптимальный код за счет упрощения вызовов методов класса.
А как насчет того, чтобы итератору передавать только идентификатор результата БД? Т.е. в модели есть метод selectAll(), который возвращает итератор, который уже инкапсулирует доступ к БД. Хотя на самом деле все равно нужно писать кучу методов для разных случаев. Но вот эта штука будет полезна тогда, когда нужно выбрать все записи, но не все поля.
Кстати, встал вопрос. Легко ли переживает mysql множество запросов одновременно? Т.е. мне нужно несколько сущностей одновременно. На данный момент я последовательно выбираю каждую сущность в память, а затем передаю виду для представления. А если вот такими итераторами пользоваться?
есть texture lookup, т.е. текстура с определенно подобранным форматом. Я их точно все не помню, но здесь, к примеру, будет достаточно RG. В R будет храниться яркость бликов, а в G — экспонента. Индекс материала — это просто текстурные координаты. С помощью интерполирования можно добиться разных вариантов. Кажется в сталкере именно так и было сделано. Вот, кстати, статья: http.developer.nvidia.com/GPUGems2/gpugems2_chapter09.html
Эта карта называется картой высот. В ней белые области означают возвышенность. Т.е. по сути это карта задает высоты в пределах от 0 до 255. Сэмплируем пиксель, применяем масштаб и на выходе получаем высоту для точки ландшафта. Относительно сложным здесь является как раз сэмплирование. Тут надо масштабировать карту под размеры ландшафта (интерполяция). Это все относится больше к обработке изображений.
Все правильно, но на самом деле все тоже самое. Только здесь геометрия плоская, а принцип такой же. Рисуем все спрайты в две текстуры (на самом деле можно воспользоваться одной). Т.к. геометрия плоская, то нам не нужна глубина пикселей. В самом примере рисуется какая-то конкретная текстура, но она легко заменяется на то, что получается в первом проходе, когда рисуется сцена и формируется g-buffer.
Да тут не много вариантов, добавляется еще specular map обычно. Черно-белая текстура (обычно низкого разрешения, а как вариант — хранить в альфа-канале normal map), белые области которой говорят о том, что поверхность хорошо отражает свет, а черные — наоборот. Так можно определить где на текстуре металлические части, которые хорошо отражают свет, а где более матовые.
Я бы сделал так: делаем большой массив структур, поля которой описывают частицу, причем чтобы этот массив еще и разрастался по необходимости. В этой структуре также было бы поле Active, которое указывало бы, что частица активна. Это в принципе и основной регулятор: нужна частица — ставим Active в true, не нужна — в false. Еще будет массив свободных блоков. Каждый элемент этого массива — это индекс начала свободного блока, где частицы неактивны. Вначале туда помещается один индекс — нуль. При создании частицы берется первый такой свободной блок и в его начало помещается новая частица, а начало смещается на единицу. Если следующая частица также активна, то блок удаляется из списка блоков. При удалении частицы если слева от нее частица неактивна, то в список свободных блоков добавляем индекс текущей частицы. Если добавляем частицу, а список свободных блоков пуст, то значит нужно нарастить массив структур.
Пул — это такая структура данных, в которой удаленные объекты используются повторно.
Как-то ты, Леонид, смело предположил, что сортировка спрайтов не интересна. Во-первых, DepthStencilState никак не относится к сортировке напрямую; этот параметр указывает состояние буфера глубины, который повсеместно используется в трехмерных играх, но и в двумерных можно получить выгоду. Для чего он нужен? При отрисовке каждый пиксель после всех трансформаций имеет три координаты: координаты на экране и глубину. Эта самая глубина сравнивается с тем, что уже записано в буфер определенной операцией сравнения, которая задается состоянием (DepthStencilState). Если пиксель проходит тест, то он передается в пиксельный шейдер и записывается в буфер глубины. Для чего это нужно? Для регулирования порядка отображения спрайтов. Сейчас это делается напрямую: отрисовал один спрайт, потом второй, и вот второй находится над первым. С буфером глубины можно не заботится о порядке отрисовки спрайтов, но при этом если рисовать их в порядке от меньшей глубины к большей, то экономятся пиксели в пиксельном шейдере при перекрывающихся спрайтах, т.к. пиксели спрайта, который находится под пикселями другого спрайта не пройдут тест на буфер глубины.
Тут в дело вступает SpriteSortMode и layerDepth. Точно не знаю, как устроен spriteBatch (это нужно еще проверить), но я надеюсь, что layerDepth регулирует как раз ту самую глубину. Я писал свой собственный OutputBatch, который поддерживает вывод помимо спрайтов еще и примитивы, и там depth я сделал одним из главных параметров. Очень важная штука: SpriteSortMode.Texture — сортировка по текстурам. При смене текстуры необходимо менять состояние устройства, а это накладно, поэтому лучше спрайты с одинаковой текстурой группировать. В случае с системой частиц это не нужно. Также это не нужно, когда кол-во разных текстур не далеко ушло от количества спрайтов. В этом случае лучше сделать одну большую текстуру и воспользоваться sourceRectangle при использовании Draw. Это сильно повышает производительность.
Часто бывает так, что если у тебя есть знакомый специалист, то проще спросить у него, чем разобраться самому… Причем это не только в программировании, но и во всем! Очень сильно раздражает когда твой собеседник просто отключает мозги и надеется, что ты ему все сделаешь. Если включить игнор у них и у самих все прекрасно получается.
А вообще кажется, что в этом мало практического значения: чтобы видеть какой-то эффект, нужно постоянно передвигаться, а если сидеть на месте, то голову особо не повертишь. Можно окружить себя несколькими мониторами и тогда было бы круто играть в автосимуляторы)) Повернул голову направо, а там видно, кто сбоку!
Кстати по поводу sealed — они еще и помогают компилятору выдавать более оптимальный код за счет упрощения вызовов методов класса.
Кстати, встал вопрос. Легко ли переживает mysql множество запросов одновременно? Т.е. мне нужно несколько сущностей одновременно. На данный момент я последовательно выбираю каждую сущность в память, а затем передаю виду для представления. А если вот такими итераторами пользоваться?
А вот и примеры: create.msdn.com/en-US/education/catalog/?contenttype=0&devarea=0&platform=20&sort=1
Пул — это такая структура данных, в которой удаленные объекты используются повторно.
blogs.msdn.com/b/shawnhar/archive/2010/03/12/reach-vs-hidef.aspx
Тут в дело вступает SpriteSortMode и layerDepth. Точно не знаю, как устроен spriteBatch (это нужно еще проверить), но я надеюсь, что layerDepth регулирует как раз ту самую глубину. Я писал свой собственный OutputBatch, который поддерживает вывод помимо спрайтов еще и примитивы, и там depth я сделал одним из главных параметров. Очень важная штука: SpriteSortMode.Texture — сортировка по текстурам. При смене текстуры необходимо менять состояние устройства, а это накладно, поэтому лучше спрайты с одинаковой текстурой группировать. В случае с системой частиц это не нужно. Также это не нужно, когда кол-во разных текстур не далеко ушло от количества спрайтов. В этом случае лучше сделать одну большую текстуру и воспользоваться sourceRectangle при использовании Draw. Это сильно повышает производительность.
Исходники могу скинуть на мейл.
А вообще кажется, что в этом мало практического значения: чтобы видеть какой-то эффект, нужно постоянно передвигаться, а если сидеть на месте, то голову особо не повертишь. Можно окружить себя несколькими мониторами и тогда было бы круто играть в автосимуляторы)) Повернул голову направо, а там видно, кто сбоку!