Seeing a performance degradation rendering a few dozen objects flying, down to 48 fps on Mac M1, is pretty insane. Something is fundamentally wrong either with the framework or the approach. It seems like 90%, if not 98%, of time is wasted on something irrelevant.
> There weren’t that many projectiles in the first place so I felt that this would be useful later. However, considering that Chrome and Safari were struggling performance wise probably due to their garbage collector working differently, I resigned myself to implement it now.
I'm curious about actual metrics with regard to Chrome / Safari's garbage collector overhead. You still don't have a lot of "objects" in the video; when V8 is used server side it handles significantly more objects. (IE, assuming each sword is 1-5 objects.)
Are these engines canvas based, or are they generating HTML? Assuming they are generating HTML, are the elements removed from the screen when you are done with them?
In a lot of garbage collected environments, you still need to call some kind of close / remove method when you are done with some kinds of objects. (In C#, it's "Dispose.")
Your "bunch of projectiles" is what, 20? You should be able to do 20,000 on even the lowliest integrated GPU these days.
As a senior game/graphics programmer looking at the screen caps, I see a game that should never be using more than 1% of the CPU and a few percent of the GPU.
> You should be able to do 20,000 on even the lowliest integrated GPU these days.
It all depends on how things are organized. If each object needs to run logic every frame, you can start to run into severe performance issues way before you get to 10k. 60fps means you have 16 milliseconds to check everything in the scene. This can be a lot of time but you only have to make one small mistake to lose any advantage.
We have to reach for data oriented techniques like ECS if we want to keep the CPU ~idle while managing 10k+ entities in the scene. This stuff is a big pain in the ass to use if you don't actually need it.
I left a comment in the previous thread about reserving judgement until the cause is identified as it's quite common to run into weird performance issues in very complex systems (games typically being so) and its very easy to say: "modern software bad." Now that it's been elucidated, I can pretty confidently say: "modern software bad." I strongly doubt this would happen in love2d, Godot, or any other engine/framework.
I would be inclined to blame small, obscure, new frameworks glued together in a weird way more than something that's unique to modern software. Godot is nearly 25 years old. I'm sure it was awful back in 2003.
> Godot is nearly 25 years old. I'm sure it was awful back in 2003.
Sure, but that's kind of my point, modern software is endemic of a mindset that most things are "fast enough" that we can reinvent the wheel, repeat old mistakes, and more or less get away with it, instead of using something better suited and more purpose built.
> Additionally, to not disable batching it was important that all drawSprite calls be placed together in the draw loop before rendering text with drawText calls.
Sounds like reflow problems. And like OP is slowly discovering the 200% Problem.
When the abstraction fails you need to know all the implementation details of the thing being abstracted as well as the abstraction. 100 + 100 = 200. Often it’s easier and more productive overall to just learn the thing. It’s a false economy thinking you won’t need to.
I was able to find this comment, linking to a talk that coined(?) it. https://news.ycombinator.com/item?id=36091791 I guess in short you would say that learning a leaky simplifying abstraction actually increases the amount you have to learn.
The other tried but then chose against GemShell, but it sounds awesome for my projects. It builds files that can be as small as 3MB by using the native webview. The pro version is just $13.
The main down side is poor performance if you’re not targeting Safari and Chrome.
> While I eventually ended up fixing the performance issues in my game, I can’t help but think of scenarios where problems could arise later that are unfixable due to limitations of the tools I’m using.
Only if you don't want to get your hands dirty with the layers you're using.
The trade-off with an abstraction layer is that every layer introduces bugs/decisions which may be a concern. But you can always (if it's open source) tweak the layer(s) below.
Moreover, why not finish the game and make your next project in something new.
Interesting writeup. It's surprising to me that the author was experiencing such severe performance issues with relatively simple scenes, and it sounds like the performance issues still aren't completely gone. In the past I've been able to run fairly complex 2D scenes in JS+canvas so I wonder if there's some sort of fundamental performance issue lurking underneath kaplay or some other library they're using?
Seeing a performance degradation rendering a few dozen objects flying, down to 48 fps on Mac M1, is pretty insane. Something is fundamentally wrong either with the framework or the approach. It seems like 90%, if not 98%, of time is wasted on something irrelevant.
Here's Chrome showing 100k objects in 3D, with very decent fps: https://m.youtube.com/watch?v=dKg5H1OtDK8 This should give some idea of what should be achievable.
> There weren’t that many projectiles in the first place so I felt that this would be useful later. However, considering that Chrome and Safari were struggling performance wise probably due to their garbage collector working differently, I resigned myself to implement it now.
I'm curious about actual metrics with regard to Chrome / Safari's garbage collector overhead. You still don't have a lot of "objects" in the video; when V8 is used server side it handles significantly more objects. (IE, assuming each sword is 1-5 objects.)
Are these engines canvas based, or are they generating HTML? Assuming they are generating HTML, are the elements removed from the screen when you are done with them?
In a lot of garbage collected environments, you still need to call some kind of close / remove method when you are done with some kinds of objects. (In C#, it's "Dispose.")
Your "bunch of projectiles" is what, 20? You should be able to do 20,000 on even the lowliest integrated GPU these days.
As a senior game/graphics programmer looking at the screen caps, I see a game that should never be using more than 1% of the CPU and a few percent of the GPU.
> You should be able to do 20,000 on even the lowliest integrated GPU these days.
It all depends on how things are organized. If each object needs to run logic every frame, you can start to run into severe performance issues way before you get to 10k. 60fps means you have 16 milliseconds to check everything in the scene. This can be a lot of time but you only have to make one small mistake to lose any advantage.
We have to reach for data oriented techniques like ECS if we want to keep the CPU ~idle while managing 10k+ entities in the scene. This stuff is a big pain in the ass to use if you don't actually need it.
I left a comment in the previous thread about reserving judgement until the cause is identified as it's quite common to run into weird performance issues in very complex systems (games typically being so) and its very easy to say: "modern software bad." Now that it's been elucidated, I can pretty confidently say: "modern software bad." I strongly doubt this would happen in love2d, Godot, or any other engine/framework.
I would be inclined to blame small, obscure, new frameworks glued together in a weird way more than something that's unique to modern software. Godot is nearly 25 years old. I'm sure it was awful back in 2003.
> Godot is nearly 25 years old. I'm sure it was awful back in 2003.
Sure, but that's kind of my point, modern software is endemic of a mindset that most things are "fast enough" that we can reinvent the wheel, repeat old mistakes, and more or less get away with it, instead of using something better suited and more purpose built.
> Additionally, to not disable batching it was important that all drawSprite calls be placed together in the draw loop before rendering text with drawText calls.
Sounds like reflow problems. And like OP is slowly discovering the 200% Problem.
What is the 200% problem?
When the abstraction fails you need to know all the implementation details of the thing being abstracted as well as the abstraction. 100 + 100 = 200. Often it’s easier and more productive overall to just learn the thing. It’s a false economy thinking you won’t need to.
I was able to find this comment, linking to a talk that coined(?) it. https://news.ycombinator.com/item?id=36091791 I guess in short you would say that learning a leaky simplifying abstraction actually increases the amount you have to learn.
The other tried but then chose against GemShell, but it sounds awesome for my projects. It builds files that can be as small as 3MB by using the native webview. The pro version is just $13.
The main down side is poor performance if you’re not targeting Safari and Chrome.
> While I eventually ended up fixing the performance issues in my game, I can’t help but think of scenarios where problems could arise later that are unfixable due to limitations of the tools I’m using.
Only if you don't want to get your hands dirty with the layers you're using.
The trade-off with an abstraction layer is that every layer introduces bugs/decisions which may be a concern. But you can always (if it's open source) tweak the layer(s) below.
Moreover, why not finish the game and make your next project in something new.
Interesting writeup. It's surprising to me that the author was experiencing such severe performance issues with relatively simple scenes, and it sounds like the performance issues still aren't completely gone. In the past I've been able to run fairly complex 2D scenes in JS+canvas so I wonder if there's some sort of fundamental performance issue lurking underneath kaplay or some other library they're using?