Конференция VBStreets

**arechemist** » 09.08.2004 (Пн) 19:41

Как можно быстро повернуть картинку на заданный угол?
Метот по пикселам через гет сет пиксель не предлогать!!!

**Oxygen** » 10.08.2004 (Вт) 0:10

Тебе сюды. http://bbs.vbstreets.ru/viewtopic.php?p=42467

**tyomitch** » 10.08.2004 (Вт) 7:45

Вот, когда-то специально писал с прицелом на скорость. Быстрее, чем Get\SetPixel, раза в три.
http://mix.web.ur.ru/v7.rar

**Ennor** » 10.08.2004 (Вт) 10:26

Или же сюды - http://bbs.vbstreets.ru/viewtopic.php?p=37984#37984

**arechemist** » 10.08.2004 (Вт) 14:10

Гыыы. Все в любом случае елси поворачивать разом картинок 10 притормаживают... Да... реальную стратежку похоже написать на VB не удастся...
Неужели придется либо штамповать много-много картинок (ну одна на 10 градусов, др на 20 и тд) и по мере необходимости их вставлять...
Либо делать так.
Ну вот допустим стратежка. у каждого игрока по 10 юнитов (20 картинок) один пошел другово атоковать с тыла, ну у того и все юниты разом и решили развернуться и тут вылезает форточка
с прогресбаром "подождите... картинки юнитов поворачиваются"
Не ужеле все так плохо... Что делать? Изучать другой болеебыстрый язык...
Каким же образом создатели казаков смогли сделать так, что на карте могут находиться около 5-ти тыс юнитов и все нормально крутяться, вращаются да еще и успевают при етом думать куда бы им сходить?

**GSerg** » 10.08.2004 (Вт) 14:34

Что, что...
DX юзать, что же ещё...

**arechemist** » 10.08.2004 (Вт) 14:48

По DX сколько инфы не смотрел ничего понять не смог... все у меня vb жалуется на объявления cамого DX'а. Что делать?

**GSerg** » 10.08.2004 (Вт) 17:23

Project

References :arrow:

DirectX 8.0 for Visual Basic Type Library

**arechemist** » 10.08.2004 (Вт) 17:40

И что эта штука быстро работает? поверю на слово и попробую....

**GSerg** » 10.08.2004 (Вт) 17:57

Эту штуку пока ещё никто не переплюнул по скорости, доплюнуть бы хоть рядом...

**Doctor Nestor** » 10.08.2004 (Вт) 22:42

GSerg, а как он, ну DX работает, что такой быстрый. Если бы там одна прорисовка была быстрой, так нет же! В принципе, прорисовать/ считать можно быстро и через GetDIBBits, SetDIBBits (toDevice).
Делал как-то свой "заменитель" DX (гораздо круче

)
Там даже аналог z буфера был ... кривой. Так вот один только просчет
значений яркости в точках (по конфигурации объектов и источников освещения) занимал для 800 Х 600 порядка 0,5 - 1,5 сек. Это на один кадр и это без прорисовки (ну она то не особо тормозила).
Так как же в DX возможны такие скоростя? А?

**Approximator** » 11.08.2004 (Ср) 4:20

Doctor Nestor писал(а):GSerg, а как он, ну DX работает, что такой быстрый.

По сути, если не говорить об использовании DirectX'ом аппаратных возможностей, в норме его скорости сопоставимы с грамотной работой через GDI...

и связано это с тем, что GDI так же может юзать DirectX

Doctor Nestor писал(а):В принципе, прорисовать/ считать можно быстро и через GetDIBBits, SetDIBBits (toDevice).

Разделяю.

Делал как-то свой "заменитель" DX (гораздо круче )
Там даже аналог z буфера был ... кривой. Так вот один только просчет значений яркости в точках (по конфигурации объектов и источников освещения) занимал для 800 Х 600 порядка 0,5 - 1,5 сек. Это на один кадр и это без прорисовки (ну она то не особо тормозила).

Imo, медленно считала. Что за машина (проц)? Алгоритм (не обязательно весь, всего лишь арифметика и организация цикла, мне кажется,

здесь порылась собака)?

**alibek** » 11.08.2004 (Ср) 9:16

Кстати, есть предложение выложить на сайте TLB для DirectX

А то недавно у меня машина переустанавливалась, а откуда я брал TLB уже не помню.

**Doctor Nestor** » 11.08.2004 (Ср) 12:43

Approximator, считал яркость в каждой точке по закону Ламберта:
пропорцинальна косинусу углов между векторами нормали и направлением на "лампочку", обратно пропорциональна расстоянию до "лампы". Оптимизировал так, что при разбиении объекта на плоские поверхности (типа треангуляции), каждый раз косинус не пересчитывался, пока гуляю в пределах одной плоскости - это ускорило в 3 раза просчёт. Но вот расстояние каждый раз считаю в цикле (оно, вроде, не должно особо тормозить). Не додумал, как тут оптимизировать. Ещё возможно в z буфере тормоза. Довольно криво определялось, что должно прорисовываться, а именно, если на одном луче от камеры находятся несколько плоскостей, то я до каждой из них расстояние просчитывал и так определял, что рисовать, а, возможно, надо одним махом определять, что рисовать, а что нет. Хрен его знает. А вообще говоря, хоть и тормозило, но достаточно реально цвета передавались - ощущение трёхмерности было.

Вот расписал так, что самому захотелось вернуться к этой работе. Давно её забросил, как раз из-за тормозов.

**Doctor Nestor** » 11.08.2004 (Ср) 13:23

Насчет системы-тогда был 400 Cel/ 196 RAM / 16 Mb Riva TnT Vant(UZ)a
проверял на 2400 Cel / 256 RAM - тормозня всё равно. Хотя, думаю, ты прав - где-то в цикле накосячит - ну я тогда маленький был

- буду копаться смотреть.

**Approximator** » 12.08.2004 (Чт) 2:41

Сцена: 3D-панорама статической или произвольная динамическая?

Doctor Nestor писал(а):Approximator, считал яркость в каждой точке по закону Ламберта:
пропорцинальна косинусу углов между векторами нормали и направлением на "лампочку", обратно пропорциональна расстоянию до "лампы". Оптимизировал так, что при разбиении объекта на плоские поверхности (типа треангуляции), каждый раз косинус не пересчитывался, пока гуляю в пределах одной плоскости - это ускорило в 3 раза просчёт. Но вот расстояние каждый раз считаю в цикле (оно, вроде, не должно особо тормозить). Не додумал, как тут оптимизировать.

Всё зависит от ответа на первый вопрос. Но, в принципе, всегда все рассуждения можно свести к статической сцене, потому буду говорить о ней. На самом деле, тебе известен закон изменения яркости в плоскости (изменение угла между падающим "лучём света" и нормалью). Стало быть можно заранее сделать готовый примитив (соотвествующий битовый образ) и в процессе копировать из него какую-либо часть целиком

. То бишь, вообще нет необходимости работать с отдельным пикселем. С расстоянием то же самое, только сначала примитив копируешь в промежуточный буфер, там уменьшаешь яркость обратно пропорционально расстоянию опять для всей области целиком, и далее, как выше было сказано...
Вся штука в том, что можно выразить расстояние от "источника света" в цифирях RGB в примитиве и простыми логическими операциями работать целиком со всей "поверхностью". То бишь у тебя и останется всего-то обсчёт примитивов, при статичных сценах это вообще делается один раз. При динамических это можно делать одновременно с изменением положения объекта в виртуальном пространстве сцены...

Пока, так и не понял, зачем нужна попиксельная работа. В крайнем случае, при очень быстро изменяющихся масштабных динамических сценах можно заранее подготовить наиболее вероятные примитивы "рельефа" и продумать законы их изменения... всё равно можно работать со всей областью целиком, минуя попиксельную тягомотину...

**Doctor Nestor** » 12.08.2004 (Чт) 10:42

Во первых: сцена динамическая.
Во вторых я не совсем понял про создание шаблонов примитивов. Как тут избавиться от попиксельной работы? Даже если известен закон изменения яркости, то придётся создавать этот битовый образ попиксельно. Или я чего-то не догоняю. Да, я понял, что их можно насоздавать при инициализации проги, а потом использовать как строительный хлам, но ведь не предусмотришь все варианты конфигураций света и объектов, особенно когда речь о динамических сценах. А вообще, попиксельная работа задумывалась мной для обхода треангуляции - то есть для работы с кривыми поверхностями сразу, без их разбиения, действительно, и там можно косинусы и расстояние считать. Объясни подробнее, если не сложно. Я, наверное, торможу.

**Approximator** » 13.08.2004 (Пт) 4:30

Doctor Nestor писал(а):Во первых: сцена динамическая.
Во вторых я не совсем понял про создание шаблонов примитивов. Как тут избавиться от попиксельной работы? Даже если известен закон изменения яркости, то придётся создавать этот битовый образ попиксельно. Или я чего-то не догоняю. Да, я понял, что их можно насоздавать при инициализации проги, а потом использовать как строительный хлам,...

На самом деле, если заранее известен закон изменения чего-либо, то далее достаточно лишь обсчитывать координаты и размеры области откуда копировать (примитив может быть больше по размерам, чем сцена, которую рендеришь). Это всегда будет быстрее, могу доказать математически.

... но ведь не предусмотришь все варианты конфигураций света и объектов, особенно когда речь о динамических сценах.

Заблуждение. Дело в том, что количество вариантов изменений яркости, например, в строке изображения счётно. Даже если строка будет формироваться в два-четыере раза, то максимальное количество проходов у тебя будет 4*<количество строк>. Что также всегда меньше количества пикселей. Более того, часть изменений можно делать в два-четыре этапа (умножь предыдущую цифирь в двое или даже в четверо и всё равно число будет меньше нежели количество пикселей) с помощью логических операций между битовыми образами.

А вообще, попиксельная работа задумывалась мной для обхода треангуляции - то есть для работы с кривыми поверхностями сразу, без их разбиения, действительно, и там можно косинусы и расстояние считать. Объясни подробнее, если не сложно. Я, наверное, торможу.

Слишком подробно, увы, долго. Могу указать лишь направление. Затем кое-что уточнить.
Итак, теория.
Сначала "работа в плоскости". Зная закон изменения интенсивности в плоскости, делаешь примитив - буфер необходимых размеров, включающий в себя все встречающиеся измения (по сути, максимальный "раствор" угла зрения и угла "освещения"). Далее, просто обчитываешь координаты верхнего левого угла и размер области из примитива, требуемой для копирования. Согласись, уже не работа с одним пикселем.
"Работа с рельефом". На самом деле, в предыдущем случае тебе необходимо было взять самую близкую плоскость. Далее, при наличии рельефа её изменять с помощью другого примитива - заранее заготовленных профилей. Изменения ведутся построчно (наиболее удобный, на мой взгляд, способ). Максимум, что необходимо кроме логических операций между данными из различных примитивов - масштабирование. А это всё равно быстрее, чем работа попискельно.
Во вкратце и всё. Если не очень понятно - забудь. Если в общем понятно, но не понятно в деталях - задай вопрос.

**Doctor Nestor** » 13.08.2004 (Пт) 11:46

Основные вопросы:
Как создавать примитив, если не попиксельно?
Как я это понял. Исправь, если неправильно.
Есть некий "контейнер" примитивов, созданных когда-то один раз, из него производится
"построчное" копирование в сцену. Причем, если в строке есть N переходов с плоскости
на другую плоскость , то произходит N копирований из буфера примитивов, понятно, что
N меньше количества пикселей. Но:
- по поводу

количество вариантов изменений яркости, например, в строке изображения счётно

Конечно счетно в силу дискретности и конечности цвета пикселя, но оно же огромно...
Даже, если мы квантуем углы обзора и положения источника света, то количество
вариантов осветки строки умопомрачительно. Это всё я к тому, что я не понимаю, как
можно насоздавать примитивов на любой случай. А если источников света несколько?
Итак, основной вопрос:
Примитивы созданы заранее или из известной конфигурации сцены?
Возможно, здесь кроется моё непонимание.
Я так понимаю ответ может быть (ДА/НЕТ).
Если ДА(заранее), то как все варианты предусмотреть (много источников и т.п)
Если НЕТ (по известной сцене) - то это разве не попиксельная работа снова будет
при создании самого примитива. А в случае динамических сцен надо будет всё опять пересчитывать
и выигрыша нету.
Не знаю, не понял я "в ощем" или "в деталях", но точно не понял.
Если не посчитаешь вопросы слишком глупыми, ответь.

**Doctor Nestor** » 13.08.2004 (Пт) 12:08

Переосмыслил твои слова. При известном положении камеры и источников освещения создать
примитивы для разных вариантов положений плоскостей в сцене и их как шаблоны использовать?
Ты об этом говорил или я опять не понял? В таком варианте, действительно, конфигураций не так уж много,
в некотором приближении.

**Approximator** » 14.08.2004 (Сб) 4:28

Doctor Nestor писал(а):Переосмыслил твои слова. При известном положении камеры и источников освещения создать
примитивы для разных вариантов положений плоскостей в сцене и их как шаблоны использовать?
Ты об этом говорил или я опять не понял? В таком варианте, действительно, конфигураций не так уж много,
в некотором приближении.

В том числе и об этом.

количество вариантов изменений яркости, например, в строке изображения счётно
Конечно счетно в силу дискретности и конечности цвета пикселя, но оно же огромно...

Да? Мне кажется, что ты не пробовал подсчитывать. Колебвания "рельефа" равны бесконечности? Поверхности "отражающих объектов" совсем уж произвольны?

**Doctor Nestor** » 15.08.2004 (Вс) 0:05

Спасибо за советы. Думаю, в скором времени проверю на деле. Если чего получится, тебе первому сообщу

**Approximator** » 15.08.2004 (Вс) 2:59

Doctor Nestor писал(а):Спасибо за советы. Думаю, в скором времени проверю на деле. Если чего получится, тебе первому сообщу

Помогу, чем смогу

Конференция VBStreets

Как можно быстро повернуть картинку на заданный угол?

Как можно быстро повернуть картинку на заданный угол?

Кто сейчас на конференции