I just don't get it...(performance question)

Discussion and feedback on Construct 2

Post » Mon Jan 12, 2015 12:26 pm

Hello World,

So your average smartphone/tablet is what, a few thousand times faster then a nes? So then how come we still have to worry about how many sprites we can display on the screen at the same time without lagging the game, and how come that number doesn't seem to have changed much since the nes era?!
B
21
S
11
G
6
Posts: 414
Reputation: 5,335

Post » Mon Jan 12, 2015 12:41 pm

that come from 3 things I would guess:

first, the nes did not have an entire OS to run while the game itself is running
second (perhaps the most important one), they may be far more powerful CPU wise and GPU wise, but that means not a lot if their support of html5 and javascript is poorly done .
third, the control level is not the same nor what you can do, as far as I know, on a NES you could only have a limited amount of sprites on the same line, with limited colors, all sprites having a relatively similar size behind the scenes, at low res, no rotations, no sprite scaling, but you could monitor and control everything at the roots of the system with no useless interactions, which you do not have with a browser based engine, with a huge layer of optimisation being done, while with C2 people struggle much more to optimise, and tbh wrappers and browser vendors are not that reliable.

a smartphone like the iphone 6 can handle gta san andreas so comparing to an NES natively is not accurate. (edit:even comparing to a NES within the realm of html5 and js is inaccurate).
Game design is all about decomposing the core of your game so it becomes simple instructions.
B
52
S
22
G
18
Posts: 2,122
Reputation: 17,093

Post » Mon Jan 12, 2015 1:03 pm

Hmmmm, yeah, I guess those things should count for something... ;) I still find the situation extremly funny/deplorable. It seems like we've gotten so far, but at the same time like we haven't really moved at all.
B
21
S
11
G
6
Posts: 414
Reputation: 5,335

Post » Mon Jan 12, 2015 1:19 pm

JavaScript is very slow comparing to other programming languages.

Scirra does not take any responsability for good working of the final product (without jittering, micro-stuttering) made with Construct 2. You will always hear expostulations and promises of the better future.
B
18
S
6
G
1
Posts: 783
Reputation: 4,187

Post » Mon Jan 12, 2015 2:01 pm

From http://nintendo.wikia.com/wiki/Nintendo_Entertainment_System:

The NES had 48 color pallets available and five different shades of grey. Twenty five different colors could be used on a single scanline. At one moment sixty four sprites can be shown on screen (each sprite must be 8x8 (minimum) pixels or 8x16 pixels (maximum)). A maximum of eight sprites can be placed on a scanline at once. ... The picture resolution for the NES is 256 x 240.


The genius of games on the NES was that they were fun and looked reasonable despite those stringent technical limitations. The games were probably extremely difficult to write, and probably involved hand-written assembly taking in to account the specific CPU and GPU architecture in use on the NES. It was also mains-powered (so no constraint on designing low-power chips) and 256x240 is only 61440 pixels (at 8 bits per pixel I think, so ~60kb).

A modern phone might be running at 1920x1080 in 32 bit color with arbitrary scaling and rotation - none of those limitations on colors or scan lines. That's about 8.2mb of pixels (135x as many as the NES). They run on very low power chips to save battery (and have to support a wide range of hardware), and Javascript has some overhead (although modern JITs are good at compiling the important bits to machine code). And despite all that, I can still get 20,000 sprites on-screen at 30 FPS on a modern phone, which is quite a lot more than the NES's maximum of 64! So I think there's been far more progress than you imagine.
Scirra Founder
B
387
S
230
G
87
Posts: 24,249
Reputation: 192,240

Post » Mon Jan 12, 2015 2:17 pm

True that, you have a point @Ashley . But looool how come you can get 20k sprites with 30 fps when I've seen other posts of people having problems with even less then 64 sprites? What is your secret, please teach us ohhh mighty grasshopper, or are we really just that bad at optimizing and "coding" our games? ;)
B
21
S
11
G
6
Posts: 414
Reputation: 5,335

Post » Mon Jan 12, 2015 2:53 pm

VIKINGS wrote:True that, you have a point @Ashley . But looool how come you can get 20k sprites with 30 fps when I've seen other posts of people having problems with even less then 64 sprites? What is your secret, please teach us, or are we really just that bad at optimizing and "coding" our games? ;)


Like ANY game engine, there are limitations, but this doesn't mean you can't achieve what you want. I used to think C2 just wasn't powerful enough, but over time I found that 99% of the issues I faced were because of poor use of events, too many effects, using every tick for everything, or mixing behaviors improperly. I downloaded countless .capx files and dissected them to learn.
Image Image Image
B
61
S
19
G
6
Posts: 325
Reputation: 7,944

Post » Mon Jan 12, 2015 3:12 pm

Unfortunately, C2 is so easy to use that a beginner can very quickly make a simple game in no time. This leads to some having much bigger ideas without the expertise to accomplish them.

It's a simple case of unrealistic expectations, whereby the the vision of the user far and away exceeds their ability.

If they read the tutorials and blogs, look at well-structured examples (important) and test often, the mistakes that many run into could probably be avoided.

As with many of these type of programs, a programming background is not necessary, but is preferable to get the very best out of the engine.
If your vision so exceeds your ability, then look to something closer.
Moderator
B
131
S
29
G
81
Posts: 5,328
Reputation: 56,630

Post » Mon Jan 12, 2015 3:38 pm

Poor performance with such a small number of sprites almost always comes down to one of two causes:

1. Extremely inefficient game design, often in direct and extreme contravention of our guidelines as performance tips
2. GPU blacklisting due to poor quality graphics driver (common on old Android devices), so it reverts to software rendering. (Nothing we or any HTML5 developer can do about that - if the browser enabled GPU acceleration, the buggy driver could crash the whole system.)

If you have any examples of poor performance that are not either of those causes, I'd definitely be interested to take a look. I very rarely see any such examples.
Scirra Founder
B
387
S
230
G
87
Posts: 24,249
Reputation: 192,240

Post » Mon Jan 12, 2015 3:51 pm

Cool, thank you for the link @Ashley , I'll be sure to give it a good read. And yeah, if I ever come across one of those examples I'll definitely let you know.
I know the feeling first hand @zenox98 , I myself had to "downscale" my expecations a bit since I started this whole thing. :)
B
21
S
11
G
6
Posts: 414
Reputation: 5,335

Next

Return to Construct 2 General

Who is online

Users browsing this forum: No registered users and 6 guests