GateEngine supports most platforms supported by Swift Package Manager, including Windows and HTML5.
The number of features and unique things that make this special are numerous, but it's far easier and more interesting for you to see how intuitive it is by checking out some examples.
A suit of examples are available at GateEngineDemos. This suite is developed and expanded in parallel with the GateEngine main branch.
Thanks for sharing, this looks fantastic! Also the projects are super clean and easy to navigate, and the code looks great. Are you planning to do some introductory videos or tutorials about it?
I have no knowledge of how game engines work, so sorry if I'm asking a dumb question, but how does the multiplatform rendering work? Does the engine have automatic mappings to DirectX on Windows and, I'm not sure, Metal on macOS/iOS?
Android support is currently delayed because I simply can't afford to buy any major android device right now. GateEngine's platform support is hand written to use native UI code to create an experience users expect on each platform. So it's important to me that I understand the platform before creating a backend.
It's possible the Linux support will work for Android, but true native Android support is coming.
Performance is important, but not a primary concern for GateEngine. I have not yet done any performance optimization passes and don't plan to until the final steps for v1.0.0
Users can visualize performance issues in their own projects by adding the PerformanceRenderingSystem to their game.
It's barebones currently, but will draw an overlay with helpful performance information.
Yes. Extensive documentation, tutorials, etc... but not until v1.0.0. is done. The API is still volatile so I don't want to spend too much time making instructions just yet. That's why I opted for GateEngineDemos for now, I can quickly fix and update them by just building them.
Nope, I opted to take the harder road to make the experience as pleasant and easy as possible.
GateEngine has a native rendering pipeline for each platform. So on Windows DirectX 12 is used and on Apple devices Metal is used.
This is an atypical approach. Most engines/libraries use a single renderer and then have users use a shader conversion tool and ship different language shaders on each platform.
GateEngine has a bult-in Swift based shader builder API. You can construct your shader in Swift using Swift code and the engine will generate a native shader at runtime in the shader language that's needed.
Here is a simple fragment shader that samples a texture in:
let fsh = FragmentShader()
fsh.output.color = fsh.channel(0).texture.sample(at: fsh.input["texCoord0"], filter: .nearest)
And this is a vertex shader that does skinning:
let vsh = VertexShader()
let bones = vsh.uniform(named: "bones", as: Mat4Array.self, arrayCapacity: 64)
let jointIndicies = vsh.input.geometry(0).jointIndicies
let jointWeights = vsh.input.geometry(0).jointWeights
var position = Vec4(vsh.input.geometry(0).position, 1)
position += bones[jointIndicies[0]] * position * jointWeights[0]
position += bones[jointIndicies[1]] * position * jointWeights[1]
position += bones[jointIndicies[2]] * position * jointWeights[2]
position += bones[jointIndicies[3]] * position * jointWeights[3]
vsh.output.position = vsh.modelViewProjectionMatrix * position
vsh.output["texCoord0"] = vsh.input.geometry(0).textureCoordinate0 * vsh.channel(0).scale + vsh.channel(0).offset
This API eliminates the need for users to have to deal with conversion, working with multiple shader languages, or managing shader file resources. So which renderer is used on which platform is completely abstracted and not something a developer needs to deal with.
To make things super easy many common types of shaders will be included so in many cases you won't need to do anything with shaders.
Thanks for this suggestion. Looks like someone already did it and the site auto filters duplicates with no error message? I'll keep this in mind for the future though.
wow, this sounds amazing, I'd be very interested in getting some deeper insight about how you did it, but I also don't want to waste your time with my amateurish, at best, understanding of the topic, so I'll take a deeper look at the project itself and wait for the tutorials
Each demo has line by line documentation if you haven't checked them out yet.
There's also a couple places you can get more information about how I did it:
I post frequently to a development journal on the STREGA'sGate Discord -> GateEngine Progress. So there's lots of information with pictures and videos to scroll through on there.
I also made this YouTube video about the renderer a couple years ago. It's changed a bit since then but the principles for the user experience are the same.
I'm looking for a good cross-platform 2D game engine written in Swift for years. Now I'm completely dependent on Unity. Wish the best for your creation and hope I will write my next pet project game using my favorite language with real type-safety and modern syntax in the opposite of an incomplete and messy C#. Have not time to contribute but I will drop you a couple of bucks each month with a GitHub sponsorship.
Hi. What device we are talking about? I want to consider sponsoring you with a device purchase if this speeds up Android target development. You can't afford to skip such a major platform (I don't like it but I can't deny the obvious) if you want your engine to gain at least some attention.
Don't worry. Android will not be skipped. I've already committed to it.
The biggest road block for Android has been tools support. GateEngine is all about making everything easy and fun, and getting Android to build isn't easy or fun at the moment. Finagolfin has a fairly easy to use SDK but even that's barrier of entry is too high. I don't want my users to have to know how to use symlinks to be able to make a game. But if it can't be helped, then that's fine; but with the new SDK support added in Swift 5.9, things should get really easy for Android very soon. Android is one of the most obvious platforms to benefit from the cross compilation support.
As for a device, I had previously settled on the Google Pixel Tablet. It looks like I could simulate a phone environment on the display and the hardware was relatively good for the price. But I'll do fresh research before making a purchase.
If you have the means to contribute more I certainly wouldn't be opposed to it but your sponsorship is already very generous and appreciated! I can't promise contributions will lead to quicker development though as Android is already very high on my priority list. I'm just waiting for an SDK, preferably one that can build on macOS and Linux hosts.
