Welcome to the forum. 😊

Icons have to be in the same directorty as the .xdk file. Also, i think they have to be png's. Does that help?

Still pretty much the same. Node 0.11 still janks, 0.10.5 is smooth as silk.

There might be some hope for the next node if they base it off of chromium v39, which isn't great but is certainly usable.

Prominent

I'm 99% sure that the same approach would work with the mac and linux exporters. Basically, delete the contents of the new mac32 or linux32 folders, copy in the files from the old. There are no 'old' 64bit exporters, as chromium 35 didn't have a 64bit version.

I can't test on mac, and I haven't tried yet on linux, so if either one works, please let us know.

Be aware that node-webkit on linux is still suffering from a missing dependency on newer versions of linux. My understanding is that this problem will be around for awhile yet. See here for more details:

https://github.com/rogerwang/node-webki ... budev.so.0

—

I just don't get why this isn't farther up the priority list. I thought Google wanted us to move toward rich web, cloud computing, and browser based apps...so why is this fundamental display glitch still around?

I really don't have anything against the devs, and it may very well be a difficult problem to solve. I'm just baffled that this hasn't commanded a higher priority.

When simple games drop frames on a powerful laptop/desktop, it's hard not to come away with the impression 'This isn't ready for prime time'. It reflects bad on us -- the developers trying to create content to power the rich web -- and in doing so, damages people's perception of the browser as a new kind of OS, one of Google's primary goals.

It's frustrating because it feels so damn close with Canary...

—

On my system, this is still an issue with the latest version of Canary. When V-Sync locks correctly, it's excellent, nearly as good as IE. But it seems to randomly malfunction, causing a terrible stutter every 2-3 frames. Resizing the window usually fixes this, but this glitch has persisted for over a month now.

Chrome v39 is better than 38, but it's still not as smooth as a well behaved instance of canary, much less IE.

It's looking like we are a long way from a smooth running version of node, short of using 10.5.

—

Just noticed this on the XDK site:

[attachment=0:629qg6qh][/attachment:629qg6qh]

I guess you're famous

Elliott grigrizljac

Love that idea...so simple! Though, it might break your game later on if you wanted to host it elsewhere, meaning you'd have to re-export it (and what if you lost your project file?). Maybe just some sort of warning or notification instead.

Might be possible at some point thru node-webkit. Node tends to have some additional functions that are more targeted toward desktop systems (like proper filesystem access). You could always put a bug in their ear.

Or maybe I don't know what I'm talking about.

. . .

...Nah.

Actually, that's a pretty good reading. Even at the high end (12,000), that's only 200 checks per tick. If you are only incurring around 2*objectcount number of checks, you are doing something right.

Technically it would be a bit more efficient. In real use, comparing two numerical values every tick is a trivial process, even on a mobile.

The else logic strikes me as being possibly confusing, but that may just be me. Use whichever approach you find easier to understand.

The thing that can kill here is the 'is visible' command. If you plan on having a lot of these objects present in the layout (>100), you should make sure that this logic only runs when triggered, instead of running as a 'dumb test' every tick.

If there will only be a handful of these objects in the game at any one time, I wouldn't worry about it.

Here:

https://www.dropbox.com/s/ysgq9jbgydm37 ... .capx?dl=0

Can't you use Sort and Reverse together?

capx:

https://www.dropbox.com/s/59hs3a7n8e030 ... .capx?dl=0