Скорость рисования и остальная скорость

[Ulex]

пробовал и так и эдак, ...рисовал в память видеокарты из ОЗУ, но что-то увидел загрузку под потолок и успокоился, и это на Pentium 4

Не, ну под потолок быть не должно. У меня различия с BitBlt где то фпс 200 против 160 не в пользу Direct_a. Это на поверхностях. Надо попробовать ещё на текстурах чё-нить сделать, но это возни много (опять матрицы, вершины ну и понеслась). Главное, скорей всего, результат такой же печальный будет.
Ещё есть такая идея, на грани фола. Собственно, то, что .pixel где то в этой теме говорил уже. Обновлять не весь экран, а только необходимую область. Лично я только так побеждал GDI на Celerone. Но это уже мухлёж.

По поводу DirectDraw у меня чёт осадок какой то остался, связаннный с оконным режимом DDraw. Сабжа не помню, но осадок стойкий.

P.S.
Аааа.., опять расстройство сплошное. Запустил свою DirectX поделку на ноуте - не работает. Тьфу, всё, плюнул, пошёл спать.

[Beermonza]

Ulex, странно, что у тебя настроение падает от сложных задач, ...у меня, так наоборот азарт еще больше проявляется, чем сложнее задача

Нашел наработки на DirectDraw, ...они так же на ноутбуке не запустились, очевидно, что-то с инициализацией происходит после выхода на режим, foolscreen срабатывает и все, черный экран до нажатия Esc. Normal не работает.

На счет грани, ...что предлагал .pixel, ...2 года назад эту тему мы перерыли вдоль и поперек. Выяснилось, что перерисовка большого куска, т.е. всего буфера занимает меньше времени, чем его частичное обновление, в котором участвует даже 2/3 поверхности. Такой способ хорош для аркад, а для изометрии неприемлем совершенно, обновлению подчас подлежит весь буфер и определять сегменты и работать с ними является "действиями ради действий", выигрыша никакого. Только в отдельных случаях, которых в изометрии крайне мало.

А вот тест с Direct3D заработал, там тоже можно работать со спрайтами, ...интересен как подмена вывода от GDI, так же как и OpenGL, ...суть будет в том, чтобы готовую собранную подложку кидать по надобности в видеопамять, и пусть она там остается, чтобы не перекидывать постоянно ее в буфер кадра, ...затем так же перекидывается второй буфер, но уже с частотой анимации (30 кадров), с альфа-каналом. Надеюсь, смикшировать и вывести на экран аппаратными средствами видеокарта сможет быстрее. От нее потребуется только это. Тогда GDI отбрасывается. Подготовку кадров и подложки буду вести по прежнему в ОЗУ через MMX.

[Ulex]

Настроение падает не от сложных задач, а от нудных. Когда вроде всё сделал, отладил, получил приемлемый результат. Запускаешь на другой машине и обламываешься. И начинается всё заново.

На счет грани, ...что предлагал .pixel, ...2 года назад эту тему мы перерыли вдоль и поперек. Выяснилось, что перерисовка большого куска, т.е. всего буфера занимает меньше времени, чем его частичное обновление, в котором участвует даже 2/3 поверхности. Такой способ хорош для аркад, а для изометрии неприемлем совершенно, обновлению подчас подлежит весь буфер и определять сегменты и работать с ними является "действиями ради действий", выигрыша никакого. Только в отдельных случаях, которых в изометрии крайне мало.

Ну я не знаю как вы её перерыли. Вот как раз в аркаде, где много подвижных и перекрывающихся объектов, этот метод может налажать. А в РПГ чему особенно меняться? Зашёл персонаж на локацию. Сколько то там на этом поле анимаций проигрывается, а остальное всё статично. Если он бегает по платцу, то скролл карты, но это не каждый кадр.

...затем так же перекидывается второй буфер, но уже с частотой анимации (30 кадров), с альфа-каналом. Надеюсь, смикшировать и вывести на экран аппаратными средствами видеокарта сможет быстрее.

А что есть второй буфер? Его размерность? Смикшировать то видеокарта сможет быстрее, а вот закидывать в неё буфер 30 раз в секунду быстрее может и не получиться. У меня по крайней мере пока не получилось.

[.pixel]

А что если в момент, когда готовый кадр копируется на форму

Как я понимаю примерно такой код отвечает за копирование…

// контекст главной формы
DCs := GetDC(Form1.Handle);
BitBlt(DCs,0,0,W, H ,ZoneBitmap.Canvas.Handle,0,0,SRCCOPY);
ReleaseDC(Form1.Handle, DCs);

Заменить на…

// контекст главной формы
DCs := GetDC(Form1.Handle);

memcpy(???) 

ReleaseDC(Form1.Handle, DCs);

и лучше даже, если он заработает попробовать написать для этого дела свой memcpy на базе mmx чтобы копировать сразу 64 бита а не 32, если это возможно конечно)

По поводу DD7
на старых компах уже присутствует такая «фишка» как DMA (Direct Memory Access) средствами DD надо просмотреть, на что способна видео карта. И с какими DMA она дружит. В случае поддержки блиттинг(SRCCOPY raster operation) по идее будет производиться без нагрузки на CPU.

[Пепел Феникса]

Заменить на…

винда не дает указатель на данные окна!
это дело подсистемы GDI.

[.pixel]

винда не дает указатель на данные окна!
это дело подсистемы GDI.

Эх... обидно досадно, но ладно)
...а dd7 такое прокатывает ... и быстрее BltFast'a работает)

void SurfacesCpy( LPDIRECTDRAWSURFACE7 pDest, LPDIRECTDRAWSURFACE7 pSrc ) 
{
	DDSURFACEDESC2 ddSurfaceDesc;
	DDSURFACEDESC2 ddSurfaceDesc2;
	HRESULT hRet;

	ZeroMemory(&ddSurfaceDesc,sizeof(ddSurfaceDesc));
	ddSurfaceDesc.dwSize=sizeof(ddSurfaceDesc);
	ZeroMemory(&ddSurfaceDesc2,sizeof(ddSurfaceDesc2));
	ddSurfaceDesc2.dwSize=sizeof(ddSurfaceDesc2);
	//pDest->BltFast (0,0, pSrc, NULL, DDBLTFAST_WAIT);

	hRet = pDest->Lock(NULL,&ddSurfaceDesc, DDLOCK_SURFACEMEMORYPTR | DDLOCK_WAIT,NULL);
	if(!FAILED(hRet))
	{
		pSrc->PageLock(0);
		hRet = pSrc->Lock(NULL,&ddSurfaceDesc2, DDLOCK_SURFACEMEMORYPTR | DDLOCK_WAIT,NULL);
		if(!FAILED(hRet))
		{
			UINT surfaceWidth=ddSurfaceDesc2.lPitch;
			UINT surfaceHeight=ddSurfaceDesc2.dwHeight;
			memcpy((char*)ddSurfaceDesc.lpSurface, (char*)ddSurfaceDesc2.lpSurface, (surfaceWidth*surfaceHeight));
			pSrc->Unlock(NULL);
		}
		pSrc->PageUnlock(0);
		pDest->Unlock(NULL);
	}
}

[Beermonza]

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

Настроение падает не от сложных задач, а от нудных. Когда вроде всё сделал, отладил, получил приемлемый результат. Запускаешь на другой машине и обламываешься. И начинается всё заново.

Все с тобой ясно ...а я люблю монотонную, муторную ("нудную") работу.

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

Ну я не знаю как вы её перерыли.

Дай боже памяти, ...в теме "Как вы относитесь к созданию игр на Delphi?" ...где-то в центре, ...номера к сожалению не скажу, там жутко много постов.

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

Вот как раз в аркаде, где много подвижных и перекрывающихся объектов, этот метод может налажать. А в РПГ чему особенно меняться? Зашёл персонаж на локацию. Сколько то там на этом поле анимаций проигрывается, а остальное всё статично. Если он бегает по платцу, то скролл карты, но это не каждый кадр.

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

Что в аркаде? ...плоскость, есть задник, есть координаты объекта, ...фон статичен, бери его, ложи позади, и сверху текстуру объекта. Т.е. сначала латачный ремонт фона, по предыдущему положению объектов, затем новые анимации на новых местах.

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

А что есть второй буфер? Его размерность? Смикшировать то видеокарта сможет быстрее, а вот закидывать в неё буфер 30 раз в секунду быстрее может и не получиться. У меня по крайней мере пока не получилось.

Первый буфер - подложка (задний фон), он 1200х800, это 2,7М, ...второй буфер - это сборка всех объектов с их альфа-каналами, в ОЗУ все кадры, а сборка весит так же 2,7М + маска 0,9М. Все упирается в память видеокарты, 32М если попадется то "ой!". Если 128М, то можно все текстуры кинуть в видеопамять, тут уже точно DirectX, и вся канитель и цель коту под хвост.

Сообщение от Пепел Феникса

винда не дает указатель на данные окна!

Вот именно, я бы уже рылся по ее указателю, ...а так приходится на фанерке (TBitmap) рисовать, затем ее туда кидать (BitBlt).

.pixel, memcpy - аналог в Delphi, я так понимаю, CopyMemory, Copy, Move, и там ассемблер по 4 байта за такт. Вот это быстрее:

     asm
        push esi
        push edi

        mov ecx, BufLengthDiv  // длина данных кратная 8-и
        mov esi, PointerBuf      // указатель на источник
        mov edi, PointerZone   // указатель на приемник

      @jj:
        movq      mm0, [esi]     // buf -> в регистр
        movq      [edi], mm0     // zone <- из регистра

        add esi, 8
        add edi, 8

        dec ecx
        jnz @jj

        pop edi
        pop esi

        emms
      end;

...и еще быстрее с SSE по 16 байт за такт.

[Ulex]

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

Давай поясню. "Статично" - не сюда.

Если всё так объёмно, то я тогда вообще не понимаю на что ты рассчитывал на 3-их Celeron_ах?

Мне сейчас ещё одна идея в головёшку пришла. Ты её конечно раскритикуешь (и будешь прав), но тем не менее, надо высказать. Идея заключается в том, что в видеопамяти создаётся две-три поверхности. Одна - это задник, размером соответственно равная BackBuffer_у. И ещё одна-две вспомогательные (большого размера). И построение кадра делится на два этапа.
Этап первый - подготовка всех поверхностей, необходимых для отрисовки конечного кадра - это выполняет CPU. На этом этапе во вспомогательную поверхность сливаются все необходимые кадры анимаций объектов (если кадр анимации нужен для отрисовки более чем одного объекта, он всё равно копируется в видеопамять один раз). И тут надо придумать какую-то систему (типа банка) хранения инфы по этим поверхностям (какая пов, какому объекту принадлежит и т.д.).
Этап второй - непосредственно рисование кадра - это выполняет GPU (DirectX). В соответствии с логикой находятся объекты, которые надо рисовать, находятся соответствующие им куски вспомогательной поверхности в видеопамяти (а они уже туда загружены на первом этапе) и копируется всё это внутри видеокарты.
Фух. Написал. Вот как то так. Можешь критиковать. Опять сейчас скажешь, что тебе нужны все кадры анимаций и сразу? По Станиславскому - не верю.

Кстати, специалисты по Direct_у. Подскажите кто, как разогнать (настроить, инициализировать) девятый DX чтобы он пустую сцену крутил хотя бы 1000 раз в секунду. У меня опять в VSYNC (fps=60) упёрлось. И больше выжать из него не могу. Какую то установку забыл сделать? Восьмой DX нормально так крутит пустой экран на 1000 fps, а девятый не хочет. Вот с такими параметрами я восьмой инициализирую. А чего девятому нужно?

	invoke	Direct3DCreate8, D3D_SDK_VERSION
	mov	PD3D, eax
	
	d3d8	GetAdapterDisplayMode, PD3D, D3DADAPTER_DEFAULT, addr [d3ddm]

	mov	eax, [sizeXclient]
	mov	[d3dpp.BackBufferWidth], eax
	mov	eax, [sizeYclient]
	mov	[d3dpp.BackBufferHeight], eax
	mov	[d3dpp.MultiSampleType], 0
	mov	[d3dpp.EnableAutoDepthStencil], 0
	mov	[d3dpp.AutoDepthStencilFormat], 0
	mov	[d3dpp.FullScreen_RefreshRateInHz], 0
	mov	[d3dpp.FullScreen_PresentationInterval], 0

	mov	eax, [hwndLOC]
	mov	[d3dpp.hDeviceWindow], eax	
	mov	[d3dpp.Windowed], 1
	mov	[d3dpp.SwapEffect], D3DSWAPEFFECT_DISCARD
	mov	eax, [d3ddm.Format]
	mov	[d3dpp.BackBufferFormat], eax
	mov	[d3dpp.BackBufferCount], 1
	mov	[d3dpp.Flags], D3DPRESENTFLAG_LOCKABLE_BACKBUFFER

	d3d8	CreateDevice, PD3D, D3DADAPTER_DEFAULT, D3DDEVTYPE_REF, [hwndLOC] ,\
                D3DCREATE_SOFTWARE_VERTEXPROCESSING, addr [d3dpp], addr [pdev]

[Beermonza]

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

Если всё так объёмно, то я тогда вообще не понимаю на что ты рассчитывал на 3-их Celeron_ах?

Я рассчитывал на Pentium 4, а за Celeron'ы искренне надеялся, что они не умрут, приняв такую нагрузку на свои плечи, в принципе не ошибся сильно, что-то еще работает.

Чтобы ты поверил в надобность такого объема памяти (15М) на один тип дерева, покажу в миниатюре раскадровку (смотри картинку). Сам спрайт 5460х1000х24bit а в модели дерева 1,5 млн. полигонов, ...такое в 3D быстро "шевелить", даже в единственном экземпляре, не в состоянии ни одна из доступных в продаже современных машин, ...а в 2D это с легкостью реализуется, нужна только память.

Метод, который ты высказал, я вот постом выше описал, ...что все текстуры в кадр и подложку накладывает процессор, кадры объектов хранятся в ОЗУ, а видеокарта микширует задний фон с готовым кадром по его альфа-каналу. Задний фон собирается только когда персонаж переступил в соседнюю клетку, а до той поры задний фон просто смещается по пикселям, ...в этой связи оказывается просто лишним каждый раз переносить подложку в буфер кадка, видеокарта сама положит под низ этот сборный фон. Процессор будет заниматься только сборным кадром объектов и отправлять в видеопамять готовый слой объектов с альфа-каналом. Уж это будет по-любому быстрее того, что сейчас есть.

[.pixel]

Beermonza, аха) я это и имел ввиду, такой способ копирования с помощью 64-битных mmx регистров, ну а sse - 128 бит просто сказка))

Ulex, по-моему у тебя…

mov	[d3dpp.FullScreen_PresentationInterval], 0

а лучше задать, как D3DPRESENT_INTERVAL_IMMEDIATE, а ты задаешь дефолт интервал.

D3DPRESENT_INTERVAL_DEFAULT This is equivalent to D3DPRESENT_INTERVAL_ONE.
D3DPRESENT_INTERVAL_ONE The driver will wait for the vertical retrace period (the runtime will "beam follow" to prevent tearing). IDirect3DDevice9::Present operations will not be affected more frequently than the screen refresh; the runtime will complete at most one IDirect3DDevice9::Present operation per adapter refresh period. This is equivalent to using D3DSWAPEFFECT_COPYVSYNC in Microsoft® DirectX® 8.1. This option is always available for both windowed and full-screen swap chains.


#define D3DPRESENT_INTERVAL_DEFAULT 0x00000000L
#define D3DPRESENT_INTERVAL_ONE 0x00000001L
#define D3DPRESENT_INTERVAL_TWO 0x00000002L
#define D3DPRESENT_INTERVAL_THREE 0x00000004L
#define D3DPRESENT_INTERVAL_FOUR 0x00000008L
#define D3DPRESENT_INTERVAL_IMMEDIATE 0x80000000L