Return to “Dev Logs”

Post

Re: [Adam] Monday, October 2, 2017

#91
charles wrote:
Sun Oct 08, 2017 2:48 am
Grumblesaur wrote:
Sat Oct 07, 2017 9:25 pm
If the scripting portion of the engine is multithreaded, and you assign a thread for every script, threads will be distributed by the operating system across as many cores as the engine is made aware of.
from the Lua reference manual
Lua supports coroutines, also called collaborative multithreading. A coroutine in Lua represents an independent thread of execution. Unlike threads in multithread systems, however, a coroutine only suspends its execution by explicitly calling a yield function.
Now that doesn't stop the game engine using O/S mutlithreading for, possibly as an example, graphics rendering and display.

regards,
Charles
Stick shift scheduling. I dig it.
Shameless Self-Promotion 0/ magenta 0/ Forum Rules & Game FAQ
Post

Re: [Adam] Monday, October 2, 2017

#92
Damocles wrote:
Sat Oct 07, 2017 12:44 pm
Concerning this topic, whats the planned logic ticks per second for LT?
(For RTS games I have found 16 Ticks per second to be more than enough. For a Racing game or Shooter, it probably should be around 60 or even higher though.)
It's too early to tell at the moment.

Grumblesaur wrote:
Sat Oct 07, 2017 9:25 pm
Such a model might make scripts that depend on other scripts impractical, since if script B requires data collected or generated by script A and script B's thread is given CPU time first, it might try to access empty or nonexistent data, or have to yield to A and try again later. We're at the mercy of the scheduler here.

What might be better is to execute scripts in order (and perhaps according to a system of priority, since some scripts will run at higher or lower levels of detail) and instead make multithreading available within the scripts so that operations that require logical or mathematical operations on large groups of entities can be farmed out to multiple threads for a quicker execution time.
Josh's current idea here is that scripts will read from the previous game state while building the current game state. That avoids most or all of the order dependence issues.
Post

Re: [Adam] Monday, October 2, 2017

#93
AdamByrd wrote:
Mon Oct 09, 2017 9:11 am
Damocles wrote:
Sat Oct 07, 2017 12:44 pm
Concerning this topic, whats the planned logic ticks per second for LT?
(For RTS games I have found 16 Ticks per second to be more than enough. For a Racing game or Shooter, it probably should be around 60 or even higher though.)
It's too early to tell at the moment.
For a game like LT, I would expect it to be varied. Josh mentioned using a system where the AI would listen for events and arrange its updates with those in mind, to keep resources free and framerate as high as possible. Such a system would have very sparse updates in open expanses with few enemies around, more updates when doing a task such as searching for ore, and even more when in the middle of combat. While riding a warp rail, you only really need check on things whenever you get to your destination, but in a dogfight, you'd need to keep the AI "thinking" constantly. As such, I don't think your question is quite applicable here, Damocles.
Have a question? Send me a PM! || People talking in IRC over the past two hours: Image
Image
Image
Post

Re: [Adam] Monday, October 2, 2017

#94
No, my question wasn't about how often an ai processes its own cycle. Its about the basic (fixed time) logic-tick in the gameloop.
The part that determines the timing.
The logic tick can be super cheap, if there are no updates scheduled to be calculated. No reason to make it delay dynamically (that would just complicate matters).

Here an example of a simple gameloop (given variable render frame durations)

Code: Select all

public void gameLoop() {
    float delta;
    float accumulator = 0f;
    float interval = 1f / targetUPS;  //tick speed of game
    float alpha;

    while (running) {
        delta = timer.getDelta();
        accumulator += delta;

        input();

        while (accumulator >= interval) {
            update();  //gamelogic
            accumulator -= interval;
        }

        alpha = accumulator / interval;
        render(alpha);  //render, using alpha as "delta" transition offset here

        window.update();
    }
}
Its useful to have the same number of updates (ticks) per second, no matter how the render speed per frame is.
Having a fixed number of updates per second makes lots of calculations easier, and avoid edge cases in case the performance drops too low, or gets too high.
Last edited by Damocles on Mon Oct 09, 2017 9:48 am, edited 1 time in total.
Post

Re: [Adam] Monday, October 2, 2017

#96
In the case of physics updates I would hope that Josh and Adam put that on a slider, so that we can adjust it for local performance.

For people like me whose machine has no issue running two games at 4K 60fps at the same time (only 60 thanks to screen refresh).
Then a physics update step rate of 60/s would be great.

For people like Talveino, who need a new laptop, you might want to set your physics updates down to 15/s.


With AI Updates, the base tick is likely to match up with the physics one, purely to allow any local AI ships to maneuver around in time with the physics updates, before a draw step.
The rest of the world might update far less often than this, and might even update less than once a second, if Josh decides to be smart and add in interpolation of the ships position when it doesn't have it's model loaded in the local system. (to make it look like it is flying smoothly) If he doesn't include that, then I'd expect AI in same system, but not loaded in would update every second to give the appearance of moving smoothish.

For AI outside the system, I would expect that the systems less than 3 hops away would update every 30 seconds or so, staggered out by a second each. And any systems further away than that to update once every 2-5 minutes.

This would mean that each AI tick should turn out to be close enough to the same length, as to minimize any perception of slow ticks.

Although the exact numbers for anything outside of the loaded in area would be up for debate, and likely controlled by fancy math. :D
°˖◝(ಠ‸ಠ)◜˖°
Toba - A Development Dump
Post

Re: [Adam] Monday, October 2, 2017

#97
I'm starting to think we'll need a menu to navigate all the sliders that have been proposed :ghost:
Image
When you're trying to fill an infinite multiverse, if you're not willing to consider the entire creative output of humanity as a starting point, you're wasting your time.
User: JoshParnell is accountable for this user's actions.

Online Now

Users browsing this forum: jayw81, Tylon and 2 guests

cron