Allow overiding of member variable functions (GDScript)

[sp33dy]

I have the following requirement:

Create an extended Sprite class, so that when it moves off one edge of the screen, it wraps to the opposite; i.e. half will show on the right when it scrolls off the left.

There are numerous ways to do this and my choice is to create a mirror sprite with an offset of the screen width until the Sprite on the left falls off-screen; at which point, it would be good to remove the mirror and move the original to the right.

I wanted to create a generic SpriteScreenWrap class so that it can be used in my game and others. I'm also writing a tutorial on this topic.

I've now discovered that if I extend the Sprite class, I can't add 'position' variable, as it is a member variable (too right!!!). However, if I add a set_position() [which I assume is a member function called when the member position is set), it is not called!

WOULD it be possible to have the ability to override the underlying function in my class, so that it gets called when the member position is set? This is important, as it would then allow me to publish a generic class for a Screen Wrap Sprite that others can use; as if it were just a normal Sprite.

I get the need to restrict the member variable, but not the function.

Any thoughts on this would be appreciated? For now, I've resorted to using a process(delta) check EVERY frame! This is quite expensive when LOTS of sprites are on screen. Whereas, if I could intercept the position's member function set_position(), i could do it ONLY when it is moved by an external controlling piece of code.

Thanks and kind regards

Carl

[Zylann]

Another workaround would be to use a custom function rather than _process, if performance is a concern.

Would it be bad for performance if every C++ getter and setter would need to check if their script has an override for them each time they get called?
Also, how would the C++ class know you want to call only the base set_position from your override?

[sp33dy]

For the workaround, I agree to what you are saying; however, the idea is to create a 'generic' class of Sprite that can be used like a Sprite, but it automatically wraps around the screen for you. By having a custom function, users then have to know how to use instead of using the standard position/global_position values.

I've just proven this works with a _process(delta) and can get a good rate of return. I'm just writing a tutorial and then you'll see what I've done. Be a few hours.

[Zylann]

Currently you could do something that results in exactly what you expect in terms of usage, but inheriting Node2D instead of Sprite (so you have a bit more to implement). I had to do that too in my game, just to customize the geometry so it's not a quad but a grid of quads for use in vertex shaders. Though changing how position works is kind of tricky...

I agree that the ability to override properties (or even anything) feel like the correct OOP approach, but for this kind of scripting environment I wonder if that's really a good idea (mostly because it adds lookup cost for everyone who are not using this in 98% other cases, considering that property is used A LOT).

But... if you want this behavior to happen only for scripts that use your position, maybe you could override _get and _set instead?

[RabbitB]

Just reiterating that there's many ways to tackle this, but we are talking about Godot, where the scene and node systems can be easily leveraged to split the work load between nodes. It's not necessary to create an actual subclass of Sprite, but instead a custom node, that when made the child of a Sprite, will perform the necessary wrapping operations.

From there, any sprite you want to screen-wrap, can have that functionality added by attaching that node, and saving it all as a scene that can be instanced elsewhere.

[sp33dy]

Thanks Zylann & RabbitB, I get and agree with what you are saying. I've played with a few alternatives and plan to do a few more this week. Let's close this request.

[sp33dy]

Thanks Zylann & RabbitB, I get and agree with what you are saying. I've played with a few alternatives and plan to do a few more this week. Let's close this request.

[vnen]

BTW, this could be solved easily if something like #6491 was implemented.