Как Вы относитесь к созданию игр на Delphi?

[Beermonza]

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

Основная проблема к-рую можно предвидеть уже сейчас, тормоза на слабых процессорах. Чего не было бы с поддержкой видеокарты, можно было бы нехилый запас сделать. Процессоры насколько я заметил, выводят GDI графику неадекватно, по марке не угадаешь, Атлоны старые вроде хорошо справляются.

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

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

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

Насчет приватного контекста. Пробовал CS_OWNDC - так и не понял в чем разница. В справочнике написано, что его можно не удалять после вызова WMPaint, но не понял как это можно проверить.

Если не путаю, на современных компах позволительно задавать общий контекст один раз при создании окна и удаление его после закрытия. В режиме CS_OWNDC достаточно только создать приватный контекст, а удалится он сам после завершения передачи данных, ...опять же, если правильно понимаю.

[mutabor]

Я сейчас не использую ни PaintBox, ни Image, ...рисую сразу на содержимое формы

Для меня ценность PaintBox'а в собственных координатах. Когда кроме области вывода графики на форме есть еще какие нибудь кнопки-панели, особенно сверху, он полезен. А так я тоже всегда прямо на форме рисую, когда окно целиком под графику. Правда я по простому, через канву )

[Beermonza]

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

Если позволите, предложу вместе подумать над алгоритмом построения кадра, в частности - отрисовкой текстур с учетом выхода за пределы экрана. Наверняка можно сделать эффективнее.

[alexBlack]

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

Если позволите, предложу вместе подумать над алгоритмом построения кадра, в частности - отрисовкой текстур с учетом выхода за пределы экрана. Наверняка можно сделать эффективнее.

А можно подробней постановку задачи ?
- Как это сделано сейчас ?
- и кадр и текстура - это ссылки, полученные вызовами CreateDIBSection ? и нужен аналог bitBlt для этих структур ?

[Beermonza]

Текстуры - это обычные 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;

Будем думать?

[alexBlack]

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

Будем думать?

Да, будем.
................................... ............................
Предложения и вопросы в readme.txt

[Beermonza]

Сообщение от alexBlack (readme.txt)

Блок с вычислением координат. ... Непонятен принцип. Что там с ячейками и константами 12/24.
Этот блок можно не менять, т.к. время выполнения мало.

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

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

Сообщение от alexBlack (readme.txt)

Используется только этот алгоритм или есть еще и другие варианты и
придется переделывать каждый ? Откуда такая формула и можно ли ее
записать по-другому ?

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

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

[alexBlack]

По поводу 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]

Добил ассемблерные вставки. Выводы:
Исходный вариант (время выполнения ~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 генерирует код лучше меня

[Beermonza]

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

Она может и широко известна в узких кругах, но я с ней не сталкивался.
Видел другой вариант - см.ниже. Если не трудно, приведите и исходную формулу. Будет больше простора при реализации на ассемблере.

Вот такой я ее видел неоднократно:

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" , а все разом.

Спасибо за старания, очень ценю!