hendrikp / cryhtml5 Goto Github PK

And in a way I have, but probably not in the direction you were thinking.

I've hacked it (square peg, round hole, very heavy hammer) into working with DirectX11 directly as an alternative to Coherent-UI.

It is (if I can say nothing else positive about it) building against the current release of CEF (and I'm not saying it wasn't previously).

And it does work, it works great.

I have, however, hit a rather large SMACK ME IN THE FACE brick wall.

I was trying to implement JavaScript functionality in what we can arguably call "the opposite direction." - at least in respect to what you've coded for. So-called "Window Binding."

Firstly I naively copied this lovely example:

CefMessageRouterConfig config;
CefRefPtr<CefMessageRouterBrowserSide> browser_side_router_ = CefMessageRouterBrowserSide::Create(config);
CefMessageRouterBrowserSide::Handler* handler_ = client::binding_test::newHandler();
browser_side_router_->AddHandler(handler_, 1);

Which compiled fabulously but provided no functionality.

After some digging, I discovered the concept of Render and Browser threads, and then that you do not actually inherit from CefBrowserProcessHandler or CefRenderProcessHandler. In fact, I realised that for all the hacking around in your code, I didn't even know for sure that it had separate threads.

Oh, I'm not an idiot, I'm sure it has threads, I'm just at a bit of a loss as to how to go about binding to the render thread.

I've worked with Awesomium and even with a custom in-house WebKit derived framework, and am almost nauseatingly familiar with the:

frame->ExecuteJavaScript("alert('ExecuteJavaScript works!');",

method of JavaScript interaction. At the time (several years ago now), I remember going to some lengths to achieve faux async operatings through repeated polling and other such hideousness.

But now that there is the possibility of doing this:

void MyRenderProcessHandler::OnContextCreated(
    CefRefPtr<CefBrowser> browser,
    CefRefPtr<CefFrame> frame,
    CefRefPtr<CefV8Context> context) {
    // Retrieve the context's window object.
    CefRefPtr<CefV8Value> object = context->GetGlobal();

    // Create a new V8 string value. See the "Basic JS Types" section below.
    CefRefPtr<CefV8Value> str = CefV8Value::CreateString("My Value!");

    // Add the string to the window object as "window.myval". See the "JS Objects" section below.
    object->SetValue("myval", str, V8_PROPERTY_ATTRIBUTE_NONE);
}

/* javascript */
alert(window.myval); // Shows an alert box with "My Value!"

I'm quite excited.

Unfortunately, I cannot seem to jam in a facsimile of OnContextCreated (that would have been too easy) and have had epic failures trying to implement things like:

CEFCryHandler::CefRefPtr<CefMessageRouterRendererSide> renderer_side_router_ = ...

causing eventual crashes, due to the rather stubborn insistence of &browser->GetMainFrame()->GetV8Context() to always be NULL. I may have had success if I could have identified a better point to initiate, OTOH I might have the third end of stick.

It has occurred to me, that there may be issues related to spinning off threads when you're a DLL hooked into an already large executable process that doesn't belong to you, and that there may be reasons that I do not presently understand preventing me from accomplishing Window Binding.

As I said at the start, I know this is not a project you are overly-invested in, but it looks like I'm the only person who has done anything further than just fork your project... even if I am butchering it. (And FTR, almost all the CryEngine bindings are still there, they've just been removed from requiring the actual engine. Had to loose the plugin manager too, unfortunately.)

If you have any time to make suggestions, I would welcome them. Other than the obvious one, which is just use Coherent-UI. That's not an option, because I'm not a game developer, just a "mod maker."

One of the first tasks would be to remove the dependency to the Plugin_D3D which is no longer needed as CryENGINE V is now shipping full engine Sourcecode. So one of the first things would be to extend the CryENGINE V Renderer interface to reliably update/exchange the HTML rendering surface, once this is done the Plugin is ready for its release.

The plugin was already fully working on older CryENGINE versions see here: https://www.youtube.com/watch?v=YphBFbS93EU

This issue and project itself can be taken on by anyone with intermediate C++, DirectX and CryENGINE experience. Happy Coding ;)