Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

A game's framerate (FPS) is determined by whichever of three threads takes the longest: the game thr... #941

Open
github-actions bot opened this issue Feb 3, 2022 · 4 comments
Assignees

Comments

@github-actions
Copy link
Contributor

github-actions bot commented Feb 3, 2022

A game's framerate (FPS) is determined by whichever of three threads takes the longest: the game thread, the rendering thread, and the graphics. In almost all Core games, the rendering thread is slowest, and responsible for taking game data and sending it to the graphics processor.


<!-- TODO: A game's framerate (FPS) is determined by whichever of three threads takes the longest: the game thread, the rendering thread, and the graphics. In almost all Core games, the **rendering thread** is slowest, and responsible for taking game data and sending it to the graphics processor. -->
Merged models allow Core to run a process when your game first loads to simplify a Merged Model into just the sides that a player might collide with and sends that data to the server.


This issue was generated by todo-issue based on a TODO comment in dce2d44. It's been assigned to @StanzillaManticore because they committed the code.
@github-actions
Copy link
Contributor Author

A game's framerate (FPS) is determined by whichever of three threads takes the longest: the game thr...

A game's framerate (FPS) is determined by whichever of three threads takes the longest: the game thread, the rendering thread, and the graphics. In almost all Core games, the rendering thread is slowest, and responsible for taking game data and sending it to the graphics processor.


<!-- TODO: A game's framerate (FPS) is determined by whichever of three threads takes the longest: the game thread, the rendering thread, and the graphics. In almost all Core games, the **rendering thread** is slowest, and responsible for taking game data and sending it to the graphics processor. -->
Merged models allow Core to run a process when your game first loads to simplify a Merged Model into just the sides that a player might collide with and sends that data to the server.


This comment was generated by todo-issue based on a TODO comment in 1cf20e5. It's been assigned to @StanzillaManticore because they committed the code.

@github-actions
Copy link
Contributor Author

A game's framerate (FPS) is determined by whichever of three threads takes the longest: the game thr...

A game's framerate (FPS) is determined by whichever of three threads takes the longest: the game thread, the rendering thread, and the graphics. In almost all Core games, the rendering thread is slowest, and responsible for taking game data and sending it to the graphics processor.


<!-- TODO: A game's framerate (FPS) is determined by whichever of three threads takes the longest: the game thread, the rendering thread, and the graphics. In almost all Core games, the **rendering thread** is slowest, and responsible for taking game data and sending it to the graphics processor. -->
Merged models allow Core to run a process when your game first loads to simplify a Merged Model into just the sides that a player might collide with and sends that data to the server.
The graphics processor then visually renders the Merged Model entirely, instead of waiting on calculations for each object on whether or not they are close enough to a player to be rendered.


This comment was generated by todo-issue based on a TODO comment in c43b1b1. It's been assigned to @StanzillaManticore because they committed the code.

@github-actions
Copy link
Contributor Author

A game's framerate (FPS) is determined by whichever of three threads takes the longest: the game thr...

A game's framerate (FPS) is determined by whichever of three threads takes the longest: the game thread, the rendering thread, and the graphics. In almost all Core games, the rendering thread is slowest, and responsible for taking game data and sending it to the graphics processor.


<!-- TODO: A game's framerate (FPS) is determined by whichever of three threads takes the longest: the game thread, the rendering thread, and the graphics. In almost all Core games, the **rendering thread** is slowest, and responsible for taking game data and sending it to the graphics processor. -->
Merged models allow Core to run a process when your game first loads to simplify a Merged Model into just the sides that a player might collide with and sends that data to the server.
The graphics processor then visually renders the Merged Model entirely, instead of waiting on calculations for each object on whether or not they are close enough to a player to be rendered.


This comment was generated by todo-issue based on a TODO comment in 5b834cf. It's been assigned to @StanzillaManticore because they committed the code.

@github-actions
Copy link
Contributor Author

A game's framerate (FPS) is determined by whichever of three threads takes the longest: the game thr...

A game's framerate (FPS) is determined by whichever of three threads takes the longest: the game thread, the rendering thread, and the graphics. In almost all Core games, the rendering thread is slowest, and responsible for taking game data and sending it to the graphics processor.


<!-- TODO: A game's framerate (FPS) is determined by whichever of three threads takes the longest: the game thread, the rendering thread, and the graphics. In almost all Core games, the **rendering thread** is slowest, and responsible for taking game data and sending it to the graphics processor. -->
Merged models allow Core to run a process when your game first loads to simplify a Merged Model into just the sides that a player might collide with and sends that data to the server.
The graphics processor then visually renders the Merged Model entirely, instead of waiting on calculations for each object on whether or not they are close enough to a player to be rendered.


This comment was generated by todo-issue based on a TODO comment in 339a538. It's been assigned to @StanzillaManticore because they committed the code.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

1 participant