Adding a Speed Multiplier (fixes #123, #130)

[H3nb]

Hi @woesss,

I noticed that people have been asking for a way to adjust game speed (#123, #130). I've been working on a Speed Multiplier feature that allows runtime adjustments.

The Approach:
I implemented a Virtual Clock system using System.nanoTime() as a monotonic base. This keeps the game logic stable even if the system time changes. I then used ASM hooks to redirect MIDlet calls (currentTimeMillis, nanoTime, Thread.sleep) to this virtual clock.

Key Features:

1. Real-time Scaling: Change speed on the fly via the overlay menu.
   
   
2. Sampled Audio Sync: I've added support for setPlaybackParams in AndroidPlayer, so sampled audio (WAV/MP3/etc.) stays in sync with the game speed.
3. Auto-detect Re-conversion: Added a JL-Mod-Dex-Version flag. The emulator will prompt users to "reinstall" old games once to apply the new ASM hooks.
   

Current Limitations:

1. MIDI Tempo: Currently, MIDI music doesn't scale with the speed multiplier because the underlying synthesizer logic doesn't support it yet. It’s mostly working for sampled SFX at the moment.

APK File: Gdrive Mediafire
Fork: https://github.com/H3nb/JL-Mod

Would you be interested in a PR for this?

Note: This is my first time contributing to an open-source project on GitHub, so I apologize if I've made any mistakes in this proposal or if I missed any protocols. I'm happy to adjust the code based on your feedback!

[woesss]

Good job. I'm working on this too and most of it is already done. But thanks, I might borrow some ideas from your implementation.

[H3nb]

Glad to hear that. It’s nice to know JL-Mod is being actively developed. Feel free to reuse anything useful from my implementation.

[H3nb]

Out of curiosity, do you have a rough roadmap for JL-Mod?

[woesss]

I can't find a solution to force a thread to wake up at a new time if the speed is changed while it's already in the TIMED_WAITING state. This is especially critical for speed values ​​close to 0. Thread.interrupt() can't be used because we won't be able to tell whether it was called by ourselves or by the MIDlet/library code.

[H3nb]

I can't find a solution to force a thread to wake up at a new time if the speed is changed while it's already in the TIMED_WAITING state. This is especially critical for speed values ​​close to 0. Thread.interrupt() can't be used because we won't be able to tell whether it was called by ourselves or by the MIDlet/library code.

Hi @woesss,
I think LockSupport.parkNanos() can solve this. The key is that LockSupport.unpark() and Thread.interrupt() are two completely separate wake-up mechanisms, so we can always tell them apart.

Instead of redirecting Thread.sleep() to another sleep-like call, redirect it to LockSupport.parkNanos(). When the speed changes, call LockSupport.unpark(thread) on all parked threads.

After parkNanos() returns, we check Thread.interrupted():

• true → interrupted by MIDlet code → throw InterruptedException (normal behavior preserved)
• false → woken up by our unpark() call → recalculate remaining time with the new speed, then park again
  This cleanly separates the two cases without any ambiguity.

Sketch

public class SpeedAwareSleep {
    private static final ConcurrentHashMap<Thread, SleepState> parkedThreads = new ConcurrentHashMap<>();
    private static volatile double speed = 1.0;

    static class SleepState {
        final long startNanos;
        final long originalMillis;
        volatile long wakeNanos;

        SleepState(long startNanos, long originalMillis, long wakeNanos) {
            this.startNanos = startNanos;
            this.originalMillis = originalMillis;
            this.wakeNanos = wakeNanos;
        }
    }

    // ASM hook: redirect Thread.sleep(ms) → this method
    public static void sleep(long millis) throws InterruptedException {
        if (millis <= 0) return;

        Thread current = Thread.currentThread();
        long now = System.nanoTime();
        long scaledNanos = (long) ((millis * 1_000_000L) / speed);
        SleepState state = new SleepState(now, millis, now + scaledNanos);
        parkedThreads.put(current, state);

        try {
            while (true) {
                long remaining = state.wakeNanos - System.nanoTime();
                if (remaining <= 0) break;

                LockSupport.parkNanos(remaining);

                if (Thread.interrupted()) {
                    // MIDlet code called interrupt()
                    throw new InterruptedException();
                }
                // Otherwise: woken by unpark() due to speed change.
                // Loop back — state.wakeNanos has been updated by onSpeedChanged().
            }
        } finally {
            parkedThreads.remove(current);
        }
    }

    // Called when the user changes the speed multiplier
    public static void onSpeedChanged(double newSpeed) {
        double oldSpeed = speed;
        speed = newSpeed;
        long now = System.nanoTime();

        for (var entry : parkedThreads.entrySet()) {
            SleepState s = entry.getValue();

            // How much virtual time has already elapsed?
            double elapsedVirtualMs = ((now - s.startNanos) / 1_000_000.0) * oldSpeed;
            double remainingVirtualMs = s.originalMillis - elapsedVirtualMs;

            if (remainingVirtualMs <= 0) {
                s.wakeNanos = now;
            } else {
                s.wakeNanos = now + (long) ((remainingVirtualMs / newSpeed) * 1_000_000L);
            }

            LockSupport.unpark(entry.getKey());
        }
    }
}

A few notes:

• LockSupport is available since Android API 1, so no compatibility issues.
• unpark() is idempotent, safe to call multiple times.

[woesss]

Yes, I know that- I already have similar code. But either we completely replace all ways of using time, or we get something that will not work stably and everywhere. MIDlet logic can use Object.wait() for exactly the same purposes as Thread.sleep()

[H3nb]

Hmm, how about using two mechanisms like this:

1. Thread.sleep() → LockSupport.parkNanos() + unpark()

Redirect Thread.sleep(ms) via ASM to a custom method that uses LockSupport.parkNanos(scaledTime) instead, tracking each thread's wake deadline.
When the speed changes, onSpeedChanged() calls LockSupport.unpark() on all parked threads. Each thread wakes up and checks Thread.interrupted():

• true → the MIDlet interrupted it → throw InterruptedException
• false → we unparked it → recalculate remaining time with the new speed, park again

2. Object.wait(timeout) → Chunked wait on the original monitor

Redirect obj.wait(ms) via ASM to a custom method that breaks the wait into small chunks (max ~200ms of real time), looping until the virtual time has elapsed.
The idea is that it still calls obj.wait(chunkMs) on the original monitor object, so notify()/notifyAll() from MIDlet code still reaches the thread normally.
When the speed changes mid-wait, the thread picks it up at the end of the current chunk (max ~200ms delay).
After each wait() returns, measure how long it actually waited. If it returned well before the chunk expired, it was likely woken by notify() rather than a timeout, return immediately to the caller instead of continuing the loop.
The only trade-off I can think of is that a notify() that arrives within a few milliseconds of a chunk boundary might be treated as a timeout, adding at most one extra chunk of delay. Narrow window, and well-written code using while(condition) { wait() } should handles this naturally.

[vietanhvn234-hub]

@H3nb Could you please send me the APK file you created?

[H3nb]

@vietanhvn234-hub sure, here you go link.