Friday, March 17, 2017

Logging the Creation of a Beast -- the Good, the Bad, and the Template Metaprogramming.

Re: Friday, March 17, 2017

Postby Silverware » Fri Mar 17, 2017 12:48 pm

Well Josh, I see you are coming around to a properly object and event orientated viewpoint now. :D

You many not have killed the FPLT, but you definitely struck a deep wound in the beast!
And it sounds like you accidentally did some of the decoupling of user input and game logic that I had been wanting since I first started seriously thinking about the LimitTheory MultiPlayer mod.
So even if the other people here don't seem all that excited, this post had me in tears from the sheer awesome.

Although I do now know that getting the multiplayer to work fully will likely require some C code...
But thats Future Silver's problem.

Huzzah!
ᕕ(ಠ‸ಠ)⊃━☆゚.*・。゚
User avatar
Silverware
Vice Admiral
 
Posts: 2672
Joined: Sun Sep 07, 2014 3:23 pm
Location: Goattown-Three, Sigma Six, Goat Space

Re: Friday, March 17, 2017

Postby Detritus » Fri Mar 17, 2017 1:01 pm

Silverware wrote:But thats Future Silver's problem.


Image

Silverware wrote:Huzzah!


Image
Egyptian God of Frustration at your service!
I have a (virtual) pet trout named Fred! He is a rather powerful fish.
Come play Renegade X with me!

Talvieno famously wrote:cannot match the power of the almighty Detritus
User avatar
Detritus
Rear Admiral
 
Posts: 1337
Joined: Mon Nov 23, 2015 10:05 pm
Location: Al Nair Gamma III B

Re: Friday, March 17, 2017

Postby Silverware » Fri Mar 17, 2017 2:06 pm

Detritus wrote:
Silverware wrote:But thats Future Silver's problem.


Image

Silverware wrote:Huzzah!


Image


Yes, present Silver knows exactly how future Silver will feel. :V
ᕕ(ಠ‸ಠ)⊃━☆゚.*・。゚
User avatar
Silverware
Vice Admiral
 
Posts: 2672
Joined: Sun Sep 07, 2014 3:23 pm
Location: Goattown-Three, Sigma Six, Goat Space

Re: Friday, March 17, 2017

Postby alpan » Fri Mar 17, 2017 2:32 pm

Throughout your new dev logs I'd actually been assuming that the inner loops were already being handled by the LT Core library, since you refer to it as static code, and, as you say, no one will mod the way the game calculates movement. Had I realized that you were doing all that in Lua I would have ventured with the suggestion myself! It seems obvious even to my woefully inadequate mind, which doesn't actually understand why this stuff didn't show up in the LJ profiler in the first place.

At any rate, you did very well to decide on this course of action.
User avatar
alpan
Lieutenant Commander
 
Posts: 185
Joined: Thu Dec 13, 2012 1:38 pm
Location: Istanbul, Turkey

Re: Friday, March 17, 2017

Postby Gazz » Fri Mar 17, 2017 2:54 pm

This starts sounding more like the X3 setup.

It has a powerful scripting system but it has commands like "fire guns at target X" or "fly to point X, Y, Z".
The flight path of a projectile is not controlled by the script.

Events/interrupts occur either when the script schedules a futire update when it wants to do some stuff on it's own or when an event like "Hey, you're being shot at by X" occurs.
There is no "I" in Tea. That would be gross.
User avatar
Gazz
Moderator
 
Posts: 3175
Joined: Tue Nov 27, 2012 4:39 am
Location: In your brains. Thinking your thoughts.

Re: Friday, March 17, 2017

Postby JoshParnell » Fri Mar 17, 2017 3:20 pm

About the motion physics (yes Dino, I know that's physics :V Just in games physics usually refers to more than kinematics): I never intended to keep that LJ tight loop, it was just a first-pass. But I was having a good bit of trouble figuring out how to create a clean, flexible, yet still maximally-efficient split. The real problem is that it's difficult to offload entity computations when the entity is in Lua. You basically lose your performance right there. Hence the insight of having the C 'core entity' wrapped in a Lua 'decorator.' That was the insight I needed. Like all good solutions, it's completely obvious in retrospective :ghost:

Gazz wrote:This starts sounding more like the X3 setup.

It has a powerful scripting system but it has commands like "fire guns at target X" or "fly to point X, Y, Z".
The flight path of a projectile is not controlled by the script.

Events/interrupts occur either when the script schedules a futire update when it wants to do some stuff on it's own or when an event like "Hey, you're being shot at by X" occurs.


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 remember thinking how strange it was when I was perusing the IrrLicht engine source a few years back and found that it used controller objects to change positions/velocities of game objects rather than modifying their values directly. After lots of thinking on the subject I'm pretty convinced that I think I get it now :D

Oh and I also noticed that X:R uses LJ..nice ;)

Silverware wrote:Well Josh, I see you are coming around to a properly object and event orientated viewpoint now. :D

You many not have killed the FPLT, but you definitely struck a deep wound in the beast!
And it sounds like you accidentally did some of the decoupling of user input and game logic that I had been wanting since I first started seriously thinking about the LimitTheory MultiPlayer mod.
So even if the other people here don't seem all that excited, this post had me in tears from the sheer awesome.

Although I do now know that getting the multiplayer to work fully will likely require some C code...
But thats Future Silver's problem.

Huzzah!


Glad to hear your excitement :D And no, I don't think you'll need C for networking. If I get the events/notifications system in good shape, you could actually probably hook into that to efficiently get the game state differentials that you'd need to send to clients. Just speculating at this point though. Right now, however, there is no run-time C compilation support. Ideally I won't need it. Realistically we may not have seen the last of TCC.

Dinosawer wrote:
JoshParnell wrote:computations that have to happen every frame [...] Motion calculations are an obvious culprit. Physics too.


Actually, not necessarily. You don't have to do physics each frame - most simulations have a timestep that adapts to the object being simmed. Say you have something that moves very slowly, there's no point in calculating a new position every second (that would in fact make things less accurate due to numerical errors).
Dunno how useful it is in LT, but a neat way of doing this is Bulirsch-Stoer:
https://en.wikipedia.org/wiki/Bulirsch-Stoer_algorithm
It's an algorithm that allows integrating over arbitrary timesteps. You give it a timestep (ANY timestep, can be super large) and a desired accuracy, and it will automatically simulate your thing at the correct precision over that timestep. Things that don't need as much effort will automatically get less effort (no work too much), things that need more will get it.
Of course, most useful in cases where ideal timesteps for your objects vary largely.


Thanks for the link, it may be useful in a different context. I like the idea of being able to approximate timestep-invariant simulation; will need to do more reading.

But I disagree about the basic case of needing to update every frame. Perhaps not the case if an object is very far away (and obviously not the case for OOS simulation), but you need to compute new position & orientation every single frame if you want smooth motion, doesn't matter how slow something is going. The eye is stupidly sensitive to that when we're talking about displaying the results at 60Hz. In games, for in-system / fine-grain simulation, you have two choices: variable timestep & update motion each frame, or fixed timestep & update motion at F Hz, usually F = 30 or 60 -- but then you have to perform state interpolation when you render, so in fact, you're still calculating a smoothly-interpolated position for every frame.

Honestly though it's kind of a moot point, the motion step is so blazingly-fast that it's not going to benefit from coarser sim. The 'best' we can really do is to keep track of which objects are in motion vs. stationary and swap them between lists as appropriate, so that we don't spend any cache misses traversing idle objects. That should make for a really nice way to have asteroids that can move without overloading the engine :D
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
User avatar
JoshParnell
Developer
 
Posts: 4211
Joined: Sun Oct 07, 2012 3:06 pm
Location: Baton Rouge, LA

Re: Friday, March 17, 2017

Postby Cornflakes_91 » Fri Mar 17, 2017 3:23 pm

Does that mean that asteroids are going to be mobile now? :ghost:
User avatar
Cornflakes_91
Admiral
 
Posts: 8914
Joined: Wed Mar 06, 2013 1:53 am
Location: Austria

Re: Friday, March 17, 2017

Postby Dinosawer » Fri Mar 17, 2017 3:25 pm

Oh yeah, motion is something you definitely don't want to use this for - more for, say, if you'd simulate planetary motion also (because planets don't need a step tine of 1/60 second :ghost: ) or similar. :)
Warning: do not ask about physics unless you really want to know about physics.
The LT IRC / Alternate link || The REKT Wiki || PUDDING
Image
User avatar
Dinosawer
Admiral
 
Posts: 5484
Joined: Fri May 09, 2014 1:08 pm
Location: Belgium

Re: Friday, March 17, 2017

Postby JoshParnell » Fri Mar 17, 2017 3:26 pm

Dinosawer wrote:Oh yeah, motion is something you definitely don't want to use this for - more for, say, if you'd simulate planetary motion also (because planets don't need a step tine of 1/60 second :ghost: ) or similar. :)


Ah oh, I misunderstood :V

Cornflakes_91 wrote:Does that mean that asteroids are going to be mobile now? :ghost:


Hopefully...depends on how well my physics engine ideas work out :]
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
User avatar
JoshParnell
Developer
 
Posts: 4211
Joined: Sun Oct 07, 2012 3:06 pm
Location: Baton Rouge, LA

Re: Friday, March 17, 2017

Postby Cornflakes_91 » Fri Mar 17, 2017 3:35 pm

JoshParnell wrote:Hopefully...depends on how well my physics engine ideas work out :]


*goes to think about new things to do with mobile 'roids*
User avatar
Cornflakes_91
Admiral
 
Posts: 8914
Joined: Wed Mar 06, 2013 1:53 am
Location: Austria

Re: Friday, March 17, 2017

Postby Triscopic » Fri Mar 17, 2017 3:55 pm

Well this is very exciting news.

Josh... please do get some sleep over the weekend: although I greatly enjoyed reading this, it just sounded a little bit like the pre-dark days, super excited, everything is clear now Josh, and we don't want him back.
User avatar
Triscopic
Ensign
 
Posts: 29
Joined: Thu Dec 13, 2012 1:41 pm

Re: Friday, March 17, 2017

Postby Dinosawer » Fri Mar 17, 2017 3:58 pm

Cornflakes_91 wrote:
JoshParnell wrote:Hopefully...depends on how well my physics engine ideas work out :]


*goes to think about new things to do with mobile 'roids*

mobile roids?
soooo
And-roids? :ghost:

*runs*
Warning: do not ask about physics unless you really want to know about physics.
The LT IRC / Alternate link || The REKT Wiki || PUDDING
Image
User avatar
Dinosawer
Admiral
 
Posts: 5484
Joined: Fri May 09, 2014 1:08 pm
Location: Belgium

Re: Friday, March 17, 2017

Postby Cornflakes_91 » Fri Mar 17, 2017 4:03 pm

Dinosawer wrote:
Cornflakes_91 wrote:
JoshParnell wrote:Hopefully...depends on how well my physics engine ideas work out :]


*goes to think about new things to do with mobile 'roids*

mobile roids?
soooo
And-roids? :ghost:

*runs*


Maybe pola-roids
User avatar
Cornflakes_91
Admiral
 
Posts: 8914
Joined: Wed Mar 06, 2013 1:53 am
Location: Austria

Re: Friday, March 17, 2017

Postby Flatfingers » Fri Mar 17, 2017 4:34 pm

:thumbup:

Maybe I'm not the right person to say it, but what the heck: To anyone who read this latest devlog and thought, "oh noes, Josh is re-architecting LT again," nope. Or at least, not really -- not in the sense of a year-long replacement of a core tech such as a language. This is not that.

As I understood it, this was a combination of two insights:

1. Instead of "broadcasting" events to lots of code, some of which doesn't need to run after every event, add a layer of abstraction that lets code only run when it receives a message that says it needs to run, and redesign events to fire messages instead of calling code directly. For the cost of this additional layer of abstraction to an event/trigger model, you can get a significant performance improvement by no longer making some unnecessary function calls.

2. Distinguish more clearly between "what to do" and "how to do it." Just as your brain supports both conscious thinking and the control of autonomic processes (heartbeat, respiration), it sounds like Josh is distinguishing between invariant functions, which can go in the core for performance (the "how") and control functions, which can be in Lua for modding (the "what"). By better balancing core functions and control functions, the performance vs. flexibility tradeoff can be directly managed.

If I've got these about right, it sounds like an early test of combining these two concepts for how the LT code talks to itself has already yielded a major improvement in performance. That is very cool! It sounds like some of that weight may be lifting. :)

It's maybe worth noting that the value of these changes (again, assuming I've understood them) goes beyond raw performance. By being consistent in applying the event/trigger communication model where appropriate, the code actually gets easier to write and modify because it tends to decouple functionality -- each module becomes a little more independent, just doing its thing when triggered. Similarly, a clearer distinction between what is core code and what's OK to do in Lua will also help with understandability.

And one other point on moving some functions into the core: computers are only going to get faster. Even if Josh feels he needs to move some functionality into the core for LT 1.0, it may not have to stay there forever. As general CPU/GPU speeds improve, it might be possible to migrate certain features out of the core, opening them up to modding. So just because some things are off-limits (so to speak) when the initial version of Limit Theory launches doesn't necessarily mean they'll stay out of reach of modders forever.

Naturally, if Josh thinks I've gotten any of the above factually wrong, I appreciate correction.

Anyway, the overall point to this is that while there's some recoding to be done, I think the main change Josh was talking about here is conceptual... but these are really good concepts, which should allow delivery of the performance potential that LT must have. These breakthroughs were necessary now. I believe Josh is on exactly the right track here, and I believe the asteroid performance stats bear that out.

So be of good cheer! I'm certainly excited. :)
User avatar
Flatfingers
Vice Admiral
 
Posts: 4413
Joined: Sat Nov 24, 2012 12:45 am

Re: Friday, March 17, 2017

Postby Slymodi » Fri Mar 17, 2017 4:55 pm

OnEvent
Spoiler:      SHOW
Image


Well it looks like I'll never escape all of the concepts I did in my time at the graphics lab :ghost:
DARKNESS CANNOT DRIVE OUT DARKNESS
User avatar
Slymodi
Rear Admiral
 
Posts: 1345
Joined: Sun Feb 03, 2013 2:51 pm
Location: Third rock from Sol

PreviousNext

Return to Dev Logs



Who is online

Users browsing this forum: No registered users and 4 guests