Godot Editor running in a web browser | Hacker News Reader

Godot Editor running in a web browser

godotengine.org

424 pointsSquareWheel124 comments

I'm still amazed how small the Godot editor is (last time I checked it was ~25MB). Just how are they able to pack this much functionality into such little space?

I guess its all relative.

In the late 80s I was impressed by a full Wordstar compatible text editor for Turbo Pascal which only occupied 25K (including the compiler). Times have indeed changed.

A lot of the godot size is the images it packs in itself.

When I cloned the godot repo, I could understand the architecture just by the file names.

I started falling in love with it as the easily understandable file names started streaming down from the cloud.

It's truly a public good.

> A lot of the godot size is the images it packs in itself.

For comparison, emacs's installed size is 76K [1].

[1] https://packages.debian.org/sid/emacs

That's the installed size of the metapackage containing no emacs executable, no elisp files, and no documentation.

On my system the emacs executable is 39M and the entire installed package is 128M. (Additionally, my Doom Emacs folder takes up another 840M.)

Ah so sorry about that. I should have checked.

> Additionally, my Doom Emacs folder takes up another 840M.

HOW?

Hd texture packs ?

doom emacs is just an emacs with a particular starting config.

Well, it contains 265 git repositories of packages I'm using.

On my Windows machine, the emax64 distribution (many packages) shows up as 491MB.

But on Windows, it seems that every app like this is essentially a Linux/mSys distro that just happens to run the application.

Of course, apps in general are getting that way.

I'm sorry if this sounds like I'm making fun of your Emacs install (I don't mean to) but how does this happen? Like, what is that when does it load all of that and how much memory/time does it take? I'm genuinely curious.

Nearly everything is loaded on demand. Start up time is less than 1 second.

Well, we should be impressed with 25MB for a decent game editor since the other players like Unity and Unreal Engine are probably around 25GB. It's also a fraction of Slack or Chrome or even the Rust compiler I believe.

The Chromium package on Arch Linux is around 68MB. The Electron runtime is a surprisingly reasonable size. Interestingly, the Go package is over 110MB. Rust is larger.

The Chromium package on Arch Linux is actually just a bit under 200MB when installed. Are you looking at the download size?

Yep, you're right, I'm looking at the compressed archive for both. Go must be huge then if the compressed package is 100MB.

I didn't check, but if the package consists mainly of binary, optimized executables, the compression may be very limited...

1 order of magnitude in 40 years? Doesn't seem a lot, but if applies exponentially would mean we will have some IDE in 2060 that's 25GB and someone will find it impressive. That's a lot of bytes for an editor.

Defining an 'order of magnitude' as 1024 seems a little odd to me. I would consider this to be closer to 3 orders of magnitued.

1024 (2^10) is ~10^3 (I know switching bases!) vs say 10 (10^1), so two orders of magnitude larger in general. A gig 10^9 would be many orders of magnitude. An order of magnitude is generally a jump to the next power of 10. So 10 (10^1) is an order of magnitude larger than 1 (10^0) as 100 (10^2) is to 10 (10^1), and so on. People frequently misuse the term when speaking in technical terms. When the average person uses it to denote a big jump, I let it go - usually ;) If you stick with base 2 I guess you could say many orders of magnitude (2^32 = 4,294,967,296 vs 2^8 = 256, or 24 orders of magnitude?).

But you could use Base-1024, in which case the term is used correctly. It's all relative ;)

Why? The common base is 10, and "orders of magnitude" is normally based on 10X between orders here. Ten fingers, decimal system, etc. Don't bring up metric vs. Imperial ;)

I work at an engineering firm, and that's how most engineers understand it.

Visual Studio is probably way more than 25GB, and it's 2020 still.

Depends on what packages you install, but my VS 2019 install folder is 2.5GB.

My VS folder itself is 4.1GB, but there are tons of other stuff that gets installed too. I know I downloaded about 28GB on my first install.

Or an entire MacOS like experience in 128k

https://en.wikipedia.org/wiki/GEOS_(8-bit_operating_system)

Having a little bit of discipline is all that's needed.

She's not as small as she used to be (Currently sitting at 61.1MB and has been over 30MB since 3.0) but to put that in perspective, that's smaller than the binaries for Half-Life 2 and even Half-Life 1. The release binary is even smaller at 33.5MB!

By not having massive dependencies?

Well, if you had massive dependencies you'd probably look at consuming them as shared libraries making your binary smaller than if you rolled your own solution, right?

The fact that the Godot editor includes the Godot runtime along with its own UI- and graphics stack (if I'm not mistaken?) in such a small bundle makes this even more impressive to me.

Godot has many parts besides the UI and graphics stack, and most of its dependencies vendored and statically linked. See the thirdparty folder for a list: https://github.com/godotengine/godot/tree/master/thirdparty

The official binaries include everything, but many of the larger bits are optional and can be disabled during build time to reduce the size of the executable: https://docs.godotengine.org/en/stable/development/compiling...

There's very little in the way of media or other assets -- it's all just code.

:) Before I read the link, I was thinking about a text editor I would keep on my rescue floppy disks. The method of distribution was typing the assembly out of the November 15, 1988 edition of PC Magazine.

http://texteditors.org/cgi-bin/wiki.pl?Ted

https://books.google.com/books?id=yFs-_3jT-5kC&pg=PA281

Or is a better question, what the hell is going on in other programs to cause them to be so gigantic?

Because some developers and project managers like, tolerate or even encourage complexity. I've read this comment on hackernews once about it, and it seems to be true.

There is Wirth's law ("software is getting slower more rapidly than hardware is becoming faster").

Generally, developers don't like performance, for some weird reason. The 97% Knuth quote might have played a major role, unfortunately it doesn't apply to game development at all. It's always a compromise between speed and code size.

For the rest, too many developers are not educated about electronics or physics, and often disregard important topics like memory management and data structures. But computer science always is complex. The generalization of garbage collected languages is also a big problem (see Minecraft)

Another problem is the lack of discipline and OSHA-like regulations in software development. The software industry is too anarchic and liberal-minded (Silicon Valley-style venture capitalism has a lot to do with this). It results in a lot of work being easily thrown away.

Honest question.. Is this "just" the way modern gamedev is being done. With these "Editors For Scenes" ?

Like the Unity and Unreal Editors ? Not hating just asking last time I "checked in" on gamedev was prob one or two decades ago and had a lot of fun with IrrLicht and Ogre.

Does this "editor approach" not get in the way ? Just looking in as an outsider with almost zero gamedev experience.. don't you end up fighting the editor to just get things done ?

Again don't flame me I have no idea what I'm talking about :)

PS. GoDot looks great :)

Partly it depends on the game but I think both Unity and Unreal, and I assume Godot, expect that the editor is just a framework and you're expected to extend them to whatever special needs your game has.

Godot is particularly good at extending the editor.

https://docs.godotengine.org/en/stable/tutorials/misc/runnin...

Hey software engineer/gamedev here.

I use Godot daily to make games for small businesses, usually around GPS-based games. What I really found is that the editor based approach of Godot actually doesn't get in the way, but is actually way closer to the DSL of a game designer.

Also the way of making nodes/scenes with signals in Godot promotes making systems that are very loosely coupled, so I haven't ran into any big problems with the engine when it comes to maintainability of projects.

And when I want to extend the engine with some native features like Android camera feed (which I'm preparing a PR for somewhere in the future), I can just dig into the code, no need to wait for something like Unity support or something.

Honestly, whether you're using this for hobby purposes or if you're dabbling in professional gamedev, this engine is worth a try.

These editors provide instant feedback on the materials, lighting, effects and animations. It’s like live reload for GUI apps.

I was very impressed when I got back into the field by how easy it is now to create and run a nearly-photorealistic scene with Unreal by only using built-in tools and the (now free) collection of assets from Quixel.

Having recently decided to bite the bullet and get back to Unreal Engine after not touching it for more than a decade, here's my impression:

1) You can essentially treat these editors as visual REPLs to your game engine. Which is useful in part because almost all gamedev is done in languages that have not seen a proper REPL (and Python doesn't count).

2) Most games these days have high art demands, these editors allow artists and designers without programming background to work on the game directly, in a more comfortable environment.

That has been the way that AAA game development has worked the last 25 years.

Professional games are like movies, programmers are a tiny percentage of people on the set.

They are the ones caring for the lights, that all cables are working properly and special effects go off as they should.

The main role, what dictates what a game is all about, belongs to game designers, producers, artists, those aren't writing C++ code, rather using visual tools.

Naturally you can make a game old style, just like on the 8 and 16 bit days, just like there are people doing movies just with an handy-cam.

The outcome isn't not going to be same though.

Gotcha !

> don't you end up fighting the editor to just get things done ?

That is often a problem, yes, but not just for the editor but the whole product.

By using such an integrated "game development framework" you basically also buy into all the tradeoffs. You get a lot of stability, robustness, WYSIWYG-editing and ready-to-use features, but you also need to align your whole way of thinking and your workflows to the design principles of the framework.

I like to compare game creation in Unity or UE4 to Photoshop. Sometimes ImageMagick or even MS Paint are the better choice, but if you only know how to use a hammer, every problem looks like a nail ;)

Godot is such an amazing/polished game engine. I like it a lot more than Unity (at least for 2D).

I clicked on the doc link from within the native editor. It is less of a tutorial than I had hoped. Do you have a suggestion for getting started with it?

The step by step docs have been very useful for me: https://docs.godotengine.org/en/stable/getting_started/step_...

If you're a "work bacwards from a finished project" kind of person, this tutorial is quite great as well

https://docs.godotengine.org/en/stable/getting_started/step_...

That's great. And, I love that the examples all specify /home/ubuntu as the home directory, so the author is clearly using Linux. This is really cool.

Yes "Your First Game" is a fine place to start even if it tells you to read some other things first. I'm a big fan of diving in to get something running, then searching or backtracking to learn the fundamentals if you need to.

There were a couple of typos in there that I ran into, it shouldn't be too hard with a little programming experience to notice these. I didn't download the finished files because I think typing it out is a much richer learning experience.

I recently got started by following couple videos on YouTube which are not hard to find. I've just followed very basic lessons, mainly to get familiar with non-programming aspects (scripting part is very easy if you already know programming).

There is also a Humble Bundle out there right now where you can get some basic lessons as low as $1[1]

[1] https://www.humblebundle.com/software/learning-game-coding-a...

How does it compared to Unreal? I've been using it a little to try and make a VR game and it's generally quite good I'm finding there are loads of bugs, or at least weird behaviours with materials and the OpenGL ES3 mode. And every time you change a setting it compiles like 3000 shaders which takes half an hour. Quite frustrating!

One of my favorite parts about Godot is that it gets away from those crazy load times / lockup you experience in Unity/Unreal. The .import file it associates with your asset is plaintext. Definitely running into fewer merge conflicts.

Ya way fewer.

The scene file is actually _readable_!!!!

The node and resource systems are vastly more accessible than Unity IMO.

Workflow feels so much better in Godot than Unity.

Godot's problems are in it's 3D renderer. It's not very performant nor good looking and has some shadow bugs...

Godot 4.0 should fix all that stuff.

The renderer is fine for my indie/low poly style, but is pretty limiting for advanced post processing and realistic designs.

The particle system isnt very good in godot 3.x so far either.

Godot has some a noticable lag spike when shaders compile as well.

So, there's lots of issues related to rendering and advanced stuff, but for my purposes, godot is way more productive than Unity for me. And thats because:

- the scene hierarchy has a superior design

- the keyboard hotkeys are better

- compilation time is non existant

- hot reloading works

- gdscript is faster to write than C#

- scene & resource files are more git friendly

- documentation is local and in-editor

- gdscript has opinionated & accessible apis for things that other languages make hard (string manipulation, encryption, file system access)

Godot is the future. I promise you this.

I don't know, to me the choice of their own NotPython as the main language seems like an incredible misstep to me. It's lacking in features (last time I checked they didn't even support basic things like lambdas), tooling and libraries.

There's a reason why both Unreal and Unity moved away from providing their own language.

I thought it was a massive misstep until I started using it heavily.

Now I really like it.

As to lack of lambdas, yes there are no lambdas, but coroutines are a first class citizen in gdscript, and network libraries, like Nakama for instance, use coroutines heavily. I prefer coroutines to lambdas anyways, and I think the industry is moving towards coroutines.

There are a ton of good things about gdscript. I was a hater on it until I started using it, and then I realised how quickly it allows me to do stuff.

Besides, I'm staring at the worlds worst Unity project right now.

Languages dont matter as much as system design.

Coroutines and lambdas are orthogonal features. if the language supports it, a lambda can be a coroutine. Arguing that one will replace the other strikes me as nonsensical.

And I don't hate gdscript, I just think it's incredibly half-baked and feels very immature. It's understandable that they only have limited resources, but that doesn't make my experience with it better.

Languages matter an incredible amount because of how heavily they influence system design. You can design an awful system in any language, but if you have to treat everything like a nail because you only have a hammer, you're bound to make a lot of awful decisions.

Edit: also, good IDE support really is incredibly helpful for working on larger projects

Im thinking of both lambdas and coroutines as techniques for asynchronous programming - like the 'complete' callback for a network call, for instance.

For functional programming, yeah there's no equivalent to a lambda in gdscript, but again, I think it's exceptionally well suited for the kinds of things you do in typical, run of the mill, game dev.

Seems lambdas are coming in 4.0.

https://github.com/godotengine/godot/issues/2684#issuecommen...

All these things. GLTF and godot have been amazing to me, though I do sometimes struggle with the asset flow but I'm getting better.

I've been using 4.0a and havent found anything with major breaks so far, and Vulkan really shines compared to opengl3.

It makes me so happy that I can have a game editor that aligns with my RMS-esque views (pro gpl). Now if I can just get my friends on board, many of them have invested so much time in unity or ue they don't want to switch. My goal is to have a prototype cool enough to draw them in eventually.

It's a common fact that Godot's 3.x[0] renderer is lacking but if it can achieve these[1][2] then 4.0 will be a game changer

As a side note I like your comment ^^

[0] didn't say current because master branch to be the current branch and it already migrated to Vulkan [1] https://www.youtube.com/watch?v=HQYZBZybP9M [2] https://www.youtube.com/watch?v=cKtwW9yU6QU

Hi! I work on Godot Engine closely, improving the 3d asset pipeline.

Things move slowly in any large project.

Changes that were made for Godot Engine to make glTF2 import acceptable were done in October 2019.

However, a feature request to make the official glTF2 importer (Blender) import standard glTF2 properly will take until Blender 2.83 (LTS) to arrive in the next few weeks.

Three.js is also able to import standard glTF2. There is an amusing chart of failures on Github. https://github.com/KhronosGroup/glTF-Sample-Models/pull/243#...

FBX 3d asset import support in Godot Engine is the same struggle.

Supporting standard FBX is the goal because of the focus on open source ecosystems. Even when the current Godot Engine fully supports FBX (Godot Engine does not currently), it will take significant time to get Blender's incompatible variation of FBX to be patched in stable releases of both Blender and Godot Engine.

Other people are working on Godot Engine rendering for the next version, but I am joyed at reviews of the glTF2 work.

I hope for future success in Godot Engine projects.

Bro we know each other ;)

Have you tried it on a package of similar size? Yes I hate the Unity/Unreal start up issues. On the other hand they are doing a ton of stuff for you. Compiling 100s or 1000s of shaders for for particular GPU, compiling all the code, processing all the assets for your particular platform. Those all get cached but the first open is painful. But I can't imagine Godot is any different. Those steps have to happen and they are all heavy steps. If Godot is faster it's more likely because it's doing less for you than because it's actually faster.

Godot seems to be a recommendation only for 2D projects. It's 3D support is lacking to the big engines. You can also see it in the showcase - it's 99% 2D projects.

Yes my understanding is 2D is first class while in the U engines you tend to turn a 3D scene sideways to get 2D and have to deal with vector mathematics rather than points in various functions. At least that's one reason a few people cited for the switch since they wanted to focus on 2D and it works without extra layers or abstraction.

As I understand it, orthogonal-view 3D as 2D is faster in the GPU than "real" 2D in the CPU, which is why it tends to be used.

My comment was more around tooling and complexity as seen by the programmer. You can have functions that look 2D but are really 3D behind the scenes, like glVertex2f in OpenGL. AFAIK Godot uses GPU acceleration still for 2D scenes like all games these days should.

Check out my game https://vrworkout.at for a VR game made with Godot. I am not a graphics designer so the models are bad which means that the rendering capabilities do not matter that much, but you have to stick to GL ES2 for the moment. Here is a video https://www.youtube.com/watch?v=mknXbyVJm3c

It's getting there, I think it's missing the top layer of polish. I've been working with it for a couple years now and it has some bugs that really hinder development speed.

That being said, once those issues are fixed I think it'll be a hard choice to not use Godot (for what I do, more 2D work).

> I've been working with it for a couple years now and it has some bugs that really hinder development speed.

What bugs do you think hinder dev speed?

I am vastly more productive in Godot than in Unity.

Currently I think the only criticisms I have are the 3D renderer is bad (whoop 4.0 lets go!), and there is not a strong community/asset marketplace.

I _love_ the workflow, though.

I'm a full time game dev and started a fairly large 3d project in Gotdot last September, I worked in it for about 2 months full time before moving to another project with another team.

The bugs that hindered my productivity were mostly "land mines" that I discovered along the way.

1. I thought having my scripts as internal scripts sounded good for a week until I realized there are all kinds of undocumented problems with storing your scripts that way. I had to refactor.

2. There is no selection outline around mesh in the editor window. Makes it impossible to build a 3D scene in Godot. My guess is that the developers expect you to build the scene in Blender then import it as one big FBX. (But that's not ideal for some things)

3. Then I hit the dangling reference bug and that was a heavy blow to my enthusiasm. The fact you can save a reference to an object in a variable, and that the engine can then change what object your variable is pointing to under the hood. It's such a fundamental bug it makes me wonder what other massive issues are there waiting for me to run into. My work around was to listen for signals for when object references were removed from the scene and manually clearing them, but its a real drag.

There were a few other things, but those ones stand out in my memory as examples of why I don't think I can work in it yet.

The reference bug won't be fixed until 4.0, so have another look at Godot then.

Update: Here are the bugs I logged.

https://github.com/godotengine/godot/issues/31758 https://github.com/godotengine/godot/issues/32383

If we're thinking of the same dangling Variant bug, a fix was backported to 3.2.2 (releasing soon): https://godotengine.org/article/dev-snapshot-godot-3-2-2-bet...

Good news!

Update: Although if I had continued with my project from September I would have shipped with this bug. That's quite a long turn around.

Wow these are some wild bugs.

I have never used a built in script and agree it should be removed.

I have never hit the dangling reference bug, and I agree it is critical. Good thing its fixed now.

I have been laying out scenes in 3D without the selection outline. It seems like a good feature to add. What I truly love about Godot is that you or I can actually add that feature. I know that turns some people off, but it actually is very attractive to me.

I think although it is missing that layer of polish, the underlying foundation layer is so much better built.

Would you recommend Godot for making a 2D bullet hell type game?

Yes, Godot would handle that very well.

I actually built a fairly functional combination of bullet hell and tower defense game in Godot about two years ago. Beware, though: the 2D lighting system for Godot is extremely slow, so if you want a buttery smooth FPS, don't do any crazy lighting.

Godot will do the job quite well, although there are plenty of alternatives that may also be worth a look (some open source, some source available): Defold, Solar2D, Heaps.io, etc. There are many good choices nowadays, although Godot gets the most love on HN.

I played with it about 2 years ago (even contributed some code to godot-cpp!) and it was pretty good, but it did have some gotchas and issues. Many are likely fixed now. You should just give it a try, its easy to get started and then you can judge for yourself.

One thing that I think would hugely shift godot's market share is a standardized asset format, similar to what Unity and Unreal have, so asset developers could offer assets in Godot-compatible format. It would be even more amazing if there was an easy way to import Unity resources. Maybe I just needed to do more research, but last time I tried, I had to pull out individual files, mess around with them in Blender, then import the model and the mesh into Godot separately, where I needed to arrange them together afterward. I think if the asset management was as simple as Unity's, Godot would be a no-brainer in many projects, especially smaller ones.

As long as it doesn't follow Unity's approach (asset bundles). Unity's favourite thing to do is break asset bundle compatibility between versions.

I'm not sure what you mean. Godot has asset formats that translate from project to project.

I've used both Unity and Godot at a hobby level and what I found was that with Unity, I spent almost all my time playing around with game mechanics. With Godot, I always spent a considerable amount of time importing resources and fiddling with them before being able to do anything useful other than add basic shapes to the screen. I think it's probably a problem of being the underdog with a much smaller asset market, but that's literally the one thing that made Unity worth checking out for me. I've downloaded most releases of Godot to play around with them as they come out though, so I'm really excited about it growing further.

There are some issues with the 3D importing pipeline, GLTF is the best supported file format, but they recently added .fbx support so thats good.

I agree that there could be further improvements made there but I've had good luck with .gltf.

Additionally, I've had problems with materials or animations importing into Unity as well. Seems like its a big, common problem.

Unity imports started getting smoother in recent years because marketplaces and artists started specifically targeting unity.

Maybe, but let me question that. What standardized asset bundles also do is create a market for asset bundles, which is good for the company they support. They also let new people buy a package of assets. Those aren't big issues for me, but I have never tried to make a commercial scale game in Godot.

Versioning is the nightmare of Unity. So many assets and plug ins only work with certain versions.

A friend of mine is developing a commercial game with unity, and that's been a big issue. It's either don't get big fixes or rework parts to upgrade unity

Well, it supports glTF which is supported by Unity and Unreal too. Most 3D packages like Blender support it too IIRC.

They even have a blog article on why it's the future (like JPEG for images) and how many big companies have started supporting it.

Yes I downloaded it last week. I got bored doing a Unity tutorial (how to best explain ... what I was doing all felt a bit disconnected from the games I guess?).

I dived right into the Godot tutorial "Your first game"[0] and had something basic running really quickly and I understood most of it without any further reading.

[0] https://docs.godotengine.org/en/stable/getting_started/step_...

Godot is a bad 3d engine, performance is abysmal.

Wow. I just downloaded and installed it (on Linux).

Hands down the best install experience of any similar tool.

* Unzip one binary and run it. * The app auto-detects everything you need, and uses the best version it finds * Its project layout requirements are "open an empty directory" * The example projects install and work!

Seriously, the biggest difficulty I had was finding the "run project" button. It took me a little bit of hunting.

Godot is truly real competitor to unity in OSS world, good job, I'll waiting this feature until it's not buggy.

I get a black screen and the JS error "Atomics is not defined." Did we overload it?

Atomics is part of the threading APIs, I'm guessing your browser doesn't support it. Although I feel like you should get a better error message...

That's strange, this project is funded by mozilla and does not run on latest firefox

It says in the blog post you need to use Firefox Nightly

Kinda strange but Godot kinda feels like a game dev oriented smalltalk to me

This is awesome. Question: everything I've read[0] about WebDAV indicates tons of compatibility problems between implementations, even those built into operating systems. I wonder what the plan is to deal with that?

Also, are there any off-the-shelf WebDAV client libraries for browsers?

[0]: https://news.ycombinator.com/item?id=10213657

I'm not a game developer but it seems like syncing with a standard git repo would be ideal. Is that possible with games or do the assets prevent it?

Your intuition is correct. git alone isn't going to cut it for the assets.

git lfs plugin should help with that one. IIRC Godot's editor has some support for creation of git repositories

https://git-lfs.github.com/

Smallish indie projects get by with git and or git lfs. git isn't really designed for binary assets and large games with terabytes of source assets usually don't use git. git's distributed nature is also an issue for non-mergable binary assets. The most common tool version control for bigger teams is perforce. It's significantly faster than git for binary files and it helps manage 2 or more people trying it edit the same binary file. There maybe be other bolt on solutions for that for git that I'm unaware of to help with that.

SVN is also quite popular, it's okay at dealing with large repos.

We use Git with LFS for our games-orientated projects, including some pretty massive projects, and have found it works really well.

We previously used SVN for similar projects, and made the switch to Git once LFS made it a feasible choice for projects with lots of large binary assets (games), and honestly never looked back, it's massively improved our workflow.

I wonder when firefox will re enable SharedArrayBuffer.

Seeing as it's available in Firefox Nightly, it'd imagine it'd be in the next release provided it doesn't present any problems from then and now.

A feature introduced in e.g. Nightly 78 might stay out of stable until say version 86. That is features make it to stable by becoming stable not because it first landed in a certain nightly and so everything was held up until all features in that nightly became stable. Releases happen on a fixed 4 week calendar cycle instead.

Based on https://bugzilla.mozilla.org/show_bug.cgi?id=1563480 I'd say it's probably a good number of releases away.

Here's some context you didn't ask for, but hope you find it helpful.

There's standardization work being done to enable SAB behind a new security context. Mozilla has a good summary: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

At the moment, I think only Chromium enables SAB by default for devices that have "Site Isolation" enabled (avoids spectre attacks by using process isolation). That's a browser feature specific to Chromium, and is disable for some low-memory devices, so it's not universal.

I'm not familiar with how far along Chromium or Firefox are. If you're interested in using SAB, start reading up on COOP and COEP.

Source: I work on web tooling at Chrome.

Which is a pity, Firefox has already landed on "nice to have" on our browser matrix, and these kind of decisions don't help.

Ergo "provided it doesn't present any problems from then and now", but I'm grateful for the context offered by that ticket.

How is Godots performance these days? I heard they are adding a ton of c# support after a lot of people have struggled with frame rates in gdscript (source: various youtubers who use Godot)

I just switched from unity to unreal because of sketchy retroactive licensing changes from unity and the performance in unreal is really making me happy so far

I wrote a large scale fluid sim (like Cities Skylines' water sim) with Godot and Rust. I think the biggest bottle neck is the gdscript honestly. I had a prototype working in GDScript and after I ported it to rust I had like a 20x speed up

Is the wait nearly over?

BTW, how do they pronounce the name?

"goh-doh" or "goh-doht" The 'o's are pronounced the same.

I've been waiting for this.

It's amazing that a native Windows/Mac app can be compiled to run in a web browser. However Web-assembly does not mean better performance. A native browser app would most likely be faster.

What do you mean by native browser app? Like JS + WebGL?

I'm guessing that an app written for WebAssembly in the first place would be faster than an app written for the desktop when they're both running in the browser.

JS is usually not the bottleneck in web apps. The bottleneck is most of the time rendering. Rewriting the app in JS would make it faster then the Webassembly version. It's a common misconception that Webassembly is faster then JS. Although theoretically possible, the compiler wouldn't be able to beat a skilled JS developer's hand written JS specific for the web platform. A turtle is faster then a rabbit - in water.

Is this true? I was under the impression that webassembly was capable of faster performance than JS, and thinking about learning a compiled languages to make my web applications faster. Would that be a waste of time?

It would not be a waste of time if you learned something. Here's a quick exercise: Write an "hello world" app and compile it to WebAssembly. Then open browser dev tools to inspect the app. You will see that a middle layer is needed to put that "hello world" on the screen. Just like JS, WebAssembly can't talk directly to the hardware and need to use the same browser API's as JS.

Besides obfuscating and being able to compile desktop apps to the web platform, one use-case for WebAssembly that might bring an performance improvement is to use it for something you currently use a Web Worker for. For example sending a bit buffer to the worker, have it do some work on it, and send it back. There is however a penalty to sending the data back and forth, although there are work being done that allows shared memory, which will make both JS and Web-assembly faster.

JavaScript is compiled to optimized native code. So you will get away with really stupid code - the optimizer will make it fast. But the more you learn, you will be able to write even faster apps. It really doesn't matter what programming language you use, it's more important to have experience and tribal knowledge of the platform you are targeting.

A funny thing about performance is that the more you know, the slower your app could become. If you for example use highly sophisticated abstractions, make use of frameworks and preprocessors, together with an orchestra of cloud functions and services with IPC message across oceans - then it will be slow. If you want performance - just keep it simple.

> JS is usually not the bottleneck in web apps. The bottleneck is most of the time rendering.

By rendering, do you mean the layout and painting steps? If so, this conflicts with any profiling I've done of heavy websites and webapps.

I would love to see some data to back this up, because my intuition tells me that this is false.

> a native Windows/Mac app

Not to mention (GNU/)Linux, FreeBSD, and OpenBSD ;) https://godotengine.org/features

Reply on news.ycombinator.com