And I’m perfectly OK with organising mine into classes via C#. You do you.
I mean, Functional Programming is a cool way to organize code, I’ve just yet to write a whole program that way.
That makes a lot of sense! Since the player is going to be in any scene where the overworld camera is. I guess it didn’t occur to me since I spent a while working on the camera as a child of the room environment itself (as a sister node to the StaticBody3D of the level), and only just recently added a character to the scene.
I wonder why they didn’t do it that way in the tutorial project, since it doesn’t seem especially complicated to link the movement of the two objects. Is it not especially common practice?
Wow, I didn’t realize that. I’m glad Godot lets you use both GDScript and C# in the same project (which influenced my decision to try the latter, since it’s not a unbreakable commitment), so if something dire ever happens I can fall back on GDScript to ask for help.
Lots of dire things will happen with C#, better get used to replacing all your strings with static ones (for example on input), as otherwise you will get issues with garbage collection.
Someone really needs to do a writeup of all the things to NOT do when using C#.
2 Likes
What about constants? Just out of curiosity. I guess static because strings are reference types and create garbage? 
In essence yes, so for example, using one of Godots example:
// `walk` will be a floating-point number between `-1.0` and `1.0`.
float walk = Input.GetAxis("move_left", "move_right");
If you are polling that every frame (which of course you would be, its input) then you are creating a new string allocation to that string every frame as its a reference type.
I couldn’t work out why my current project was periodically (literally every couple of minutes or so) was seeing a spike in frame time (like 100ms+), and this was the reason. (along with anything else that uses a string too every frame)
Once I moved any string I was using in process (or very regularly) to an autoload of Stringnames and used those instead the spikes disappeared. You can use something like Jetbrains IDE and monitor the Garbage collection in realtime, its quite surprising how much this adds up.
You could of course do all the input stuff in GDScript instead.
2 Likes
That’s fine, just don’t go mocking every mention of alternatives by using absurdities like “lelw, might as well do assembly”. You’ve done this twice already when responding to me.
There are legitimate alternatives to OO ways of thinking that are relevant today in high performance software, despite people like yourself waving them away. If a software architect is not aware of those alternatives and can’t get their head out of the OO box - the performance of their software might suffer. This may not be a factor for some accounting program (although it can be), but when it comes to realtime graphics applications - it starts to play quite an important role.
Conceptualizing tiny individual chunks of system resources as semantic “objects” that have to be “created” whenever you need them and “destroyed” when you no longer need them, is as much a relic of the past as is “lewl, the assembly”. It originated in the 80s.
Look closely at how it operates under the hood, and you’ll see that it’s far from optimal if you need things running with high efficiently on today’s hardware. Why? Because it, by design, doesn’t care about data locality.
Modern hardware really likes locality. On the CPU side, it maximizes opportunities for super fast L1 and L2 cache hits. And GPUs are all about tight data packing. You don’t get to create a “triangle object” every time a GPU needs to draw an individual triangle. The tragedy is that people who are strictly OO-schooled think you need to do precisely that, then organize accordingly, to the detriment of the perfomance.
Ultimately, the purpose of software is to run efficiently on a computer, not to make its creators feel better about themselves when yapping at boardroom meetings.
You can say: “Well what does that matter, an Asteroids game will never reach the number of asteroids where this comes into play”.
Not many games are Asteroids. Most games will typically be hungry for performance.
OO is a good organizational tool, but knowing when and how to abandon it is as important as knowing your gang-of-four recipes by heart.
1 Like
Its just a bit of fun, no mockery is going on.
I never waved anything away. Use whatever language and coding paradigm that works for the situation at hand.
Now who is waving away….
I have in no way indicated in any of my posts that OOP is the only way. I’m literally saying that I prefer doing it that way. But you would prefer us to ‘abandon it’ (your words not mine).
If you don’t want to use OOP then go right ahead, I have absolutely no issues with anyone doing what works for them or certain situations.
Its an odd hill to die on .. but there you go.
How am I waving OO away if I literally said it’s a good organizational tool? I’m just pointing out it’s wise to be cautious when using it as the be-all-end-all organizational tool, specifically when it comes to high performance software.
My view is to not be exclusionary but pragmatic. It’s not either or. I’m sure I don’t need to tell you that tools can and should be combined. Note that I said WHEN and HOW to abandon it. Not: hey fellow kids, you need to abandon it. My point was precisely to not be boxed into a paradigm - in this case OO. You’re strawman-ing way too much for my taste.
Nobody is dying on any hills here. You’re projecting your fatalist views onto a technical discussion.
How about this. Let’s have an Asteroids coding challenge, with a requirement of handling one million asteroids. You do your neat “class Asteroid” thing and I’ll do some “assembly” shit combined with some “class X” stuff, see which one performs better. You up for it?
1 Like
To go back to the main topic, it’s interesting to note here that GDScript is also a type of language that doesn’t let you do anything outside of classes. Everything must be a class here. That said, autoloads are not really singletons in the strict sense. There’s nothing stopping you from instantiating their class multiple times. That, by definition, is not a singleton. Interestingly, we’ve seen many cases on this forum where people got confused with strange errors precisely because they unknowingly instantiated their “singletons” more than once.
1 Like
And yet you just posted this ….
No of course not, because we all know what the result would be, I’m not arguing that and NEVER have , quite the opposite in fact, I have said multiple times now whatever works for the situation.
Honestly I’m done, as this has nothing to do with the OPs question, and you seem to have a very specific issue with what I write and are being antagonistic for the sake of it, so I will leave it at that.
I’d say it’s the other way around. You jumped my singleton description with an off-topic strawman remark in the vein of “might as well just code everything in one large spaghetti bowl, lulz”.
1 Like
Because in the tutorial project, the entire game is the same size as the screen. The camera never needs to move.
It’s a very common practice to attach the camera to the player.
2 Likes