Re: Friday, March 17, 2017
Posted: Fri Mar 17, 2017 5:14 pm
Haemorrhoids.Cornflakes_91 wrote:Maybe pola-roidsDinosawer wrote: mobile roids?
soooo
And-roids?
*runs*
Haemorrhoids.Cornflakes_91 wrote:Maybe pola-roidsDinosawer wrote: mobile roids?
soooo
And-roids?
*runs*
Did you not pay any attention?Vartul wrote:Of course, all of this has nothing to do with actually improving the game in any way. So I guess Josh shouldn't really spend any time on this. But I just wanted to point it out.
Umm..you misunderstood me. I meant that finding out exactly how much faster the new implementation is compared to the old one (we all know it's blazing fast and a huge upgrade, but exactly how big an upgrade?) doesn't benefit Josh or LT in any way. It's more of an idle curiosity. I was not talking about the work that Josh did at all. I understand how important it is to tackling FPLT and how Josh might begin to focus on gameplay very soon because performance issues are close to solved.Silverware wrote:Did you not pay any attention?Vartul wrote:Of course, all of this has nothing to do with actually improving the game in any way. So I guess Josh shouldn't really spend any time on this. But I just wanted to point it out.
Josh was pointing out that the limitation on up to 50 thousand objects on screen with positions, rotations, and movements, was no longer code, but rather Graphics Card.
Where before he was complaining about fewer than sixty frames a second. Now with this relatively small change, he gets 33 at fifty thousand things on screen, and at least 60 frames when dealing with ten thousand.
He mentioned there that the AI wasn't going to cause an issue either.
So taking this information, and plugging it into his other recent posts about how he managed to fer a thousand or so ships into the demo. We could have a thousand ships in a single combat currently and the engine WOULD NOT STRUGGLE.
This is a massive gain.
You know how he was complaining that the times things were taking to run were all small enough before that they weren't easy to optimize in any meaningful way?
Well he just found one new way.
He also found out that the profiler he was using is shit, and thus can start looking for a better solution.
What Josh has done here is tacked an order of magnitude onto the scale that can be run at reasonable performance. *AND* found that he has been potentially missing information during profiling.
These are very good advances.
And doing so in a week? My hat is off to that.
You would be very wrong then.Vartul wrote:Umm..you misunderstood me. I meant that finding out exactly how much faster the new implementation is compared to the old one (we all know it's blazing fast and a huge upgrade, but exactly how big an upgrade?) doesn't benefit Josh or LT in any way. It's more of an idle curiosity. I was not talking about the work that Josh did at all. I understand how important it is to tackling FPLT and how Josh might begin to focus on gameplay very soon because performance issues are close to solved.
Maybe you should've paid more attention.
You know, you really should read the original comment before going on these long tirades. Nothing you say relates to anything I say.Silverware wrote:You would be very wrong then.Vartul wrote:Umm..you misunderstood me. I meant that finding out exactly how much faster the new implementation is compared to the old one (we all know it's blazing fast and a huge upgrade, but exactly how big an upgrade?) doesn't benefit Josh or LT in any way. It's more of an idle curiosity. I was not talking about the work that Josh did at all. I understand how important it is to tackling FPLT and how Josh might begin to focus on gameplay very soon because performance issues are close to solved.
Maybe you should've paid more attention.
Knowing the exact measure of an optimization is how you classify if it was worth the effort or not.
If you don't test before and after, and don't test thoroughly getting exact numbers, how can one say that the change was an objective improvement?
Knowing the scale of the improvement also helps you focus on either finding other things akin to it, if it was a major improvement.
Or to avoid doing similar things if it was barely an improvement.
With Joshes case, knowing the maximums as they are now also helps him judge other code later on.
If he for instance adds a new feature that then prevents him making more than 5000 asteroids run at the same frame-rate, then he just lost an entire order of magnitude in performance, and he can take a look at what exactly caused that with the new feature.
Knowing the issue, and knowing the scale of the resolution, these are the keys to optimization.
it allows you to judge/guesstimate how much more fancy stuff (cupcakes with sprinkles, blah) you can strap on without going back to under-serve your customersVartul wrote:How does this new information help me in serving my customers? Well it's bloody useless. But it was fun to find out anyway I guess.
I feel like now we're just stretching the analogy past its applicability to the actual situation. But to answer your point, we wouldn't need that information at all. The information Josh needs is this- what is the baseline performance I need? Let me set this hardware as my minimum requirements. I want LT to run smooth on this hardware while fulfilling my design goals (lots of NPCs, asteroids etc.) The minimum requirements is Josh's "100 customers". Finding out that the new method is let's say 15 times faster than the old one is useless. It's just a feel good number. If he's getting 60 fps on baseline hardware when he only needed 30fps (the machine makes 300 cupcakes when you only need 100), he can go and get cupcakes with sprinkles etc, which will bring the performance to 30fps, but add more shinies. Notice how none of this discussion involves or uses the comparison information (15 times faster).Cornflakes_91 wrote:it allows you to judge/guesstimate how much more fancy stuff (cupcakes with sprinkles, blah) you can strap on without going back to under-serve your customersVartul wrote:How does this new information help me in serving my customers? Well it's bloody useless. But it was fun to find out anyway I guess.
With a framework change you don't always have the luxury because you won't get a 1:1 comparison.Silverware wrote:You would be very wrong then.
Knowing the exact measure of an optimization is how you classify if it was worth the effort or not.
If you don't test before and after, and don't test thoroughly getting exact numbers, how can one say that the change was an objective improvement?
I would have played X:R (I got it free after all) but the promises of "more modable and easier" turned out to be either marketing or wishful thinking.JoshParnell wrote:It is, of course, complete coincidence that I played some X:R this week (yes, say what you will, it's still impressive IMO), extracted the game data, perused those awful XMLs. But yes, to be perfectly honest, the X:R engine is to blame for inception of event-driven high-level gameplay. It then reminded me of a million things I've seen before related to the topic.
xDTalvieno wrote:Oh, very shiny indeed!
On the "tech talk" note, I think I'm going to start compiling a summary of what you said (with less tech-speak) for the less technically-inclined members of the community, so everyone can have a chance to enjoy your devlogs.