движение точки на Canvas

[B_N]

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

.............а потом его содержимое копирую на канву процедурой Draw.

А я именно это и назвал "гонять туда-сюда битмапы". Такова, по крайне мере, сущность функции BitBlt, которую, очевидно, воплощает метод Draw.

[Sibedir]

А я именно это и назвал "гонять туда-сюда битмапы". Такова, по крайне мере, сущность функции BitBlt, которую, очевидно, воплощает метод Draw.

Ну тогда уж не туда-суда, а только сюда. А надо это, чтобы изображение не мерцало.

Вот, немного переделал под ваш вариант:Точки.zip
Главное вот здесь:

procedure TForm1.Timer1Timer(Sender: TObject);
var
  i: Integer;
begin
  with BM do begin
    Canvas.Brush.Color := Form1.Color;
    Canvas.Rectangle (0, 0, W, H);
    for i := 0 to C-1 do begin
      Points[i].X := (Points[i].X + Points[i].dX) mod W;
      Points[i].Y := (Points[i].Y + Points[i].dY) mod H;
      Canvas.Pixels [Points[i].X, Points[i].Y] := clWhite;
    end;
  end;
  Canvas.Draw (0, 0, BM);
end;

[st01en]

Ого, не думал что так много мнений.
Оговроюсь сразу что от реализации на DX или OpenGL я пожалуй воздержусь, всетаки это вспомогательная графика. Но на досуге всетаки попробую реализовать .

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

Если я правильно понял топикстартера, то задача сводится к:
1. С помощью GetPixel запомнить старый цвет точки.
2. С помощью SetPixel поставить новую точку.
3. По мере необходимости вернуть с помощью SetPixel старую точку и начать с п.1

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

что-то я не понял как вы меня поняли
Задача отобразить движение, я себе представляю движение так:
1. обьект отображается на новых координатах
2. обьект удаляется\затирается\etc. на старых координатах.

собственно говоря вопрос был в том что лучше делать в п.2
похоже что действительно легче перерисовать заново и не мучаться.

Sibedir, похоже действительно других вариантов не остается, спасибо.

Спасибо всем.

[B_N]

Ха! Ну и как Вы себе представляете это "2. обьект удаляется\затирается\etc. на старых координатах."?

Всю жизнь рисование движущихся объектов складывалось из:
1. Сохранить часть фона, на которой мы будем рисовать объект.
2. Нарисовать объект.
..............................
3. Вернуть сохраненную ранее часть фона на место.

Если объектов много или фон динамический, значит п.1 не используем, а вместо этого держим фон offscreen, но копируем, тем не менее, только "грязные" его части. А ворочать битмапы размером в мильон-другой пикселов это, знаете...

[st01en]

Ок, я же говорил, что в этом не силен.
Покажите, плс, на примере кода, мне так легче доходит чем на словах .

Спасибо.

[mutabor]

B_N прав, но все же это больше относится к оптимизации, вовсе не обязательно перерисовывать только необходимые части, можно и целиком весь фон перерисовывать. Так намного проще будет. Для современного процессора эти мильоны пикселей как семечки, современный я имею ввиду хотя бы выше 1 ГГц.
Алгоритм вы в принципе знаете. Даже про мерцание вам рассказали.

[st01en]

Да, спасибо. Насчет полной перерисовки я и так практически в первую очередь подумал, про рисование сначала в буфере тоже когда-то читал. Я собственно спросил потому что считал, что это довльно медлено будет(стыдно признаваться на самом деле лень было попробовать). Похоже что пока иммено так и реализую, а попозже попытаюсь понять и реализовать то, что B_N сказал
До вечера еще немножко поколдую и наверно создам еще одну темку, а то как-то сильно громоздко у меня данные обрабатываются.

[Sibedir]

2 B_N

Всю жизнь рисование движущихся объектов складывалось из:
1. Сохранить часть фона, на которой мы будем рисовать объект.
2. Нарисовать объект.
..............................
3. Вернуть сохраненную ранее часть фона на место.
Если объектов много или фон динамический, значит п.1 не используем, а вместо этого держим фон offscreen, но копируем, тем не менее, только "грязные" его части. А ворочать битмапы размером в мильон-другой пикселов это, знаете...

Я прошу прощения B_N, но я с вами не согласен, да и с вами mutabor. Какая же это оптимизация. Кстати, эти вещи с битмапом я проделывал еще на PIII 400 МГц. Ни каких тормозов.
Поправте меня, я наверное вас не так понял.

1. Сохранить часть фона, на которой мы будем рисовать объект.

Куда и как? Как регион что-ли? Так это еще дольше. Как прямоугольные области? Быстрее только если мало движущихся объектов. И как сохранять фон, если он окажится не статичен. Ну тут я еще соглашусь. Мона ченить придумать. Но та ситуация, что возникает с п.3 делает п.1 не нужным.

2. Нарисовать объект.
3. Вернуть сохраненную ранее часть фона на место.

Ну вопервых логичнее было бы сначала нарисовать фон, а потом объект. А то если смещение объекта будет меньше самого объекта произойдет наложение фона на объект.
И вообще, что вы делаете, если на том месте куда вы возвращаете фон находится еще один движущийся объект. Вы ж его затрете
До и После.JPG

[B_N]

2 Sibedir

Ну не согласны, так не согласны, что же делать.....
Только перед тем, как спорить, спрофилируйте вот такой кусочек, хотя бы даже по-простому, с GetTickCount():

	DWORD dw1, dw2, dw3;
	long x, y;
	HDC dc = ::GetDC(this->m_hWnd);
	HDC memdc = ::CreateCompatibleDC(dc);
	HBITMAP hBmp = ::CreateCompatibleBitmap(dc, 640, 480);
	HBITMAP hOldBmp = (HBITMAP)::SelectObject(memdc, hBmp);


	dw1 = GetTickCount();
	for(long i = 0; i < 100; i++) ::BitBlt(memdc, 0, 0, 640, 480, dc, 0, 0, SRCCOPY);
	dw2 = GetTickCount() - dw1;

	dw1 = GetTickCount();
	for(long i = 0; i < 10000; i++) 
	{
		x = rand() % 640;
		y = rand() % 480;
		::BitBlt(memdc, x, y, 32, 32, dc, x, y, SRCCOPY);
	}
	dw3 = GetTickCount() - dw1;


	::SelectObject(memdc, hOldBmp);
	::DeleteObject(hBmp);
	::DeleteDC(memdc);
	::ReleaseDC(this->m_hWnd, dc);

Если неохота, могу сказать, что в переменной dw2 - 130, а в dw3 - 70 (это на PIII-500), т.е. второй цикл, который выполняется в сто раз больше раз, работает (над маленькими кусочками, разумеется) в два раза быстрее... Да, а что за процессор такой, PIII-400, не подскажете? Быстрые процессоры и графплаты делают не для того, чтобы писать неоптимальные алгоритмы. А вторую часть Ваших возражений я вообще не понял... Вы мне возражаете, или соглашаетесь по пунктам 1. и 3.? Я ведь там написал, когда какой из них не нужен, а Вы мне возражаете моими словами...

[mutabor]

Я прошу прощения B_N, но я с вами не согласен, да и с вами mutabor. Какая же это оптимизация. Кстати, эти вещи с битмапом я проделывал еще на PIII 400 МГц. Ни каких тормозов.

Самая обыкновенная оптимизация
Ответьте на такой вопрос. Что быстрее нарисуется: большой битмап, или несколько маленьких его кусков?

А 1 ГГц, это я так, приблизительно сказал. На пятистах может и не тормозит, но согласитесь процессорного времени поболее кушает, чем на двух тысячах.