Retro 3D Engine details/plan
about 3 years ago
– Tue, Aug 31, 2021 at 08:32:37 AM
While I've been quiet for a few days while meeting a professional deadline the Kickstarter has continued ticking up at a steady pace and now we're less than $4,000 away from hitting the stretch goal for the free and open source, MIT-licensed, retro software 3D engine for the modern era. For this update I'd like to talk about the plan for that in more detail. Please keep in mind everything I say here may be subject to change! In fact if you have ideas and/or suggestions, please leave comments about them.
First off, it won't simply be a software polygonal 3D rasterizer. Making "OpenGL but not as good" isn't really the intent here, even if that would be a pretty interesting exercise. Maybe it'll support some sort of polygonal 3D, maybe not, but it definitely won't be the focus.
It's also probably not going to be an engine that offers all styles of 3D covered in the first seven episodes. Making a software 3D engine that could actually be viable for a game release is tricky enough without trying to make it do literally everything. That's a way to get an engine that does everything poorly.
So what will it be? I'm thinking a portal-based engine, kinda like Duke3D, but with its own style of doing things. I'd like to try to make it not restricted to only indoor scenes, maybe through integrating voxel based heightmapped terrain. I think that could be a really interesting evolution.
As for the technical details, the project will be split in two parts. The first part will be the "core" of the engine, which deals with all the actual rendering. This part will be written in C for maximum performance and portability. It won't concern itself with things like windowing, audio, input, etc. That means that any language that can provide those things and can interface with a DLL written in C will be able to use the core engine. You could potentially use this from things like Unity or Unreal, but also from projects using SDL2, FNA, MonoGame, OpenTK, raylib, etc*.
* These are not promises, they're examples of game engines/frameworks that could potentially interface with the engine core because they can, in theory, interface with C code in some way.
The second part will be the "usable out of the box" portion of the engine. This will probably be in C# for similar reasons to why the code for the videos will be in C#: ease of use, accessibility, and popularity in game development. I haven't decided what this will sit on top of but it's probably SDL2 in some way, whether that's through FNA or SDL2-CS. This part of the engine will provide windowing, audio, input, etc.
This is probably how most people would use the engine, but I wanted the core to be transferable between different back-ends since that's kind of the strength of a software renderer; it doesn't really rely on much of anything to work. You feed it some data and it gives you a big mess of bytes that represent the screen, and you can do whatever you like with it from there.
As for the name, I've gotten a few suggestions to call this the "Enigine" or something to that effect but I think naming the entire engine after me might be a little much. >_> Personally, I was thinking of calling it the Throwback Engine. What do you folks think?
Although... Eniko's Throwback Engine does have a nice ring to it. 🤔
Recommended Kickstarter:
Finally I'm going to continue the Kickstarter tradition of highlighting promising and interesting looking Kickstarters at the end of these updates.
This time I'd like to point out Noguchi's Bell, a Kickstarter for an animated series about a young samurai in a cyberpunk dystopia. It has a really striking visual style, but even more interesting is that it's entirely made in Dreams, a game creation kit available on the PS4 and PS5. It's really cool to see how far people can take tools like this. Creativity thrives under limitations, which is something that as retro 3D enthusiasts we can all probably relate to.
