Can we have ucent ?

[solidstate1991]

On Tuesday, 30 October 2018 at 18:07:23 UTC, Basile B. wrote:
> For the first time today i had needed the ucent type. 
> Fortunately it was only for bit operations so easy to do as a 
> struct, however this is two hours lost for a type that's in a 
> curious state (rename it shrodinger128 maybe ?).
>
> I think that the feature could be implemented as compiler 
> special functions that would be located in druntime (with 
> special case for GDC and LDC since the type exists in their 
> respective backend if i understand correctly).

I was toying with using SSE2 for bitwise operations, however it 
turned out to be a total waste of time. I was thinking on using 
it for pixel-precise collision detection, but was very unstable 
and prone to bugs, so I defaulted to the previous per-pixel 
detection method but kept the bitarrays for collision shapes.

If I ever going to use a multi-pixel approach, I'm going to do it 
on a per-byte basis: It's way easier on a small scale, especially 
if I put a very common restriction of that the sprites/tiles must 
be the multiple of 8. TransformableTileLayer already have the 
restriction of tile sizes must be the power of two for superfast 
division (through the bit-shift method) and modulo (through "& 
(divider-1)" method) operations.

I was also thinking on using 128bit approach on my LZHAM port, 
but the issue there is that it's very clunky to implement, 
restricted to certain processors and compilers (unless I want to 
go with a hard-to-debug assembly code), and the algorithm 
overhead might make it even slower than 32 or 64bit register 
usage.