Java Continuations and GreenThreads

Shared Code
#81

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?

This


@Override
public void run() throws SuspendedException { 
    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…

#82

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. ;D

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.

#83

@theagentd … hm I agree and I don’t know how to respond to that :slight_smile: So I didn’t post a reply

@Riven
How can I make it work with ant? I don’t like distributing it with a continuations-agent.jar. It would be much more comfortable to simply make it be pre-compiled…

So here is what I used in my build.xml to try to make it work:


  <taskdef name="continuations"
           classname="de.matthiasmann.continuations.instrument.InstrumentationTask"
           classpath="lib/asm-debug-all-4.1.jar:lib/continuations-matthiasm.jar:ant.jar:${module.jdk.classpath.ruinsofrevenge}"/>

   <target name="-post-compile">
      <continuations verbose="true">
          <fileset dir="${build.classes.dir}"/>
      </continuations>
  </target>

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…

But still it gives me this error:


Failed to load type(s):
Class not found de.matthiasmann.continuations.inistrument.InstrumentationTask
#84

Okey. My problem is solved now, everything works now - even without an Agent (of course).

In the end I had the problem, that your classes weren’t distributed pre-compiled. That would have made the “extract classes from jar; post-compile; overwrite classes in jar” redunant.

For everyone else who wants to use the ant task together with Riven’s and MatthiasM’s awesome libraries, can use this jar:
Direct download

#85

I distribute the sourcecode as a separate download already.

#86

Yeah, thats okey, the jar I gave is just for people who don’t want to put .java source files into their project, but make their project have some .jar’s linked…