Return to “Dev Logs”

Post

Re: Friday, March 17, 2017

#33
I don't know about all of this Josh. I truly appreciate the update. Just please make sure you get rest. I worry about you going back to old bad habits. Please please take the rest in the long run it pays off. I know you're excited and frankly myself as well. However, I am more than willing to wait so much longer if your health is going to suffer. Just a fan worried for you. Peace.
Post

Re: Friday, March 17, 2017

#34
Umm..I'm happy about this development like everyone else, and it's incredible how the game performance is orders of magnitude faster, but the data that Josh gave us doesn't really tell us "exactly" how much faster the new implementation is. So 1000 asteroids take 10ms in the old implementation, and 2ms in the new one. This isn't useful because 2ms is the threshold limit for the engine and the actual performance improvement is hidden somewhere within that. This becomes obvious when Josh goes to 10,000 asteroids and the LJ implementation crashes while the new one still gives 2ms.

After that Josh tries 50,000 asteroids which of course the old implementation isn't able to run, and the new one gives 30ms.

See the problem? We never have comparison values. What would help is if we try to render a number of asteroids that the old implementation is able to display without crashing, and for which the new implementation gives a time value above 2ms. Which is not possible because the old one can't handle 10k asteroids and the new one gives 2ms at 10k. :cry:

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. :shifty: But I just wanted to point it out. :geek: :monkey: :ghost:
Post

Re: Friday, March 17, 2017

#35
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. :shifty: But I just wanted to point it out. :geek: :monkey: :ghost:
Did you not pay any attention?

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.
°˖◝(ಠ‸ಠ)◜˖°
Toba - A Development Dump
Post

Re: Friday, March 17, 2017

#36
Silverware wrote:
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. :shifty: But I just wanted to point it out. :geek: :monkey: :ghost:
Did you not pay any attention?

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.
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. ;)
Post

Re: Friday, March 17, 2017

#37
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 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?

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.
°˖◝(ಠ‸ಠ)◜˖°
Toba - A Development Dump
Post

Re: Friday, March 17, 2017

#38
Silverware wrote:
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 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?

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.
You know, you really should read the original comment before going on these long tirades. :roll: Nothing you say relates to anything I say.

EDIT: Here, I'll make a last ditch attempt to explain. Let's use an analogy.

I have a cupcake factory. My cupcake machine is old. I need to serve a 100 customers every day, but my poor old machine can only make 20 cupcakes in a day. Now that sucks. So I get in an engineer to upgrade my machine and make it shiny and fast. Now it makes a lot more cupcakes in a day. How many more? Well, I let it run for a day and it made 300 cupcakes! Awesome. This means that not only can I serve the hundred customers I wanted to, but I can actually go way beyond that now. I can serve upto 300 customers.

So it was important to let the machine run for a day and find out how fast it is. Because otherwise I might have been under-utilizing it by serving only 100 customers.

But I get curious about something. How much faster is my upgraded machine compared to my old one? Well, that one made 20 cupcakes in a day, and the new one makes 300. So I find out that it's 15 times faster than the old one! Holy shit. That's cool. 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.
Post

Re: Friday, March 17, 2017

#40
Cornflakes_91 wrote:
Vartul 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.
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 customers
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).

Regardless, my original point was the question regarding lack of an exact estimate of improvement, and a possible way to find one, which got buried after Silverware assumed I was somehow calling Josh's breakthrough useless.
Last edited by Vartul on Sat Mar 18, 2017 2:41 am, edited 1 time in total.
Post

Re: Friday, March 17, 2017

#41
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?
With a framework change you don't always have the luxury because you won't get a 1:1 comparison.

"Proper" profiling works better with smaller and more localised improvements.

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.
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.

Modding the game so that the player could really enter and fly a capital ship? Flat out not possible. I didn't look any further because... why?

The event-driven system was what made the earlier games (like X3) work.
Took a while for modders to wrap their heads around the various tasks and interrupts and how to juggle them but it is an incredibly powerful system.
With the MARS script I think I could have over a dozen separate scripts running on one ship, each on their own task ID and listening/reacting to different interrupts or shared variables (pointers).

That they did have different "interrupts" was what allowed the large scripts to still run smoothly because a piece of script was atomic until it came to an interrupt point in the script. Then it would go back into the queue with something like
- "call me back in 3100 ms"
- "whenever this AI command completes"
- "as soon as you get around to it".
There is no "I" in Tea. That would be gross.
Post

Re: Friday, March 17, 2017

#45
Talvieno wrote:Oh, very shiny indeed! :thumbup:

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.
xD

I certainly won't stop you, but good lord man, from whence do you pull all the time to do this stuff! :ghost:

Unless, perhaps, you can frame it such that you can re-use the less-technical summaries for the KS monthly summaries? That seems like an effective way to minimize the extra time spent.
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford

Online Now

Users browsing this forum: No registered users and 2 guests

cron