Jump to navigation Jump to search
In KOS there are three major ways of drawing things on the screen.
Software rendering means drawing is performed using the Dreamcast's "SH4" CPU only, not the "PVR" graphics chip. After configuring the video screen you can write to the screen's memory area directly.
- Flexible: You can emulate a simple blitter, an NES-like sprite renderer, a raytracer, a photon mapper and other methods the Dreamcast graphics chip doesn't support.
- You have to implement a complete renderer yourself
OpenGL is a cross-platform graphics programming interface. Earlier implementations of OpenGL in KOS were slow and incomplete, but recent work by PH3NOM and kazade over the past years have culminated in the much more performant GLdc.
- Cross-platform: OpenGL code written for the Dreamcast should mostly work on other platforms as well (barring bugs which should be fixed) and vice versa, which makes porting existing software easier.
- Familiar: If you've programmed OpenGL before you will feel right at home. There are many tutorials and books outside of the DC homebrew scene.
- Fast: OpenGL is implemented as a thin layer on top of the low-level PVR API. It will be difficult to outperform it without in-depth PVR API/hardware knowledge and major effort.
- Only fixed-pipeline OpenGL version ~1.5 (no shaders) is supported due to hardware limitations, although some modern extensions are supported (e.g. FBO)
- Since the Dreamcast PVR graphics chip is a tile-based raycaster instead of the usual rasterizer approach (NVIDIA/ATI GPUs etc.), some operations don't map to OpenGL very well (e.g. multipass rendering should be used instead of the non-existant z-buffer, scissoring is awkward).
The PVR API is the low-level graphics programming interface in KOS for the PVR graphics chip. It exposes all the features the Dreamcast has to offer.
- Fast: For specific niche cases that the OpenGL API doesn't cover well you might be able to outperform it
- Direct access to all PVR graphics chip features. E.g. OpenGL has no concept for PVR "occlusion volumes".
- Lacking in features: The PVR API is very bare bones. You will have to implement basic functionality such as polygon clipping yourself.
- Non-obvious: There are many ways to do certain things like geometry submission and you will have to experiment a lot in order to obtain good performance.
- Learning curve: You have to learn a new API that is only used on the Dreamcast