"64bit color (Billions of colors)"
Is there any point when most people now are using 24bit lcd's (some are 18bit)
That's developers fault, using AF to make roadsigns/marks not blurry is like using a nuke to kill some flies
64bit color (Billions of colors) vs. we have 32bit (16 millions), I know Linux has in their software 64bit, but I like to see in hardware.
Something like this "resolution" 2560x1600x64bit
"Future" hardware won't give you either/both. Someone needs to write a better software algorithm for the first while the second simply is too time-costly for software artists (i.e. current HW triangle rates is safely ahead of software demands).better lighting
more geometry
"Cost-free" things that are not free are a bad idea... to quote a friend, "sure we can give you free 16x anisotropic filtering, but you're not going to like the speed of bilinear"cost-free 16x AA (ala Xenos' 4x AA)
You should get to know Kristof...."Cost-free" things that are not free are a bad idea... to quote a friend, "sure we can give you free 16x anisotropic filtering, but you're not going to like the speed of bilinear"
64bit color (Billions of colors) vs. we have 32bit (16 millions), I know Linux has in their software 64bit, but I like to see in hardware.
Something like this "resolution" 2560x1600x64bit
How about this: high precision internal framebuffer - > fast, error dispersion dithering -> 24 bpp on screen?
aka GS stage?HW support for tree-structured threading (allow a thread to spawn threads)
why not what we can have right now? FP16 framebuffer -> tone mapping algorithm -> 30bpp on screen