Towards 3D rendering: a multiplatform implementation
Lately, I've been working on getting an easily portable, and supported system for 3D rendering in the vision of integrate it fully into Gen7 to make it a 2D/3D Engine. It's an incredible challenge, but a lot of people are asking for 3D support and I can't hide that it made myself want to dig into the topic.
OpenGL.
OpenGL, the graphics API standard which proved itself since decades now. Today maintained by the non-profit Khronos Group, the industry standard seen its first implementations by Silicon Graphics in 1992 (23 years ago!), the creator of N64's GPU and a lot of other standards still used to today before filling its bankruptcy in 2009.
That standard is very well established, and got ported on multiple systems making it the best solution for Gen7 Engine so I choosed it.
Ported? I spoke too soon.
Well no. More I have started to work on it, more I had to fill the gaps myself. Diving in trigonometrics and 1993's source codes, I've successfully got results on 3 different platforms, after days of work:
The first challenge was to get the OpenGL implementation working on Wii. A one was existing, but it's very buggy and as you wonder I had to fix it.
On PC, it just uses the native API DLLs to wrap on the GPU. So far not much problems.
The first thing is, as you can see, they're pretty different. It's just because each rendering gets translated to the own engine's API, and so each one has its own standards. Every material is defined by properties that can be freely interpreted by the graphics API (GX on Wii, GU on PSP and native OGL on Windows), in opposition of programmed shaders or pipelines in order to get the same result everywhere.
And the PSP. First renders were just apocalyptic, it was about Resident Evil on the scene. The sphere became a why on earth cube, the torus a.. thingy I can't name and the cone exploded itself. Resident Evil I told you.
After research, the GLUT library (OpenGL UTilities) that draw primitives such as these have not been programmed at all on PSP (the reason the sphere became a cube is just because the programmer forwarded the sphere rendering's to a cube one as it doesn't exist), so I had to fill the gap. So I had to create the GLUT Shapes implementation from scratch based on 1993's sources and (try) to understand the mathematics behind as it's all procedurally generated using parameters, implementation I shared on Github on https://github.com/iyenal/PSPGL-OpenGL-Shapes [1].
But then, as you can notice triangles are missing. It's just because all the trigonometric functions are using the standard C/C++ <math.h> library, where precision isn't the same on all platforms and in our case, not enough for the PSP (probably as an handheld, precision got lowered for less CPU usage and more battery) to recognize the place of some triangles. Hopefully it has a dedicated VFPU unit for that, so precision can be same if not higher than its counterparts by converting these calls (except sqrt).
In conclusion, the good thing is that it got pushed to the main official (homebrew) PSPSDK ports repository [2][3], so now anyone can benefit from a working OpenGL+GLUT library under PSP.
The latest PR and change since 2017, pspsdk speaking
Well I have passed on the details, but feel free to ask questions on the matter.
References:
[1] https://github.com/iyenal/PSPGL-OpenGL-Shapes
[2] Push request to PSPSDK repo: https://github.com/pspdev/psp-ports/pull/27#event-3236799307
[3] PSPSDK-ports repo: https://github.com/pspdev/psp-ports
Lately, I've been working on getting an easily portable, and supported system for 3D rendering in the vision of integrate it fully into Gen7 to make it a 2D/3D Engine. It's an incredible challenge, but a lot of people are asking for 3D support and I can't hide that it made myself want to dig into the topic.
OpenGL.
OpenGL, the graphics API standard which proved itself since decades now. Today maintained by the non-profit Khronos Group, the industry standard seen its first implementations by Silicon Graphics in 1992 (23 years ago!), the creator of N64's GPU and a lot of other standards still used to today before filling its bankruptcy in 2009.
That standard is very well established, and got ported on multiple systems making it the best solution for Gen7 Engine so I choosed it.
Ported? I spoke too soon.
Well no. More I have started to work on it, more I had to fill the gaps myself. Diving in trigonometrics and 1993's source codes, I've successfully got results on 3 different platforms, after days of work:
The first challenge was to get the OpenGL implementation working on Wii. A one was existing, but it's very buggy and as you wonder I had to fix it.
On PC, it just uses the native API DLLs to wrap on the GPU. So far not much problems.
The first thing is, as you can see, they're pretty different. It's just because each rendering gets translated to the own engine's API, and so each one has its own standards. Every material is defined by properties that can be freely interpreted by the graphics API (GX on Wii, GU on PSP and native OGL on Windows), in opposition of programmed shaders or pipelines in order to get the same result everywhere.
And the PSP. First renders were just apocalyptic, it was about Resident Evil on the scene. The sphere became a why on earth cube, the torus a.. thingy I can't name and the cone exploded itself. Resident Evil I told you.
After research, the GLUT library (OpenGL UTilities) that draw primitives such as these have not been programmed at all on PSP (the reason the sphere became a cube is just because the programmer forwarded the sphere rendering's to a cube one as it doesn't exist), so I had to fill the gap. So I had to create the GLUT Shapes implementation from scratch based on 1993's sources and (try) to understand the mathematics behind as it's all procedurally generated using parameters, implementation I shared on Github on https://github.com/iyenal/PSPGL-OpenGL-Shapes [1].
But then, as you can notice triangles are missing. It's just because all the trigonometric functions are using the standard C/C++ <math.h> library, where precision isn't the same on all platforms and in our case, not enough for the PSP (probably as an handheld, precision got lowered for less CPU usage and more battery) to recognize the place of some triangles. Hopefully it has a dedicated VFPU unit for that, so precision can be same if not higher than its counterparts by converting these calls (except sqrt).
In conclusion, the good thing is that it got pushed to the main official (homebrew) PSPSDK ports repository [2][3], so now anyone can benefit from a working OpenGL+GLUT library under PSP.
The latest PR and change since 2017, pspsdk speaking
Well I have passed on the details, but feel free to ask questions on the matter.
References:
[1] https://github.com/iyenal/PSPGL-OpenGL-Shapes
[2] Push request to PSPSDK repo: https://github.com/pspdev/psp-ports/pull/27#event-3236799307
[3] PSPSDK-ports repo: https://github.com/pspdev/psp-ports
