Do you need to fetch this.getWorldInfo() in every place you use it?

Post reply
0 favourites
  • 8 posts
From the Asset Store
Fetch Quest
$19.99 USD
Fetch Quest 1 music pack is a collection of 10 in-game music loops.
pdkmusic's avatar
pdkmusic

  • Hey all,

    I noticed from looking at the vanilla behaviors that in each place world info is used, the following line appears. 

    	const wi = this.GetWorldInfo();

    Does that reference go bad any time there is a change, or can I add a const reference to it along with property declaration and use it thereafter anywhere I want in the behavior?

    If I can, why do the vanilla behaviors declare it it every function where they need it?

    TLDR: Why do built in behaviors call GetWorldInfo in multiple places instead of just once?

  • Ashley, could you tell me? Am I able to cache world info, or do I need to define it in every method I create? 

    	const wi = this.GetWorldInfo();

    Also, why not just simply refer to: 

    	this._worldInfo

    I see the above line defined in the manual, but I can't find an example in official behaviors other than repeated calls to GetWorldInfo() in every function that needs it (mostly). I see some functions where wi gets passed to another function via a parameter. For example (in sprite plugin): 

    Draw(renderer) {
 const texture = this._currentTexture;
 if (texture === null)
 	return;
 renderer.SetTexture(texture);
 const wi = this.GetWorldInfo();
 if (wi.HasMesh())
 	this._DrawMesh(wi, renderer);
 else
 	this._DrawStandard(wi, renderer)
 }

 _DrawStandard(wi, renderer) {
 	let quad = this._bquadRef;
 	if (this._runtime.IsPixelRoundingEnabled())
 		quad = wi.PixelRoundQuad(quad);
 	renderer.Quad4(quad, this._currentQuadTex)
 }

 _DrawMesh(wi, renderer) {
 	const transformedMesh = wi.GetTransformedMesh();
 	if (wi.IsMeshChanged()) {
 		wi.CalculateBbox(tempRect, tempQuad, false);
 		let quad = tempQuad;
 		if (this._runtime.IsPixelRoundingEnabled())
 			quad = wi.PixelRoundQuad(quad);
 		transformedMesh.CalculateTransformedMesh(wi.GetSourceMesh(), quad, this._currentQuadTex);
 		wi.SetMeshChanged(false)
 	}
 	transformedMesh.Draw(renderer)
 }

  • Also, why not just simply refer to: 

    > 	this._worldInfo

    In the documentation that property is not documented, and so for support purposes it does not exist. If you use it, it could break at any time (e.g. if we rename or rearrange some stuff in the engine, which we do occasionally). So you should only call this.GetWorldInfo().

    You could cache the return value of that yourself, but I don't really see any point in doing that.

  • construct.net/en/make-games/manuals/addon-sdk/runtime-reference/base-classes/sdkworldinstancebase

    this._worldInfo is in the manual. I haven't seen it used anywhere else, which is why I was asking.

    I ask about saving the reference for the simple reason that the documentation isn't clear about what exactly GetWorldInfo() does and doesn't provide guidance on best practices.. If it is simply returning a reference that takes no work to collect that is fine - but I have worked with a number of Engines that can have to do quite a lot of work for internal calls like that, and its safer to just cache everything you use (assuming what you got wasn't just a copy of the data).

    I'm authoring behaviors for the purpose of saving performance and would like to avoid naive use of the api. Without examples of how to use it, or further documentation , there really isn't any place to look but the official behaviors and plugins. Its silly to expect users to master the provided api with basically 0 examples.

    To add further difficulty, you can search the sdk manual, and get 0 results for an item that is in the manual sometimes, or links to only one page when it is on 5. The moral of the story is that it is quite difficult to simply refer to the manual to figure out how to do something, and much easier to look at a behavior you KNOW is already doing that thing.

  • The general coding standard is properties and functions beginning with an underscore are private, and anything else is public. To follow that convention, this._worldInfo is a private property that the class itself can use, but outside callers can use GetWorldInfo().

    Honestly, JavaScript performance is so outstanding these days that worrying about references/GC is very likely premature optimization and a waste of time. These days I ignore all that stuff for engine code and 95%+ of the time it works out fine. The main problem is people underestimating how good the technology is. See the manual section on Performance tips most of which applies to JS coding too.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Shoots, thanks - good to know.

    As far as GC goes though, for example, I thought you said vector2 were dangerous because of gc. I try not to optimize ahead of time, but just wanted to make sure I was following best practices in this case.

  • As far as GC goes though, for example, I thought you said vector2 were dangerous because of gc.

    I think I wrote about that kind of thing in a blog post in 2012. Things have come on a long way in the intervening 14 years!

    You might want to focus on reducing object overhead if you're writing something like a high performance custom physics engine, but I think these days most of the time, it's probably fine.

  • Ah, yes... Spot on Ashley ! I found the forum post I was thinking of from 2013.

Post reply
  • 8 posts
Return to board index
Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)