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

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?!

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).

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.

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.

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

[quote:id3nxi9j]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.

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?

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.

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.

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.

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.

Ashley Well, thanks for ruining my game Ash.... You see I decided to check the performance link you gave me, and I figured I'd take care of some of the easier ones, so I started with "Avoid objects with large areas of transparency." and guess what happened?!?!

After I shift+croped my assets every level that wasn't currently opened got fucked up! Weeks of work down the drain.... And of course I had to notice it only after I just finished the last level, saved and closed C2, so now I can't even go back and freaking undo it! I have to manually fix every element on each of those levels and reinput their normal/initial size.

Well mate, when you have any other bright ideas let me know, I'll be sure to jump right on them.

P.S. If I sound bitter, that's because I am.

Ashley Well, thanks for ruining my game Ash....

You can't blame him, because you changed your project without first checking what effect will that cause. Not to mention not using C2's backup system.

Next time I recommend saving the project with C2's backup system (2 or 3 should be enough), and if you have an acceptable size of cloud storage, you should save your project there (Dropbox has a 30 day file restore option for example).

> Ashley Well, thanks for ruining my game Ash....

>

You can't blame him, because you changed your project without first checking what effect will that cause. Not to mention not using C2's backup system.

Next time I recommend saving the project with C2's backup system (2 or 3 should be enough), and if you have an acceptable size of cloud storage, you should save your project there (Dropbox has a 30 day file restore option for example).

I don't use the backup that much, but whenever I am about to do something that I may not like or may have unknown results, I save the project under a new name such as v1, v2, a, b, whatever. Then, if I don't like it, I can just go back to my previous file. It's much easier than trying to hit undo a ton of times or hoping I don't save over something and break it.

Ok, I've calmed down a bit, I've been told I might have a problem with impulse control, who knows.

So yeah, maybe it's not his fault, sorry Ashley, but glerikud, Drew you guys are getting all it wrong.

It's not that I didn't have a clue what I was doing. I knew exactly what I was doing, and understood perfectly what was supposed to happen, this is a bug.

When you open up an object that has multiple animation frames and you press shift+crop it's supposed to remove the transparent pixels on all the animation frames. And it did, but only on the layouts that where active at the time! On every other layout that had those objects that wasn't opened it bugged out, and instead of croping them it resized them to some very blurry, ugly, 128x128 or 64x64 sizes. What's even more puzzeling is that none of those bloody sprites where 128 or 64 to begin with.

So what I have to do now is jot down the correct sizes of every frame of every object from the layouts where the croping worked, and go to all of the other layouts and manually change each object(we're talking about hundreds of instances) to the correct size that the crop should have made them!....

So was I wrong to blame Ashley, maybe(depends on wether or not he knew about this bug imo, cause he could have given me a heads up), and if so I apologize, but considering how much extra work I have to do now, and how much time and effort I put into it in the first place getting everything set up just perfect, I think my fustration should be understandable...

And yeah, I get the point about saving often and in multiple places, but I usually think of that in terms of not losing my work if the power goes down, or if I am actually about to do something new that I don't fully understand; I however am not used to thinking about bugs in a version that is clearly labeled on the site as stable.

But heck, maybe I'm wrong about that too, I don't even know anymore...

That's very unfortunate you had a development disaster. I've had them myself. All I can suggest is that you pass your experience on to others.

Assist starting devs by suggesting to start with simple projects to learn and reading blogs/tutorials that focus expectations. The number of people jumping into the deep end are staggering. Then when their mobile network games doesn't work it's the engines fault.

Back and version control is essential with any big project.(i've had my life saved a few times because we used bitbucket)