Форум программистов
 

Восстановите пароль или Зарегистрируйтесь на форуме, о проблемах и с заказом рекламы пишите сюда - alarforum@yandex.ru, проверяйте папку спам!

Вернуться   Форум программистов > разработка игр, графический дизайн и моделирование > Gamedev - cоздание игр: Unity, OpenGL, DirectX
Регистрация

Восстановить пароль
Повторная активизация e-mail

Купить рекламу на форуме - 42 тыс руб за месяц

Ответ
 
Опции темы Поиск в этой теме
Старый 13.05.2008, 16:46   #491
Beermonza
Инженер ИС
Старожил
 
Аватар для Beermonza
 
Регистрация: 13.12.2006
Сообщений: 2,671
Радость

Цитата:
Сообщение от mutabor
Основная проблема к-рую можно предвидеть уже сейчас, тормоза на слабых процессорах. Чего не было бы с поддержкой видеокарты, можно было бы нехилый запас сделать. Процессоры насколько я заметил, выводят GDI графику неадекватно, по марке не угадаешь, Атлоны старые вроде хорошо справляются.
И Intel Celeron 300, древнейший по сегодняшним меркам, справляется с нагрузкой, которую планируется ему передавать, ...я сейчас специально увеличил многократно количество объектов (столько в игре на экране просто не может быть) и смотрю как ведет себя мой Core, ...он справляется блестяще! ...останавливаться на достигнутом не собираюсь, когда-то и Canvas.Draw казался самым быстрым, теперь уже нет, ...благодаря alexBlack'у, нагрузка снизилась еще на 1/3.
Давайте же будем нажимать на "кнопку" без посредников! ...если Вася был мертвецки пьян, то "вагон" разгружен не будет )

Я сейчас не использую ни PaintBox, ни Image, ...рисую сразу на содержимое формы. Как стало известно, в Windows без разницы куда выводить графику, хоть в окно, хоть в кнопку, ...нужен лишь контекст.

Цитата:
Сообщение от alexBlack
Насчет приватного контекста. Пробовал CS_OWNDC - так и не понял в чем разница. В справочнике написано, что его можно не удалять после вызова WMPaint, но не понял как это можно проверить.
Если не путаю, на современных компах позволительно задавать общий контекст один раз при создании окна и удаление его после закрытия. В режиме CS_OWNDC достаточно только создать приватный контекст, а удалится он сам после завершения передачи данных, ...опять же, если правильно понимаю.
Руководитель проекта MMO 2D RPG: Настоящее имя Денис Стрижак (10.05.1981-6.02.2019) Мир духу его
Beermonza вне форума Ответить с цитированием
Старый 13.05.2008, 18:38   #492
mutabor
Телепат с дипломом
Старожил
 
Аватар для mutabor
 
Регистрация: 10.06.2007
Сообщений: 4,929
По умолчанию

Цитата:
Я сейчас не использую ни PaintBox, ни Image, ...рисую сразу на содержимое формы
Для меня ценность PaintBox'а в собственных координатах. Когда кроме области вывода графики на форме есть еще какие нибудь кнопки-панели, особенно сверху, он полезен. А так я тоже всегда прямо на форме рисую, когда окно целиком под графику. Правда я по простому, через канву )
The future is not a tablet with a 9" screen no more than the future was a 9" black & white screen in a box. It’s the paradigm that survives. (Kroc Camen)
Проверь себя! Онлайн тестирование | Мой блог
mutabor вне форума Ответить с цитированием
Старый 14.05.2008, 15:23   #493
Beermonza
Инженер ИС
Старожил
 
Аватар для Beermonza
 
Регистрация: 13.12.2006
Сообщений: 2,671
По умолчанию

Думаю, мы вместе найдем наибыстрейшую формулу работы с графикой в окне Windows )
Пока структура такая:
1) подготовка заднего фона, запись в буфер в ОЗУ;
2) перенос буфера заднего фона в буфер построения кадра (в ОЗУ, на ASM);
3) построение кадра в буфере (в ОЗУ);
4) вывод кадра на экран через контекст (WMPaint);

Если позволите, предложу вместе подумать над алгоритмом построения кадра, в частности - отрисовкой текстур с учетом выхода за пределы экрана. Наверняка можно сделать эффективнее.
Руководитель проекта MMO 2D RPG: Настоящее имя Денис Стрижак (10.05.1981-6.02.2019) Мир духу его
Beermonza вне форума Ответить с цитированием
Старый 14.05.2008, 16:05   #494
alexBlack
Участник клуба
 
Регистрация: 12.10.2007
Сообщений: 1,204
По умолчанию

Цитата:
Сообщение от Beermonza Посмотреть сообщение
Если позволите, предложу вместе подумать над алгоритмом построения кадра, в частности - отрисовкой текстур с учетом выхода за пределы экрана. Наверняка можно сделать эффективнее.
А можно подробней постановку задачи ?
- Как это сделано сейчас ?
- и кадр и текстура - это ссылки, полученные вызовами CreateDIBSection ? и нужен аналог bitBlt для этих структур ?
alexBlack вне форума Ответить с цитированием
Старый 14.05.2008, 17:14   #495
Beermonza
Инженер ИС
Старожил
 
Аватар для Beermonza
 
Регистрация: 13.12.2006
Сообщений: 2,671
Смех Подробности работы с текстурами в ОЗУ

Текстуры - это обычные Bitmap картинки, загруженные в массив через LoadFromFile, ...текстура содержит в себе и маску, это два одинаковых по размеру изображения, расположенных друг под другом, ...верхнее в цвете, нижнее - маска прозрачности.

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

y_up - начальная строка выборки изображения (по-ScanLine);
y_down - конечная строка выборки;
y_zone - начальная строка выборки изображения в DrawBuf;
x_left - начальный пиксел (слева);
x_right - конечный пиксел (справа);
x_zone - начальный пиксел в DrawBuf;
TexDispX - смещение по-X объекта на карте к центру его координат;
TexDispY - смещение по-Y объекта на карте к центру его координат;
TexW - ширина текстуры (в сборе ровно половина исходного изображения);
TexH - высота текстуры;
W - Ширина экрана;
H - Высота экрана;
dt - клетка карты, Y-координата;
dz - клетка карты, X-координата;
TexLine - точная длина строки изображения для текстуры.

Вот так выглядит обрезка текстур, в алгоритме, который выполняется один раз после смещения координат карты, и параметры обрезки сохраняются в массив для каждого объекта (экономим ресурсы):

Код:
// назначение пределов y_up, y_down, y_zone
  if (H-(12+(dt*12)-TexDispY))>0 then
    begin
      if (12+(dt*12)-TexDispY)<=0 then
        begin
          y_up:=Abs(12+(dt*12)-TexDispY);
          y_zone:=0;
          y_down:=TexH-1;
        end;

      if ((12+(dt*12)-TexDispY)+(TexH))>=H then
        begin
          y_up:=0;
          y_zone:=12+(dt*12)-TexDispY;
          y_down:=H-(12+(dt*12)-TexDispY)-1;
        end;

      if ((12+(dt*12)-TexDispY)>0) And (((12+(dt*12)-TexDispY)+TexH)<H) then
        begin
          y_up:=0;
          y_zone:=12+(dt*12)-TexDispY;
          y_down:=TexH-1;
        end;
      
      // указатели на области изображения
      TexPointer:=Tex.ScanLine[y_up];
      MapPointer:=Tex.ScanLine[y_up+TexH];
      ZonePointer:=DrawBuf.ScanLine[y_zone];

      // назначение пределов x_left, x_right, x_zone
      if (W-(24+(dz*24)-TexDispX))>0 then
        begin
          if (24+(dz*24)-TexDispX)<=0 then
            begin
              x_left:=Abs(24+(dz*24)-TexDispX);
              x_zone:=0;
              x_right:=TexW-1;
            end;

          if ((24+(dz*24)-TexDispX)+TexW)>=W then
            begin
              x_left:=0;
              x_zone:=24+(dz*24)-TexDispX;
              x_right:=W-(24+(dz*24)-TexDispX)-1;
            end;

          if ((24+(dz*24)-TexDispX)>0) And (((24+(dz*24)-TexDispX)+TexW)<W) then
            begin
              x_left:=0;
              x_zone:=24+(dz*24)-TexDispX;
              x_right:=TexW-1;
            end;
        end;
    end;
Вот так идет отрисовка в ОЗУ:

Код:
for yy:=y_up to y_down do
  begin
    // Указатели на первый пиксель в текущей строке
    DWORD(TexPixel):=DWORD(TexPointer)+x_left*3;
    DWORD(MapPixel):=DWORD(MapPointer)+x_left*3;
    DWORD(ZonePixel):=DWORD(ZonePointer)+x_zone*3;

    for xx:=x_left to x_right do
      begin
        if (MapPixel.R>0) And (MapPixel.G>0) And (MapPixel.B>0) then
          begin
            // Смешивание цветов по формуле прозрачности
            ZonePixel.R:=ZonePixel.R+(TexPixel.R-ZonePixel.R)*MapPixel.R shr 8;
            ZonePixel.G:=ZonePixel.G+(TexPixel.G-ZonePixel.G)*MapPixel.G shr 8;
            ZonePixel.B:=ZonePixel.B+(TexPixel.B-ZonePixel.B)*MapPixel.B shr 8;
          end;
        // Указатели на следующие пиксели в текущей строке
        DWORD(TexPixel):=DWORD(TexPixel)+3;
        DWORD(MapPixel):=DWORD(MapPixel)+3;
        DWORD(ZonePixel):=DWORD(ZonePixel)+3;
      end;

    // Указаетели на следующую строку
    DWORD(TexPointer):=DWORD(TexPointer)+TexLine;
    DWORD(MapPointer):=DWORD(MapPointer)+TexLine;
    DWORD(ZonePointer):=DWORD(ZonePointer)-W*3;
  end;
Будем думать?
Руководитель проекта MMO 2D RPG: Настоящее имя Денис Стрижак (10.05.1981-6.02.2019) Мир духу его
Beermonza вне форума Ответить с цитированием
Старый 14.05.2008, 17:27   #496
alexBlack
Участник клуба
 
Регистрация: 12.10.2007
Сообщений: 1,204
По умолчанию

Цитата:
Сообщение от Beermonza Посмотреть сообщение
Будем думать?
Да, будем.
................................... ............................
Предложения и вопросы в readme.txt
Вложения
Тип файла: rar Project1.rar (174.1 Кб, 95 просмотров)

Последний раз редактировалось alexBlack; 15.05.2008 в 11:34.
alexBlack вне форума Ответить с цитированием
Старый 15.05.2008, 16:15   #497
Beermonza
Инженер ИС
Старожил
 
Аватар для Beermonza
 
Регистрация: 13.12.2006
Сообщений: 2,671
По умолчанию Подробнее...

Цитата:
Сообщение от alexBlack (readme.txt)
Блок с вычислением координат. ... Непонятен принцип. Что там с ячейками и константами 12/24.
Этот блок можно не менять, т.к. время выполнения мало.
Того же мнения, тут искать якорь нет смысла. dt*12 и dz*24 - это смещение картинки объекта в буфере, если мысленно подставлять в переменные числа (это как и положено делает цикл, перебирая ячейки карты), то можно определить место положение левого верхнего угла Bitmap'а в буфере. У меня тайлы поля размером 49x25, я грубо беру половину и смещаю на нее каждый следующий тайл в массиве карты. Константы 12 и 24 нужны для того, чтобы "центр" тайла был в центре а не в его верхнем левом углу.

По поводу ScanLine, ...и в моем случае он берется один раз после изменения на игровом поле (сдвинулась карта в нужное место, можно передвигать персонажа, участвовать в схватке и пр., и пока на экране эта область ScanLine "отдыает"), так что в цикле он не участвует. Если есть возможность вообще от него отказаться, то я за!

Цитата:
Сообщение от alexBlack (readme.txt)
Используется только этот алгоритм или есть еще и другие варианты и
придется переделывать каждый ? Откуда такая формула и можно ли ее
записать по-другому ?
Только такой вариант смешивания цветов использовал. Формула получена математическим упрощением (приведение к общему знаменателю) широко известной с двойным делением на 256. Логика была: "чем меньше мат. заков типа "делить", "умножить" тем лучше." Так оно и есть, ...представленная в примере формула на порядок быстрее.

Постоянно преследуют мысли заменить весь цикл отрисовки в DrawBuf с известными границами данных на ASM-код, только не силен в этом, искал примеры, не смог понять . В файле test.txt это оно и есть? ...вроде только само смешивание, ...а остальное наверное не подлежит ускорению?
Руководитель проекта MMO 2D RPG: Настоящее имя Денис Стрижак (10.05.1981-6.02.2019) Мир духу его
Beermonza вне форума Ответить с цитированием
Старый 15.05.2008, 18:20   #498
alexBlack
Участник клуба
 
Регистрация: 12.10.2007
Сообщений: 1,204
По умолчанию

Цитата:
По поводу ScanLine, ...и в моем случае он берется один раз после изменения на игровом поле (сдвинулась карта в нужное место, можно передвигать персонажа, участвовать в схватке и пр., и пока на экране эта область ScanLine "отдыает"), так что в цикле он не участвует.
Странно, а у меня так не получилось. Если я получаю вызовом ScnaLine ссылку на начало данных строки, то могу обратиться только к байтам этой строки. Обращение через эту же ссылку к следующей строке вызывает Access violation. Поэтому пришлось вызывать ScanLine еще и в цикле.

Цитата:
Если есть возможность вообще от него отказаться, то я за!
Думаю, есть. При загрузке текстуры получаем ссылку на начало данных bits.

Код:
procedure TForm1.loadTextures;
var HeaderSize, BitsSize: Integer;
    Header: pointer;
begin
   tex := TBitMap.Create;
   tex.loadFromFile('2.bmp');
   texH := tex.Height div 2;
   texW := tex.Width;
   texLine := texW*3;
   if texLine mod 4 <> 0
   then texLine := ((texLine div 4)+1) * 4;

   GetDIBSizes(tex.Handle, HeaderSize, BitsSize);
   GetMem(Header, HeaderSize);
   GetMem(Bits, BitsSize);
   try
      GetDIB(tex.Handle, 0, Header^, Bits^);
   finally
      freeMem(Header);
   end;
end;
Перед циклом вычисляем ссылку на начало строки y_up вместе со смещением на x_left

Код:
   TexPointer  := bits + (texH*2-1   -y_up       )*texLine   + x_left*3;
   MapPointer  := bits + (texH*2-1   -(y_up+TexH))*texLine   + x_left*3;
   ZonePointer := scr  + (H-1        -(y_zone)   )*DrawLine  + x_zone*3;
Внутри цикла просто перемещаемся на начало следующей строки

Код:
   TexPointer  := TexPointer  -texLine;
   MapPointer  := MapPointer  -texLine;
   ZonePointer := ZonePointer -DrawLine;
Вот здесь интересный момент. Пока не лазил в документацию во этому поводу, но строки в bits расположены наоборот - с последней до первой. Поэтому в приращении стоит -textLine.

Цитата:
Только такой вариант смешивания цветов использовал.
Если вариант один, то есть смысл сделать на asm'е

Цитата:
Формула получена математическим упрощением (приведение к общему знаменателю) широко известной с двойным делением на 256. Логика была: "чем меньше мат. заков типа "делить", "умножить" тем лучше." Так оно и есть, ...представленная в примере формула на порядок быстрее.
Она может и широко известна в узких кругах, но я с ней не сталкивался.
Видел другой вариант - см.ниже. Если не трудно, приведите и исходную формулу. Будет больше простора при реализации на ассемблере.

Цитата:
Постоянно преследуют мысли заменить весь цикл отрисовки в DrawBuf с известными
границами данных на ASM-код, только не силен в этом, искал примеры, не смог
понять . В файле test.txt это оно и есть? ...вроде только само
смешивание, ...а остальное наверное не подлежит ускорению?
да, в test.txt это мои попытки сделать на ассемлере. Но, знаете, трудно
улучшить в лоб то, что генерирует компилятор. Максимум можно выкинуть shr. Нужно менять подход. Поэтому я спрашивал нельзя ли изменить формулу на работу с байтами и словами. Сейчас компилятор делает так:

byte(R) + byte ((integer(R)-integer(R)) * integer(R) shr 8)

из статьи:
http://www.wl.unn.ru/~ragozin/diff/mmx.htm
попробовал вставить кусок кода на mmx-командах. В принципе работает, хотя и не сильно быстрее, но формула немного другая, поэтому и результат отличается.

a = b + (a - b) * alpha

Еще вопрос по условию.

if (MapPixel.R>0) And (MapPixel.G>0) And (MapPixel.B>0) then begin

т.е. если ВСЕ составляющие отличны от нуля, то смешивать.
Не нарушит логику, если будет другое условие :

"если ВСЕ компоненты = 0, то НЕ смешивать" ?

Пока все. С asm'мом буду пробовать.
alexBlack вне форума Ответить с цитированием
Старый 15.05.2008, 21:23   #499
alexBlack
Участник клуба
 
Регистрация: 12.10.2007
Сообщений: 1,204
По умолчанию

Добил ассемблерные вставки. Выводы:
Исходный вариант (время выполнения ~1.7 единиц):

Код:
   TexPointer  := bits + (texH*2-1   -y_up       )*texLine   + x_left*3;
   MapPointer  := bits + (texH*2-1   -(y_up+TexH))*texLine   + x_left*3;
   ZonePointer := scr  + (H-1        -(y_zone)   )*DrawLine  + x_zone*3;
   // указатели на области изображения
   for yy:=y_up to y_down do begin

      TexPixel  := P24Color(TexPointer );
      MapPixel  := P24Color(MapPointer );
      ZonePixel := P24Color(ZonePointer);
      for xx:=x_left to x_right do begin
         if (MapPixel.R>0) And (MapPixel.G>0) And (MapPixel.B>0) then begin
            ZonePixel.R:=ZonePixel.R+(TexPixel.R-ZonePixel.R)*MapPixel.R shr 8;
            ZonePixel.G:=ZonePixel.G+(TexPixel.G-ZonePixel.G)*MapPixel.G shr 8;
            ZonePixel.B:=ZonePixel.B+(TexPixel.B-ZonePixel.B)*MapPixel.B shr 8;
         end;
         // Указатели на следующие пиксели в текущей строке
         TexPixel  := P24Color(PChar(TexPixel)  +3);
         MapPixel  := P24Color(PChar(MapPixel)  +3);
         ZonePixel := P24Color(PChar(ZonePixel) +3);
      end;

      TexPointer  := TexPointer  -texLine;
      MapPointer  := MapPointer  -texLine;
      ZonePointer := ZonePointer -DrawLine;
   end;
Тот-же код с использованием команд mmx. (время выполнения ~1.5 единиц)
Вот это уже есть смысл использовать. Некоторые замечания по коду.
Во первых обработка идет по 4 байта, а не по три. (можно обрабатывать по 8 байт - время уменьшается до ~1.4) Здесь нужно еще подумать. Или сделать размер текстур кратным 4-м или дополнительно обрабатывать оставшиеся байты. Из-за этого я несколько вольно обошелся с условием. Смешение цветов делается для всех байт. Просто умножение на 0 дает 0
и ничего не вносит в исходную картинку. Это не соответствует исходному условию
при котором смешение не производится, если хотя бы один цвет =0.

Код:
   TexPointer  := bits + (texH*2-1   -y_up       )*texLine   + x_left*3;
   MapPointer  := bits + (texH*2-1   -(y_up+TexH))*texLine   + x_left*3;
   ZonePointer := scr  + (H-1        -(y_zone)   )*DrawLine  + x_zone*3;

   asm // подготовка маски
      pxor      xmm7, xmm7      //
      mov       eax, $FFFFFFFF  // маска
      movd      xmm3, eax
      PUNPCKLBW xmm3, xmm7
   end;
   for yy:=y_up to y_down do begin

      TexPixel  := P24Color(TexPointer );
      MapPixel  := P24Color(MapPointer );
      ZonePixel := P24Color(ZonePointer);
      C := (x_right-x_left+1)*3 div 4;
      if C <= 0 then break;
      
      asm
         //push edi
         //push esi
         //push edx
         //push ecx

         mov ecx, C
         mov esi, [TexPixel]
         mov edx, [ZonePixel]
         mov edi, [MapPixel]
       @@1:
         cmp dword ptr [edi], 0
         je @@next

         movd      xmm0, [esi]     // tex
         PUNPCKLBW xmm0, xmm7      // convert to word

         movd      xmm1, [edx]     // zone
         PUNPCKLBW xmm1, xmm7
         psubw     xmm0, xmm1      // tex-zone

         movd      xmm2, [edi]     // map
         PUNPCKLBW xmm2, xmm7

         pmullw    xmm0, xmm2      // (tex-zone)*map
         psrlw     xmm0, 8         // shr 8
         paddw     xmm1, xmm0      // zone + (tex-zone)*map shr 8

         pand      xmm1, xmm3
         packuswb  xmm1, xmm1      // convert to byte

         movd      [edx], xmm1

       @@next:
         add esi, 4
         add edx, 4
         add edi, 4
         loop @@1

         //pop ecx
         //pop edx
         //pop esi
         //pop edi
      end;
      TexPointer  := TexPointer  -texLine;
      MapPointer  := MapPointer  -texLine;
      ZonePointer := ZonePointer -DrawLine;
   end;
   asm
      emms
   end;
PS. простое переписывание кода на ассемблере ничего не дало кроме понимания.
(не буду приводить код) Наоборот, время выполнения стало еще больше.
т.е. Delphi генерирует код лучше меня

Последний раз редактировалось alexBlack; 15.05.2008 в 22:03.
alexBlack вне форума Ответить с цитированием
Старый 16.05.2008, 00:06   #500
Beermonza
Инженер ИС
Старожил
 
Аватар для Beermonza
 
Регистрация: 13.12.2006
Сообщений: 2,671
По умолчанию

alexBlack, ну что же, не получилось так не получилось, и на том спасибо за помощь

Цитата:
Сообщение от alexBlack
Странно, а у меня так не получилось. Если я получаю вызовом ScnaLine ссылку на начало данных строки, то могу обратиться только к байтам этой строки. Обращение через эту же ссылку к следующей строке вызывает Access violation. Поэтому пришлось вызывать ScanLine еще и в цикле.
Это и верно, будет ошибка, если ты пытаешься взять все данные сразу или в последствие будешь обращаться к другой части, для которой ScanLine вызван не был. Обрати внимание на использованный мой метод "перебрасывания" Pointer'a

Код:
DWORD(TexPointer):=DWORD(TexPointer)+TexLine;
...это переход на следующую строку, ...тут TexLine получен при загрузке картинки, ...значение этой переменной отрицательное (Integer):
Код:
TexLine:=Integer(Tex.ScanLine[1])-Integer(Tex.ScanLine[0]);
По поводу получения указателя на начало данных при загрузке bits, у меня не работает вот эта часть кода:

Код:
GetDIBSizes(tex.Handle, HeaderSize, BitsSize);  
    GetMem(Header, HeaderSize);  
    GetMem(Bits, BitsSize);  
    try  
       GetDIB(tex.Handle, 0, Header^, Bits^);  
    finally  
       freeMem(Header);  
    end;
... первая же строка не устраивает Delphi. HeaderSize, BitsSize: Integer; в них GetDIBSizes поместит размеры заголовка и основных данных да?



Цитата:
Сообщение от alexBlack
Цитата:
Сообщение от Beermonza
Формула получена математическим упрощением (приведение к общему знаменателю) широко известной с двойным делением на 256. Логика была: "чем меньше мат. заков типа "делить", "умножить" тем лучше." Так оно и есть, ...представленная в примере формула на порядок быстрее.
Она может и широко известна в узких кругах, но я с ней не сталкивался.
Видел другой вариант - см.ниже. Если не трудно, приведите и исходную формулу. Будет больше простора при реализации на ассемблере.
Вот такой я ее видел неоднократно:

Result = Source * (Alpha/256) * (SelfAlpha/256) + Dest * (1 - (Alpha/256) * (SelfAlpha/256))

SelfAlpha - это общая прозрачность полученного результата (кроме прозрачности для каждого пиксела Alpha). Этот параметр я выкинул, после упрощения получилось более просто, ...кроме того читал, что A shr 8 выполниться быстрее и всегда целочисленно, чем А/256, тут еще и Round придется использовать к тому же, ...вот упрощенная формула:

Result := Dest + (Source - Dest) * Alpha shr 8;

Цитата:
Сообщение от alexBlack
Еще вопрос по условию.

if (MapPixel.R>0) And (MapPixel.G>0) And (MapPixel.B>0) then begin

т.е. если ВСЕ составляющие отличны от нуля, то смешивать.
Не нарушит логику, если будет другое условие :

"если ВСЕ компоненты = 0, то НЕ смешивать" ?
Да, ...общий смысл: "если все компоненты RGB маски равны 0 (черный цвет), значит абсолютная прозрачность, смешивать НЕНАДО." ...просто написано обратным условием. Прямое условие "если ВСЕ компоненты маски = 0, то НЕ смешивать" будет верным.

Цитата:
Сообщение от alexBlack
...обработка идет по 4 байта, а не по три. (можно обрабатывать по 8 байт - время уменьшается до ~1.4) Здесь нужно еще подумать. Или сделать размер текстур кратным 4-м или дополнительно обрабатывать оставшиеся байты.
Если прирост скорости оправдает увеличение текстур до нужной кратности, тогда вариант годится.

Цитата:
Сообщение от alexBlack
Просто умножение на 0 дает 0
и ничего не вносит в исходную картинку. Это не соответствует исходному условию
при котором смешение не производится, если хотя бы один цвет =0.
не вносит, значит ничего не делает, а ресурс кушает, нужно отсечь. ...только не "если хотя бы один цвет = 0" , а все разом.

Спасибо за старания, очень ценю!
Руководитель проекта MMO 2D RPG: Настоящее имя Денис Стрижак (10.05.1981-6.02.2019) Мир духу его

Последний раз редактировалось Beermonza; 16.05.2008 в 00:17.
Beermonza вне форума Ответить с цитированием
Ответ


Купить рекламу на форуме - 42 тыс руб за месяц

Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск


Похожие темы
Тема Автор Раздел Ответов Последнее сообщение
Уроки по созданию игр для новичков... -=DeS=- Gamedev - cоздание игр: Unity, OpenGL, DirectX 750 14.11.2017 20:26
Музыка программистов - как вы относитесь к АРИИ? Весёлый Жека Свободное общение 46 10.10.2008 22:32
Конкурсы по созданию игр на Delphi mutabor Свободное общение 0 15.06.2007 12:40
Работа по созданию ПО remix Фриланс 3 22.04.2007 11:00