Polymorph weekly news #4
Fourth week already and half way? Let’s see.
So back to interviewing @frankiezafe, our project leader and main motor behind the Polymorph Engine (haha, I’m so funny). So Frankie and I had a little chat, which was supposed to last one hour but ended up taking two. Although this post won’t be as long, I promise. But I was keen to know how projects were going from his point of view.
As you may have seen from his last posts, there is now what is called an Empty example for Ogre 2.0 running. It’s not that empty because it has a camera, lights and objects floating in empty space, but you get the idea. It’s a basic demo to start working from. It’s also a great tool to check that things compile in all platforms. So far, François has it running on Linux. It should run on Windows and other platform are coming. By the way, if you are interested, please have a go at it and send feedback. There is now documentation and code on the repository. And while it’s not yet a complete Empty example, it should get you started. And we’re excited to read what you think of it.
So François is now step by step going deeper in the Ogre3d documentation. His experience with Openframeworks proved very valuable here. Because he already knows how the GPU (graphic card) is handling images, as he says it:
You throw a bag of numbers at it in the correct format and it spits out an image.
Although handling Ogre is a lot more different than Openframeworks. If Openframeworks is an excellent introduction to C++ and a very flexible tool, Ogre is way more complex and structured. It requires a good understanding of high level C++ concepts and related software design patterns, which makes Ogre a powerful tool indeed, but harder to learn. I could sense that this was kind of a hard step for François, but it also came with its moments of joy, when he shared with me the code that defines the camera movement.
These little things in Ogre make it so much easier, said François.
His work from this week focused on code to generate mesh, materials and texture on-the-fly, meaning things are not preloaded from files at startup, but generated by the engine itself when the game runs. François is taking inspiration from Mad Max tutorials, but “cleaning up” the code, as he says it, and creating basic classes from it. Making it then reusable code for following projects. It may not look like it, but all this is necessary for the development of PEEL, the first game of Polymorph.
PEEL should come out at the end of August, hence my introductory mention of “half way”. Polymorph exists since 4 weeks and should deliver an alpha verison of its first game in 4 weeks. There is many steps until then, but Pieter and François are making progress. And Daniel Perez has agreed to make a Pure-Data patch for spatialized sound. So stay tuned and see you next week.