StormingKiwi wrote: ↑Sat Jan 28, 2023 5:21 am
Do you realise the initial discussion was talking about the result of the sort, right, and not the algorithm used to effect that sort?
Do you realise that I did not talk about any specific algorithm and that YOU did? I realised that you proposed a solution:
Natural sort is not a sort algorithm per se. It’s something more you do, whatever the main sort algorithm. And you do it for all elements.
As I see it, you made these points in your paragraphs:
Sorting Algorithms Table.png
I hope those two attachments make the algorithmic efficiency point clear to you.
In fact, again, YOU made these points, not me. And this time with algorithmic efficiency of many known sort algorithms which, again, has nothing to do with those more things you have to do with each elements, whatever the used sort algorithm.
And quite frankly, no need to be a monster programmer to know for a fact that sorting an almost already sorted list is quite inefficient with quick sort algorithm. Not even only considering the approach, nodes or so called buckets.
The name of the fleets is a list. The list is unsorted. You're saying the algorithm runs on every frame from 1 to infinity.
No, I supposed
that. I said “it seems”. Please don’t reword my sentences. This is based on obvious behaviours than even you have probably noticed… or maybe not? More below.
In DW2, according to you, the sort algorithm runs on every frame: If true, astoundingly sloppy programming.
You’ll have then to explain how it’s not very rare to see some of these lists update themselves from time to time, in a quite ecstatic way, some elements moving a little back and forth rapidly, and not just deleted/added/modified elements during the course of simulation. I wish I had captured a video of this.
And more importantly, the fact that it happens even when
the game is paused (and the latency delay of the pause largely passed… another behaviour you probably noticed too, but I prefer you not to argue it is certainly due to that and the list updating a little due to simulation still running for a few seconds). Looks like some inherent rounding errors in some values considered during the sort. Depending on what exactly? Distances may be a good guess… talking about big floats numbers, but who knows? Not open source, you see. Anyway, what could modify the order, even a little then, and so rapidly, back and forth, besides another sort invocation? Explain. Maybe we’ll have fun both of us.
And you know what? Even this is not that sloppy, to me. I mean, when the simulation runs… more of a programming time compromise, something that can be dealt with later. I can understand that, I can pardon that, which looks like to be a heresy to you. Now, during the pause is another story… Many games do stuff they don’t need during pause. DW2 is not an exception, and my fan keeping steadily crazy for long pauses is the main proof. Man, when I want to pause for long periods, doing something else without saving and quitting the game, I took the habit to bring up the research screen, where I noticed the engine is a lot more machine cycles friendly, as this is the only place where I noticed the fan slowing down after a while. No need to bring up the task manager or any performance analysis tool, I keep it for my own engine code where I can make real use of the results of these tools.
When I said sloppy programming, I was talking about the fairly difficult and rare skill for programmers of "designing a human-machine interface for the convenience of the human", not the basic skill of "designing a computer program to avoid wasting computational resources on calculations it does not need to do."
You just took it wrong. Your post, your main point is of interest. I never implied it was unwelcome. The sloppy and lazy thing in the later post was a bit too much to me. And I can see some sloppy and lazy things in other more obvious areas. That's quite common in game industry, and not only independent studios, far from it.