next »

['n ddrylliog]

Hi,

What'd you think about being able to :
- Set the speed the time is passing by, e.g. normally it's 1.0f but you can set it to .5f or 2f to make your game half or twice as fast.
- Pause the time. All ScheduledOperations are still executed but the time stay the same until your "Resume" the time. IIRC, the pause/resume method in their current implementation disable all ScheduledOperation(s)
- Having sub-OperationScheduler(s) so that you can group operations and order them (e.g. : first I want all User Input operations, then all Network operations, then all IA operations, then the Graphic rendering). That would be most useful, and can be provided easily.

Marvin, can you do that, or I'm doing that ?

[Marvin Fröhlich]

- Set the speed the time is passing by, e.g. normally it's 1.0f but you can set it to .5f or 2f to make your game half or twice as fast.

I've already thought about that. But it might be a little tricky. But it's certainly possible and at least very useful.

- Pause the time. All ScheduledOperations are still executed but the time stay the same until your "Resume" the time. IIRC, the pause/resume method in their current implementation disable all ScheduledOperation(s)

"pause" simply pauses the RenderLoop. So all subsystems like the OperationScheduler are also paused.

- Having sub-OperationScheduler(s) so that you can group operations and order them (e.g. : first I want all User Input operations, then all Network operations, then all IA operations, then the Graphic rendering). That would be most useful, and can be provided easily.

OperationScheduler is an interface. So you can always write your own implementation as you like and publish it to the RenderLoop by invoking the setOperationScheduler() method. I'm not sure, if it wouldn't get a little bloated, if this was provided by default. And we will never cover any need with it. So people should be aware of it and can write their own implementations, if the default one is not sufficient.

And also remember, that the default OpScheder executes the ops in the order, they have been added.

Marvin, can you do that, or I'm doing that ?

I will do it (the two first ones).

Marvin

['n ddrylliog]

Okay, I will do the Sub-OperationScheduler one, it's not as tricky or bloated as you think. (Well, at least how I think about implementing it).
It's just a matter of

Code:

SubOperationScheduler implements ScheduledOperation, OperationScheduler

You add it to your main OperationScheduler and that's how you can group operations.
I know, SchedOps are executed in the order they're added : but it's only sufficient for simple usecases. See the Input/Network/IA/Graphics separation usecase I wrote in my first message. You have to keep in mind some people want to make big projects with Xith3D..

For the pause I was talking about, it's unlike the current pause/resume function. It should be called setFreezed(boolean freezed). When the world is frozen, all ScheduledOperation are still getting executed, but gameTime and frameTime stay the same. See ?

[Mathias 'cylab' Henze]

It would be nice to have a PreparedOperation, that adds a

Code:

public void prepareOperation(long gameTime, long frameTime, long estimatedFinishTime);

where prepareOperation is called on another thread, so you can execute time consuming tasks there. Once prepareOperation is finished executeOperation is called on the next renderLoop. The estimatedFinishTime argument should contain a guess, when the executeOperation method will be called. This could start with gameTime+30ms and could get estimated more precisely by measuring the actual execution time of prepareOperation (multiplied with e.g. 2 for safety).

['n ddrylliog]

+1

[Marvin Fröhlich]

(2.) and (3.) are now implemented. (1.) will follow.

I've added a setPauseMode() method, that takes an int. 0 = not paused, 1 = paused totally, 2 = paused only rendering. There are appropriate constants at the RenderLoop class.

The OperationSchedulerImpl class now extends the new super class of RenderLoop, which is capable of starting a new Thread, that periodically updates the OperationScheduler (which also implements the new "Updatable" interface).

And there's a new OperationScheduler implementation called "OperationSchedulerQueue". It is capable of holding a list of OperationSchedulers, which is updated in a certain order. There can be one OpScheder, which is the "active" one. All calls to OperationSchedulerQueue's schedule*() methods are dispatched to the currently active one. Of course the OSQ also extends UpdatingThread, which enables it to run in a separate Thread, too.

Marvin

['n ddrylliog]

Great ! But shouldn't setPauseMode() use an enum instead of an int ?

[Marvin Fröhlich]

Great ! But shouldn't setPauseMode() use an enum instead of an int ?

Yes, in principle. But it is a method of the base class, that handles the threading. And this class can be used for arbitrary subclasses, which can have other pause modes. The RenderLoop itself for example has the additional pause mode PAUSE_RENDERING, which the threading super class cannot know. And it is also imaginable to use the pause mode like a bit mask.

Marvin