[no bug] core::round32 .. ?

[Ulf]

This is a bug.
I don't know how it's been like this the whole time!

Code: Select all

core::round32(1.5) = 2

core::round32(-1.5) = -1

Is that a bug or what?

It must be a bug if

Code: Select all

core::round32(-1.51) = -2

Now tell me I'm a genius or an idiot...

This is a fix for it (if I am correct and I can't see how I am not hehe)

Code: Select all

inline f32 round_( f32 x )
{
	if (x < 0.f)
		return - floorf( -x + 0.5f );
	return floorf( x + 0.5f );
}

I don't know how to fix the assembly (fast math) version. I could probably work it out as I have done some assembly before.

[DavidJE13]

it's not a bug. Rounding has several possible "tie breakers" (see http://en.wikipedia.org/wiki/Rounding#Tie-breaking )
The "round half up" variant is the best to use in general, because round( x + n ) should be equal to round( x ) + n as long as n is an integer. example:

current method:
round( -1.5 + 2 ) = round( 0.5 ) = 1
round( -1.5 ) + 2 = -1 + 2 = 1

your method:
round( -1.5 + 2 ) = round( 0.5 ) = 1
round( -1.5 ) + 2 = -2 + 2 = 0

[hybrid]

Yes, there are things like "round towards zero", "round by chop", "round towards larger", ... And no, you're not a genius just because you find a bug, whether it's a real one or not.

[Ulf]

@hybrid.. it's ok. I'm not serious.

I was about the bug, not my genius. I keep that hidden under my insanity.
But, you could have at least humored me and said I was an idiot. Thanks for nothing.

@DavidJE13
Thanks. I understand that.

I came upon the idea because I was having issues with my rotation for the software drivers.
Working out when to round, ceil, or floor the result is mucking me up.

My rotation now finally is set up correctly with the correct usage of sourceRect and destRect, and it draws very close to perfect now (I know I said that before.. but now it is), Now there is a half pixel or so off on some of the pixels but not most.