Tracking issue: Emulation rendering

[CodingRays]

Tracking issue for the emulation rendering system.

Questions

• How much do we actually want this system to support? If we want to properly support everything were basically building OpenGL in vulkan. If not many mods or Minecraft features wont properly work.
• How much OpenGL state do we need to track? Currently only depth write enable is tracked.
• How do we track uniform values? Minecraft uses a mix of updating them on each draw call and keeping them between calls. This makes this really messy as there is no single way we can track everything. It also means that we have to update everything every draw call since we cant know if something has changed or not.
• Do we need to support new uniforms for example for mods? This would be hugely complex i don't think this is worth it.
• Can we get away with not supporting updating global objects during a frame? If we cant the render code would massively increase in complexity and probably require a partial rewrite.
• Minecraft has a lot of places where it handles textures differently. Where and how do we inject?
• Minecraft uses a single class for both VBOs and immediate meshes how do we cleanly inject into that?
• Currently Minecraft seems to update some uniforms outside of the main render function. What is the deal with that?
• How do we detect and eliminate any post processing Minecraft attempts to do?

Problem description

Minecraft heavily relies on OpenGL state to render and has no high level abstraction which we could inject into. This also means that many mods directly use low level OpenGL abstraction. Therfore we need to track OpenGL state and pipelines and emulate some subset of it.

This is heavily dependent on how much we want the emulator renderer to support. Ideally we would want to do as much rendering as possible in dedicated systems however having a powerful fallback system would be very useful to deal with updates or to support mods.

Current progress

At the beginning of a frame a new emulator frame is also started. During Minecrafts render function any draw calls, state changes or other actions will be recorder into the emulator frame and processed asynchronously. After all of Minecrafts render code has executed the frame is ended and the emulator will submit it for execution.

The current system uses a single render pass drawing to a single framebuffer. This massively simplifies the system as all we need to worry about is shaders and pipeline state. However it makes emulating any post processing or more advanced rendering impossible. Considering the complexities of doing a more powerful emulation i don't think its worth it doing any more than this.

Immediate meshes are uploaded in a special buffer which is reset and reused each frame.

Textures and VBOs must persist between frames. Therefore they are represented by "global objects". Because of the single render pass used for drawing changes to global objects must happen before or after rendering a frame. To enable this any changes made during a frame will either be reorderd before or after the frame depending on if the global object has been used already in the frame.

All uniforms Minecraft uses are collected into a single collection of descriptor sets and shared between all shaders. Any uniforms not used by Minecraft is not supported. Every time a draw call is made a new copy of all the descriptors needs to be created.