Ruskul's Recent Forum Activity

  • Ashley , also _inst is in the manual too

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

    So... What is the difference between:

    this._inst.GetWorldInfo();

    and

    this.GetWorldInfo();

    In the context of behaviors: Nothing??? Seems like there are both methods for getting those things as well as properties, and no real guidence as to which we should use and why?

    Why bother with this.GetRuntime when I can just say this._runtime ?

  • It is not intended that anyone looks at internal code?

    I would strongly caution against trying to infer what kind of code you ought to be writing from internal code.

    But there are no other examples to refer to! The manual has few to no examples for most entries, and the forum support for JS is quite limited. What in tarnished brass trumpets are we supposed to do ?!... this is getting very exasperating.

  • 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.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • 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)
     }
  • I'm a bit confused as I dig around official behaviors.

    I see examples of both the following:

    	const wi = this._inst.GetWorldInfo();
    
    	//some other place in the same behavior
    	const wi = this.GetworldInfo();
    
    
    

    In the manual, this._inst is defined as:

    Reference to the Instance representing this instance in the runtime. This allows access to Construct's built-in runtime features for instances.

    If I am defining a behavior and working inside the Instance.js file, are those 2 lines of code synonymous? For that matter then, wouldn't the following work:

    	const wi = this._worldInfo;
    

    Or do I completely misunderstand?

    I'm just confused why both are used (reference custom movement).

    Yes this was removed yearsss ago

    Well, that checks out lol, last time I sent a pm was years ago.

  • Have you added this to the gihub suggestions? I didn't see it over there but wanted to double check.

    Data is a major reason why sometimes I choose unity over construct. Though usually it's due to lack of abstraction.

    Solving the nested families issue, or allowing cross family picking would also improve working with data without even specifically addressing data issues.

    I thought there used to be a way to PM people on the website, but I can seem to find it. Was it disabled?

  • Heh, this had come up before on the older suggestions platform:

    https://www.construct.net/en/forum/construct-3/general-discussion-7/suggestion-custom-data-feature-176502

    I also think this would be very useful in production environments, though, it looks like this is to address the global space, if I understand correctly. In order to be able to communicate from family to family, per instance, you need to be able to have data that is common across a particular plugin. So an obj in both FamA and FamB could set a common var through FamA and then later FamB could use that info in whatever way it needs to.

    I totaly agree that its a great practice to keep code isolated and performing its own thing, but games often require coupled code (platformer and Solid is a grand built in example) and a common data shared between all instances and accessible by any family would solve that issue. Z order, opacity, and color can be used to facilitate communication, but those have other uses obviously.

  • It seems the best way currently, is to forget instance variables, and use JSON or dictionaries as a form of instance variables.

    That's typically what I've ended up doing, it has its pros and cons, but personally I think there are far more pros to use a dictionary than instance vars!

    Yeah, I like dictionaries too for those reasons. I never have had or thought to put them in a family. Can you elaborate on the benefits of that? currently I'm using overboy's data+ so I can have them on instances in order to avoid foreach picking loops. But, obviously that means I lose the benefit of two families being able to reference the same dictionary.

    The workarounds are all decent and simple to use, but they all end up requiring for each loops. Hierarchies, compound objects, uid family shifting (where you simply pick another family by UID), are all viable until you have performance bottlenecks.

    I fear that high count objects simply have to have as little abstraction as possible, even if it means recreating the same behaviors multiple times. Fun facts, I even noticed family events take a little longer to run than the same thing on an object with equal counts, etc... The performance was maybe only a 10% difference, so not a concern for me given other high costs, but still fun to notice.

    I think that in the end I am probably going to go with ease of programing and simply design the game around a smaller object count. I'll be able to simply get the core of the game complete and then see how many objects it tolerates and then go from there.

    In unity or unreal, having several 1000 objects can start to bog things down, but you can get crazy insane performance for millions of objects if you go with ECS (an alternate paradigm for games that is neither oop or component based, but allows modern AAA games to have things like schooling fish or flocking birds by the thousands). The downside is that it takes more work to set up, has to be custom tailored, and is difficult to make modular or extend - so it ends up being a real pain every time, regardless of how similar two sets of objects are. I think the case stands here in similar fashion. If you have 100 dynamic/complex objects, performance differences between an abstracted framework running a foreach and a custom optimized solution will be meaningless. If you want 1000s, you start to see the benefits, but optimizations start to really be case specific.

  • > Why does that matter? Your workaround is running every tick

    I'm guessing one overlapping check + one variable check is less costly than two overlapping checks.

    Definitely, the performance difference will depend on how many objects you have, but it will remain true for even small object counts (though, the philosophy of when to optimize should be considered in small count cases)

  • That makes sense. Thanks for the details ASHLEY. indeed, it is clear now.

    If you had any thoughts on the below, I would great appreciate it.

    If nested families takes too much work and isn't a priority, there is one thing that may be easy to implement that would alleviate part of the issue (namely communicating between families). Currently, the easiest way to to communicate between families is to use a common variable (z order, opacity, color, etc...). But that won't work if need those for what they were made for. The following suggestion is useful not just in context of the current issue, so deciding to have nested families in the future wouldn't make this suggestion obsolete.

    If we could extend/define our own common variables for a plugin, then would could use those between families to communicate and aid in picking. For example, if I could create an instance variable that would then be available to every single instance, regardless of family, then I could use that to share data between them. Basically a type of custom common variable.

    The other option (which also has its own beifits even if nesting is later added) is to allow families to share instance variables or behaviors between them. Currently construct knows when a behavior called "platformer" already exists on an object type and won't allow us to add it again without it being a different name. Would it be easy to simply allow both families to refer to the same behavior/var? Then defining shared functionality would be as easy as naming the behavior or variable the same name accross families and not preventing it. Since construct prevents the same name, I am assuming that a particular conflict could be leveraged as a useful feature. You would still have to potentially repeat code in this setup, but using a shared variable would be more akin to defining an interface.

    I made the argument that nesting is the most important feature on the github post, but I think that only applies to managing larger projects or advanced use cases where complexities of abstraction are the most pressing issue. But I understand the benefits of this would not be apparent to many beginners.

    I would add, that for me at least, if changing families to allow for nesting made all family use less performant at game run time, I wouldn't like that either. lol

    As it stands the foreach workaround and uid picking isn't terribly inconvenient, but it does become a performance drain, and if the performance drop from that is unbearable I can at least try other methods.

Ruskul's avatar

Ruskul

Member since 23 Nov, 2013

Twitter
Ruskul has 2 followers

Trophy Case

  • 10-Year Club
  • Forum Contributor Made 100 posts in the forums
  • Forum Patron Made 500 posts in the forums
  • x6
    Coach One of your tutorials has over 1,000 readers
  • Educator One of your tutorials has over 10,000 readers
  • Regular Visitor Visited Construct.net 7 days in a row
  • RTFM Read the fabulous manual
  • Email Verified

Progress

17/44
How to earn trophies