7:48:28|3b|ACTION wonders if i'm doing something wrong, of these drivers really give me 16 bits/channel accumulation buffers and 4 aux buffers for pretty mcuh any pixel format that can draw to window
7:48:55|3b|(exceptions being the 16bit float formats and some non-accelerated ones)
7:54:22|3b|yeah, looks like glew 's visualinfo tool agrees
7:54:54|3b|wonder if it can lazily allocate them or something, or if ram is just cheap so might as well :p
8:03:10Shinmeramight be easier than having api switching internally to turn them on/off
8:04:44|3b|guess it could also make too many pixel formats too
8:08:18|3b|ACTION can almost pick pixel formats now though :)
8:08:31|3b|for some reason it thinks 2 samples is an exact match for 16 samples though :/
8:09:35|3b|ah, called wrong function to compare them
8:20:44|3b|this part would probably be the same for glx version or egl or whatever anyway
8:22:55|3b|though windows APIs will show up again if i decide to hook into DXGI stuff for swapchain stuff
8:24:14|3b|hopefully can avoid that for now, supposedly using fp16 framebuffer is enough to get HDR, which is the main thing i want out of it at the moment
8:24:46|3b|DXGI would add better frame timing, and possibly more stable HDR or something
8:25:25|3b|still need a few extra windows calls to do HDR properly though even without DXGI
8:35:28ShinmeraI was wondering why you were suddenly spending time on this stuff
8:35:52|3b|mostly just lack of energy, and it sounded at least somewhat interesting to have