Общество изобретателей велосипедов
GameDev.ru / Сообщества / Вело-изобретатели / Форум / 2D движок SR2D, Софтверный движок для работы с 2D графикой на VB6, vb.net, C# (32 стр)

2D движок SR2D, Софтверный движок для работы с 2D графикой на VB6, vb.net, C# (32 стр)

Поделиться

Страницы: 1 2 3 4 ... 17 ... 31 32 33 34 Следующая

122Постоялецwww9 ноя. 201723:32#465
Mikle
> Там почти сплошной ассемблер, просто так не перекомпилируешь
В который раз убеждаюсь что ассемблер не нужен.
И наверное уже этим ассемблером ты закрыл себе большинство компиляторов, оставив только один-два. А лет через N смена компилятора потребуется. Ведь наверное она потребуется, иначе будем иметь ситуацию по типу старых исходников типа Q1 которые надо собирать древним мамонтовым чучелом. Не говоря и о том, что на новых CPU компилятор может давать более эффективный код чем тот который был вручную написан для старых процов, ну типа в каком-нибудь Эльбрусе 2050 эти ваши AVX будут только для совместимости оставлены. Не говоря и о том, что юзая асм ты CPU не сможешь поменять с x86-го без переписывания кода, а компилятор ведь может.

А то быстродействие что асм тебе дал, оно крохотное. 20-30% всего. Ну конкурс тысячи кубов вот оно там всё. Скорость достигается верными алгоритмами а не запихиванием асма в каждый ботлнек.

Правка: 9 ноя. 2017 23:33

MikleМодераторwww9 ноя. 201723:43#466
122
Понятно, что асм платформо-зависим, но я уже больше 10 лет этим пользуюсь, и пока потеря совместимости не предвидится.
Скорость меня волнует не сильно, это не столько игровой движок, сколько для инструментов. Асм мне дал кайф от разработки, этот аргумент тебе должен быть понятен.
1000 кубов тут вообще не в тему - то 3D, и там победили алгоритмы не рендера, а предварительного отсечения, это просто разные задачи. Вспомни потом рендер кролика - мой был и гораздо качественнее, и быстрее, потому что там предварительное отсечение было не очень актуально.
SilentPrayerCGПостоялецwww10 ноя. 20177:40#467
Mikle
> Вряд ли. Там почти сплошной ассемблер, просто так не перекомпилируешь, а
> переписывать с нуля не очень охота.
Жаль .__. было бы идиально (для меня по крайней мере)
ХаусПостоялецwww10 ноя. 20178:13#468
Mikle
> Асм мне дал кайф от разработки, этот аргумент тебе должен быть понятен.

Героин мог бы заменить асм и наличие последнего не нужна была.

122Постоялецwww11 ноя. 20172:38#469
Mikle
Раз был кайф от разработки тогда да, претензии к асму не нужны.

А вот кролик тот, уж он меня бесит знатно. Злая задача для движка, все в этом кролике оказалось против. Одно то что там треугольники вместо квадов и картинку испохабило и быстродействие уронило. Однако замечу, что то сравнение было тогда не идеальным: ведь с моей стороны был растеризатор для разных задач, тот же который и на конкурсе кубов был. А ты для кролика дал растеризатор вовсе не тот, который был от тебя на конкурс кубов. И фактически получил два разных кода для разных задач. А попробуй запустить кролика на том коде, который кубы рисовал, вот будет дело.

MikleМодераторwww11 ноя. 20178:49#470
122
> для кролика дал растеризатор вовсе не тот, который был от тебя на конкурс
> кубов. И фактически получил два разных кода для разных задач.
Убрал сортировку по дальности, включил Z-буфер, сменил разрешение текстуры (я его захардкодил). Вот и все изменения.
122
> Одно то что там треугольники вместо квадов и картинку испохабило и быстродействие уронило
А мне наоборот повысило, я всегда на треугольники ориентировался.
122
> попробуй запустить кролика на том коде, который кубы рисовал
Не выйдет, там сортировка по кубам. Вот кубы запустить на рендерере кролика получится, будет ещё процентов на 15-20 медленнее.
122Постоялецwww11 ноя. 20179:48#471
Mikle
> А мне наоборот повысило, я всегда на треугольники ориентировался.
На плоскостях будешь терять, разве нет? Много поверхностей которые можно замоделить квадами, типа цилиндра, конуса, да и сама плоскость. И у тебя вместо одного квада будет два треугольника. Вот накладные расходы вырастут. Тот коварный кролик меня и подвел потому что большие расходы "на полигон" зато малые расходы "на заливку внутри полигона".

А у тебя видимо нет ни того ни другого: нет минуса в виде заметных расходов на полигон, но нет и вытекающего из этого плюса быстрой заливки в условиях перекрытия.

MikleМодераторwww11 ноя. 201710:47#472
122
> На плоскостях будешь терять, разве нет?
Да, на архитектуре, где преобладают прямоугольные формы, буду терять.
Вот я сгенерировал модель 1000 кубов, замени ей модель кролика в кроличьей демке:1000CubesModel
Там используется текстура кролика, берутся случайные координаты.
Ракурс несколько не тот, что в кубах, но лезть в демку менять уже не охота, при желании сравнить, ты можешь свою демку с кубами переделать под мой ракурс.

Правка: 11 ноя. 2017 10:49

122Постоялецwww11 ноя. 201711:05#473
Mikle
> Вот я сгенерировал модель 1000 кубов, замени ей модель кролика в кроличьей
> демке
Не могу, сама демка исчезла. Она там была? http://www.gamedev.ru/flame/forum/?id=218277&page=17#m248
И модель уж лучше в .obj дай чтоб я и в свой её же загрузил для сравнения.
122Постоялецwww11 ноя. 201711:20#474
Mikle
> Да, на архитектуре, где преобладают прямоугольные формы, буду терять.
А они не везде преобладают?
Стволы дерева\трубы - квадами. Стены всех форм с равномерными изгибами - квадами. В сфере только полюса трианглы, остальное квады.

Добавил позже.
Не, тут смысла нет после боя кулаками махать, забей. Я в том кролике проиграл и тут ничего не сделать.
Вот всё было против:
- Низкое разрешение против меня. Мой двиг долго запрягает но быстро закрашивает и на каком-нибудь 4096x2160 мог бы вырваться заметно.
- Отсутствие перекрытия в сцене. Долгое запрягание касается и отсечения невидимых плоскостей а в кролике оно мотается вхолостую.
- Треугольники а не квады. Двиг заточен под квады отсюда некрасивая картинка на кролике. Не говоря о том что лишняя вершина гоняется.

Правка: 11 ноя. 2017 13:03

MikleМодераторwww11 ноя. 201713:57#475
122
> Не могу, сама демка исчезла.
Вот: Rabbit
122
> Она там была?
Там была демка с текстурной фильтрацией и светом.
122
> И модель уж лучше в .obj дай чтоб я и в свой её же загрузил для сравнения.
Это сложнее, у меня есть конвертер из .obj в свой формат (через .x), обратного нет.
Но там ничего сложного - каждый куб состоит из 12 треугольников.
122
> А они не везде преобладают?
> Стволы дерева\трубы - квадами. Стены всех форм с равномерными изгибами -
> квадами. В сфере только полюса трианглы, остальное квады.
А сам квад при растеризации ты не делишь на треугольники всё равно? Как ты заливаешь? А что будет, если в кваде вершины лежат не в одной плоскости?
Я вообще не понимаю, откуда берётся выигрыш при рендере квадами (речь, естественно, не о 2D).

Правка: 11 ноя. 2017 14:36

122Постоялецwww11 ноя. 201719:28#476
Mikle
> А сам квад при растеризации ты не делишь на треугольники всё равно?
Нет. Ну то есть их можно поделить на этапе создания модели. А в рендере нет конечно, только квады. Треугольники получаются тем что две вершины квада располагаются в одной позиции.

> Как ты заливаешь?
Один цикл по области экрана, сверху вниз слева направо. И полики и задник сразу. В многопотоке много маленьких горизонтальных отрезков экрана для потока.

> А что будет, если в кваде вершины лежат не в одной плоскости?
Квад может начать проваливать тест видимой поверхности, то есть если часть квада повернута к камере задом а часть передом. Исправляется отрисовкой модели без теста на видимость стороны, двухсторонние поверхности. На скорость влияет мало но двухсторонние модели начинают проваливать уже z-буфер который 8-битный и обильно дают z-файтинг. :)

> Я вообще не понимаю, откуда берётся выигрыш при рендере квадами
Нууу, это честно говоря удивительно от тебя слышать.
Любой двиг тратит на полигоны некоторое время. Возьми Дум, отрисовка одной стены в экран или 100 колонн, будет ли разница в фпс? Возьми Q1, стенка или 100 кубов? Двиг Дюка3д думаю также себя поведет. Геометрия тяжела ведь там расходы на то чтобы подготовить её к заливке, отбросить часть, посчитать всякие значения на границе полигона и так далее.

122Постоялецwww11 ноя. 201719:33#477
Mikle
> Вот: Rabbit
В целом та же история: мало нагрузки на заливку экрана. Кубы далеко и маленькие. Полигоны сравнимы с полигонами кролика по размеру.
А вот на игровой сцене будет различие. Ну условно две-три комнаты, разрешение фулашди, заливка во весь экран вначале ближайшим шкафом, потом стеной за шкафом, потом диваном соседней комнаты, потом дальней стеной соседней комнаты. Четырехкратное ашди, вот тут просядет. А мой не просядет ничуть.
MikleМодераторwww12 ноя. 20178:25#478
122
> А вот на игровой сцене будет различие.
Это понятно, у тебя двиг, а у меня только рендер, типа OpenGL или Direct3D, в них тоже никаких подобных оптимизаций нет.
122
> Любой двиг тратит на полигоны некоторое время.
Да, но вот тут загвоздочка. Тратится время на вершины, а их количество не меняется. Или ты не используешь индексирование вершин? Сколько вершин ты рассчитываешь при рендере одного куба? Я - 8, а потом строю 12 треугольников на уже рассчитанных вершинах. Будь вместо двух треугольников квадрат - это бы мало что изменило.
Ты полигоны не заливаешь, а строишь по ним спан-буфер, но сути дела это не меняет. Я хочу понять в какой момент ты получаешь выигрыш от квадов. В голову приходит только отбрасывание невидимых полигонов и расчёт света, он же у тебя не повертексный, а пополигонный, полигонов вдвое меньше - выигрыш. Но это же мелочь, да и в кубах света не было.
Может ты что-то ещё делаешь не так, как я себе представлял?
122Постоялецwww12 ноя. 201710:39#479
Mikle
> Я хочу понять в какой момент ты получаешь выигрыш от квадов.
Не хочу всех деталей раскрывать.
В целом затраты на полигон это:
а) Рассчет многих доп-параметров для полигона. а.1 - рассчет z-глубины, а.2 - тест на видимую сторону, а.3 - тест на попадание в 2д экранную область
б) Передача пакета данных туда-сюда, куда входят вершины в 2д, вершины в 3д и куча доп-информации.
-- тут начинается многопоток --
в) Цикл по полигонам в кеше и вызов рассчета освещения. Ну мало ли что вот прямо сейчас не используется, не буду же я для кролика вырезать дефайнами из кода куски.
г) Цикл по полигонам в кеше и масштабирование их z, перераспределение этой величины для лучшего отображения.
д) Сортировка полигонов по z, ближние вначале. Не обязательна для рендера но исправляет некоторые шероховатости.
е) Самое долгое: создание информации для заливки экрана одним проходом.

> Тратится время на вершины, а их количество не меняется.
На вершины в самом деле, тратится фиксированное время. Там просто повороты по трем осям и смещение, копейки.

> в какой момент ты получаешь выигрыш от квадов
Если кратко, то квадов в два раза меньше чем треугольников. Ну и в два раза соответственно быстрее все рассчеты с ними идут.
Я не могу понять, что тут может удивлять. Это вроде в любом софтрендере так было.

Правка: 12 ноя. 2017 11:04

Страницы: 1 2 3 4 ... 17 ... 31 32 33 34 Следующая

/ Форум / Общество изобретателей велосипедов / SR2D - софтовый 2D движок

2001—2017 © GameDev.ru — Разработка игр