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

Use Sio2 com.simsilica.thread.* classes for handling job work #69

Open
rvandoosselaer opened this issue Oct 19, 2022 · 3 comments
Open
Labels
enhancement New feature or request

Comments

@rvandoosselaer
Copy link
Owner

No description provided.

@rvandoosselaer rvandoosselaer added the enhancement New feature or request label Oct 19, 2022
@vxel
Copy link

vxel commented Oct 30, 2022

What are the expected advantages compared to the current Java Executor threads ?

@rvandoosselaer
Copy link
Owner Author

rvandoosselaer commented Oct 30, 2022

The main advantage of the JobState is that it queue's a job on a worker thread and when this job is finished, it will execute a second method on the JME render thread.
Behind the scenes it's also using a java ThreadPoolExecutor.

The Job interface that is submitted to the executor has 2 methods:

  • public void runOnWorker();
  • public double runOnUpdate();

The runOnWorker() method is invoked on the worker thread and runOnUpdate() is invoked when the runOnWorker() method is done on the render thread. The runOnUpdate() also returns an 'amount of work', this way you can specify how much work is done on the render thread. If the maximum amount for that pass on the render thread is reached, it will continue processing the results of the finished jobs on the next pass.

I am already quite far in the development of Blocks 2.0 and actually did not use the JobState to handle work in the ChunkManager. I just use an executor to submit tasks too. When a task is finished, the method to trigger the listener is enqueued on the render thread. So all implementing classes of the listener can safely perform scene graph manipulations.

Blocks 2.0 will be a major overhaul and will not be backwards compatible with previous versions. The most notable changes are in the Type system and the ChunkManager*.

The Type system now uses up to 6 textures for a block (up, down, north, east, south, west) and has a lot more parameters to tweak the look and feel. Types can be expressed and loaded in json format.
I also added a custom TextureAtlas that supports adding a border around tiles to overcome the mip map bleed effect. All block textures are added to the TextureAtlas on startup, so only 1 texture is used for all blocks.

The CellManager takes a lot of the changes you made in Ialon. Actions to place/remove blocks now return a BlockActionResult. This class contains the added block (if any), removed block (if any) and a set of cells that need an update.

* In Blocks 2.0 ChunkManager has been renamed to CellManager. This is also the naming used in Mythruna which is - in my opinion - at the moment to most impressive game in development for JME. I took over the naming conventions to speak the same language on the JME forum.

@vxel
Copy link

vxel commented Oct 30, 2022

OK thanks, so I guess the goal is to simplify the Pager and the ChunkManager

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants