> I feel your are right: even the performance of a simple platform game (Kiwi) is very underwhelming on a i5 machine with 4gb.
Please provide actual benchmark numbers, otherwise this kind of statement is worthless.
My office machine can render over a quarter of a million on-screen sprites at 30 FPS in Chrome, so you can get great performance in a browser. A single actual measurement is worth more than an entire forum full of vague statements.
What is your office machine's spec, if you don't mind my curiosity? By the way, shouldn't you be testing at 60fps instead of 30fps?
Celeron N3050 (8GB ram, 850gb SSD and Intel graphics) laptop with Linux Mint
older Windows 7 zhg33.1ufd@5i 4GB tablet Intel HD graphics
I made certain to update all drivers to the latest ones.
I am attaching screenshots here: imgur.com/a/J3nUo
I discovered that the fps tops at 30fps for the Kiwi game on the older Windows machine (which explains the 'slow' feel), but runs at 60fps on my Mint system (vanilla browser window without inspect element active).
The frame rate is quite irregular on the whole on the old Windows machine, and stutters and yanks happen while playing. This does not happen on the Linux laptop.
Running the debugger on both machines impacts the fps a lot. A similar platform game in Godot keeps running at 60fps when the debugger is run. I also tested the profiler in Godot, and the preview keeps running at 60fps on both machines. I wanted to turn off parts of the debugger in C3, but it would not let me.
Inspect element and its fps counter causes the shooter sample game to run at 30fps, but runs at 60fps on the older Windows machine.
It's a mixed bag of results, really. I cannot benchmark without the debugger or inspect mode in Chrome, and both slow down the Kiwi game preview.
I can only say that:
+Godot runs fine throughout on both machines with or without the debugger running, while Construct 3 struggles on the older Windows machine.
+Construct 3 on my Linux Mint machine runs okay, although is not as responsive as Godot. As I said before, it takes a fraction of a second longer to register mouse clicks in Construct 3 compared to native apps. I blame Chrome here, not Construct 3.
+The debugger slows down simple games in Construct, even on the Linux machine.
+ It's hard testing Construct 3, because the sample projects are relatively simple games. I'd love to see a larger project tested.
I'll wait until the final version is out, and do some testing again then.
This argument would be more valid if 30fps was the target, possible to achieve steadily, or possible to lock a game at. With an entirely variable framerate, and with the default (and uneditable) target being 60, this doesn't really mean anything, as a performance benchmark or for what's possible to achieve in a commercial product. Wildly varying framerates, which is what we currently have to deal with any time a Construct project drops below 60, looks like absolute garbage and is a great way to get lots of complaints from anyone who purchases a game with a variable framerate. We don't live in 1996. Slowdown and frame drops aren't expected 20+ years later in 2D games.
I tend to agree. Although perhaps we are expecting too much from lower spec'd hardware and Construct 3 games running in Chrome? I don't think it is the C3's developers' fault - Chrome looks like a resource hogging beastie after my experiments on both Linux and Windows.
I see more and more complex web applications being offered lately. Let's hope Google will take note, and improve their brower's performance for demanding web apps.