C3 runtime SDK documentation now available

1 favourites
From the Asset Store
Telegram Mini Apps SDK is a plugin that allows impliment Telegram Mini Apps features.
  • The C3 runtime SDK download for plugins and behaviors is now available. The addon downloads now include C3 runtime ports to demonstrate how they work. Find the downloads here: https://www.construct.net/make-games/manuals/addon-sdk

    (Note the effects SDK has no changes; it's 100% compatible with the C3 runtime already, because it doesn't involve any JavaScript code.)

    The initial version of the C3 runtime API documentation is available here: https://www.construct.net/make-games/manuals/addon-sdk/runtime-reference

    The runtime has a very large API surface. The documentation does not yet cover everything, but it should be a good start.

    For more information on how to make an addon for the C3 runtime, please see the new section on Runtime scripts in the guide. This is not yet 100% complete - it still needs to cover how to access DOM features when hosted in a worker, but there's no way to test that yet, so it's not covered for the time being. Please also note the section about use of private or undocumented API calls; you should not use these, we won't provide support for them, and we can't guarantee they will be kept backwards-compatible.

    Hopefully this is enough to allow addon developers to start porting to the new C3 runtime. If you have any questions about the new C3 runtime SDK, or need any particular areas that aren't covered at all to be documented, please let me know!

  • I'm about to migrate my plugin to the C3 runtime.

    Now expression methods should return the value using "return" statement instead of calling ret.set_int/set_float/set_string like it was in the C2 runtime. It's cool and all but I need to support both (C2 runtime and C3 runtime) versions of the plugin and the last thing I need is having two of every expression methods that are almost identical.

    I thought I could avoid having identical methods by doing both "return" and "ret_set":

    Expression() 
    { 
    	// code goes here ------------
    
    	ret.set_any( result ); 
    	return result;
    }
    
    

    But it doesn't work because when running in C2 runtime Construct says Assertion failure: Plugin mistake: Don't return values from the expression method - call ret.set_int/set_float/set_string instead

    Is it really that necessary to not let me use "return" statement in expression methods? It would be so much more convenient if I could.

  • It won't work in the C3 runtime either, because ret is not defined. So, sorry, that won't work at all.

    It's a trivial change - we've done it for all the official addons and I don't think it's really a big part of porting an addon.

  • Well it does work because it's actually:

    Expression()
    {
    	//- C2-C3 COMPATIBILITY ------------------------
    	var params_ = Array.from(arguments);
    	var ret;
    	
    	if( __CONSTRUCT3_RUNTIME3__ )
    		ret = {set_int(){}, set_float(){}, set_string(){}, set_any(){}};
    	else
    	{
    		ret = params_[0];
    	
    		for( var i=0; i<params_.length-1; i++ ) 
    		params_[i] = params_[i+1];
    	
    		params_.pop();
    	}
    	//----------------------------------------------
    
    	// runtime-independent code goes here ----------
    
    	ret.set_any( result );
    	return result;
    }
    

    The question is why does the engine throw this error when it's actually a mere warning that doesn't break the game, the engine, and doesn't even show when you export the game (it only shows in preview mode).

    It's easy to say that it's a trivial change when it comes to someone else's code. It hurts that I can't come up with the workaround that's convenient to me just because of the error that's not even a real error.

    It won't work in the C3 runtime either, because ret is not defined. So, sorry, that won't work at all.

    It's a trivial change - we've done it for all the official addons and I don't think it's really a big part of porting an addon.

  • I ended up doing this and it works fine:

    if( __CONSTRUCT3_RUNTIME3__ )
    return result;
    else
    ret.set_any( result ); 
    

    But still...

    It won't work in the C3 runtime either, because ret is not defined. So, sorry, that won't work at all.

    It's a trivial change - we've done it for all the official addons and I don't think it's really a big part of porting an addon.

  • The C2 runtime throws that warning to catch accidental use of return value; instead of ret.set_float(value);. All that compatibility code will also have a high performance overhead. You have to change the rest of the addon anyway, including the way the expression methods are declared - since you have to do all of that, I don't think it's a big change to replace ret.set_float(value) with return value;.

  • Ok, I hear you. Cheers!

    The C2 runtime throws that warning to catch accidental use of return value; instead of ret.set_float(value);. All that compatibility code will also have a high performance overhead. You have to change the rest of the addon anyway, including the way the expression methods are declared - since you have to do all of that, I don't think it's a big change to replace ret.set_float(value) with return value;.

  • Ashley

    Can I request for these runtime references. Thanks.

    1. fps
    2. loadingprogress
  • Why do you need them?

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • Ashley

    Why do you need them?

    I want to port, or at least, make a basic preloader addon. I really need it for my project. I need those references to stabilize the preload and also to integrate the Construct 3 Loading. I hope you understand.

  • Why do you need them for a preloader addon? What does it do and why can't you do it without these? In particular requiring the FPS for this seems particularly weird.

    Given we are obligated to permanently support all APIs we document with backwards-compatibility forever, I'd prefer to keep the SDK to the essential minimum.

  • Why do you need them for a preloader addon? What does it do and why can't you do it without these? In particular requiring the FPS for this seems particularly weird.

    Given we are obligated to permanently support all APIs we document with backwards-compatibility forever, I'd prefer to keep the SDK to the essential minimum.

    scirra.com/store/construct2-plugins/mmpreloader-layout-preloader-3620

    TobyR made some preloader addon that a lot of us agreed useful on Construct 2. To make it stable, taking FPS into account is important and the loading progress to integrate the Construct Loader Layout loading progress with the preloader layout to extend the Layout-by-Layout loading.

    I actually asked this from you guys but you guys seem to have your hands full at the moment with the c3runtime and I don't want to disturb that. I only ask this so I can finally port to the c3runtime. Thank You.

  • To make it stable, taking FPS into account is important

    That's the wrong solution, and uses an extremely coarse measurement anyway. You probably should use something like requestIdleCallback instead. Besides in the C3 runtime layout loading is now asynchronous so may not jank the game any more while loading. Also the whole idea of preloading an entire other layout will spike the memory usage high, significantly increasing the risk of out-of-memory crashes... it kind of defeats the point of the layout-by-layout memory management that aims to keep peak memory usage low.

    I'm not sure why this needs to have anything to do with loadingprogress either - why not just give the plugin its own expression? The more you hack in to the runtime code, the more brittle it is in the face of future changes. The best architecture is to keep as much code as possible entirely independent of the runtime.

  • Ashley

    That's the wrong solution, and uses an extremely coarse measurement anyway. You probably should use something like requestIdleCallback instead.

    Okay. I'll look that up.

    Besides in the C3 runtime layout loading is now asynchronous so may not jank the game any more while loading. Also the whole idea of preloading an entire other layout will spike the memory usage high, significantly increasing the risk of out-of-memory crashes... it kind of defeats the point of the layout-by-layout memory management that aims to keep peak memory usage low.

    Well, I'm not sure about that. But I surely haven't encountered that in c2runtime on Construct 3 at least.

    Although, aside from the conventional usage of that addon, there is an exclusive use for that addon that the normal layout-by-layout loading can't do.

    Imagine having 100 Spriter Character objects / 100 Sprite objects.

    You have to preload only 10 of those characters per game. As you only use 10 Players per battle match.

    You can't do that with normal layout-by-layout loading as you will have to load image memory that isn't even used.

    With this, it ensures that images that are only needed are the ones only loaded.

    Plus, you can add custom initializations per layout.

    I'm not sure why this needs to have anything to do with loadingprogress either - why not just give the plugin its own expression? The more you hack in to the runtime code, the more brittle it is in the face of future changes. The best architecture is to keep as much code as possible entirely independent of the runtime.

    It needs to. For example, you are on the loader layout. Before going to the main layout, you need to preload the main layout to only load the images needed and also for some custom initializations. But, you need to wait for the Construct Engine to load first or at least finish.

    I hope that explains it all.

  • Ashley

    What is the bare minimum needed to convert a C2 runtime plugin to a C3 runtime plugin? I tried looking through the plugin examples and the SDK docs, but I want to be sure I'm understanding this correctly.

    From what I can tell, the following is needed:

    ACES

    • All ACES moved from plugin.js to their respective files
    • ACES work slightly differently now and need to use return instead of SetRet

    Plugin

    • Boilerplate constructor code and such under plugin class such as cr.plugins_.MyCompany_MyPlugin = function(runtime) gets moved to plugin.js and adapted to the new format

    Type

    • Code for pluginProto.Type needs to be moved to type.js and boilerplate code like pluginProto.Type = function(plugin) adapted to the new format

    Instance

    • Anything that was previously instanceProto is now moved to instance.js.
    • Loading resources and drawing work very differently and require adaption.
    • As in the other sections, boilerplate code, constructors, etc need to be adapted.

    Aside from small changes like properties being passed to constructor, as opposed to being accessed via this/

    Is there anything I got wrong, or I'm missing? Also, the meat of the plugin and js methods should all function the same otherwise, or are there any additional requirements or restrictions for general code?

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)