Return to “Dev Logs”

Post

Re: Friday, March 17, 2017

#16
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!
°˖◝(ಠ‸ಠ)◜˖°
WebGL Spaceships and Trails
<Cuisinart8> apparently without the demon driving him around Silver has the intelligence of a botched lobotomy patient ~ Mar 04 2020
console.log(`What's all ${this} ${Date.now()}`);
Post

Re: Friday, March 17, 2017

#19
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.
Post

Re: Friday, March 17, 2017

#20
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.
Post

Re: Friday, March 17, 2017

#21
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
Post

Re: Friday, March 17, 2017

#24
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
Post

Re: Friday, March 17, 2017

#29
: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. :)

Online Now

Users browsing this forum: No registered users and 3 guests

cron