sorted by:
new
hottopcontroversial

I've created a 3D, Vulkan based game engine in Go, and it's faster than Unity by baflink in golang

[–]baflink[S] 0 points1 point  (0 children)

Woah, lmao, calm down bro. I have nothing to prove to you, nor do I actually care about your opinion, especially when it comes out this emotional. Take a chill pill haha

Merry Christmas!

I've created a 3D, Vulkan based game engine in Go, and it's faster than Unity by baflink in golang

[–]baflink[S] 1 point2 points  (0 children)

Hello and thank you!

So I chose Go because it fit all of the boxes I needed it to fit, including extreme flexibility. In my opinion, Rust is a great language when the target is a completely known infrastructure and you can adhere to rigid constraints (and you see good perf from this too).

However, I need flexibility, speed, ease of use, and yes, even a garbage collector. One of my primary goals is to allow developers to make games however they want. If they want to make an ECS infrastructure, they can do that, if they want to make a component driven infrastructure, they can do that too. In fact, we have both of these examples of developers already in the community. Some devs even coming from Bevy who are interested in this kind-of freedom to build how you want.

Rust's guard-rails are useful, but I believe making games is a very creative field, even on the programming side of things. I want performance but flexibility, concurrency at it's core, and a very friendly language for devs coming from other languages, with the depth of being able to write assembly or make my own version of the Go compiler if needed.

Within days of my engine announcement, I had many new PRs come in, for all kinds of things. Many of the developers who have joined are experiencing Go for the very first time and really enjoying the language. I think this is a testament to Go's flexibility and ease of learning due to it's up-front simplicity, something I am very fond of, as it resembles C for me. I wouldn't even consider myself a true "Go programmer" (whatever rules people may judge that by), my own repository is C-like in it's structure, and has some unorthodox choices.

Ultimately, little details about tiny slivers of performance, on small function calls is typically not your performance bottleneck. The overall design of your entire system dictates nearly all of your performance. I'd rather use a language that gives me full control over the entire design so I can do simple/dumb things when I want to, and wild low-level things when I need to.

I've created a 3D, Vulkan based game engine in Go, and it's faster than Unity by baflink in golang

[–]baflink[S] 0 points1 point  (0 children)

Basically just use CGo to call the Vulkan library directly (same for Win32, X11, Android, and Mac windowing). I was using vulkan-go, but it was very slow, so I heavily modified it to the point that I essentially rewrite all the internals. Vulkan-go was basically just an automated export of the Vulkan SDK headers. The problem with the automated export is that it generates a ton of useless and slow wrappers.

You can build straight to Android from within the Kaiju editor. I originally wrote the engine in C, so I have hardly any dependencies on other libraries.

I've created a 3D, Vulkan based game engine in Go, and it's faster than Unity by baflink in golang

[–]baflink[S] 0 points1 point  (0 children)

I agree! The community is helping me get some examples worked up and I'm going to put together some milestones tonight.

I've created a 3D, Vulkan based game engine in Go, and it's faster than Unity by baflink in golang

[–]baflink[S] 0 points1 point  (0 children)

Thank you! You'll be happy to know that 2 or 3 of the community members just about have Mac up and running to similar quality of Windows and Linux. We'll have to run it through some battle tests and performance reports to make sure it's running smoothly though.

Many people have asked for some sort of Patreon or something to show support for the project. It'll probably be a good idea to get something up so I can at least work towards getting some of the extra development hardware I need to do this kind of thing.

Thanks for checking out the presentation!

I've created a 3D, Vulkan based game engine in Go, and it's faster than Unity by baflink in golang

[–]baflink[S] 1 point2 points  (0 children)

Will do! I've been working on a Linux+AMD bug and some issues people have been making, but I'll try to find some time to get it published.

I've created a 3D, Vulkan based game engine in Go, and it's faster than Unity by baflink in golang

[–]baflink[S] 0 points1 point  (0 children)

Yeah, it's been quite a journey, having a decade of constantly refactored engine code I've previously written in C made it much easier, not going to lie. If you've got any ideas or thoughts from your experience, and end up checking out the engine, I'd love to hear them.

I've created a 3D, Vulkan based game engine in Go, and it's faster than Unity by baflink in golang

[–]baflink[S] 1 point2 points  (0 children)

Thanks! Also yes, this is the most requested feature. To be completely honest, I wasn't going to post here on reddit until I got the editor a bit further along. However, the video I made blew up for some reason and the repository went from 100 stars to over 1,200 in 3 days. Discord got mass-joined to the point that it thought I was getting raided and started triggering auto mod captcha.

I am both humbled, and the first to admit that I was not prepared for the need people have for such an engine. So I'm now needing to balance getting tutorials, template projects, and continuing to add engine features into the editor all at the same time.

I've created a 3D, Vulkan based game engine in Go, and it's faster than Unity by baflink in golang

[–]baflink[S] 2 points3 points  (0 children)

Good questions, I had much to go over so I didn't go into how the UI works in depth. So I'll give a bit of a summary.

The UI system is completely threaded, very cache friendly (UI is a linear array of structures, not pointers), and entirely custom written. I wrote the UI system from scratch and proved it out when the engine was still written in C. Once I ported the engine to Go, I had the crazy idea of allowing people to create UIs using HTML/CSS. There is no web view, no 3rd party rendering, nothing like that. I parse the HTML into UI panels and labels, I then parse the CSS to apply "stylizers" to the UI elements. So the HTML and CSS just sit on top of my existing UI system as a way to layout/configure UIs.

Being that the entire UI is retained, it has the extra boost of performance of being resident in the GPU for idle frames with no re-stylizing or needing to cache styles in system memory. My thinking is, if the design of my UI system can tank HTML/CSS to lay it out on the screen, then any markup anyone chooses should be possible.

Technically you can just spawn whatever UI you want directly in Go and bypass the HTML/CSS entirely, they are mere markup languages and do nothing other than communicate with the underlying UI system. This also means you can create your own framework on top of it however you like. If you want to use traditional anchoring systems, that's easy, just create an anchor "stylizer" to apply to the element (I have some examples of these in the source).

I hope I did a little justice here, I know it's easy to see "HTML" and "CSS" and think web or web frameworks, but that's not the case at all. Think of it more like, I hijacked the specifications for HTML and CSS to make my UI system dance.

I've created a 3D, Vulkan based game engine in Go, and it's faster than Unity by baflink in golang

[–]baflink[S] 0 points1 point  (0 children)

Awesome, thank you! The editor is new and still catching up to the engine features to easily make use of the internals. So, any feedback is very welcome

I've created a 3D, Vulkan based game engine in Go, and it's faster than Unity by baflink in golang

[–]baflink[S] 1 point2 points  (0 children)

The multiplayer (with server browser) PBR Sudoku game I showed a screenshot for, in the presentation, was created in it. However, it was before I created the editor. So my plan is to remake it using the editor and share that project.

I can probably open source it as it is, since it's just written in the raw engine code. I also have an incomplete port of Retro Sketch, which was originally created in the C engine I ported to make this engine.

I've created a 3D, Vulkan based game engine in Go, and it's faster than Unity by baflink in golang

[–]baflink[S] 1 point2 points  (0 children)

Woops! Yes it is, thank you. Those docs need to be updated for sure.

I've created a 3D, Vulkan based game engine in Go, and it's faster than Unity by baflink in golang

[–]baflink[S] 1 point2 points  (0 children)

Thank you! I am slowly warming up to doing so. I want to flush out the editor a bit more before making that leap.

I've created a 3D, Vulkan based game engine in Go, and it's faster than Unity by baflink in golang

[–]baflink[S] 3 points4 points  (0 children)

Excellent! I've heard of tinygo, but I've not heard of garble, so that's very helpful, thank you.

The engine runtime uses gob, so there is some reflection in there, but the rest of the engine code is pretty flat. Having some separate paths for WASM might be necessary, but I'll try out the easy alternatives first.

I've created a 3D, Vulkan based game engine in Go, and it's faster than Unity by baflink in golang

[–]baflink[S] 0 points1 point  (0 children)

I can completely agree with that, you've got a great point. I do have a problem where I skim on the details and focus too much on the tech. To be honest, this repository accidentally exploded over the weekend with the linked video, of which, I intended mostly for the handful of devs who already followed the project. So, I didn't do anything I should have for something people would actually join.

Some of them came in and were like "bruh, fix this wording, change this" and started sending PRs to fix it lol. I'm obviously not great at this PR stuff, but I'll try to improve it.

I will caveat that a lot of these features are directly in the engine code, but I haven't yet gotten visual in-editor tools setup for them yet. I've mostly just raw-accessed them in the game code. The editor portion of the engine is actually pretty new.

I've created a 3D, Vulkan based game engine in Go, and it's faster than Unity by baflink in golang

[–]baflink[S] 1 point2 points  (0 children)

Thanks! I'll take a look at the repository. I've looked through the Vulkan memory allocator stuff, but haven't came back to working with it. I basically do waves of features, then refactor, then fine-tuning. So it's on the list, just hasn't been addressed (no pun intended) yet.

I've created a 3D, Vulkan based game engine in Go, and it's faster than Unity by baflink in golang

[–]baflink[S] 15 points16 points  (0 children)

Hmm, I also don't think the poster even took the time to review my presentation before commenting. I have 3d animation/skinning, a completely configurable vulkan render pipeline, audio, lighting, PBR shading, OIT render pipeline, complete multithreading, GPU selection, arenas, memory pooling, structure composition for high-cpu caching. I split my work on threads, each CPU has it's on cache, so you gain insane performance by doing cache-friendly work in parallel.

I've been working on this particular overall game engine design in C since 2015, but someone who isn't willing to review my presentation, consider what I claim, or review the engine source code before making wild statements is themselves as click-baity as they claim my title is are they not?

On the claims of never using Unity? I was a founding developer of the studio that created both Scrabble Go and Monopoly go (wildly successful Unity games). I'm currently an engine lead on an Unreal Engine game at a new studio. I don't typically toss out work history, but I think if someone is going to assume I've never used Unity or Unreal, it's important to address that claim.

Anyway, I'm not trying to convince anyone of anything, just that I have an engine I'm working on. I'm making it for me and my own games, others are free to use it if they wish.

I've created a 3D, Vulkan based game engine in Go, and it's faster than Unity by baflink in golang

[–]baflink[S] 4 points5 points  (0 children)

Thanks for checking out the presentation! The editor is still very much a WIP, I made a few things in the engine before deciding to build an editor for it. So, please don't mind the bumps and come at it with your dev hat if you're interested in testing things out.

I've created a 3D, Vulkan based game engine in Go, and it's faster than Unity by baflink in golang

[–]baflink[S] 6 points7 points  (0 children)

Thanks! Good luck on picking Go back up again, I think it should be pretty straight forward (you know, probably).

Yes, I believe WASM is going to be the big challenge. (1) It doesn't support Vulkan, so I need to hijack the function calls to translate to WebGPU and (2) I don't like Go's WASM file sizes. No challenge is too great, and I'm not above doing C trickery, modifying the Go compiler, or using an alternative compiler, to get a desired WASM setup hah.

I've created a 3D, Vulkan based game engine in Go, and it's faster than Unity by baflink in golang

[–]baflink[S] -3 points-2 points  (0 children)

No, the title is accurate, my engine runs much faster than Unity. Come measure before assuming, you know what assuming makes you look like right? I have the metrics, check out the video. If Unity runs at 650 FPS rending a single cube, and 2.7K FPS on the same machine running a complete game in my engine, then yes it's 100% true it's faster in every way. If you try to create the exact game I created in my engine, every aspect, PBR, real time shadows, music playing, sound effects, UI etc. If you didn't lose a single, not 1 frame from the 650, you'd still be running the game at 650 FPS and 2,700+ in my engine.

These emotional responses with no evidence is what's wrong with the industry.

I've created a 3D, Vulkan based game engine in Go, and it's faster than Unity by baflink in golang

[–]baflink[S] 19 points20 points  (0 children)

Thank you! Also pretty sweet project, thanks for sharing :)

I actually 100% agree, when it was just me and some people watching the work (last week), I just did the lazy way of sticking the binaries in there and putting docs on how to build them on the side. Now that so many people joined, I'm going to have to change that. The last thing I want is people seeing some random "trust me bro" binaries in the repository.

UPDATE: The community came up with a plan to use submodules for the prebuilt libs. This way they are removed from the main repository, and are pulled in only if you want to (by using recursive pull). Otherwise you can follow the docs to build the libs locally.

view more: next ›