10-18-2018, 06:45 AM
(This post was last modified: 10-18-2018, 06:45 AM by Richard Kain.)
Took a little break from Python, and switched over to something else I had been curious about. I wanted to know if Tilengine could be profitably integrated into Unity, as an alternative rendering engine to Unity's standard implementation. I'm not really interested in replacing Unity's default rendering, so much as using Tilengine to supplement it with a more authentic version of 2D rendering.
Initial experiments seem good. I was able to feed the Tilengine.dll and SDL2.dll into a standard Unity project as native plugins. I was also able to properly import and reference the Tilengine.cs bindings. Then I cooked up a quick-and-dirty script to reference and initialize the Tilengine Engine object. Worked like a charm, and even ran in the editor preview window with no errors. Of course, that's just the most basic set-up. The real challenge is going to be binding the Tilengine reference to a pixel array. That isn't going to be quite as easy in Unity as it was in PyGame. (where one of the fundamental structures had exactly what I needed) My plan at the moment is to create a RenderTexture in the Unity editor, add a link to it in my script, and use that as a target for both initializing Tilengine, as well as binding it to the pixels for the RenderTexture.
I was a little disappointed to see that the Engine initializer is a singleton instance. Since you can't construct multiple instances of the Engine, it will most likely be impossible to have multiple Engines running within Unity. One of the niftier applications of this experiment would be to have populated RenderTextures that could be used as the texture for a television screen in a 3D game. The 2D focus and low-level performance of Tilengine would probably make for a tighter version than trying to emulate such an effect using Unity's standard implementation of faux-2D 3D sprites and a separate camera. It can still be done, certainly. But you can likely only do it one screen at a time, and wouldn't be able to render multiple different screens in the same scene. A minor limitation that won't effect most people, but still something to think about.
Initial experiments seem good. I was able to feed the Tilengine.dll and SDL2.dll into a standard Unity project as native plugins. I was also able to properly import and reference the Tilengine.cs bindings. Then I cooked up a quick-and-dirty script to reference and initialize the Tilengine Engine object. Worked like a charm, and even ran in the editor preview window with no errors. Of course, that's just the most basic set-up. The real challenge is going to be binding the Tilengine reference to a pixel array. That isn't going to be quite as easy in Unity as it was in PyGame. (where one of the fundamental structures had exactly what I needed) My plan at the moment is to create a RenderTexture in the Unity editor, add a link to it in my script, and use that as a target for both initializing Tilengine, as well as binding it to the pixels for the RenderTexture.
I was a little disappointed to see that the Engine initializer is a singleton instance. Since you can't construct multiple instances of the Engine, it will most likely be impossible to have multiple Engines running within Unity. One of the niftier applications of this experiment would be to have populated RenderTextures that could be used as the texture for a television screen in a 3D game. The 2D focus and low-level performance of Tilengine would probably make for a tighter version than trying to emulate such an effect using Unity's standard implementation of faux-2D 3D sprites and a separate camera. It can still be done, certainly. But you can likely only do it one screen at a time, and wouldn't be able to render multiple different screens in the same scene. A minor limitation that won't effect most people, but still something to think about.