Game development - good performance rendering graphics like the SNES
With past projects, it was default for me to think that to obtain a good rendering performance, even for 2D games, was to use GPU-based rendering. It is the default to think that for almost everyone if you search on the internet. Well, but I was frustrated and I could no accept that. I implemented a software-based system for rendering graphics inspired by the SNES and obtained very satisfying results. Of course, rendering on the SNES is hardware-based, but with modern CPUs, I could not believe that software rendering could not reach the performance of the SNES. The system that I implemented, which is tile-based, can draw 16 layers, each with 30 x 20 tiles (600 tiles in each layer, 9600 tiles total), and each tile with 16 x 16 of size, and the frame rate is still 60 frames per second. It is much more than what I expected on an average laptop (processor Intel i3), so it is a good thing. I am currently using it to make an unannounced game, and I will keep this system for future projects.
It is worth noting that the pictures of the tiles, and the layers are in a format of indexed color palette. This helps the performance. Only at the final step of rendering the view on the screen that the composed picture of the view is rendered using the indexed color palette to the RGBA screen.
I will leave to you the weight of each advantage and disadvantage.
The advantages
- The code is very portable. It would work on any desktop OS or any console, and only the final step of rendering on the screen would need to be ported.
- It is much simpler to work with this than working with graphical APIs for GPUs. For example, OpenGL not only has many versions that break compatibility, but the same version in different platforms is not guaranteed to have all features of that version implemented.
- Performance, as mentioned above.
- Color palette swap is easy.
The disadvantages
- Limited to a color palette.
- Pictures must be of 16 x 16 size or composed of multiple pictures of 16 x 16 size.
- Run-time operations such as scaling and rotation are difficult to be implemented.
Final words
If I remember more advantages or disadvantages I will update this list. But, the lesson here is that not always the default collective mindset is correct. For the kind o project that I am doing, software rendering on a considerable resolution for a 2D game (480 x 320) had an efficient performance with frame rate of 60 frames per second.