Posts by DracisLooby

Welcome to our brand new Clickteam Community Hub! We hope you will enjoy using the new features, which we will be further expanding in the coming months.

A few features including Passport are unavailable initially whilst we monitor stability of the new platform, we hope to bring these online very soon. Small issues will crop up following the import from our old system, including some message formatting, translation accuracy and other things.

Thank you for your patience whilst we've worked on this and we look forward to more exciting community developments soon!

Clickteam.

    I will chime in with some info;

    First thing, if a resource is accessible on the internet through a browser, it can be downloaded, modified, and reuploaded, by whoever can access it, with readily available tools, most of them built into nearly every desktop web browser. If a resource gets used by a client, you can be sure it can be saved, and reproduced.

    More specifically, the HTML5 Runtime is written pretty much solely using web technology that is served 100% to the client when in use, this includes the runtime code, your apps specific fusion bytecode, and all its sounds/graphics. All of this is loaded up front, or on demand by the runtime.

    Unfortunately, its pretty much 100% impossible to stop anyone from copying and using a public internet resource, but we do take heavy steps to deter the behavior, and make it very difficult to do so in the HTML5 Runtime, and I will not say its not impossible, but its a bit above non-trivial to de-obfuscate the runtime.js code and understand it after its been 'compiled', however, the real challenging task would be going through and reverse engineering an apps fusion formatted bytecode by hand, since its not laid out in a datastructure, but read byte-by-byte in the html5 runtime. For the most part, the code behind your apps is fairly difficult to get from HTML5 apps, therefore 'safer' in a sense, but the graphics / sounds / runtime code are all readily available.

    Again, all that said, you must not trust that anything that anyone can access publicly from the internet cannot, or will not, be stolen, copied, and / or redistributed, its just part of the nature of the WWW.

    Huh, the code for this is already pretty much implemented, the only difference is instead of drawing a solid color at the beginning of each frame to clear it from the last, you just clear frame to alpha/transparent.
    I will ask about getting a toggle check-box for 'Clear Frame Background' added in asap.

    I am still researching this issue pretty heavily, I have yet to find a portable solution,
    IFrames are under a pretty restrictive set of rules.

    There is currently a fix I've been testing, but it only works if the IFrames are 'secure', or hosted on the same domain and sandbox settings set to allow it.

    The issues is that when you use IFrames, you imbed a page into a page, each can have its own JavaScript context.

    The event for getting focus can be emitted in JavaScript by both the parent page, and by the child page, but it does not trickle down from parent to child, so even if the parent has focus, the child never receives the event, making the application freeze, because it technically does not have 'focus'.

    I can listen for the parents events if the IFrame content is considered 'secure', but if the content is from a different domain, or the IFrame has set its sandbox security too high, It will actually cause a security exception when I attempt to listen for the events on the parent page.

    Finding a cross platform work-around is going to have to take a creative approach, and I've been looking for one.
    When I find out more about a potential fix, I will update more.

    MJK, that would be an unintended side effect of FGL using 2 Different domain sources for their content, which makes the bug very tough to solve.

    I attached event listeners to the top level page, but the issue stems from security concerns over content coming from 2 different addresses. My Chrome didn't have this error because I tested it all from my local machine on one address, so this puts a minor complicated spin on how this bug can be solved, I will have to do a lot more research into it.

    Also, I still can't seem to reproduce the error on my iPhone 5c, do you have an Example MFA I could take a look at? I want to get it solved, it looks like an annoyingly simple bug to stomp if I could just find the source of it.

    CrystalNoir - WebGL for 3D, or WebGL Implementation of the 2D Runtime? I'm learning Three.js to make a usable 3D WebGL extension, but porting the whole Runtime rendering code might be a bit of a challenge.

    ximo - I Don't have a Windows Phone to test with, but If I did, I would work to make sure the Runtime is as cross-platform as possible, I will look into a simulator if there is one.

    SolarB - I am looking into getting the default shader stuff working, but I'm also researching Canvas shading. The issue so far is only performance, because shading must be manually implemented, and unfortunately done on the CPU instead of the GPU.
    One solution I need to experiment with might be to copy and project a hidden 2D Canvas at each rendering stage onto a 3D WebGL canvas, shading it with the WebGL GPU support, then pulling that texture back out onto the visible canvas, though it might be too slow, and alienate mobile devices that don't support WebGL.

    Heya,

    I decided to create a basic extension for interacting with HTML5 WebWorkers.

    WebWorkers are scripts that are run in a separate thread then the main JS execution.
    When you create a WebWorker, it spawns a real OS level thread, and run concurrently to the main thread, thus not blocking it.

    You can post messages to the WebWorker, and can receive messages from the Worker. Also, errors in the scripts don't interrupt the main thread, but just fire an event that can be caught and listened for.

    If you're wondering why this matters, or what its useful for; You can put server I/O onto a separate thread, do heavy math calculations, or even hold use it to hold variables, all outside the main threads memory, meaning no hitches, pauses, or stutters in your application.

    As labeled, this extension is experimental, its designed for advanced users, and requires knowledge of JavaScript to create the WebWorker Scripts.

    The extension includes a help and example files.

    Please login to see this link.

    I'll post a link to an example later when I make one.

    Let me know what you think!

    Heya Everyone,

    I've just realized after a month, I haven't introduced myself before; I'm Ben Otter (Dracislooby on the Forums and in the chat)!

    I recently started working for Clickteam on the HTML5 Runtime/Exporter, mostly because I know JavaScript and Web Technologies pretty thoroughly!
    My Job is to Fix Bugs, Optimize, and add new Features to the HTML5 Runtime, making it the best I can, as well as develop and release HTML5 extensions from time to time.

    I also try to be in the Clickteam Live Chat app (Click Converse) every weekday to answer questions and offer help for the HTML5 Runtime, and Fusion in general, as well just chat about anything.

    So far most of my changes have been internal, or are still in progress, but I have a lot of cool new ideas to make the HTML5 Runtime more robust, like refactoring it to be easier to insert into web pages, and even run more then one app on a page at a time, but that will all come in time.

    That's all I can think to post, but if you have any questions or comments about me, my qualifications, or what I'm working on right now, feel free to post and ask any questions to this thread or PM me!

    Other then that, hope you all have a good day!

    Found it, I'm pretty sure I've found the source of the bug, and got a fix working.

    The Issue seems to stem from FGL using HTML IFrames to isolate games. Clicking outside the IFrames would make the game loose focus, and never regain it, even when clicked.

    My fix for this is to have the HTML5 Runtime detect if its in an IFrame, and if it is, listen to the parent pages events for gaining and loosing focus, instead of its own. This seems to work in my tests on Firefox, Chrome, Internet Explorer 10, iOS Safari, and Android Chrome, but It still needs more testing, and it might not work if the parent window forces the IFrame to be sand-boxed.