12 Aug 2015
Hey there, I’m smoogipooo and I’ll be hosting your daily progress report for today.
As osu! moves forward with OpenGL one of the biggest challenges we face is maintaining compatibility for older systems. With osu! and especially with OpenGL we strive to maintain compatibility until the statistics show that >99% of the userbase won’t be impacted by a change. Statistics have shown that this is not the case for the move to OpenGL, and we have also received numerous reports of OpenGL not working well on specific systems.
All the problematic systems had one common trait - the GPU manufacturer’s drivers were not installed and the only Display Adapter in the Device Manager was the Microsoft Basic Device Adapter and likewise gl_info.txt showed GDI Generic as the renderer. We realized that the problems indicated that osu! was being rendering through software. Upon diving into OpenTK I found that while all the graphics contexts had the GENERIC_FORMAT flag, none of the graphics contexts had the GENERIC_ACCELERATED flag which is required to obtain hardware acceleration. This type of acceleration is called MCD acceleration, and surprisingly enough Quake 3 managed to obtain MCD acceleration for reasons still unknown to me (black magic?).
For some cases it is enough to alert the users to install their drivers, however for many other cases the driver is incompatible with the user’s Operating System. Unable to reach a solution to this, a few days ago I mentioned the possibility of translating OpenGL to DirectX as DirectX is supported by Microsoft and compatibiliy won’t be a problem. Upon looking at how Google Chrome and Mozilla Firefox do WebGL I was directed towards ANGLE which seems to provide exactly this translation.
Well… Not exactly - there are a few caveats:
- All OpenGL code must be changed to OpenGL ES 2.0, as ANGLE only supports ES 2.0 and 3.0.
- This means that there is absolutely no fixed-function pipeline and everything must be vertex buffered - there is no immediate mode. osu! still uses the fixed-function pipeline for many of its core functions.
- Slider rendering must be completely rewritten as they made extensive use of the fixed-function pipeline.
- Vertices must be buffered and sprites must be batched in order to achieve the same level of performance as Cutting Edge. Tom94’s recent efforts with this has brought performance above Cutting Edge on the OpenGL renderer!
- This also brings us closer to fixing sliders however we will explore slider rendering through shaders to further improve performance.
- Shaders need to be rewritten to conform to both OpenGL ES and DirectX standards, complete with loop unrolling. Bloom is currently working but I haven’t had as much success with blur.
- The shader framework has also undergone quite a few changes to accommodate their new usage throughout the game.
This is not a replacement for OpenGL and will be offered as a compatibility mode only for systems that can’t otherwise obtain a hardware accelerated renderer through OpenGL. OpenGL will provide better performance than DirectX through ANGLE and will remain as our choice of graphics library.
The project is currently in its final stages - buffering and batching are working, shaders are mostly working and most primitive elements are drawing. Buffering and batching everything is already cleaning up the codebase quite nicely so we’re enthusiastic about that too. All that’s left is to fix up sliders and clean-up any remaining code. I leave you with a pretty nice (in my opinion) effect I discovered after the red and blue channels of textures were inverted: