Варианты оптимизации "разгрузки" системы от посторонних вычислений

@Retyrn0 · Регистрация: 24.06.2013

Author24 — интернет-сервис помощи студентам

Добра Вам! Пишу игровой движок. В виду специфичности рендера массив пикселов генерится в оперативной памяти. Для оптимизации необходимо быстро загонять этот массив на экран, запретить прорисовку остальных окон(полный FULLSCREEN) и, возможно, есть какие-то ещё варианты оптимизации "разгрузки" системы от посторонних вычислений? Спасибо.

@~~-=ЮрА=-~~ · 09.03.2014, 15:41

Рисуй в совместимом контексте, на целевой контекст пикселы переноси с помощью BitBlt либо StretchBlt

@Retyrn0 · 09.03.2014, 19:53 **[ТС]**

Я так и делал - скорость не плохая, но хотелось бы максимально возможную.
OpenGL может справиться с выводом из оперативной памяти на экран быстрее, чем BitBlt, по идее?
Стоит ли прикручивать целую библиотеку для использования единственной функции отрисовки или прироста не будет или не значительный?
Собственно, я могу и сам проверить скорость, но обитатели форума наверняка уже изобретали эти велосипеды, окучивали все возможные грабли. Был бы рад, чтобы Вы сэкономили моё время.

Добавлено через 2 минуты
И если эффект от GL будет, то glDrawPixels - лучший вариант или есть ещё более быстрая альтернатива? Прошу поделиться опытом.

@Somebody · 09.03.2014, 20:42

Не знаю насчёт скорости, но glDrawPixels в новых версиях OpenGL убрали. Более универсальный способ - это использовать изображение как текстуру.
Также не знаю насчёт скорости, но ещё вариант - это layered windows и UpdateLayeredWindow.

@~~-=ЮрА=-~~ · 09.03.2014, 20:56

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

Убежденный · 09.03.2014, 21:12

Сообщение от Retyrn0

Для оптимизации необходимо быстро загонять этот массив на экран, запретить прорисовку остальных окон(полный FULLSCREEN) и, возможно, есть какие-то ещё варианты оптимизации "разгрузки" системы от посторонних вычислений?

Единственный реальный вариант - использовать аппаратное ускорение и
ресурсы GPU. Плюс всякие SSE/MMX. А GDI и software rendering - это,
читай, прошлый век, сама Windows "старается" его не использовать,
уходя в сторону всяких Direct2D, например. Ибо ме-е-е-дленно...

@Retyrn0 · 09.03.2014, 21:55 **[ТС]**

Сообщение от -=ЮрА=-

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

Согласен. Ибо то ли криворукость помешала, то ли вспышки на Солнце, но оказалось, что SetDIBitsToDevice более чем в 10 раз быстрее OpenGL...хотя, возможно, дело в железе. Например формат моего DIBa соответсвует формату карты(?) Может действительно удариться в формат карты и генерировать изображение DDB, чтобы отказаться от лишних преобразований? И как именно работать с DDB, я не до конца понимаю, для вывода DDB используются те же функции?

Прошу прощения за "миллион вопросов", но мозг уже кипит от кучи прочтённого и это барахло тормозит понимание простых(по видимому) вещей.

Добавлено через 8 минут

Сообщение от Убежденный

Единственный реальный вариант - использовать аппаратное ускорение и
ресурсы GPU.

То же согласен. Но есть пара "но". Распараллеливание алгоритма достигается довольно просто, но внутри алгоритма есть условия(достаточно не мало). К тому же, думаю, что перенос на GPU - это уже скорее оптимизация, которая обязательно будет иметь место, но пока нужно хотя бы реализовать работающее приложение с более-менее приемлемой скоростью.

@Retyrn0 45 / 48 / 5 Регистрация: 24.06.2013 Сообщений: 677
		1
	Варианты оптимизации "разгрузки" системы от посторонних вычислений 09.03.2014, 15:36. Показов 705. Ответов 6 Метки нет (Все метки) Добра Вам! Пишу игровой движок. В виду специфичности рендера массив пикселов генерится в оперативной памяти. Для оптимизации необходимо быстро загонять этот массив на экран, запретить прорисовку остальных окон(полный FULLSCREEN) и, возможно, есть какие-то ещё варианты оптимизации "разгрузки" системы от посторонних вычислений? Спасибо. 0

@~~-=ЮрА=-~~ Заблокирован
	09.03.2014, 15:41	2
	Рисуй в совместимом контексте, на целевой контекст пикселы переноси с помощью BitBlt либо StretchBlt 0

@Retyrn0 45 / 48 / 5 Регистрация: 24.06.2013 Сообщений: 677
	09.03.2014, 19:53 [ТС]	3
	Я так и делал - скорость не плохая, но хотелось бы максимально возможную. OpenGL может справиться с выводом из оперативной памяти на экран быстрее, чем BitBlt, по идее? Стоит ли прикручивать целую библиотеку для использования единственной функции отрисовки или прироста не будет или не значительный? Собственно, я могу и сам проверить скорость, но обитатели форума наверняка уже изобретали эти велосипеды, окучивали все возможные грабли. Был бы рад, чтобы Вы сэкономили моё время. Добавлено через 2 минуты И если эффект от GL будет, то glDrawPixels - лучший вариант или есть ещё более быстрая альтернатива? Прошу поделиться опытом. 0

@Somebody 2835 / 1644 / 254 Регистрация: 03.12.2007 Сообщений: 4,222
	09.03.2014, 20:42	4
	Не знаю насчёт скорости, но glDrawPixels в новых версиях OpenGL убрали. Более универсальный способ - это использовать изображение как текстуру. Также не знаю насчёт скорости, но ещё вариант - это layered windows и UpdateLayeredWindow. 0

@~~-=ЮрА=-~~ Заблокирован
	09.03.2014, 20:56	5
	не будет никакой опен соурс работать на наивной оси мелкософта быстрей ,чем нативное апи того же мелкософта 0

Убежденный Ушел с форума 16473 / 7436 / 1187 Регистрация: 02.05.2013 Сообщений: 11,617 Записей в блоге: 1
	09.03.2014, 21:12	6
	Сообщение от Retyrn0 Для оптимизации необходимо быстро загонять этот массив на экран, запретить прорисовку остальных окон(полный FULLSCREEN) и, возможно, есть какие-то ещё варианты оптимизации "разгрузки" системы от посторонних вычислений? Единственный реальный вариант - использовать аппаратное ускорение и ресурсы GPU. Плюс всякие SSE/MMX. А GDI и software rendering - это, читай, прошлый век, сама Windows "старается" его не использовать, уходя в сторону всяких Direct2D, например. Ибо ме-е-е-дленно... 0

@Retyrn0 45 / 48 / 5 Регистрация: 24.06.2013 Сообщений: 677
	09.03.2014, 21:55 [ТС]	7
	Сообщение от -=ЮрА=- не будет никакой опен соурс работать на наивной оси мелкософта быстрей ,чем нативное апи того же мелкософта Согласен. Ибо то ли криворукость помешала, то ли вспышки на Солнце, но оказалось, что SetDIBitsToDevice более чем в 10 раз быстрее OpenGL...хотя, возможно, дело в железе. Например формат моего DIBa соответсвует формату карты(?) Может действительно удариться в формат карты и генерировать изображение DDB, чтобы отказаться от лишних преобразований? И как именно работать с DDB, я не до конца понимаю, для вывода DDB используются те же функции? Прошу прощения за "миллион вопросов", но мозг уже кипит от кучи прочтённого и это барахло тормозит понимание простых(по видимому) вещей. Добавлено через 8 минут Сообщение от Убежденный Единственный реальный вариант - использовать аппаратное ускорение и ресурсы GPU. То же согласен. Но есть пара "но". Распараллеливание алгоритма достигается довольно просто, но внутри алгоритма есть условия(достаточно не мало). К тому же, думаю, что перенос на GPU - это уже скорее оптимизация, которая обязательно будет иметь место, но пока нужно хотя бы реализовать работающее приложение с более-менее приемлемой скоростью. 0