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

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

Поделиться
Страницы: 129 30 31 32 33 34 Следующая »
SilentPrayerCGПостоялецwww18 ноя. 201717:08#480
Mikle
> это не столько игровой движок, сколько для инструментов
ну вот по идее для инструментов как раз бы 64 пригодился, если огромные массивы обрабатывать или вроде того
для игр конечно нет наверное, я ни одной современной х64 игры не припомню

а существует что-нибудь такое-же простое как sr2d, но поддерживающее 64? ну кроме graphics стандартного разумеется.

MikleМодераторwww18 ноя. 201718:43#481
SilentPrayerCG
> а существует что-нибудь такое-же простое как sr2d, но поддерживающее 64?
Я, честно говоря, и 32 больше не знаю.
SilentPrayerCG
> огромные массивы обрабатывать
Можно реальный пример?
SilentPrayerCGПостоялецwww18 ноя. 201720:08#482
Mikle
> Можно реальный пример?
Рельный пример, где нужен будет именно sr2d?

Ну я вроде писал давно, я к примеру усреднял n картинок, загружается к примеру 1000 картинок и усредняется попиксельно.

Не помню еще что-то делал где был большой лист битмапов, х32 не вывозил и выдавал out of memory.

Сейчас многий софт технический уже даже не делает 32 версии. 3дмакс к примеру.

Я конечно и близко не такой прям царь программирования что-бы писать подобный софт, но каждый раз когда есть это ограничение, я чувствую словно я в рамках.
Хотя я понимаю что для ряда задач это не не важно, хотя все равно можно в итоге упереться в эти рамки я думаю. К примеру хз как себя будет вести в х32 обработка одного гигантского изображения.
Или типа если я пишу что-то, я должен тупо ограничивать максимальное разрешение, и маскимальное количество на случай перегрузки?


проблема наверное в том что я лажовый кодер, я юзаю вб, и мои знания очень ограничены, тем не менее твоя библиотека оказалось максимально простой даже для меня
другой бы программист просто бы не нуждался в ней, а сделал все сам бы и было бы быстро

Правка: 18 ноя. 2017 20:11

SilentPrayerCGПостоялецwww21 ноя. 20179:40#483
Даже если отбросить реалтайм вывод, setpixel у тебя работает быстрее чем в дефолтном bitmap.

Вообще ты же не считаешь, что х64 вообще не нужен?) в принципе. х64 приложения.

MikleМодераторwww21 ноя. 201710:07#484
SilentPrayerCG
> Даже если отбросить реалтайм вывод, setpixel у тебя работает быстрее чем в дефолтном bitmap.
Естественно, я ведь заношу пиксель в обычный массив, к которому нет доступа у внешних программ, а bitmap - это объект, который необходимо Lock-ать для любого изменения.
SilentPrayerCG
> Вообще ты же не считаешь, что х64 вообще не нужен?
Нет, конечно.
Я мог бы сейчас написать, что да, как-нибудь сделаю SR2D х64, но слишком много у меня желаний, что ещё нужно сделать.
Так что я идею не отбрасываю, но и не обещаю.
SilentPrayerCGПостоялецwww21 ноя. 201710:35#485
Mikle
> Естественно, я ведь заношу пиксель в обычный массив, к которому нет доступа у
> внешних программ, а bitmap - это объект, который необходимо Lock-ать для любого
> изменения.

Можешь поподробнее объяснить про это? Это что-то связанное с lockbits? я так и не разобрался

> Нет, конечно.
> Я мог бы сейчас написать, что да, как-нибудь сделаю SR2D х64, но слишком много у меня желаний, что ещё нужно сделать.
> Так что я идею не отбрасываю, но и не обещаю.

С моими скромными умениями, я бы просто везде бы его использовал как замену графиксу.


К примеру вот последнее, я писал программку, которая просто в картинке пиксели переписывала, убирала к примеру все пиксели у которых альфа меньше 255.
То что в фотошопе я точно не знаю как сделать, по крайней мере быстро.
Я решил для вьюпорта сделать бэкграунд в виде клеточек, что-бы прозрачность было видно.
Если запихивать его в бакграундимидж и включать тайлинг, при ресайзе формы и контролов это все тормазит дичайше.
Если рисовать через событие паинт вручную, то немного лучше, но когда растягиваешь на весь экран тоже начинает подтормаживать.

Я так и не понял как стандартными средствами сделать это.
Хотя.. метод утёнка) пока писал.. наверное нужно было просто в картинку его вписать именно выриант для вывода, а не рисовать каждый раз позади XD глупый я.
Ыыы.. почему я сразу про это не подумал.

Кстати ресайзинг Picturebox-a с картинкой в режием zoom тоже оставляет желать лучшего в плане производительности.

122Постоялецwww21 ноя. 201710:57#486
SilentPrayerCG
> Кстати ресайзинг Picturebox-a с картинкой в режием zoom тоже оставляет желать
> лучшего в плане производительности.
Майкл, вот тебе идея на миллион: рядом с каждой функцией (а можно и прямо в её имени) указывай некую условную её скорость. Потому что юзеры вообще не в теме и не понимают даже очевидного что масштабирование медленное например. Надо давать эту инфу юзерам прямо в глаза.

Скажем, разбить быстродействие на несколько категорий типа 1-10. И тогда юзер хоть задумается, вызвать ему одну функцию с индексом 10 или пять с индексом 1. Глядишь, и додумается растяжение картинки вынести из кадра и делать его заранее.

SilentPrayerCGПостоялецwww21 ноя. 201711:57#487
122
> Глядишь, и додумается растяжение картинки вынести из кадра и делать его
> заранее.
Тем не менее это все равно немного то. Идея была что картинка масштабируется сама по себе, а фон статичный, так более наглядна прозрачность.
Как вариант конечно зашить её в кадр, но так будет менее галядно, но конечно быстрее.

К тому-же основной фпс дроп был не при масштабировании а при режиме tile в background image
Я думаю что если заменить масштабирование на самопальное через паинт оно будет быстрее работать чем то которое впилино в picturebox
по крайней мере тайлинг так быстрее работает.

Не правильно немного прочитал в начале.

Дак я еще и не брался за масштабирование, проблема была в бэке, он слишком медленно рисовался.

Масштабирование я использовался тупо контрлоловское, оно медленное, я не знаю как оно реализовано там и почему, так-же не знаю почему бэкграунд тайлинг медленный у контролов.
На sr2d и не пробовал, наверняка на нем было бы быстрее. И масштабирование если сделать и бэк.

Правка: 21 ноя. 2017 12:33

MikleМодераторwww21 ноя. 201714:29#488
SilentPrayerCG
> Можешь поподробнее объяснить про это? Это что-то связанное с lockbits?
Да. Битмап (или, к примеру, DirectDrawSurface) - это тоже массив данных, но с ним система может производить какие-то отложенные действия, при записи туда данных может возникнуть конфликт. Поэтому для доступа к данным сначала нужно выполнить Lock, это сигнал системе, что трогать данные нельзя, система опросит все процессы, работающие с данными, дождётся окончания, если какой-то процесс уже запущен, и только тогда процедура Lock завершится, и ты можешь писать-читать данные. По окончании работы выполняешь Unlock - знак системе, что с данными опять можно работать. Таким образом процедура Lock довольно тяжёлая.
Когда ты выполняешь GetPixel или SetPixel, Lock и Unlock выполняются неявно.
122
> Майкл, вот тебе идея на миллион: рядом с каждой функцией (а можно и прямо в её
> имени) указывай некую условную её скорость.
Это просто должно быть в ReadMe, которого у меня нет :)
Там не сильно много запоминать, там скорости не сильно расходятся, естественно, AlphaBlending тормозит сильнее, чем обычный Paint, это должно быть и так понятно. Функции с маской тормозят больше - там два источника, а не один. Ну и несколько особняком стоят ресайз и вращение. С АА, естественно, вращение будет медленнее, ресайза без АА у меня вообще нет.
122Постоялецwww21 ноя. 201714:43#489
Mikle
> ресайза без АА у меня вообще нет
И самый популярный формат графики, пиксельарт, тебе закрыт. Ну такое себе решение.

> Это просто должно быть в ReadMe, которого у меня нет :)
И который юзеры не читают даже когда есть. :)

MikleМодераторwww21 ноя. 201715:04#490
122
> самый популярный формат графики, пиксельарт, тебе закрыт
В пиксельарте ресайз вообще не особо полезен, разве только увеличение в целое число раз, а это очень простая ф-ция.
the trickПостоялецwww21 ноя. 201715:09#491
GetPixel и SetPixel это довольно тяжелые операции поскольку это целый набор операций переключение в режим ядра и обратно, блокировка контекста, преобразования координат, отсечение, преобразование цвета (при необходимости), построение временного растра, блиттинг.
SilentPrayerCGПостоялецwww21 ноя. 201715:23#492
Mikle
> Да. Битмап (или, к примеру, DirectDrawSurface) - это тоже массив данных, но с
> ним система может производить какие-то отложенные действия, при записи туда
> данных может возникнуть конфликт. Поэтому для доступа к данным сначала нужно
> выполнить Lock, это сигнал системе, что трогать данные нельзя, система опросит
> все процессы, работающие с данными, дождётся окончания, если какой-то процесс
> уже запущен, и только тогда процедура Lock завершится, и ты можешь
> писать-читать данные. По окончании работы выполняешь Unlock - знак системе, что
> с данными опять можно работать. Таким образом процедура Lock довольно тяжёлая.
> Когда ты выполняешь GetPixel или SetPixel, Lock и Unlock выполняются неявно.

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

MikleМодераторwww21 ноя. 201722:13#493
SilentPrayerCG
> т.е это в принципе то на что он способен, в плане производительности и за эти
> приделы выйти нельзя?
Он, это о чём речь? О SetPixel? Да, при такой реализации. Можно написать свой SetPixel, выполняя СЕРИЮ которых, будешь иметь более высокое быстродействие. Перед серией выполняешь Lock, получаешь указатель на данные, свой SetPixel работает через этот указатель.
122Постоялецwww21 ноя. 201722:29#494
Mikle
> В пиксельарте ресайз вообще не особо полезен
И так и не совсем так, по разному бывает. Иной раз и вращение в пиксельарте делают, а уж ресайз и подавно, хотя иногда это считается "неклассическим" подходом.
Страницы: 129 30 31 32 33 34 Следующая »

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

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