подскажите какие-нибудь интересные графические 2д эффекты, фокусы с расстановкой пикселей или цветами, учитываю что не должна использоваться какая-либо видео акселерация видео картой(я имею ввиде без опенгл или дирестикс). Надеюсь вы меня поняли и что-нибудь подскажите :D
Что-нибудь такое?
Прикрепленные файлы
FireLens.ZIP ( 14.14 килобайт )
Кол-во скачиваний: 231
Да, спасибо. Линзу поизучаю, но хотелось бы ещё что-то интересное, моежт какие-то фокусы с изменением цвета и т.д.
не знаю подойдет или нет, но есть такая темка: http://forum.pascal.net.ru/index.php?showtopic=3867
2klem4, Переработаю на свой лад и подойдёт, спасибо и позор мне что я так плохо пользуюсь поиском :D
2andriano, Спасибо! :D
Господа знатоки, вот думаю как реализовать эффект для взрыва, собственно, что требуется:
Нужно сделать широкий круг увеличывающийся от точки взрыва, но круг должен искажать окружение, как взрывная волна или что вроде этого(я думаю для этого нужны только гетпиксели и путпиксели), в идеали хотелось бы не круг, а эллипс т.к. у меня игра в перспективе.
Чтобы понятней я пытался найти нормальный скриншот из игры где подобное реализовано(только так круг, а не эллипс), но нашёл только один не очень удачный скриншот т.к. там это не очень хорошо видно.
Как вы видите от точки взрыва разрастается круг искажающий окружение. Правда он не очень больше, но надеюсь вы его разглядели :D
Есть какие-нибудь идеи как это реализовать? Где гедпиксели делать и т.д.
Если взрыв наподобие того, что справа - полупрозрачный анимированный спрайт.
Тот эффект, что ты описал (если я правильно понял), делается подобно линзе. Т.е. пиксели смещаются от центра "взрыва" вдоль радиуса.
Чтобы избежать "дырок" в формируемом изображении, для каждого пикселя результирующего изображения вычисляешь пиксель старого и из него берешь цвет, который записываешь в новое изображение.
Честно говоря, по оному статичному скриншоту не могу сказать, что это за эффект. Если исажения сводятся к тому, что точки часть изображения в кольце как бы растягивается и сжимается, то (т.к. точки смещаются относительно своего исходного положеня), то - да, эффект аналогичный линзе.
И еще по поводу прежнего сообщения: если собираешься работать с динамичной графикой, например, с игрой, забудь про гетпиксель и путпиксель - это слишком медленно.
Работаешь с экраном (вероятно экранным буфером) как с массивом пикселей без вызова процедур для отдельных точек. Притом, желательно в том порядке, в каком они расположены в буфере, т.е. по строкам растра.
Значит ли это, что мне все процедуры надо переписывать для записи их в массив? Я честно говоря ещё начинающий(хотя нет, просто топчусь на месте) мне бы разжевать слегка :D
Не понял вопроса. Какие процедуры ты записываешь в массив? И зачем?
Любая процедура, участвующая в формировании изображения должна работать с объектами, существенно превосходящими одну точку. Скажем, со строкой растра, с прямоугольной областью экрана или с другим примитивом.
Внутри процедуры идет работа непосредственно с фреймбуфером. Сам фреймбуфер определяется адресом начала, глубиной цвета и длиной сканлинии в байтах. Именно используя эти параметры, процедура и осуществляет работу с изображением.
Процедуры типа putpixel и getpixel пригодны только для учебных примеров или статичной графики.
Собственно, сравни скорость формирования изображения при помощи этх процедур и непосредственной записью в фреймбуфер, и вопросы сами отпадут.
А пример подобного где-нибудь посмотреть можно? Может даже на этом форуме, я просто фразу для поиска немогу удачную подобрать
Но я так понимаю придёться пользоваться ассемблером? Или я опять ничего не понял? Разве можно стандартными средствами узнать значения в фреймбуфере?
P.S.
Извини за подобные вопросы(наверняка глупые), просто мне реально хочеться этому научиться и я готов приложить усилия, но пока не понимаю куда копать.
Можно, конечно, получить данные непосредственно экрана. Но это долго. Долго это было под DOS, т.к. видеопамять намного тормознее по операции чтения, чем по операции записи. Еще дольше это под Windows.
В то же время хорошо себя зарекомендовал следующий алгоритм:
1. готовим в оперативной памяти буфер в формате BMP-файла, причем, с удобной нам глубиной цвета.
2. в обработчике сообщения WM_PAINT процедурой StretchDIBits переливаем содержимое буфера на экран.
Примечания:
к п.1: обычно я использую 256-цветный режим, т.к. для операций в труколоре обычно больше подходит OpenGL. Но это мое личное мнение. Опять же, сущесвуют исключения, например, то, что я привел вл втором посте темы.
к п.2: мне кажется, что если размеры буферов совпадают (т.е. не требуется масштабирования), то операцию преобразования цвета (например от палитры 256 цветов в труколор) берет на себя железо видюшки прозрачно для программы. По крайней мере, судя по скорости этого преобразования.
Что же касается примера, то чем не подходит, опять же, архив из второго поста? Там я как раз реализовал описанную технику.
PS. Да, язык Ассемблера здесь в подавляющем большинстве случаев совсем необязателен. В приведенном римере, например, на нем написано всего несколько строк, и то лишь для того, чтобы использовать MMX для ускорения одного конкретного алгоритма.
Откомпилировано оно в TMT-Паскале, для Delphi, вероятно, надо адаптировать. 16-разрядным компилятором, не должно компилироваться в принципе. Поэтому сразу положил exe-шник, чтобы можно было посмотреть.
Собственно, привел-то я пример того, как можно сделать (общий принцип) и как это будет выглядеть. На то, что эта прогамма может быть откомпилирована без переделки я и не рассчитывал.