-
Как можно осуществить быстрый вывод изображений с удалением фона и изменением размера, их быструю загрузку в ОЗУ, желательно без DirectX? А то мои прошлые "графические движки", если они вообще таковыми являлись, работали со скоростью бешеной черепахи.
-
Я пишу на OPenGL, но пишу 3Д. Для вывода 2Д вполне хватает кэнваса. Могу пример кинуть.
-
> желательно без DirectX?
Думаю, что быструю графику хорошего качества с различными современными спецэффектами (пусть даже и 2д) без участия DirectX или OpenGL вряд ли получится получить. Но можно попробовать GDI (или GDI+?).
> Для вывода 2Д вполне хватает кэнваса.
Только в том случае если ты собираешься выводить графики, или примитивную графику аля прототип игры. Для графики полноценной игры, возможностей канваса не хватит :)
-
> [2] Домик
Вот GDI+ как раз использовать не нужно, ничего хорошего не выйдет плане производительности.
Лучше на основе какого-нибудь FastDIB млм подобных.
-
> Только в том случае если ты собираешься выводить графики, > или примитивную графику аля прототип игры. Для графики > полноценной игры, возможностей канваса не хватит :)
Вполне хватает. НАсыщенная сцена с нормальным разрешщением легко рисуется. Конечно не стандартными средствами VCL.
> homm, как раз в этом лучше разбирается.
-
> homm © (29.05.07 21:37) [3]
Да, я знаю. Я сразу написал, что без DirectX или OpenGL быструю и качественную графику не сделать. Но если человеку очень хочеца без DrectX... Пусть пробует.
> НАсыщенная сцена с нормальным разрешщением легко рисуется.
Я бы не рискнул делать игру, основывая её графическую часть на канвасе :)
-
> [5] Домик (30.05.07 12:05) > > homm © (29.05.07 21:37) [3] > > Да, я знаю. Я сразу написал, что без DirectX или OpenGL > быструю и качественную графику не сделать. Но если человеку > очень хочеца без DrectX... Пусть пробует. > > > НАсыщенная сцена с нормальным разрешщением легко рисуется. > > Я бы не рискнул делать игру, основывая её графическую часть > на канвасе :)
Возможно мы под Канвасом подразумеваем разные вещи. Лично я под Канвасом подразумеваю ручной рендер основанный на стандартных средствах, без вмешательства DX и OGL. Такими средствами был в свое время написан Анрыл и много других хороших игр. ;)
-
У GDI/софтвера, кроме скорости вывода, есть ещё такая проблема - отсутствие нормального механизма двойной буферизации с переключением страниц (page flipping) и синхронизации с вертикальной развёрткой. Во всяком случае автор SpriteUtils, который в этом направлении копал долго и упорно, в конечном итоге пришёл к использованию DirectDraw. Правда, у него игра была весьма специфичная, с быстрым скроллингом карты, а если скроллинга нет или он относительно неторопливый, то, наверное, сойдёт и BitBlt. По скорости - да, если руки прямые, можно сделать быстро, но догнать и тем более перегнать OpenGL/Direct3D вряд ли получится (на нормальной машине, у которой мощность видеокарты пропорциональна мощности CPU и видеокарта, само собой, поддерживает 3D-ускорение). Даже интегрированное видео как минимум не проигрывает CPU. Есть у меня тест на блендинг (полупрозрачность) - exe, 30 кб: http://slil.ru/24440980Видеокарта (именно интегрированная, i915) быстрее Cel 2.8 в 2-3 раза.
-
> По скорости - да, если руки прямые, можно сделать быстро, > но догнать и тем более перегнать OpenGL/Direct3D вряд ли > получится (на нормальной машине, у которой мощность видеокарты > пропорциональна мощности CPU и видеокарта, само собой, поддерживает > 3D-ускорение). > Даже интегрированное видео как минимум не проигрывает CPU. > Есть у меня тест на блендинг (полупрозрачность) - exe, 30 > кб:
Да никто не спорит. Для этого и создавались эти АПИ, для этого и видеокарты постоянно обновляются.
-
> Есть у меня тест на блендинг (полупрозрачность) - exe, 30 кб: > http://slil.ru/24440980
Это что еще за троян? Зачем она в сеть просится?
-
Кстати, нельзя ли гденить еще исходчег выложить? Охото глянуть, как там софтвере сделан.
-
От слов к делу! Покажите или исходничек без DX, ну или даже с DX (как бы мне сейчас не хотелось его использовать). И еще, я пока не разрабатываю игру графикой похлеще чем в Готике 3 или Думе 3, и с поддержки DirectX 10, поэтому мне особо не нужны на этом движке яркие спецэффекты. Это не отрицание DX, просто хотел провести разминку перед тем как писать с помощью него
-
Охото глянуть, как там софтвере сделан.Additive - FastLIB'овский AddBlend. Alpha - конвертированный под FastLIB MMXAlphaPut из SpriteUtils. Кстати, с альфой довольно шустро работает функция GDI AlphaBlend, хотя, говорят, нестабильно в Win9x. Я тестировал на Win2000 - вроде всё нормально, скорость cопоставима с MMXAlphaPut, хотя AlphaBlend в некотором смысле "мухлюет" - использует premultiplied alpha, т.е. нужно заранее умножить на alpha пиксели исходной картинки. От слов к делу! Покажите или исходничек без DXЕсли по этому поводу: http://pda.delphimaster.net/?id=1180354902&n=7то PixelFormat пробовал? Я у себя проверял - действительно быстрее, но на разных ОС и драйверах оно может быть по-разному, поэтому выразился осторожно. Теоретическая основа такая: 32 бита: 1) мелкософт умудряется писать жутко кривой код для обработки 24-битных картинок (притом что именно этот формат до XP включительно является стандартом). Проверено также со StretchBlt, и не только мной - 32-битные битмапы значительно быстрее. 2) на некоторых картах копирование на экран быстрее если формат битмапа = формату рабочего стола, а обычно стоит именно 32 бита. pfDevice: при выводе таких битмапов может использоваться (и обычно используется на NT-семействе, хотя зависит от драйвера) аппаратное ускорение, но только для простых операций вроде BitBlt и TransparentBlt (StretchBlt не ускоряется). Доступ к пикселям (Pixels, Scanlines) такого битмапа получить нельзя, точнее можно, но очень медленно. Если так уж надо исходничек примера с блендингом - завтра, может быть... то есть, гм, сегодня, но днём.
-
-
-
> PixelFormat пробовал?
еще как пробовал. Все идет ОК, теперь е*... мучаюсь со способами хранения групп изображений для последующего вывода. А вообще я взял себе за образец движок игры "Alien Shooter" (играл кто-нибудь? Он мне больше нравится чем некоторые 3D шутеры). По моему это хороший ориентир. Ну дак вот там изображения хранятся в файлах *.vid и выводятся один за одним в зависимости от угла поворота. Щас разрабатываю эту структуру хранения различных видов объекта.
-
gray_falcon, ядро у Alien Shooter основано на DirectX. И даже такой скорости тебе никакой GDI движок не даст )
-
Хм. Я навино полгалал, что Алиен Шутер - смесь 3Д и 2Д. Я ошибался? :)) Надо будет на dtf спросить.
-
сейчас вышел Alien Shooter полный 3D !
-
> И даже такой скорости тебе никакой GDI движок не даст )
Что значит «И даже такой» ? :) Он у меня 300-500 fps выдет :)
-
> сейчас вышел Alien Shooter полный 3D !
Если имеется в виду Alien Shooter 2, то спешу вас огорчить, там все 2D.
-
homm, сомневаюсь что твой GDI движок способен выводить столько контента с достойной скоростью на таком разрешении.
-
> XProger © (01.06.07 19:19)
Не, никто не спорит, что CPU+GPU быстрее, чем CPU. Но все же ИМХО не стоит сбрасывать все это сосчетов.
-
> homm, сомневаюсь что твой GDI движок способен выводить столько > контента с достойной скоростью на таком разрешении.
Да я спорю что-ли :), я про то что Alien Shooter выдает фэпээсов совсем не «и даже» :))
-
Кстати, XProger (и не только), помнишь кто-то спрашивал, как можно наиболее оптимально заполнить поле 640х480 квадратами 8х8? Я вылизал алгоритм до самого предела. Если интересно, кто-нибудь возметься реализовать такое на апаратном ускорении (каком — без разницы), чисто ради сравнить результаты? Мне почему-то кажеться, что быстрее не может получиться. Вот что у меня получилось по скорости в полном software: На формирование одного кадра уходит примерно 3,1 МГц, что соответствует примерно 1760/3,1 =566 кадров в секунду! Причем если отключить только одну функцию BitBlt, переносящую результат на экран, получаем примерно 1760/1,6 = 1076 кадров в секунду! Конечно второй показатель практически безполезен, без блитинга в видеопамять. В обшем вот архив с проектом и демкой (30 Кб) http://homm86.narod.ru/files/fps.rar
-
homm, а можешь это сделать разноцветными квадратами с нормальным циклом отрисовки расчитывающим РЕАЛЬНЫЙ фпс в зависимости от кол-ва отрисованных кадров за последнюю секунду? За реализацию на OpenGL в таком случае - возьмусь.
-
Обновил архив. Так и не понял, зачем имеено «разноцветными квадратами», но добавил и патернов, выбирай какой нравиться бльше :)
-
-
~1200FPS на демке homm, ~1000FPS на демке XProger :)
-
Да уж, похоже вера в аппаратное ускорение вернулась :)) У меня 1500 получилось, в 3 раза больше :)
> ~1200FPS на демке homm, ~1000FPS на демке XProger :) Что еше можно было ожидать от VGA ;) Наверное коре 2 дури и видео встроенное.
-
170 против 340. Правда стоит заметить что запускалось все при напрочь загруженном проце и пустой карте...
> [29] homm © (02.06.07 09:48)
Еще раз убеждаемся, что все зависит только от оборудования.
-
Core 2 Duo E6300, ATI Radeon X1950Pro - мягко говоря не чета встроенному.
-
> [31] Vga
тогда не знаю, почему Прогеровская демка так «тормозила» :) У меня 7600GT, как уже говорил 1500fps.
-
Одна из причин - на АТИ под винду опенгл сделан через жопу, увы. На маках говорят дрова лучше, но то маки и там дырекса нету
-
Объясните мне, или я че не допонял, мне зачем выводить изображение 1000 раз в секунду, когда у меня CRT с частотой обновления экрана в 100 Гц. Мне вполне этой 100 хватит, такую частоту 2D движок на канвасе точно потянет.
-
> Объясните мне, или я че не допонял, мне зачем выводить изображение 1000 раз в секунду
Нужно пытаться минимизировать время построения любого объекта. Представь группу разработчиков. Оди реализует HDR шейдеры, другой модели рисует, третий текстуры, четвертый картой занимаеться. Делают они каждый свое дело, у каждого по 80-100 кадров на тестовый сценах получаеться, а потом все это дело собирают и получаеться не более 20. Вроде-бы и так все шустро было, а игра получилась тормознутая.
-
gray_falcon, высокая скорость отрисовки - показатель скорости работы софта и железа. Больше частоты развёртки в играх естественно не нужна, но Canvas, так называемый, в тех же играх этого выдать не способен... стоит применить пару поворотов с блендингом (которые естестенно тебе придётся реализовывать самому вручную) и FPS упадёт до единиц.
-
> [27] XProger © (02.06.07 02:39) > твой ход...
Ну давай, попробую :)) http://homm86.narod.ru/files/test.rarПравда это уже на основе твоей демы, но все равно, я еше 230 кадров из нее выжал :P
-
homm, а у меня почему-то проигрывает на 150 фпс... я так понимаю ты попытался выйграть на облегчении работы CPU... В отрисовке здесь работает GPU, так что я спокойно могу крутить циклы до 100000 сложений в рендере и FPS даже не просядет )
-
Ну не знаю как у вас, а у меня 1376 - 1378 FPS =)
-
> а у меня почему-то проигрывает на 150 фпс...
«Этого не может быть, потому что этого не может быть» © Очень интересный результат. :) Я бы понял, если бы 8-й жифорс сравновали, там что-то говорили о переводе логики из режима работы с плавающей точкой в целочисленый, ито это для шейдеров, а так вообще не понятно. Может кто еще попробует и скажет, какой вариант выдает сколько фэпээсов?
ЗЫ XProger, может что-нить в фоне работает, забыл отключить? У меня даже винамп с диспетчером задачь напару сотню попугаев съедают.
-
У меня test[homm] тоже проигрывает test[XProger] на полсотни кадров. А на G80, AFAIK, основан на скалярных (а не векторных, как раньше) процессорах с плавающей точкой. R600 - на суперскалярных с плавающей точкой, но тоже не векторных.
-
homm, я сравнивал наши демки по очереди... твоя вроде не запускает вторичных процессов? )
-
-
Мдя. А мож даже и 1900
-
> Vga ©
Может тогда так? :) procedure Render;
const
W = 640 div 8;
H = 480 div 8;
D = 1/8;
var
i: Integer;
X, Y: Integer;
begin
for i:=0 to 4799 do
begin
TCB[4*i].X:=Random(8)*D;
TCB[4*i].Y:=Random(8)*D;
TCB[4*i+1].X:=TCB[4*i].X+D;
TCB[4*i+1].Y:=TCB[4*i].Y;
TCB[4*i+2].X:=TCB[4*i].X+D;
TCB[4*i+2].Y:=TCB[4*i].Y+D;
TCB[4*i+3].X:=TCB[4*i].X;
TCB[4*i+3].Y:=TCB[4*i].Y+D;
end;
glTexCoordPointer(2, GL_FLOAT, 0, @TCB[0]);
glEnableClientState(GL_VERTEX_ARRAY);
glEnableClientState(GL_TEXTURE_COORD_ARRAY);
glDrawArrays(GL_QUADS, 0, 19200);
glDisableClientState(GL_VERTEX_ARRAY);
glDisableClientState(GL_TEXTURE_COORD_ARRAY);
end;
-
Кстати да :D
-
У меня как раз 1900 и вышло, а без этого исправления писовался ккой-то бред и было не более 1300.
-
Тото картинка странная. И ФПС теперь 2100
-
> Тото картинка странная. И ФПС теперь 2100
Ну вот, а автор той темы, с которой все и началось хотел все-то 30 :D
-
-
Ну и победные для моей системы 2 килогерца, если заменить glVertexPointer(2, GL_FLOAT, 0, @VB[0]); на glVertexPointer(2, GL_SHORT, 0, @VB[0]); Ура! :) Спасибо, друзья, узнал сегодня много интересного, все-же грфика не основное мое занятие :)
-
А с GLint? По идее, в 32бит системе должно быть быстрее, но требуется больше данных гонять по шине
-
И кстати, у тебя что за система? Видяха, ее шина, проц?
-
> А с GLint?
Посредине между GL_FLOAT и GL_SHORT.
> В отрисовке здесь работает GPU, так что я спокойно могу > крутить циклы до 100000 сложений в рендере и FPS даже не > просядет )
Ну 100000 это конечно ты загнул, а вот 10000 да, работает практически без ущерба для основной сцены :)
-
Sempron2800+ (разогнан с 1600 до 1760) память ДДР-2 около 600 что-то. PCI-E GF-7600GT.
-
> память ДДР-2 около 600
это частота :)
-
Гм. Видимо влияет пропускная способность шин памяти и возможно карты. И проц видимо быстрее работает с целочисленной математикой.
-
http://opengl.gamedev.ru/articles/?id=124Лучше положения вершин, нормали, текс. координаты и др. атрибуты хранить в 16-битных целых (GL_SHORT) - это не даёт perfomance penalty начиная с Radeon 9200 и GF4Ti, зато существенно экономит память (при этом такие числа обладают гораздо большей точностью, чем half float) и снижает время загрузки геометрии (как с жёсткого диска в оперативную память, так и в буферы в видеопамяти).
-
Гм. Статью я читал, однако это благополучно забыл :) Но вообще-то, я имел в виду CPU
-
> Ну вот, а автор той темы, с которой все и началось хотел > все-то 30 :D
Ладно, считайте что уговорили, BitBlt, как говорится, хорошо, а OGL лучше. Тогда никто не покажет простой пример применения этой библиотеки (или DX) наподобие "загрузил бмп-вывел на экран и все". Желательно если хоть с какимито комментариями. А то с этими экзаменами времени изучать справочники нету. заранее благодарен :}
-
> > Ну вот, а автор той темы, с которой все и началось хотел все-то 30 :D > Ладно, считайте что уговорили, BitBlt, как говорится, хорошо, а OGL лучше.
Имлся ввиду другой автор(вроде бы) другой ветки :) Не могу я ее найти что-то :) А вообше, бери за основу как раз ХПрогеровскую демку, движек вполне хорош для маленьких проектов. Тока код движка наверное для D7 был написан, в D5 мне много чего править пришлось )
-
Пишет XProger вообще-то уже в D10 (если не 11) и планирует обломать более старые дельфи совсем, методом использования новых фич. Для 2D там AFAIK непосредственно ничего нету, кроме общих инструментов и установки ортографической проекции. В этом плане лучше движок DGLE, хотя он довольно таки кривоват... А вообще, AFAIK, Asphyre (экс PowerDraw) - вполне таки хороший двухмерный движок. Если есть API для дельфи, то я слышал, что еще хорош PopCap Framework. Ну а в качестве примера вполне сойдут исходники соответствующих функций из DGLE ( http://dron.mirgames.ru)
-
За мерянием некими девайсами (которое, каюсь, я же и спровоцировал :)) никто не вспомнил про http://www.igdc.ru/Имеется множество игр с исходниками, и на аппаратных, и на софтверных движках. Аппаратных, впрочем, больше, из софтверных могу вспомнить космосим (или это называлось "скроллер", точно не помню) antonn'а и арканоид Imp'а. + готовые движки. Помнится, Darthman выкладывал простенький 2D-движок на OGL - DL-FX2, кажется, он назывался.
-
Удалено модератором
-
Удалено модератором
-
Удалено модератором
-
Удалено модератором
-
Удалено модератором
|