1. Alun Bestor
  2. Boxer
  3. Issues


Issue #3 duplicate

Interface events block emulation

Alun Bestor
repo owner created an issue

Because both emulation and UI are handled on the main thread, any UI event that opens its own event loop (such as opening a menu, holding down a button, dragging a slider or scroller) will pause the emulation while it is in progress.

At best, this causes the sound to cut out or play the same continuous note, and stutter for a few frames after control returns to DOSBox. At worst, this can crash or freeze games that depend heavily on CPU timing or that rely on the system clock for modulating their speed (System Shock is exhibit A for this.)

While this would be fixed automatically by issue <<issue 2>>, it may be more feasible in the short term to run BXEmulator on a separate thread. Indeed, BXEmulator was designed this way as an NSOperation subclass.

There are two fundamental obstacles to this working:

getting events from the main thread to the DOSBox thread, and

ensuring that changes to the emulation state (such as CPU speed adjustments, view redraws etc.) always occur on the DOSBox thread.

Comments (2)

  1. Alun Bestor reporter

    Given the findings related in issue #3, it becomes clear that a two-thread model will be a waste of time and we should go directly for two-process model detailed in issue #2. This should provide the same benefits, with the same communication requirements, and a lot less hassle with internal state. I'm moving further work on and discussion of this problem off to issue #2.

    Duplicate of #2.

  2. Log in to comment