I got what this lib is doing now, but I wasn't able to run my code. It got me this error:Calling function not instrumentedIn Coroutine.yield();.

I guess it is because of the bytecode not being changed. Having a yield() function simply reporting an error doesn't make sense.

So I looked into continuation-agent.jar and found that MAINFEST. It had the "premain" stuff included, but I didn't know how to use it. Either I did something wrong when I tried to run my exported .jar using a edited MAINFEST, or this doesn't work.

I've also tried to look at ant. I didn't use ant before, so this wasn't easy for me, and I didn't got it working in those couple of hours. I don't know how to "integrate" the ant code Matthias Mann showed in his blog post.

Do I read this correctly - mixing green threads and real threads is problematic? I must misunderstand, as obviously this would mean not being able to take advantage of the multiple hardware threads of modern processors...?

Works perfectly here Glad I could understand the basics of Green Threads and Continuations.

I just wonder, what if I want all my entities (which run on a VirtualThread each) have a delta time delivered. Just like I usually do it with a tick(float delta) method. How can I do that?I don't actually have the problem, since there is

Ticked based approaches are the opposite of the what green threads are meant to provide.

Having two "services" for each entity is what i prefer. One "high level script" (or "behavior script") with continuations, that gives orders like this:

set_destination(target)wait_until_target_reached_or_failed

Then a second, tick based loop, which handles the per-frame updates to position, direction, path following etc. This second service can run in a separate native thread, as you are suggesting, without using green threads. Then the two threads exchange messages. The path generation can be done on the script thread because that thread is not time sensitive, and generating a path is a one-time big time expense, while path-following is not. If some script event is delayed, thats not a problem. The bot might just stand a couple of more milliseconds where its path ended before continuing with its next action, but that is not game-breaking. But statistically, bots will be always following a path, and will rarely require attention from the script thread. Attacking the player, however, must be done on the tick thread, because the bot must react to player right away. What the script thread can do, is to set the bots reaction to player. Something like: "attack on sight", "neutral", "friendly", "ignore", "stop the path if attacked" etc. Then the condition checking and actual attacking is done by the per-frame thread. If the script wants the attack to end, it has to change the reaction type.

Ticked based approaches are the opposite of what green threads are meant to provide.

Having two "services" for each entity is what i prefer. One "high level script" (or "behavior script") with continuations, that gives orders like this:

set_destination(target)wait_until_target_reached_or_failed

Then a second, tick based loop, which handles the per-frame updates to position, direction, path following etc. This second service can run in a separate native thread, as you are suggesting, without using green threads.

That's indeed how you'd do it, except that I'm strongly suggesting to keep the second service (running the VirtualProcessor) in your main thread too. It makes sure that all memory read/write access is done on the same thread, which means your code is much simpler to comprehend and debug, as everything is deterministic.

Yeah that is indeed simpler, but the path generation tends to be quite expensive. So some kind of scheduler is needed to make sure, that it doesn't happen that in a single iteration a bunch of bots request a new path at the same time, because that would be noticeable. So path generation is a good candidate to move out to a second thread. If its on a separate thread, then that thread can generate paths non-stop. And since path generation is tied to what the bot would actually do, the whole scripting is simpler and no "path generation queue" is necessary, if all is done with green threads. The bots will wait for their path until their turn comes to get it generated. I'm assuming that all this is running on a multicore CPU. With a single core, all should run on a single thread, like you described.

Preferably you'd do VirtualThread.yield() in your path-finder, as to let the AI of multiple units handle path-finding concurrently (on the same thread), The longer a unit searches, the longer that specific unit has to wait for the final path, without blocking any other unit.

From an AI point of view, this is 'fair', and technically it's 'nice' (I love subjective terms).

I can't stress this enough, keep all your logic on 1 native thread, if you value your sanity.

Hi, appreciate more people! Σ ♥ = ¾Learn how to award medals... and work your way up the social rankings!

So you suggest not to do that, since it is 'ticky' ( )... What about this?

1 2 3 4 5 6

@Overridepublicvoidrun() throwsSuspendedException { move(speed);// Probably also with subtracting the time the AI computation took:VirtualThread.sleep(16);}

Well... this is awesome... I just Imagine what would happen. We wouldn't have a delta-time dependent game loop in the end, but a 'multiple-update render-once' loop. That fancy one, which doesn't make the 125 FPS jumps theagentd linked happen...

I don't actually know how to apply this to a game, which hasn't got anything similar to units. It's not a RTS.If I apply this to my kind of game, which has "more action", then I'd be polling the input in the continuation and moving the player in the tick() method?

We wouldn't have a delta-time dependent game loop in the end, but a 'multiple-update render-once' loop. That fancy one, which doesn't make the 125 FPS jumps theagentd linked happen...

Uh, what? Did I miss something?

This

1 2 3 4 5 6

@Overridepublicvoidrun() throwsSuspendedException { move(speed);// Probably also with subtracting the time the AI computation took:VirtualThread.sleep(16);}

is "running at 60 FPS" no matter what rendering framerate there is. And it's not another native thread...

It's running at 62.5 FPS, but whatever.

I don't remember posting any code that uses a variable time step recently. I've also not really recommended doing updating and rendering in different threads at the same time. Oh, did you refer to the Call of Duty video I posted? I thought you meant that some code I posted did sudden jumps up to 125 FPS.

Simply updating at a certain speed does solve the 125 FPS problem, but it also introduces some problems. Although the code looks very different, how would this behave differently from simply having a normal update loop that updates every 16th millisecond? It doesn't solve any of the key problems here. By updating 62.5 times per second, you're limiting yourself to 62.5 FPS too, since even if you were to render 125 FPS, every other frame would be identical to the one before since nothing's moved. What if the player's computer can't update the game at 62.5 updates per second? The game speed will slow down. The solution is the same as before: to update at a relatively low rate (30Hz maybe), but generate additional (unique) frames in-between by interpolating positions between the last and current frame.

The thing is that this has nothing to do with green threads, or even how you update the game. It only concerns how you render it. You can use a green thread for each game object to update them and render them with interpolation for perfect results, but green threads have nothing to do with the 125 FPS problem. You still have to face the exact same problem I was talking about in the 125 FPS problem thread.

The paths "lib/asm-debug-all-4.1.jar", "lib/continuations-matthiasm-jar" and "ant.jar" are all checked and correct. Clicking on the "de.matthiasmann.*.InstrumentationTask" and IntelliJ IDEA opens the class...

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org