Hi everyone!
I'm the dev behind this work-in-progress game.
This post was intended for my existing audience and I didn't expect for it to be posted on HN.
Anyway, now that it's here, feedback on performance is still very much appreciated!
The reason I'm not making this web playable despite being built using web technologies is that I'm targeting Steam for this game. Therefore, I need to make sure the game works well when installed as an executable on Mac, Windows, Linux.
There was already trust established between me and my audience so that's why it felt appropriate to tell them to download executables.
I understand why HN users not familiar with me, would be wary of downloading random executables from the internet. It's a good instinct to have!
"The reason I'm not making this web playable despite being built using web technologies is that I'm targeting Steam for this game. Therefore, I need to make sure the game works well when installed as an executable on Mac, Windows, Linux."
If it runs on the web, it should run the same as an executable, otherwise your exporter is broken. I would likely debug on the web first (just to get access to chrome dev tools including the profiler and performance meassurement tools). Is there some way to do comfortable debugging/profiling with the way you export via GemShell?
I think you have to ask yourself what you're trying to get out of this, strategically. I know it's probably a "forbidden" option, but Unity is really good at hitting all the platforms at the same time and giving you the ability to deeply understand why things might be running like shit.
I'm working with a partner on a steam game and it was the most rational choice we could arrive at. Our goal is to make enough revenue from the this project to justify another one. We seek to make a living doing this.
I struggle with the lack of advocacy for effective tools on this platform. If we are being honest about the overall engineering proposition, the trade of moderate, unknown capitalist exploitation risk for platform targeting stability might actually be worth it if the goal is to get the game into the hands of as many players as possible.
Electron/Tauri/whatever is just the start of the battle. You also have to consider different input, storage, etc., systems if you want to hit targets like Steam Deck - which is a huge deal for visibility these days. The web is a nasty abstraction layer once we start talking about things like Xbox controllers.
Why are you worried about performance for a 2D game that's basically moving a few sprites around the screen? A game like this shouldn't be taxing for modern hardware; and should even run cleanly on pretty much any computer made in the last 15-20 years. (Or even older, if you weren't using Javascript.)
As some of the other comments imply that there are some performance issues; more than using a profiler, I would make sure that your mental model of the event loop from your framework is correct. If all you're doing is moving some sprites around the screen, you need points where your code pauses because it has nothing to do. This could either be awaiting something from the framework, or putting most of your logic in callbacks that are triggered by the framework.
A different way to say it: Between frames, there's not that much calculation that your game needs to do when you're just moving a few sprites around in 2D. The event model that you hook into should be something where your game does its calculations, and then waits between frames.
> Why are you worried about performance for a 2D game that's basically moving a few sprites around the screen? A game like this shouldn't be taxing for modern hardware
> As some of the other comments imply that there are some performance issues
Because there's nothing implied and they experience perf issues first hand? TFA:
The fact that they experienced issues on a relatively powerful machine is some kind of commentary on modern software development. The screenshots look like something you could have played on a typical 1998 machine or even older.
It could be a bug or something. Bugs have been with us from the beginning. There may not have been as many bugs in 1998, but if so, only because the computers crashed very easily back then.
> is it just my machine? I’m using a Macbook Air M3 with 16GB of RAM
Using one of the singularly most powerful personal computers ever made. It's probably not the machine if they don't notice everything else being unexpectedly bad too.
A real example: MacBook Pro m4 will have absolutely god awful performance on certain web based games * (compared to windows or even android), regardless of the browser or any browser performance settings. This is not the hardware explicitly, obviously it’s a very high performance chipset, but it’s definitely the hardware in terms of what the OP is asking. Because that particular hardware is falling down all over the place in this scenario when others are not.
Fixing it? Sure that’s almost certainly on the games side, some kind of inefficient process or element that doesn’t work right in that environment and needs to be hammered out or replaced.
But for diagnosis? Yeah, “it’s the hardware” is the right answer. And you can’t fix it without diagnosis.
*replicated on latest chrome, Firefox, safari, and Brave, with the games: Idlescape and (now dead)osrsIdle ~8 months ago
The game appears to be similar to a point-and-click adventure game, which were popular in the 80s, and ran just fine.
In 1988, a CRAY Y-MP supercomputer had "64 megawords of memory". I have no idea how large a word was on those machines, but by todays standards, that means 128MB. Let's go with that. The Y-MP was the size of two massive fridges.
Now, the Macbook air OP owns, which is smaller than a toaster, has 128 TIMES as much memory in it as a supercomputer did back in 1988. Similar story for processing power, storage, etc. Point and click adventure games haven't changed all that much, and even back then didn't require a supercomputer to run.
> But for diagnosis? Yeah, “it’s the hardware” is the right answer.
Given the above, how you came up with this is beyond me.
No, it's true. There can be defects in the graphics driver that make certain, specific functions in GLSL or WGSL either completely broken or woefully inefficient.
It can be very dependent on hardware generation, too. One of my past projects was a very simple, photosphere-based learning environment. Photosphere rendering is incredibly simple. But on Intel processors with Iris Xe integrated GPUs used by one particular year of iMacs (I don't remember which, it only impacted 2 users and it was several years ago), I couldn't use the standard cube sampler because it was just broken. I had to split my photospheres into 6 cube faces and render 6 quads separately to be able to use the not-broken 2d sampler. The issue didn't appear on any other generation of Iris Xe on macOS and it didn't appear on any generation of Iris Xe on any other OS. It was very specifically the combination of macOS and that generation of GPU.
Yes, video drivers are, generally, buggy and unreliable. The hardware they're hooked up to is fucking amazing.
Also, I can 99.9999% guarantee that this guys' problem is not a driver bug, so trying to nerd-snipe me with "but driverzzz broroooooo" is pedantic and annoying. The guy is drawing like 100 quads; it should run at a bazillion frames a second on literally a toaster.
I'm curious about this. I always had the impression, mostly from reading Shamus Young, that there's no such thing as drawing something other than a triangle.
Blender guides tell you to divide your model into quadrilaterals. Though I did find one reddit post saying "I imported this model from a console game and it's all triangles. I thought models were supposed to use quads." The answer was "that model is finished, so it's in triangles because that's what you actually draw".
What's going on? Is there such a thing as drawing polygons with more than three sides? Why is the current advice "use quads" to the point that people don't even realize they're drawing triangles?
What is going on here is that modeling a mesh and rendering it are very different things. There are algorithms to edit a model that work best on quad based topology (e.g. selecting edge loops and others). That's why quads are preferable for editable "source" versions of 3d models. The conversion from quads to triangles is also a very fast algorithm.
GPUs rasterize triangles because they are a primitive type with very convenient properties: rasterization requires only a few basic math operations per pixel and triangles can never overlap themselves in projections, which quads can.
It's generally tempting to assume the mesh data that is edited in a DCC tool (Maya etc.) as the same as what is rendered. This couldn't be further from the truth because they need to be in completely different representations. For example, vertices on UV map seams need to be duplicated for rendering, but that would make editing the mesh extremely unwieldy. So the datastructures are totally different.
It's built of triangles so a quad is 2 triangles etc.
The advice about using quads I'm not sure is really a tautology. I tend to work with quads until one of the quads is non-planar then I cut it so that when I bring it into a game engine the import/bake step doesn't triangulate the mesh in a way I didn't want it to.
opengl can do dots, lines, triangles, quads, ngons. just an option in the drawcall. pretty sure dx and vulkan will be the same but i didnt try em... what is more optimal.. idk.
maybe under the hood past the drawcall it will triangulate it. never bothered to look into that.
pretty sure the HW doesnt care one bit as it operates on vertices... not primitive shapes. (ofc like u note if ur quad is non planar it wont look like u expect but thats no concern for the driver or hw..)
I though about mentioning that but I didn't want to muddy the waters. There other option in opengl like you said but I can count on one had the times I've used them in a professional context and I think possibly zero for anything that I've shipped. Also I have never looked into what it does under the hood in those cases. You might be right.
The base primitive a GPU draws is triangles; they are the fastest primitive for math-y reasons, but the basic premise is that you can subdivide any triangle into two right-angle triangles, which have favorable properties for scanline-based rasterization.
Now, software modelling packages can represent geometry in any way they want, as long as that software package can somehow eventually transform that representation into triangles for the GPU to rasterize to pixels (barring custom software rasterizers).
My comment referred to quads, but at the end of the day, a quad is 2 triangles. Same goes for arbitrary polygons. The GPU speaks triangles.
this guy is unlikely to have read the games source or reversed it far enough to make these claims..what you see on the screen, how a game represents it on memory and how the translation between them works , can vary greatly.
that all being said. it is very easy to write bad code for games or use old features etc., we're all guessing unless some of you put a profiler and debugger to it... if so , show the money.
Jesus, dude. I was just pointing out that graphics driver defects very much can result in any number of difficult to diagnose issues. Yes, even decreasing performance over time, if the driver isn't releasing memory correctly and the system is starting to hit swap. There really is no telling for certain what is going on with graphics without having a deeper analysis across multiple, varied system configurations. Which is nigh inaccessible to hobbyist developers.
I guess I just wasn't willing to assume OP was basically incompetent and hadn't already done a basic algorithm review if their post about not being able to debug this issue made it this far.
I have to agree with the other person, comments like yours are annoyingly pedantic and just derails the conversation to a useless place. Like cmon, look at the game for a second, the chances of fps problems being due to him running on the Mx macbook pro (whether hardware or driver defects) is like 0.00001%.
A game like this should be running for like 1000+fps and this point should be emphasized in case the maker of this game is clueless when it comes to this kind of stuff, as his blog suggests (sharing an executable with users and asking for a recording is not how you would debug this perf issue) And it's totally fine if they are clueless, we all start somewhere. What sucks is derailing comments like yours that do the opposite and pretend that there is a conversation to be had here other than the implementation is probably terrible, which is, again, completely fine if it is, and we can talk about it and help them with it or point them in the direction of good resources about this stuff.
sorry for the rant, I just see these "akshually theoretically it could be due to blablabla" type comments on HN so much lately and I hate them
its now about how the game looks its about what features it uses to do its thing and how drivers on many platforms handle them.
this is also a reason why there are so many gfx driver patches which fix specific games...
its usually not the hardware but driver issues.
also, its infeasible for a solo dev to test on a plethora of platforms and device/driver combos, so any feedback from random internettians about performance can be really helpful to prevent breakage on platforms not available to the dev to test on.
On an M2 Mac with 24GB the game went smooth for a few fights and then went down to around 10fps and got slower with every attack an enemy did in the fight. The longer I played the slower it got. CPU and memory usage was stable all the time.
Not a game dev. Besides profiling, I would create game scenarios that exercise certain parts of the game engine.
For example, I would create a game fight scenario where the player has infinite health and the enemy just attacks super fast at some settable rate. That way you could monitor whats happening in extreme abnormal conditions with the hypothesis that if the game works in extreme conditions then it will work in normal conditions.
Another example. If you have random encounters like in old school JRPGs then I would create a scenario where a fight happens per step of the player, the fight loads, then the enemy immediately dies, rinse wash and repeat. That should allow you to asses how the game performs after 100s of fights quickly.
The idea here is to create tests that improve your signal to noise ratio. So you create a scenario that will create a large signal so that then you can more easily diagnose the performance issues.
This is the future of troubleshooting: where did the LLM decide to introduce recursion based on calculation that draws on an otherwise unused global counter and a separate timer initiated at launch for absolutely no reason.
It can't be hardware, as others have noted these kinds of games have been working great on machines that are magnitudes slower than the OPs machine. Maybe it's some kind of search that is running linearly on an assumed small dataset and it gets bigger than imagined, instead of it running a binary search or something. Maybe some of the data is unreasonably large for what it contains and can't get cached as easily.
And, as others have mentioned, if you really want to know, profile.
Sounds like the culprit though, could be tons of small objects added for effects or something that still don't show up in memory usage but adds iteration time?
Assuming it's capable of running in your browser, I'd suggest using chrome's dev profiling tools to help with finding the optimization areas. Based on feedback from everyone else, sounds like something is not cleaning up as the game keeps running.
Firefox runs the game well on the Mac, while the Neutralino build (presumably using the WebKit shipped with Safari) experiences some performance issues. Can you replicate the performance issues with Safari? If so you might be able to glean some insights from https://webkit.org/web-inspector/timelines-tab/
When profiling, it can often be useful to compare profiles of "working well" versus "not working well". So you could record a 10 second timeline when things are going smoothly, then a 5 second timeline when perf is bad - things that jump out on the second timeline are worth looking at.
That was my gut feeling too, or at least something Tahoe related. I reckon they’re using Gemshell based on the game icon, which they’ve also been talking about on their YouTube channel.
On Gemshell’s store page (https://l0om.itch.io/gemshell) it seems they’re in turn using Neutralino JS, which should be using a Webview, like Tauri.
First off, yay for making games! I love working on games, and have spent many, many hours doing it, so welcome to the club :)
Second, let me introduce you to my good friend, the profiler. A profiler is an absolutely indispensable tool for making games. Find one that you like, and learn to wield it with laser-guided precision.
Generally, there are two things you want a good profiler to tell you about; execution speed, and memory. Finding a profiler that tells you about execution speed is pretty easy (basically all of them at least nominally do that), and finding one that also profiles memory (in a useful way) is somewhat harder. I'm not sure of the state of profilers for Javascript, but maybe the tool you're using (KAPLAY) has one built-in?
From my long-forgotten days of programming javascript, one thing you want to look out for (which is difficult to spot without a profiler), is creating memory leaks. Memory leaks in Javascript can be a double-edged sword; you're both using more memory than you should, and the garbage collector has more pressure on it. Over time, this can bring an application to a crawl as the GC spends more and more time traversing leaked objects.
Good luck friend. It's dangerous to go alone, take this :sword:
GPU code performance != CPU code performance. You can have a visually trivial game (Dwarf Fortress pre-makeover) that will grind your CPU to a halt because of all the simulations it has to process. You can also have a visually complex game that will run fine because the rendering will be properly optimized to reduce drawcalls etc but as the number of units grows, it will push your CPU to the limit.
A bit offtopic, but if it would have been playable in the browser I would have tested it, but I don't want to download and install a (for me) random exe.
(and I don't see how performance could be an issue unless a major screw up, but like others have said, use a profiler. Sounds like memory leak from what was shared here)
What kind? It would be helpful to know what you're experiencing, attempts you've made to fix, etc.
Or is this a thinly veiled "I've been working on this for a while and it's taking longer than I thought and want some encouragement." Which is fine! It's a great thing to ask for.
It's probably worth reminding everyone here that it's possible to write slow code in "fast" languages and fast code in "slow" languages. The state of software as it stands today is horrendous, but seeing as no one here (author included) seems to know why it's slow it's probably worth reserving judgement.
If you can't get a simple game like that perform well even when written in JavaScript on a semi-modern PC you wouldn't be able to do it in any language. It's certainly not the issue.
PC was ridiculed for its bad graphics capabilities by fans of other home computers. Only over time PC's capabilities for graphics and video games improved piece by piece until after many years PC fans had the last laugh.
they missed out, i reckon. whereas the commodore and atari users had heaps of fun and then moved over to pc anyway.. they'd have more colorful memories.
If you have a friend who is encountering the performance problems enable profiling report export and ask them to send that over to you. Hopefully that'll show you what is taking so many cycles.
You can use developer tools in the browser to simulate slower CPU. Use performance profiling to find which functions are taking up the most time. Try switching to battery saving mode, it might throttle your CPU a bit too.
If you really want to dive deep in performance improvements, you should purchase lowest end laptop with integrated GPU, if budget allows.
And how about providing an embedded web version of your game, because downloading unsigned executables these days should be considered a no-no.
Completely unplayable. It runs fine at first, and then suddenly drops to below 1FPS for no discernible reason. This happens regardless whether I am on the world map or combat scene.
I am running the exe, couldn't find the browser version.
On an unrelated note, I am surprised to see a JS program working without the usual 200MB NW.js runtime (as seen with RPG-MV)
That's because I'm using GemShell. It's tool that generates executables using, under the hood, Neutralino which is similar to Tauri (uses the OS's webview rather than packaging a Chromium instance).
Just downloaded and tried it on my M1 Mac and the performance was what I'd expect for a game like this, both in and out of battle. Totally smooth and ~15% of CPU usage in both cases. By the way, I love the pixel art, and the gameplay has potential, it's a style I've never personally played before but I could see it being compelling.
can confirm. very slow. here's the output I got on Debian 13 on an older i5, but it doesn't look like it's telling us very much.
./Small-RPG
libEGL warning: DRI2: failed to authenticate
VMware: No 3D enabled (0, Success).
libEGL warning: egl: failed to create dri2 screen
VMware: No 3D enabled (0, Success).
libEGL warning: egl: failed to create dri2 screen
** (WebKitWebProcess:2822): WARNING **: 14:52:20.184: The GStreamer FDK AAC plugin is missing, AAC playback is unlikely to work.
This is absolutely fine for someone to request on their personal blog to a group of followers who may well be interested in the game and support the author. People have used their blogs for this sort of thing for decades.
Forget about performance, specially in a 2d game like this one. Focus on making it fun (really-really fun is possible).
I have played games that didn't performed so well because they were so fun. Games are about fun, anything else (narrative, performance, sound...) is secondary.
Why not consult with industry professionals rather than random people on the internet? Gaming is a huge industry worth billions and have many people who have dedicated themselves to the craft. They not only can diagnosis common problems and future problems, but can help effectively change your processes, ultimately identify and solve these similar problems yourself.
All for not that much money, you are in a good position to capture a bunch of value if you are serious.
Hi everyone! I'm the dev behind this work-in-progress game.
This post was intended for my existing audience and I didn't expect for it to be posted on HN.
Anyway, now that it's here, feedback on performance is still very much appreciated!
The reason I'm not making this web playable despite being built using web technologies is that I'm targeting Steam for this game. Therefore, I need to make sure the game works well when installed as an executable on Mac, Windows, Linux.
There was already trust established between me and my audience so that's why it felt appropriate to tell them to download executables.
I understand why HN users not familiar with me, would be wary of downloading random executables from the internet. It's a good instinct to have!
"The reason I'm not making this web playable despite being built using web technologies is that I'm targeting Steam for this game. Therefore, I need to make sure the game works well when installed as an executable on Mac, Windows, Linux."
If it runs on the web, it should run the same as an executable, otherwise your exporter is broken. I would likely debug on the web first (just to get access to chrome dev tools including the profiler and performance meassurement tools). Is there some way to do comfortable debugging/profiling with the way you export via GemShell?
That should is doing a lot of potentially very painful heavy lifting in your statement.
Yes, but before checking the tools and compilers for bugs, it usually makes sense checking and verifying the own code first in a controlled setting.
I think you have to ask yourself what you're trying to get out of this, strategically. I know it's probably a "forbidden" option, but Unity is really good at hitting all the platforms at the same time and giving you the ability to deeply understand why things might be running like shit.
I'm working with a partner on a steam game and it was the most rational choice we could arrive at. Our goal is to make enough revenue from the this project to justify another one. We seek to make a living doing this.
I struggle with the lack of advocacy for effective tools on this platform. If we are being honest about the overall engineering proposition, the trade of moderate, unknown capitalist exploitation risk for platform targeting stability might actually be worth it if the goal is to get the game into the hands of as many players as possible.
Electron/Tauri/whatever is just the start of the battle. You also have to consider different input, storage, etc., systems if you want to hit targets like Steam Deck - which is a huge deal for visibility these days. The web is a nasty abstraction layer once we start talking about things like Xbox controllers.
Make a web game. This isn’t a web game.
Why are you worried about performance for a 2D game that's basically moving a few sprites around the screen? A game like this shouldn't be taxing for modern hardware; and should even run cleanly on pretty much any computer made in the last 15-20 years. (Or even older, if you weren't using Javascript.)
As some of the other comments imply that there are some performance issues; more than using a profiler, I would make sure that your mental model of the event loop from your framework is correct. If all you're doing is moving some sprites around the screen, you need points where your code pauses because it has nothing to do. This could either be awaiting something from the framework, or putting most of your logic in callbacks that are triggered by the framework.
A different way to say it: Between frames, there's not that much calculation that your game needs to do when you're just moving a few sprites around in 2D. The event model that you hook into should be something where your game does its calculations, and then waits between frames.
> Why are you worried about performance for a 2D game that's basically moving a few sprites around the screen? A game like this shouldn't be taxing for modern hardware
> As some of the other comments imply that there are some performance issues
Because there's nothing implied and they experience perf issues first hand? TFA:
> I’ve been experiencing performance issues
> I’m using a Macbook Air M3 with 16GB of RAM
The fact that they experienced issues on a relatively powerful machine is some kind of commentary on modern software development. The screenshots look like something you could have played on a typical 1998 machine or even older.
It could be a bug or something. Bugs have been with us from the beginning. There may not have been as many bugs in 1998, but if so, only because the computers crashed very easily back then.
They could be a novice developer. I'm not going to be a snob.
> is it just my machine? I’m using a Macbook Air M3 with 16GB of RAM
Using one of the singularly most powerful personal computers ever made. It's probably not the machine if they don't notice everything else being unexpectedly bad too.
Well. That’s a bit misleading.
A real example: MacBook Pro m4 will have absolutely god awful performance on certain web based games * (compared to windows or even android), regardless of the browser or any browser performance settings. This is not the hardware explicitly, obviously it’s a very high performance chipset, but it’s definitely the hardware in terms of what the OP is asking. Because that particular hardware is falling down all over the place in this scenario when others are not.
Fixing it? Sure that’s almost certainly on the games side, some kind of inefficient process or element that doesn’t work right in that environment and needs to be hammered out or replaced.
But for diagnosis? Yeah, “it’s the hardware” is the right answer. And you can’t fix it without diagnosis.
*replicated on latest chrome, Firefox, safari, and Brave, with the games: Idlescape and (now dead)osrsIdle ~8 months ago
> Well. That’s a bit misleading.
Uhh .. wut?
The game appears to be similar to a point-and-click adventure game, which were popular in the 80s, and ran just fine.
In 1988, a CRAY Y-MP supercomputer had "64 megawords of memory". I have no idea how large a word was on those machines, but by todays standards, that means 128MB. Let's go with that. The Y-MP was the size of two massive fridges.
Now, the Macbook air OP owns, which is smaller than a toaster, has 128 TIMES as much memory in it as a supercomputer did back in 1988. Similar story for processing power, storage, etc. Point and click adventure games haven't changed all that much, and even back then didn't require a supercomputer to run.
> But for diagnosis? Yeah, “it’s the hardware” is the right answer.
Given the above, how you came up with this is beyond me.
No, it's true. There can be defects in the graphics driver that make certain, specific functions in GLSL or WGSL either completely broken or woefully inefficient.
It can be very dependent on hardware generation, too. One of my past projects was a very simple, photosphere-based learning environment. Photosphere rendering is incredibly simple. But on Intel processors with Iris Xe integrated GPUs used by one particular year of iMacs (I don't remember which, it only impacted 2 users and it was several years ago), I couldn't use the standard cube sampler because it was just broken. I had to split my photospheres into 6 cube faces and render 6 quads separately to be able to use the not-broken 2d sampler. The issue didn't appear on any other generation of Iris Xe on macOS and it didn't appear on any generation of Iris Xe on any other OS. It was very specifically the combination of macOS and that generation of GPU.
> There can be defects in the graphics driver
Yes, video drivers are, generally, buggy and unreliable. The hardware they're hooked up to is fucking amazing.
Also, I can 99.9999% guarantee that this guys' problem is not a driver bug, so trying to nerd-snipe me with "but driverzzz broroooooo" is pedantic and annoying. The guy is drawing like 100 quads; it should run at a bazillion frames a second on literally a toaster.
> The guy is drawing like 100 quads
I'm curious about this. I always had the impression, mostly from reading Shamus Young, that there's no such thing as drawing something other than a triangle.
Blender guides tell you to divide your model into quadrilaterals. Though I did find one reddit post saying "I imported this model from a console game and it's all triangles. I thought models were supposed to use quads." The answer was "that model is finished, so it's in triangles because that's what you actually draw".
What's going on? Is there such a thing as drawing polygons with more than three sides? Why is the current advice "use quads" to the point that people don't even realize they're drawing triangles?
What is going on here is that modeling a mesh and rendering it are very different things. There are algorithms to edit a model that work best on quad based topology (e.g. selecting edge loops and others). That's why quads are preferable for editable "source" versions of 3d models. The conversion from quads to triangles is also a very fast algorithm.
GPUs rasterize triangles because they are a primitive type with very convenient properties: rasterization requires only a few basic math operations per pixel and triangles can never overlap themselves in projections, which quads can.
It's generally tempting to assume the mesh data that is edited in a DCC tool (Maya etc.) as the same as what is rendered. This couldn't be further from the truth because they need to be in completely different representations. For example, vertices on UV map seams need to be duplicated for rendering, but that would make editing the mesh extremely unwieldy. So the datastructures are totally different.
Well said.
It's built of triangles so a quad is 2 triangles etc.
The advice about using quads I'm not sure is really a tautology. I tend to work with quads until one of the quads is non-planar then I cut it so that when I bring it into a game engine the import/bake step doesn't triangulate the mesh in a way I didn't want it to.
Building out of quads is more about overall topology and the aesthetic result.
this is what i thought too. its sort of easier to see if ur topology is good / efficient. atleast for me.
opengl can do dots, lines, triangles, quads, ngons. just an option in the drawcall. pretty sure dx and vulkan will be the same but i didnt try em... what is more optimal.. idk.
maybe under the hood past the drawcall it will triangulate it. never bothered to look into that.
pretty sure the HW doesnt care one bit as it operates on vertices... not primitive shapes. (ofc like u note if ur quad is non planar it wont look like u expect but thats no concern for the driver or hw..)
I though about mentioning that but I didn't want to muddy the waters. There other option in opengl like you said but I can count on one had the times I've used them in a professional context and I think possibly zero for anything that I've shipped. Also I have never looked into what it does under the hood in those cases. You might be right.
The base primitive a GPU draws is triangles; they are the fastest primitive for math-y reasons, but the basic premise is that you can subdivide any triangle into two right-angle triangles, which have favorable properties for scanline-based rasterization.
Now, software modelling packages can represent geometry in any way they want, as long as that software package can somehow eventually transform that representation into triangles for the GPU to rasterize to pixels (barring custom software rasterizers).
My comment referred to quads, but at the end of the day, a quad is 2 triangles. Same goes for arbitrary polygons. The GPU speaks triangles.
this guy is unlikely to have read the games source or reversed it far enough to make these claims..what you see on the screen, how a game represents it on memory and how the translation between them works , can vary greatly.
that all being said. it is very easy to write bad code for games or use old features etc., we're all guessing unless some of you put a profiler and debugger to it... if so , show the money.
Jesus, dude. I was just pointing out that graphics driver defects very much can result in any number of difficult to diagnose issues. Yes, even decreasing performance over time, if the driver isn't releasing memory correctly and the system is starting to hit swap. There really is no telling for certain what is going on with graphics without having a deeper analysis across multiple, varied system configurations. Which is nigh inaccessible to hobbyist developers.
I guess I just wasn't willing to assume OP was basically incompetent and hadn't already done a basic algorithm review if their post about not being able to debug this issue made it this far.
I have to agree with the other person, comments like yours are annoyingly pedantic and just derails the conversation to a useless place. Like cmon, look at the game for a second, the chances of fps problems being due to him running on the Mx macbook pro (whether hardware or driver defects) is like 0.00001%.
A game like this should be running for like 1000+fps and this point should be emphasized in case the maker of this game is clueless when it comes to this kind of stuff, as his blog suggests (sharing an executable with users and asking for a recording is not how you would debug this perf issue) And it's totally fine if they are clueless, we all start somewhere. What sucks is derailing comments like yours that do the opposite and pretend that there is a conversation to be had here other than the implementation is probably terrible, which is, again, completely fine if it is, and we can talk about it and help them with it or point them in the direction of good resources about this stuff.
sorry for the rant, I just see these "akshually theoretically it could be due to blablabla" type comments on HN so much lately and I hate them
> There can be defects in the graphics driver
Which is software, not hardware. Just not the software written by this dev.
Cray Y-MP had a 64-bit word size. They came with 32, 64, or 128 MWords. So 256, 512, or 1024MiB.
its now about how the game looks its about what features it uses to do its thing and how drivers on many platforms handle them.
this is also a reason why there are so many gfx driver patches which fix specific games...
its usually not the hardware but driver issues.
also, its infeasible for a solo dev to test on a plethora of platforms and device/driver combos, so any feedback from random internettians about performance can be really helpful to prevent breakage on platforms not available to the dev to test on.
> > is it just my machine? I’m using a Macbook Air M3 with 16GB of RAM
> Using one of the singularly most powerful personal computers ever made.
Some arbitrary PC Master Racer: "Hold my beer, and I will show you a powerful personal computer." :-)
On an M2 Mac with 24GB the game went smooth for a few fights and then went down to around 10fps and got slower with every attack an enemy did in the fight. The longer I played the slower it got. CPU and memory usage was stable all the time.
Not a game dev. Besides profiling, I would create game scenarios that exercise certain parts of the game engine.
For example, I would create a game fight scenario where the player has infinite health and the enemy just attacks super fast at some settable rate. That way you could monitor whats happening in extreme abnormal conditions with the hypothesis that if the game works in extreme conditions then it will work in normal conditions.
Another example. If you have random encounters like in old school JRPGs then I would create a scenario where a fight happens per step of the player, the fight loads, then the enemy immediately dies, rinse wash and repeat. That should allow you to asses how the game performs after 100s of fights quickly.
The idea here is to create tests that improve your signal to noise ratio. So you create a scenario that will create a large signal so that then you can more easily diagnose the performance issues.
This is the future of troubleshooting: where did the LLM decide to introduce recursion based on calculation that draws on an otherwise unused global counter and a separate timer initiated at launch for absolutely no reason.
Isn’t the glaringly obvious problem Garbage Collection?
I’d try digging into this first. Try to completely disable VC and see if there are any slowdowns before you run out of memory. Go from there.
Hah, keep disabling VC, but also disable GC.
It can't be hardware, as others have noted these kinds of games have been working great on machines that are magnitudes slower than the OPs machine. Maybe it's some kind of search that is running linearly on an assumed small dataset and it gets bigger than imagined, instead of it running a binary search or something. Maybe some of the data is unreasonably large for what it contains and can't get cached as easily.
And, as others have mentioned, if you really want to know, profile.
Sounds like the culprit though, could be tons of small objects added for effects or something that still don't show up in memory usage but adds iteration time?
Without downloading the exe (work laptop right now, can try later), have you followed the optimization suggestions in KAPLAY's guides?
https://kaplayjs.com/docs/guides/optimization/
Assuming it's capable of running in your browser, I'd suggest using chrome's dev profiling tools to help with finding the optimization areas. Based on feedback from everyone else, sounds like something is not cleaning up as the game keeps running.
Yes and it is extremely straightforward to find the right thing to look at profiling it: what does your `requestAnimationFrame` look like?
Firefox runs the game well on the Mac, while the Neutralino build (presumably using the WebKit shipped with Safari) experiences some performance issues. Can you replicate the performance issues with Safari? If so you might be able to glean some insights from https://webkit.org/web-inspector/timelines-tab/
When profiling, it can often be useful to compare profiles of "working well" versus "not working well". So you could record a 10 second timeline when things are going smoothly, then a 5 second timeline when perf is bad - things that jump out on the second timeline are worth looking at.
Related to the initial poor performance of Electron on macOS Tahoe?
https://github.com/electron/electron/issues/48311
That was my gut feeling too, or at least something Tahoe related. I reckon they’re using Gemshell based on the game icon, which they’ve also been talking about on their YouTube channel.
On Gemshell’s store page (https://l0om.itch.io/gemshell) it seems they’re in turn using Neutralino JS, which should be using a Webview, like Tauri.
First off, yay for making games! I love working on games, and have spent many, many hours doing it, so welcome to the club :)
Second, let me introduce you to my good friend, the profiler. A profiler is an absolutely indispensable tool for making games. Find one that you like, and learn to wield it with laser-guided precision.
Generally, there are two things you want a good profiler to tell you about; execution speed, and memory. Finding a profiler that tells you about execution speed is pretty easy (basically all of them at least nominally do that), and finding one that also profiles memory (in a useful way) is somewhat harder. I'm not sure of the state of profilers for Javascript, but maybe the tool you're using (KAPLAY) has one built-in?
From my long-forgotten days of programming javascript, one thing you want to look out for (which is difficult to spot without a profiler), is creating memory leaks. Memory leaks in Javascript can be a double-edged sword; you're both using more memory than you should, and the garbage collector has more pressure on it. Over time, this can bring an application to a crawl as the GC spends more and more time traversing leaked objects.
Good luck friend. It's dangerous to go alone, take this :sword:
I love your comment! That's the way to talk to a junior dev without the unnecessary smug.
I'd suggest getting a SteamDeck and use it as the lower limit on performance. If it runs there, it will run everywhere else.
Even a Steam Deck is overkill for a game like this. This is NES-levels of graphics.
GPU code performance != CPU code performance. You can have a visually trivial game (Dwarf Fortress pre-makeover) that will grind your CPU to a halt because of all the simulations it has to process. You can also have a visually complex game that will run fine because the rendering will be properly optimized to reduce drawcalls etc but as the number of units grows, it will push your CPU to the limit.
I tell people Dwarf Fortress is a cpu stress test tool, not a game.
The NES isn’t spinning up objects for every bullet on the screen or a million other ways a novice developer can blow up a GC.
No this doesn't look like NES graphics at all. This is more like the SNES era.
A bit offtopic, but if it would have been playable in the browser I would have tested it, but I don't want to download and install a (for me) random exe.
(and I don't see how performance could be an issue unless a major screw up, but like others have said, use a profiler. Sounds like memory leak from what was shared here)
> performance issues
What kind? It would be helpful to know what you're experiencing, attempts you've made to fix, etc.
Or is this a thinly veiled "I've been working on this for a while and it's taking longer than I thought and want some encouragement." Which is fine! It's a great thing to ask for.
It's probably worth reminding everyone here that it's possible to write slow code in "fast" languages and fast code in "slow" languages. The state of software as it stands today is horrendous, but seeing as no one here (author included) seems to know why it's slow it's probably worth reserving judgement.
If it wasn't for Javascript, that kind of game should have been able to run on a 2Mhz 8086 and 640kb of RAM.
Even with Javascript, there should only be a 10x performance penalty at worst, and getting to 2x penalty is feasible.
We do need to scale based on screen size though - copying pixels around is expensive.
But a low-end machine from 10 years ago should be mandated for all developers.
If you can't get a simple game like that perform well even when written in JavaScript on a semi-modern PC you wouldn't be able to do it in any language. It's certainly not the issue.
PC was ridiculed for its bad graphics capabilities by fans of other home computers. Only over time PC's capabilities for graphics and video games improved piece by piece until after many years PC fans had the last laugh.
they missed out, i reckon. whereas the commodore and atari users had heaps of fun and then moved over to pc anyway.. they'd have more colorful memories.
Do you have a profiler at hand?
If you have a friend who is encountering the performance problems enable profiling report export and ask them to send that over to you. Hopefully that'll show you what is taking so many cycles.
You can use developer tools in the browser to simulate slower CPU. Use performance profiling to find which functions are taking up the most time. Try switching to battery saving mode, it might throttle your CPU a bit too. If you really want to dive deep in performance improvements, you should purchase lowest end laptop with integrated GPU, if budget allows. And how about providing an embedded web version of your game, because downloading unsigned executables these days should be considered a no-no.
Intel i5-9350, UHD Graphics 620, Windows 11 v25H2
Completely unplayable. It runs fine at first, and then suddenly drops to below 1FPS for no discernible reason. This happens regardless whether I am on the world map or combat scene. I am running the exe, couldn't find the browser version.
On an unrelated note, I am surprised to see a JS program working without the usual 200MB NW.js runtime (as seen with RPG-MV)
That's because I'm using GemShell. It's tool that generates executables using, under the hood, Neutralino which is similar to Tauri (uses the OS's webview rather than packaging a Chromium instance).
More info here, if you're interested : https://jslegenddev.substack.com/p/export-web-games-for-desk...
Sounds like something is going really bad. I'd be very curious to know what's happening.
Just downloaded and tried it on my M1 Mac and the performance was what I'd expect for a game like this, both in and out of battle. Totally smooth and ~15% of CPU usage in both cases. By the way, I love the pixel art, and the gameplay has potential, it's a style I've never personally played before but I could see it being compelling.
Thanks for the feedback! Very much appreciated!
can confirm. very slow. here's the output I got on Debian 13 on an older i5, but it doesn't look like it's telling us very much.
Was really hoping you were making a small rocket propelled grenade
You may want to add instructions to the game currently it is unplayable
Not running a random "Linux build" (which is probably not going to find some lib anyway) - in 2025 the baseline should really be an AppImage.
[dead]
[flagged]
This is absolutely fine for someone to request on their personal blog to a group of followers who may well be interested in the game and support the author. People have used their blogs for this sort of thing for decades.
It wasn't posted by the developer.
I didn't realize that this wasn't posted by the dev, and that it was only meant for his normal subscribers. So my criticism is a little harsh here.
> Here is the link to where you can download it, and also maybe, you know... PAY FOR IT?
Why criticize someone for hosting their in-progress game on itch.io? That's... a completely normal thing to do.
Forget about performance, specially in a 2d game like this one. Focus on making it fun (really-really fun is possible).
I have played games that didn't performed so well because they were so fun. Games are about fun, anything else (narrative, performance, sound...) is secondary.
If frames are dropping, it's likely not fun.
Why not consult with industry professionals rather than random people on the internet? Gaming is a huge industry worth billions and have many people who have dedicated themselves to the craft. They not only can diagnosis common problems and future problems, but can help effectively change your processes, ultimately identify and solve these similar problems yourself. All for not that much money, you are in a good position to capture a bunch of value if you are serious.