Just wanted to let you guys know that Awesomium 1.7 RC3 is finished and the team is just preparing the documentation now.

So very soon we will have a much faster exe exporter with direct to window rendering! Yay! I'm so psyched about this!

Can't way to try this - because I know Ashley will include this in one of his next updates. Let's hope RC3 is all we hoped for.

Same problem here - looking forward to the update :)

I get it if two objects is destroyed within about 0.05 sec or less.

Last I heard from them, they already solved the problem. We just need to wait for their next update so Ashley can include it in his next update.

Awesomium is a tad less regular on the releasing front though.

Never mind :)

Works like a charm!

lokesen www.scirra.com/forum/copy-an-entire-array_topic53153.html

Example: arrayWebstorageExample.capx (r103)

Wow!

That was 10 times easier than expected!

Thanks for the capx!

I have a hard time understanding this CAPX.

As I see it - it only stores the array to a global value that is saved with webstorage.

Then when you load it, it doesn't get back into the array again.

Can somebody tell me how to make this CAPX load the global value back into the CAPX please?

This is good news for me!!!

One step closer to releasing my game :)

The problem with Awesomium is that there's an indirection in the rendering. Awesomium by default generates a 'pixel buffer' for every rendering frame. An 'image' is then built from this buffer. Then the 'image' is showed on screen. That's overly simplificated but that's pretty much what happens. That really hurts performance. To get an idea in a real world example: If you have a web page rendering. The process runs one time at start to generate the web page frame. If nothing changes, ex.: No animation on page, no button clicked, nothing, there's no need to generate a new frame, no refresh occurs. Then when you move the mouse a refresh happens. In a game, which is highly dynamic most of the time, that process happens every time normally 60 times per second. So you get the idea. Of course that buffer copy can be optimized but it's not always enough. Then again of course there can still be a bug that makes things worse.

That doesn't explain why there is no difference between a very slow computer and a fast computer. Same performance with same resolution.

So while Awesomium maybe rendering slowly - there is clearly some kind of bug or bottleneck besides this.

I have run some test on different machines to determine the performance of Awesomium.

We all know the performence is poor especially in fullscreen, but there is more to it than that.

I have testet my game on these two machines:

AMD e300 with integrated GPU and a very slow cpu.

Intel i5 2500k + GeForce 560ti

Both machines run the game in fullscreen 1920x1080 with about 12-15 fps and 1280x800 with 35-40 fps!

Judging from this, it is clear that there is some kind of bug in Awesomium and that is not related to the performance of the CPU or GPU - but rather some kind of software bottleneck.

Please make your own tests with different resolutions on different machines to confirm this bug.

I'll write to the Awesomium team about this.

Cheers!

I got this random bug that crashes Awesomium. Sometimes it's when executing the exported program and sometimes it's after a few minutes running the program. Totally random and always different places. And it's the same no matter what construct 2 game I export.

I had no problem with R100 awesomium exports and stability. So I am interested in hearing if others have this problem too.

That said - all previous issues from R100 are gone, besides the slow performance in fullscreen. So that's pretty amazing for a weeks work Ashley!

I made a pretty advanced webstorage system with multiple slots and modes. It's actually amazing what you can save in a string with webstorage and also suited for RPG's and inventories. You just have to use some creativity and be very systematical about how you approach it.

If there is any place where two identical tiles is placed next to each other, then you can benefit from making them tiled background.

A 32x32 tiled background and a 32x32 sprite is equally efficient. But a tiled background that is made of 32x32 and is 512x512 or 32x512 is just as efficient as the 32x32 sprite or tiled background.

In other words - if there is no use for a sprite, always use tiled background. But remember that a sprite can do many other things a tiled background cannot.