4 ms·

> Performance is not a feature! 100% disagree. We develop Construct 2 (http://www.scirra.com http://www.scirra.com) which is an HTML5 game engine and we take

> Performance is not a feature! 100% disagree. We develop Construct 2 (http://www.scirra.com http://www.scirra.com) which is an HTML5 game engine and we take every care to make the engine as well performing as possible. An example: We've written about Garbage Collection in JS: http://www.scirra.com/blog/76/how-to-write-low-garbage-real-time-javascript http://www.scirra.com/blog/76/how-to-write-low-garbage-real-... Garbage collection pauses can make games unplayable for HTML5 games and some of our competitors engines suffer from GC pauses which their user bases complain about. Games made with our engine don't suffer from GC pauses as much because we've taken care to make Construct 2 as well performing as possible, this is a good feature of our engine.

TazeTSchnitzel 15y ago
I also disagree. I'm working with some friends on a Python port of a small multiplayer game, which is quite heavy on image transformations. Because of this, we can't use some popular Python libraries like Pygame since they aren't hardware-accelerated [for transformations], and hence run too slow.
ralfd 15y ago
The author writes from the "native Apps" point of view.
- Arwill 15y ago
  Even for that it is not true. I call the phenomenon the "FPS wall". You cram features into the game, and the engine performs slower and slower. At some point you reach a certain low FPS (something like <20 FPS) and there is no way then to get back to better performance. That also means that you cannot put any new features in, because you would just make the game unplayable. And since the engine is flawed in itself, there is no way to optimize away the slowness. I don't agree with the author at all. Its much better to have an open source engine. You can customize it to your own needs by stripping out parts you don't need. Thus get performance by dropping features you don't need at all, and thus saving development time by not having to optimize parts you do need, but which take more time than they would be worth. If you don't care about tailoring the engine to the game you are writing, then the engine will show its restrictions on the game. And that is the road to mediocrity. Its not just the glitter, but engines tend to limit the gameplay too, if you let them.

TazeTSchnitzel 15y ago

I also disagree. I'm working with some friends on a Python port of a small multiplayer game, which is quite heavy on image transformations. Because of this, we can't use some popular Python libraries like Pygame since they aren't hardware-accelerated [for transformations], and hence run too slow.

ralfd 15y ago

The author writes from the "native Apps" point of view.

Arwill 15y ago
Even for that it is not true. I call the phenomenon the "FPS wall". You cram features into the game, and the engine performs slower and slower. At some point you reach a certain low FPS (something like <20 FPS) and there is no way then to get back to better performance. That also means that you cannot put any new features in, because you would just make the game unplayable. And since the engine is flawed in itself, there is no way to optimize away the slowness. I don't agree with the author at all. Its much better to have an open source engine. You can customize it to your own needs by stripping out parts you don't need. Thus get performance by dropping features you don't need at all, and thus saving development time by not having to optimize parts you do need, but which take more time than they would be worth. If you don't care about tailoring the engine to the game you are writing, then the engine will show its restrictions on the game. And that is the road to mediocrity. Its not just the glitter, but engines tend to limit the gameplay too, if you let them.