T3D Awesomium Integration Pack - Released

#21 Wow, really cool stuff Stefan! I'm _very_ interested, been trying to settle on an alternative to Torque GUIs for quite a long while now. Just to clarify, it looks like the crosshair automatically changes to a pointer when you hover over a UI area that has more than your alphacutoff amount of color, correct?

Very nice work!

#22 Thanks Chris!

Quote:
Just to clarify, it looks like the crosshair automatically changes to a pointer when you hover over a UI area that has more than your alphacutoff amount of color, correct?

The crosshair is actually hidden and a cursor is drawn on the Awesomium texture itself, in the world. If you've played Doom 3, it's exactly the same.

#23 Oh, gotcha. So you could easily make different pointers for different awesomium draw targets then, I imagine. Very cool, will commence badgering my team to pick this up!

#24 That's a good feature, I'll implement it tomorrow and I'll update the pack. Right now it's hardcoded but I'll expose it to script and let each Target (or Context as they're called in the pack) be customizable with its own cursor bitmap.

Thanks for the suggestion!

#25 The pack has been updated. There's now a CursorBitmap property for each AwTextureTarget. The demo has been updated to reflect this feature, too.

#26 Well, that's what I call service! Good luck with the pack!!

#27 Thanks Chris!

#28 So hey, I bought it, plugged it in, love it, seems to be working fine! But I do have a few questions... first do you have any more sample code floating around? I'm still unclear on how you make the javascript talk to the torque script. In your Demo example I couldn't actually find any javascript except the jQuery thing...

Also, how do you hand over control to the "browser" in game? I'll have to plug this into a clean torque build, I have other things going on in the build I used it with, but so far I'm not getting the switch over to web page control, when I left click I'm still getting my normal bindmapping. (Will keep plugging away, I'm sure it's something dumb.)

#29 Hi Chris. Thanks for purchasing the pack!

Quote:
first do you have any more sample code floating around?

I'll hook you up with another sample and put it into the pack. Give me a few hours.

Quote:
In your Demo example I couldn't actually find any javascript except the jQuery thing...

There's JavaScript in the .html file which is responsible for talking to TorqueScript. It's the click handler at the bottom of the file.

Inside the Functions.cs file you'll find the calls from TorqueScript to JavaScript.

Quote:
Also, how do you hand over control to the "browser" in game?

This is done automatically by Torque (for instance when you click the control) but you'll have to instruct it to do so via its GuiProfile since it's not desired for all controls. For testing, you can use a GuiTextEditProfile, but those have borders too..

I should have mentioned this in the documentation, When I upload the additional JavaScript sample code, I'll update the documentation too.

#30 The pack has been updated with a new demo with another JavaScript sample which shows how to do bidirectional JavaScript <-> TorqueScript (seen below), more documentation and one fix for AwGui.

#31

Quote:There's JavaScript in the .html file

Oh, hehe, derp! Right where it should be. Got in a bit of a hurry there... :-P But thanks, now I'm getting it.

Still not getting my crosshair to pointer transition though, or accompanying "got focus" sounds... Didn't even realize there was going to be a torque gui involved, so far I've been just using the textured materials on TSStatics... but then I guess the new question is, how do you paint a torque GUI window onto a static object, so that you have something to set canKeyFocus=true on?

Sorry if I'm just being slow. Even without player interaction this has already done me a world of good! I was literally just settling into the project of filling a tutorial level with static ugly billboards painstakingly manufactured in gimp and sketchup, when along came awesomium and now I can do them all in html, even live off the web if I wanted to make it self updating.

Random side question: would it be terribly difficult to swap out awesomium for berkelium and keep using your wrapper on it? Or would that totally not work? (Or is berkelium even a thing anymore, now that awesomium is free for indies?)

#32 Ah, after some research, it seems I've been missing the boat since about 2006, on a little thing called "guiTextureCanvas":

http://www.garagegames.com/community/resource/view/10899/

However, that thread kind of peters out at the end with people asking about T3D... it seems this class has not made its way into the engine yet? Or has it? Has the name changed? Or is there a new resource floating around for it?

#33 This is going to get long. ;)

Quote:
Still not getting my crosshair to pointer transition..... Or accompanying "got focus" sounds......

This is because you're not using a AwShape, you're using a TSStatic. You *can* use a TSStatic, but they're not load-balanced and you won't be able to give them focus. Check out the mission file in the demo.

Quote:
Didn't even realize there was going to be a torque gui involved, so far I've been just using the textured materials on TSStatics...

Oh no, there's no Torque Gui involved if you're only using Shapes like you've been doing. There's a Torque Gui implementation too which is what you see when you first enter the demo, but it's separate from AwShape.

So you don't need a GuiControlProfile in your case. All you need is a AwTextureTarget, and a AwShape in your mission file.

Quote:
Sorry if I'm just being slow. Even without player interaction this has already done me a world of good!

Hehe, you're not slow. All you need is one change to your setup and you're good to go, ie use AwShape instead of TSStatic.

Quote:
Random side question: would it be terribly difficult to swap out awesomium for berkelium and keep using your wrapper on it?

Funny you should ask. The pack actually started as a wrapper for several different libraries (including my own) but Berkelium was actually a lot less stable (sadly, I was really happy about it until I started testing it). Berkelium precompiled was also tricky to use with some compilers because of name mangling, while Awesomium uses virtual interfaces so it works in most cases.

Additionally, Berkelium is based on Chrome which is LGPL. I didn't want into the legalities of that and compiling it from scratch was a nightmare, so I scrapped my own library and used Awesomium.

#34 Aha, there it is! Very nice, very nice. Clicking away like crazy over here.

Now the one remaining question: keyboard input? Does AwShape handle that as well? Or am I just getting greedy now? :-)

#35 AwGui does. There's no technical reason AwShape couldn't, but it's mainly for mouse input as that makes most sense. For keyboard input you'd have to disable player binds when you get focus as they use the same keys, and I was primarly looking to replicate Doom 3 ingame GUI's with AwShape.

Hope that makes sense. :)

#36 Right on, makes perfect sense, just curious. I could imagine it being pretty cool to be able to walk up to a web form and start typing into it... but what I *need* is exactly what I have right now, thank you very much sir!!!

Very nice timing indeed. :-)

#37 Hey Stefan, and anyone else using this pack, I was noticing some severe slowdown in my app since I installed it and started playing around.

After sniffing around for a while, I happened to open my task manager at one point and found 23 processes called "awesomium", all of which were using at minimum three or four megs of RAM, and some up to 140M.

As it turns out, every AwTextureTarget defined anywhere in script starts up a process and loads its webpage, whether or not it is ever used in the level. Like a dork, I had gone ahead and included the sample AwTextureTargets from the pack in my build, and they were pointing all over the internet at all kinds of memory intensive web pages... adding in one vimeo link of my own, and I got up to quite a stack of RAM being consumed.

For this reason, beyond obviously commenting out all texture targets that are not actually in use :-P, I also intend to put "cover" pages on all texture targets that point out to the live internet - ie, if I'm putting in a link to youtube, grab screenshot and put it in a small local html file, with the whole picture being a link to the actual youtube page, which doesn't load until someone comes along and clicks on it. I think this should reduce the memory overhead dramatically.

EDIT: Yup, worked like a charm. It's too bad all of the processes seem to bottom out at 3-4 megs, but when I click on my video that one shoots right up to 46 megs, and one of the other processes climbs as well (a central controlling thread?) Seems like a good thing to keep in mind anyway.

#38 Hi Chris,

Thanks for the feedback. This actually sounds like a bug, no processes should be started if the AwTextureTarget isn't referenced in the level. I'll attempt to fix this later today.

I do want to say that all those processes shouldn't slow you down any unless you're out of memory and swapping to disk. Each process is paused and its rendering stalled when the page hasn't been rendered in T3D for a short while.

I actually gave a lot of thought to automatic page pruning when I designed the pack, but decided not to implement it. The intent was to prune any page that hadn't been used for a while. Imagine you're the user though and you return to that page only to find it "reset" (ie, not at the point where you left it). That could be confusing. I could implement it and leave it customizable, and when the page is reset it would return to the last visited page, *but* any input in text fields, logins, etc (unless you're using a session) would be lost. What's your opinion on this, Chris?

Clever workaround though, didn't think of that. :)

I'll let you know when the fix is up. Thanks again!

#39 The pack has been updated.

• Fixed a bug where AwTextureTargets would load its webpage and start rendering internally, even though the target itself wasn't being used anywhere. This was not intended, and AwTextureTargets now only consume resources if they're in use.
• When the AwTextureTarget is no longer in use (for instance: if all shapes go out of scope, get destroyed or when switching missions) it will unload its resources.
• Fixed a crash that could occur when leaving a mission while focusing a AwTextureTarget and then entering a new one.
• Added a new property to AwGui named "UnloadOnSleep" which is a boolean value that lets you control if the AwGui should unload its resources completely when it goes asleep, as opposed to just pausing its rendering. This can be used to limit the amount of memory used when you got lots of AwGuis.

You can grab the update from here.

#40 Wow, thanks, lightning response man! :-)

This all sounds great. Downloaded!

----------------------------------------

EDIT: whoops, something went wrong... was there anything to do besides grab your new engine code files and rebuild? I got a running build that displayed my first texture target, but when I turned and brought my second texture target into scope it crashes hard every time.

In debug mode, the point where it dies is AwContext::update(), which was called from AwContext::getTexture(). Maybe I should try a full rebuild?

REEDIT: Nope, full rebuild didn't do anything. Fails every time as soon as I try to look at that second AwShape. All of it works just great in the update before this last one. The console doesn't add much but here are the relevant couple of lines:

Material - Billboard_TerrainMaster_Material(2225) - Failed to load diffuse map art/shapes/tutorials/#TerrainMasterTextureTargetName for stage 0
First-chance exception at 0x1141f00f (Ecstasy Motion_DEBUG.dll) in Ecstasy Motion_DEBUG.exe: 0xC0000005: Access violation reading location 0x00000041.