[Samodelkin]

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

всё очень печально
Запускал только-что на пентиуме вариант без пола и потолка - 4 кадра в секунду (если в обзор попадает спрайт - 3 кадра)
Комп как бы намекает, что это всё плохая затея.

Ну как я уже выше написал мой код расчитан на новое железо и хорошую графику

Попробуй вот так (код я не проверял и не компилировал):

uint32_t fog( const uint32_t inColor, const uint32_t rayLen, const uint8_t factor ) {
	uint16_t color[ 3 ];
	color[ 0 ] = ( char )( inColor >> 8 );
	color[ 1 ] = ( char )( inColor >> 16 );
	color[ 2 ] = ( char )( inColor >> 24 );

	if ( rayLen < ( 256 << factor ) - 256 ) {
		color[ 0 ] += ( rayLen >> factor );
		color[ 1 ] += ( rayLen >> factor );
		color[ 2 ] += ( rayLen >> factor );
		if ( color[ 0 ] >= 256 ) color[ 0 ] = 255;
		if ( color[ 1 ] >= 256 ) color[ 1 ] = 255;
		if ( color[ 2 ] >= 256 ) color[ 2 ] = 255;
		uint32_t outColor = 0;
		outColor |= ( ( ( char )color[ 0 ] ) >> 8 );
		outColor |= ( ( ( char )color[ 1 ] ) >> 16 );
		outColor |= ( ( ( char )color[ 2 ] ) >> 24 );
		return outColor;
	} else {
		return 0xffffff00;
	}
}

factor сначала задавай 0, а потом 1 и выше до 7 включительно.

Тут главное не напутать с форматом цвета. Например согласно little endian 4 байтное число 0xaabbccdd на самом деле записывается в память в обратном порядке - ddccbbaa. Таким образом при преобразовании типа, например в 2 байтное число оно превратится в ddcc, то есть 0xccdd если в нормальном представлении. Так что я код написал что у тебя в памяти идет ARGB в таком порядке, то есть в 4 байтном числе это 0xBGRA. Однако операторы сдвига как раз работают с числами в нормальном представлении, то есть для числа 0xaabbccdd если применить >> 24 то будет ожидаемое aa, а не какое то значине справа от числа, так что я просто написал чтобы было понятно как работает внутри

Да кстати расширение mmx (а также sse в более новых машинах) может работать с упакованными значениями - и видимо они здесь как раз кстати подойдут, но я пока сам так еще не делал.