Delphi. Как воспроизвести текстурную анимацию?

[Ruz34]

Вот пример картинки:



Как в Delphi менять положение изображения так, чтобы получилась анимация?

[Vladiger]

По сути, алгоритм прост: - Вы имеете дело с текстурой, которая представляет из себя матрицу 5 x 5 и получим 25 фреймов анимации, где каждый фрейм, это какой то участок текстуры в зависимости от фрейма...
Предположим у нас есть текстура размером 255 x 255:

TextureWidth = 255;
TextureHeight = 255;

разделим её на 5 спрайтов по вертикали и по горизонтали, тем самым получим ширину и высоту каждого спрайта:

SpriteWidth = TextureWidth / 5;
SpriteHeight = TextureHeight / 5;

Теперь нам остается просто узнать координаты спрайта X и Y в зависимости от текущего фрейма при отрисовке:

SpritePosX = (Frame * SpriteWidth) % TextureWidth;
SpritePosY = (Frame / 5 * SpriteHeight) % TextureHeight;

Всё... Перебирая в цикле от 0 до 24 каждый фрейм, отрисовываем каждый спрайт по очереди.

Но остается вопрос: - Чем будем рисовать? Direct Show, DirectX, OpenGL?

[phomm]

Для GDI=Canvas можно использовать либо Canvas.CopyRect либо работать через ImageList. В любом случае понадобится таймер и буферное изображение. В процедуре таймера, должен меняться Frame кадра и потом там же по сути в таймерном событии - отрисовка:

var bmp := Tbitmap;
bmp := Tbitmap.Create();
//для имейджлиста
ImageList.GetBitmap(Frame, bmp);
//для copyrect
bmp.canvas.copyrect(параметры , bmp.Canvas); - чтобы параметры правильно ставить ,
// надо почитать справку, а как рассчитывать их уже привели, правда, в виде сишного кода
// рисуем в нужное место наш bmp (по сути один из кадров)
bmp.Free();

[Ruz34]

Похоже, что проще использовать GIF анимацию с помощью дополнительных компонентов... А какой из вариантов на ваш взгляд лучше?

[Beermonza]

Крайне неудобная система хранения анимации, с последующими тормозными операциями вычленения кадра. Гораздо проще и эффективнее хранить анимацию в "портянке", т.е. в одну полоску кадра. В начале анимации сдвиг кадра равен 0, участок портянки начальный левый. При достижении конца процедуры таймера, на смене кадров, сдвиг увеличивается на длину кадра, т.е. сложение. Отрисовка использует готовый сдвиг и вырежет тем же TRect следующий кадр. И, естественно, нужно элементарное условие конца портянки анимации, тут сравнение сдвига с длиной графического файла анимации.

Ещё проще "нарезать" анимацию по собственным кадрам в одномерный массив типа array of TBitmap. Тут у каждого кадра есть номер, ...обращаемся к ячейке и выводим в буфер. Нужен элементарный счётчик кадров с условием перехода на 0-й кадр.

[Vladiger]

Гораздо проще и эффективнее хранить анимацию в "портянке", т.е. в одну полоску кадра

Так то да, согласен... Двигай кадрики влево-вправо, делов то...
Но это может быть не лучшим решением если текстура загружается в видеопамять. Она должна быть квадратная.
Хотя топикстартером и не обозначено где и как должна ипользоваться эта текстура, но я уже вперед забежал, судя по всему использоваться она будет в какой нибудь игре. А если игра начнет разрастаться то Tbitmap явно начнет не хватать, в ход пойдет DirectX или OpenGL и все... И понеслась!!!

[Beermonza]

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

Так то да, согласен... Двигай кадрики влево-вправо, делов то...
Но это может быть не лучшим решением если текстура загружается в видеопамять. Она должна быть квадратная.
Хотя топикстартером и не обозначено где и как должна ипользоваться эта текстура, но я уже вперед забежал, судя по всему использоваться она будет в какой нибудь игре. А если игра начнет разрастаться то Tbitmap явно начнет не хватать, в ход пойдет DirectX или OpenGL и все... И понеслась!!!

Глупости. Для видеокатры главным требованием будет кратность размеров текстуры степени двойки. Можно делать текстуры с размерами 48х1024 и брать кадры 48х32 пкс, например. TBitmap меняется на TPNGObject.

[Vladiger]

Глупости. Для видеокатры главным требованием будет кратность размеров текстуры степени двойки. Можно делать текстуры с размерами 48х1024 и брать кадры 48х32 пкс, например. TBitmap меняется на TPNGObject.

Возможно Вы правы. Сам я не проводил тестов на производительность видеокарточки в зависимости от размеров текстур, просто помнится где то натыкался на такую информацию, в голове отложилось...
Сейчас погуглил немного: - Действительно, люди используют всякие текстуры. Видимо информация о их "квадратности" сильно устарела и была направлена на "очень" древние видеокарточки с объемом 8-16 Мб, при том это не означало что неквадратную текстуру нельзя в них использовать, а означало то, что это сильно снижало производительность этих карточек, а так же такие текстуры занимали слишком много видео памяти, гораздо больше чем сами текстуры...

Но насколько я понял, в данный момент роль играет не только кратность 2, но и кратность сторон текстуры. Т.Е. если высота текстуры 32, то ширина может быть 64, 96, 128 и.т.д и.т.п... например текстура 32x320 - это "правильная" текстура, а 32x322 - "неправильная"...

Или это тоже не важно?

[Beermonza]

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

Но насколько я понял, в данный момент роль играет не только кратность 2, но и кратность сторон текстуры. Т.Е. если высота текстуры 32, то ширина может быть 64, 96, 128 и.т.д и.т.п... например текстура 32x320 - это "правильная" текстура, а 32x322 - "неправильная"...

Или это тоже не важно?

Для того чтобы понять как задавать размеры текстуры можно обратиться к распространённому графическому формату DDS. Минимальный размер текстур 4х4 пкс. Изменение сторон текстуры нужно выполнять умножением на 4 (это 2 в степени 2). 4 - это число пикселей, обрабатываемых за такт ядром. В каждом пикселе 4 байта - компоненты, три из них цветовые (RGB) и одна канала прозрачности (A). Каждый байт - это 8 бит кода. Итого: 128 бит - это регистры процессора.

Если текстура по ширине или высоте не делится на 4, то остатки текстуры в 3, 2, 1 пиксель будут обрабатываться отдельно с "коротких" 64-битных, 32-битных регистрах, теряя на этом время. Со стандартными наборами Canvas или WinApi GDI можно не заморачиваться, т.к. обрабатывается за такт только 1 пиксель, применять можно произвольные размеры текстуры.