Project G:
Changes are highlighted.
- Renderer:
- Programming interface: reimplementing
- Documentation: ongoing
- Camera function: done, for now
- Gamma Correction: done, for now
- Update rotation algorithm: to-do
- Lighting: ongoing, Blinn-Phong model, Gaussian model done
- Texturing: to-do, basic functionality due 25/8
- HDRR: to-do, due 15/8
- Shadowing: to-do, due 20/8
- Game Logic:
- Main loop: done, for now
- Mouse movement and key detection: done, for now
- Key mapper: to-do, due 23/8
- Network:
- Everything: currently not on schedule
- Modelling:
- Simple Wavefront .obj loader: done, for now
- Simple material property loader: to-do
- Everything else: to-do
- Physics:
- Everything: currently not on schedule
- Sound:
- Everything: currently not on schedule
- Optimisation:
- Migrating: reimplementing everything in C
- Debug:
- For all components: never ends
Details:
Performance is not the main reason for porting to C. Using the Python implementation, frame per second is still above 200 when there are more than 1000 triangles, and even with a simple yet expensive shader. That is, Python is not the bottleneck.
What forces me to migrate is the limitation of PyOpenGL. With it, things like VAO, framebuffer need to come by extension. For the current version PyOpenGL 3.0.1, that means importing one more file for each functionality. Yes it is a one-liner, yet it is still very annoying (and uncertain. Why should I use ARB extensions if that those are core functionality of 3.0+?). Another thing, PyOpenGL officially supports OpenGL only up to 3.2, I want 3.3 (much easier to programme).
With PyOpenGL 3.0.2 up, the problem of extensions seems to disappear, but 3.0.2 is still in early development stage, and I can find no easy way to install it. In fact, I cannot even find the source. The problem will go away if I can find some OpenGL extension loader, like GLEW and GLEE. Sadly, GLEE has OpenGL support up to only 3.0 (and there is no Python binding), and PyGLEW has not been updated since 2007 (even before OpenGL 3.0 is out).
Combine the hope of OpenGL 3.3 functionality, I turn to C. Waiting SDL 1.3 to be finalized, now I use freeglut as a temporary solution for manage OpenGL context window creation and simple mouse / keyboard detection.
But... Using freeglut, which is capable of creating at least a 4.0 context, I am still only getting 3.1. After updating the NVIDIA driver from Fujitsu website, I finally see a 3.3 context. Going back to Python with Pygame and PyOpenGL, I see 3.3 too...
Anyway, we are in the middle of the way to Canaan now. When SDL 1.3 turns gold, I do not want to wait for Pygame to catch up, so we will migrate to C by this year nevertheless, it is just a matter of time. Hope we will not be stuck for 40 years.
When the C version of renderer first ran, I thought there would be a huge increase in FPS, as the window (running pretty much the same code) on OpenGLBook.com runs at about 3000 FPS. My own calculation suggests that my window (at the same 800x 600 resolution) is only running at 500 FPS at most. The difference is so huge that I immediately suspected either the (still-empty) rendering pipeline or the FPS-counting algorithm went wrong. Inspection failed to support the suspicion. It is hard to believe that it is hardware limitation. Before I move the programme to other computer, this remains a mystery.
As of why it is C and not C++, it is because C++, from the core of the specification, is just a mess.
The previous Develog.
