So you're suggesting I record the positions of my objects during a sample bit of gameplay, then re-animate them using that database? That's a really clever idea. The problem in my use case is the sheer number of objects (around 1000-2000 onscreen) I'd need to track...logging all that data would be bound to induce some slowdown.

BTW, I tested your link, and I saw much what I expected: after a breif 'settling down' period, IE produced the smoothest result...virtually no jank. Chrome had a much lower cpu usage than IE, but it's jank did not 'settle down' after awhile. Firefox, needless to say, janked the worst.

I saw this too...I've been meaning to post some reply for the last few days.

I ran the following benchmark 5 times each in Chrome, Firefox, and IE:

http://google.github.io/latency-benchmark/

However the results were far from definitive, or consistant:

https://www.dropbox.com/sh/1xjqtzq8hp9u ... wLABa?dl=0

I also tried to record some gameplay from my project Nebular Drift...but I haven't been able to find any screen capture program that doesn't slow down performance, record at the wrong frame rate, playback at the wrong speed, cause a bunch of extra jank...or do all of the above! I've tried:

Camstudio

Hypercam

Fraps (free version)

VirtualDub(Couldn't get the settings sorted out)

If anybody can give me some pointers on this, I'd be grateful.

In other news, I've been working on a data logger that can be dropped into any c2 game to track cpu, dt, fps, objCount, and ImgMemUse. Also, some logic to write out said data to a graph (that's taken a lot more work). The logger is pretty simple and only needs a bit more work; I'll probably upload the graphout capx separate.

Screw reality. I'm waiting for the Oculus Rift.

Congrats on the podcast! Downloaded all 3, looking forward to hearing them! BTW, do you guys have a RSS somewhere that I'm missing? I'd love to add this to my gpodder.

In the game I'm working on, I have a master layout that the game takes place in, along with some extra layouts for the menu. I also have a bunch of layouts that represent my level layouts, named "1,2,3,etc...".

When I run my game, I have an event sheet that loops thru all these layouts and loads their data (objects, position, time limit, etc) into a dictionary. I then use that data to spawn out my levels onto the master layout.

The main reason I built the game this way was that, up until recently, there were no global layers. So, essentially, if I had 100 layouts for 100 levels, and I wanted to change some of the background FX, layer properties, etc, I would have had a huge amount of work to do, and the possibility of missing a layout, or corrupting some other settings.

That being said, with the system in place, I have some advantages. Memory isn't a problem for me, because I have a minimal set of objects and almost all of my animations are procedural, so that aspect of 'layout per level' is moot.

On the plus side: with this system, I can control object spawning, and break it up over a number of ticks if need be. And, since my levels are being spawned out of a dictionary, I can output as JSON to a text file, and simply update said text file to update my levels. So, instead of having to have people redownload my whole game if I change something in a level layout, I can just update one text file instead.

I'll bump this. And I'd like to have everything shinkan listed, but if I had to pick one, it would be groups.

jayderyu

That's a good suggestion. I still like having certain values as normal globals so I can tweak them easily during development. Also, the one drawback with the dictionary is a lack of auto-fill. However, there are a lot of less important global values that would be much better off in a dict like you suggest.

Another approach is to create a global sprite, and place it on a global layer. Then, add instance variables to it. This way you don't have to worry about mis-spells, you have auto-complete, and you still avoid cluttering up the top-level scope with normal globals.

All other requests not withstanding, I'd like to continue from the comment I just left on r185:

...you, thank you, thank you, thank you, thank...

eli0s

Well, Ashley's second bug report for chrome got assigned very quickly...of course, the title was "Chrome is janky compared to IE11 in HTML5 game". IE is much better than it used to be, but frankly, it seems as though the general perception is still 'IE sucks'. If you can quantifiably show that IE does something better than firefox, there will probably be more interest.

Maybe the new bugzilla entry should read: "Firefox lags behind IE in realtime HTML5 performance".

Ah, yes. That's unfortunate. Did you try firefox and chrome? I'm quite dismayed to see how badly my prototype performs in firefox, though admittedly it's a tough case (on the high graphics setting, there can be as many as 2500 objects onscreen, between player bullets, enemies, and enemy projectiles). Chrome does jank now and then, but it's definitely not as severe as Firefox.

BTW I tried that test in IE11 and the dt variation is sometimes much smaller (22-24ms) but it still looks pretty bad on the motion. Are actual games any better or worse in IE11? (I think a bug report with a title like "Chrome does X worse than IE11" should get their attention - it's worked before )

Subjectively, I've always noticed that IE seems 'smoother' than chrome/firefox, even if chrome/firefox is reporting lower cpu usage/higher frame rates. I haven't tested many other people's games in IE, but I've tested a number of my own projects.

It would be nice if there was some way to indicate to browsers that a page should be run in 'high performance mode', ie, long GC delays should be avoided if at all possible, display performance takes priority, and all logic should be compiled to the highest efficiency code possible, ASAP (preferably on another thread, like IE does).

This looks good, and I should probably give some better feedback, but frankly, you had me at 'Exploding Donuts'.