Drawn text on hud

Discussions about Coding and Scripting
dot
Average
Posts: 59
Joined: Tue Oct 30, 2018 3:41 am

Re: Drawn text on hud

Post by dot »

You make too many wrong assumptions.
For this case it does not matter, or any difference what to use Actor or two variables.
No need to build theories because I like variables in this particular case.
Any option is acceptable.
If further required, it can be replaced without serious consequences by Actor.
If I need more than one font, I use Actor.
You do not need premature optimization, as you yourself wrote about it.
User avatar
Feralidragon
Godlike
Posts: 5489
Joined: Wed Feb 27, 2008 6:24 pm
Personal rank: Work In Progress
Location: Liandri

Re: Drawn text on hud

Post by Feralidragon »

Ok, do it however you want to do it.
I pity those who will follow these and end up with more problems than the ones they started with, but ok, I don't really want to waste more energy on this.
dot
Average
Posts: 59
Joined: Tue Oct 30, 2018 3:41 am

Re: Drawn text on hud

Post by dot »

https://wiki.beyondunreal.com/Legacy:Un ... cal_Issues
Spawning and destroying actors are fairly expensive operations on the server side, and are even more expensive in network games, because spawns and destroys take up network bandwidth. Use them reasonably, and regard actors as "heavy weight" objects. For example, do not try to create a particle system by spawning 100 unique actors and sending them off on different trajectories using the physics code. That will be sloooow.
Specifically, I do not like a bunch of extra code around FontInfo. For comparison:

Code: Select all

var FontInfo MyFonts;

function Destroyed() {
	Super.Destroyed();
	if ( MyFonts != None )
		MyFonts.Destroy();
}

function PostBeginPlay() {
	Super.PostBeginPlay();
	MyFonts = FontInfo(spawn(Class<Actor>(DynamicLoadObject(class'ChallengeHUD'.default.FontInfoClass, class'Class'))));
}
vs

Code: Select all

var Font CacheFont;
var float CacheWidth;

if (CacheFont == None || CacheWidth != Canvas.ClipX) {
   CacheFont = class'FontInfo'.Static.GetStaticSmallFont(Canvas.ClipX);
   CacheWidth = Canvas.ClipX;
}
User avatar
Feralidragon
Godlike
Posts: 5489
Joined: Wed Feb 27, 2008 6:24 pm
Personal rank: Work In Progress
Location: Liandri

Re: Drawn text on hud

Post by Feralidragon »

And that's why I said that I didn't want to waste more energy on this, we both clearly have completely different coding philosophies and we will never see eye to eye, at least for the time being, but I will make this post to make it as clear as possible, even for potentially others to understand where I am coming from.

You're clearly very oldskool and you're treating code as if it needs to run in machines with weak CPUs and 32MB of RAM, so you will try all the possible "hacks" and even create redundant code with no possibility for expansion, just to save a meaningless tiny bit of memory and to cut a few CPU cycles.

I, on the other hand, realized a while ago, that by doing so you get to a point where the code just becomes "garbage", no matter how simple and nice it looks at first, if it causes the entire architecture of a system to be hard-limited and have issues and limitations, it's just not good code at all, period. Even if that tiny piece of code runs flawlessly by itself and seems to cause no harm, that doesn't mean it's good code from the overall architecture point of view, and this is seen especially when you want to change it, expand it or simply interact with it, and there's where you will spend time having to potentially refactor everything.
Sometimes hacks and quick solutions are needed, when there's no other way, but when there's another more correct way, they should be completely avoided.

That's why I mentioned "premature optimization", which is exactly what you're advocating for, either you realize it yourself or not: you should only optimize when you actually *need* to optimize, not before, this is what "premature optimization" stands for, given that before the optimization you should focus to have a good code architecture to begin with.
This does NOT mean that you should just code away disregarding performance, not at all, it means the opposite in fact, it means instead that performance considerations should be part of the design overall, but as the big overall picture and not small specific optimizations here and there, even because "performance" is not the bounding factor anymore in coding nowadays, it's "change".

Hence what I proposed was not a premature optimization, it was the very opposite, it was to use what already existed the way it was meant to be used, rather than duplicate the code just to avoid to spawn an actor which does the same.

It all goes down to DRY, SOLID, composition over inheritance, and so on, basic and proven good programming principles which maybe to yourself are just "theories" and whatnot, and which are completely unknown to most of the community even, especially with an engine which does not follow either of them at all, but if the community in general keeps seeing these kinds of "solutions", implementing them "as is", and not start to follow these, they will always end up having all sorts of basic bugs and limitations in their code they wouldn't have otherwise, and it will look more and more like dark magic rather than something technologically sound, to not mention that mods won't play well together either (we already have this problem nowadays, and make no mistake, I am equally as guilty of it myself from the time I didn't know any better either).

It's a matter of principle, and looking ahead at the big picture that you're drawing, rather than the specific brushes, lines and colors you're using to paint it, that's all.
I believe you're just being shortsighted and not seeing the overall picture overall, and that's why we won't be able to see eye to eye.

Not that there aren't other examples even in this forum from other programmers doing similar things, but you being a new member, I thought it was worth a shot to check what kind of programmer you are, and if you were the kind we could have a productive exchange with, for both sides.


And on a last note concerning actors overall, the wiki is not completely accurate (just like any wiki for that matter), for instance:
For example, do not try to create a particle system by spawning 100 unique actors and sending them off on different trajectories using the physics code. That will be sloooow.
and guess what, that's a terrible example, as this is not accurate.

While it's true that actors are heavy-weight objects, given their long initialization process, with tons of needless properties which require memory to be allocated and CPU to be checked for replication, being part of a global actors list which influence how fast an AllActors iterator runs (and other similar ones), ticked every frame (unless set otherwise), truth is that even a number such as "100" didn't make any sense even 10 years ago, and I have personally proven this time and time again by doing things which went way over that value in the total number of actors doing physical things, in the order of thousands at times, with no issues. Because no matter how a bad of a picture the wiki makes out of actors and iterators in general, they're actually not that problematic overall, at least 10 years ago, and certainly not nowadays, they make an exaggeration of the overall performance of things.

Even machines from 10 years ago were fast enough to deal with these things, and even the game as it is (which goes full circle with the entire premature optimization thing) actually spawns a lot of stuff even at a standard level: projectiles, effects, gibs, etc, with absolutely no recycling at all. Even weapons and pickups, as whenever you pick one it spawns a brand new "copy" of it.

If this worked from the get-go for them with the limited hardware at the time, why are we trying here to avoid to spawn a *single* actor just because it's considered "heavy-weight" by a wiki which is not fully accurate to begin with?
Especially when the weight of this actor is no different from everything else that the game itself spawns in large quantities at times anyway?

All I am asking you is to look at the big picture, and not keep indulging in practices which violate things like DRY and SOLID, just for the sake of micro-optimizations.
dot
Average
Posts: 59
Joined: Tue Oct 30, 2018 3:41 am

Re: Drawn text on hud

Post by dot »

In fact, I'm just too lazy to write a lot of code. And I do not like the need to write two additional methods just because I want to assign the font. I would prefer not to know about it at all, and that the canvas should not have a state that changes unpredictably.

Strictly speaking, I want to display text on the screen and that's it. I don't want to complicate it all. The simpler it is, the better. This is just a test case. I will NEVER need another font. I don't need any particular font at all. I need him not to jump, that's all.

There is such an expression Astronauts Architecture. This is also a premature optimization, but not for CPU or memory cycles, but for the possibility of expansion.
https://www.joelonsoftware.com/2001/04/ ... scare-you/

For example, when I want to send a test letter to my email, I prefer to call the mail function with three parameters. And I will spend two minutes on this.
It will be an ugly, ordinary letter.
But if a whole framework is imposed on me for this, which can do everything with letters, then I will not like it. If in order to send a letter I need to read 10 pages of text in 5 different places, create 10 objects in 3 factories, then I will not like it.

No need to complicate things unnecessarily.

I don't understand UnrealScript well. In fact, I see him for the first time. I don’t want to read a ton of text just to do such a basic thing as text output to the screen.

The principle of KISS. And I see no point in applying FontInfo in this case. There will never be more than one font. So this is just a waste of time.

If I need something powerful and extensible, with a bunch of fonts and all that, I use FontInfo, but not here.

If I need to unscrew the screw, I will unscrew it with the scissors, or the knife, which I have at hand. It will take me a minute. I will not spend an hour going to the store for a set of screwdrivers. This is if the screw is one.
If there are a hundred screws, then I will buy a screwdriver. Because it is advisable.
User avatar
Feralidragon
Godlike
Posts: 5489
Joined: Wed Feb 27, 2008 6:24 pm
Personal rank: Work In Progress
Location: Liandri

Re: Drawn text on hud

Post by Feralidragon »

You're talking about over-engineering, and I understand where you're coming from.

But pragmatism (KISS) is not the same as doing the quickest and dirtiest thing possible, is just doing the simplest.
And the "simplest" will mean different things depending on the standard you set yourself up to do things, and right from the first solution you're clearly setting your own standard to be so low, that you're OK even if things do not work for all the use-cases like in your very first solution, although by doing things with the same level of simplicity (or even simpler) but following a higher standard you could.

Following principles like DRY and SOLID in no way violate KISS, as a matter of fact KISS helps programmers to use DRY and SOLID without over-engineering the crap out of their own code, and both DRY and SOLID in turn help to keep things as KISSable as possible, by following a simple recipe, complementing each other.
And KISS is tightly coupled with YAGNI, and YAGNI is mostly what you're actually advocating for here.

The thing is, from a strict YAGNI point of view, what you're doing is not more or less correct than what I proposed, it's about the same actually (what I proposed is not any more complicated than what you last proposed), but the moment you apply DRY, you're already violating it (although my solution violates a bit too, but to a much lesser degree and it's unavoidable), and when you add SOLID on top of it, you're violating SRP and OCP, and all on a potentially false premise that it's never going to be used the way it was meant to be used.

Then a developer comes, uses your code to fix all their problems, it seemingly works, then someone else remembers that this FontInfo thing exists and does a custom one, which will then work for everything except these mods which used your particular solution.

If you're really new to UnrealScript, and maybe this community in general, then one thing you will realize over time is that even after almost 20 years we're still doing new stuff, often using and still discovering unused UT features for new things. The fact that maybe no one is using this one yet does not imply that no one will ever use it.

I cannot even count the number of times plenty of mods, addons and whatnot which eventually got popular and became a must-have, were doing things in such a shortsighted similar way that other programmers, even nowadays, had to account and hack around code for those special cases. Not that I was any better back then in plenty of things, but once I learned better over time (with experience and many mistakes along the way), I changed my own ways of going about code and now even code I started years ago, is still relevant and flexible today, it pays off to me and my fellow programmers.

I will always use a screwdriver for a single screw, unless I have absolutely no alternative, because if even at that day I only need to unscrew a single screw, I generally have to put it back properly and over time I will certainly need it for other screws, plus with the right tool for the job, I make sure I don't screw over the screw to the point I cannot even unscrew it with the proper tool, like I also often see from other people with a similar mentality as yourself, which have a tendency to fuck things for others by not doing things the right way.
Post Reply