Dragon Age Origins Recomp: v0.10.0-dev.4 Recompiles Four Missed Jump Tables

By Indie Kings | October 21, 2026

Updated October 21, 2026: Dragon Age: Origins Recompiled shipped v0.10.0-dev.4 on October 21, 2026, and the build does two things worth a second look: it recompiles four jump tables the recompiler had previously missed, and it stops the game from dying on a failed downloadable-content check instead of showing its own error message. It also arrives on a launcher that now has a Release and a Dev update channel, keeps a spare copy of every save, and rebuilds the game for the exact processor you are standing at.

This site covered the project on October 20, when v0.10.0-dev.3 was the newest build. That piece covered what the recompilation is and what it adds. This one covers the part that changed since: the launcher's release engineering, and the fixes in the build published today.

Image: GitHub social preview for the 96dot/Dragon-Age-Origins-Recomp repository. Image credit: 96dot, via GitHub.

Four jump tables the recompiler had missed

The v0.10.0-dev.4 release notes, published on October 21, 2026, list two crash fixes and a temporal upscaling improvement. The crash fixes are the interesting part.

The first is narrow and nasty. Loading a save while an area is still streaming in, a case the notes describe as seen when loading Ostagar after Awakening, could crash the render thread. The fix makes effects whose parameters have not loaded yet draw without them, rather than waiting on data that is not there.

The second is the one with consequences for anyone who owns the DLC. Four jump tables that the recompiler had missed are now recompiled. One of them sits in the Title Update 6 downloadable-content check, and when that check found a problem the game stopped instead of showing its own "downloadable content is corrupt" message. The other three live in both the disc code and the Title Update 6 code, and had not been seen to crash.

That last detail is the sort of thing a static recompiler is exposed to and an emulator is not. A jump table the translator did not recompile is not a wrong translation of an instruction, it is a missing piece of the program's own data, and the symptom appears far from the cause. The release notes put it plainly: the game stopped, and it should have said something useful.

The third change is cosmetic by comparison. The screen border no longer jitters, and full-screen 2D, meaning menus and loading screens, is no longer jittered either. The notes credit the community contributor who reported it. A separate fix in the same series, from v0.10.0-dev.1, stopped motion vectors crashing under Wine and Proton through vkd3d-proton, where stream output was unbound with an empty view instead of unbound with none.

Release and Dev, and what the update check sends

The launcher grew an update channel switch in the v0.10.0-dev.1 build, and it is the kind of small feature that changes how a project is used.

Per the README, there are two channels, chosen in the launcher's Configure, Advanced, Update channel screen, or with update_channel in the [launcher] section of the configuration file. Release, the default, offers releases only, which at version 0.x are marked pre-release on GitHub and offered all the same. Dev offers the dev releases too, for trying what is next early. The release notes are explicit that dev builds can have bugs, and that an install made from a dev release starts on the Dev channel.

Switching back to Release does not roll the install back. Per the v0.10.0-dev.1 notes, the launcher then waits for the next release, v0.10.0, rather than going back to an older one. That is the right behaviour for a build that has already been recompiled on your machine, and it is also why the release notes for every dev build carry the same advice: if you would rather wait, stay on v0.9.0, because its launcher does not offer dev releases.

What the check sends is worth stating. Per the README, the launcher asks api.github.com/repos/96dot/DAORecomp/releases for the list of releases, and the request carries only the program's version. That can be turned off in the same Configure, Advanced screen or with check_updates = false in the configuration file. Builds from source do not check at all, and when the launcher is hidden there is no check either; the notes say to open it now and then by holding Shift.

On the update path itself, the launcher downloads the new release's executable into an update/ folder inside the install folder, checks it against the SHA-256 lists the project publishes on GitHub, and runs it against the same folder. The checksum catches a damaged or altered download. An update rebuilds only what changed, so the disc image is not needed a second time, and saves, settings and mods are kept.

Save backups and the restore path

Every save overwrite now keeps the version it replaces, in a save_backups folder inside the install. Per the README, it keeps one backup per save, the one before its latest overwrite, and a save the game crashed while writing does not replace it.

When there is not enough room to keep the old save, or the new one's folder cannot be made, the save is not overwritten at all. The game shows a message over the top saying it was not saved, and the old one stays. Closing the window while the game is writing a save waits for the write to finish, up to 10 seconds.

The restore path is in the launcher's Save Backups screen. It lists the backups by character, with when each backup and the save in its place were made. Restoring asks first and will not run while the game is running, and the save it replaces becomes the backup, so restoring again switches back. Two folder names have meanings worth knowing: a .new folder is a backup that could not be put in place, with the reason in the log, and a ~current folder is the save a restore set aside, which is put back when the list is next read with the game closed.

This matters more than it sounds. The cheats menu that arrived in v0.9.0 changes the save like anything else in the game, and the release notes for that build say to back the save up first if you may want it as it was. Before this week there was a way to do that, through a separate save backup screen; now the protection is built into the overwrite path itself, and it fails safe by refusing the write rather than losing the old file.

A build made for your processor, and your processor only

The README is unusually clear about a limitation that other projects bury. The game is built for your processor. With AVX2, which it uses on Intel from 2013 and AMD from 2015, the build takes those newer instructions, and a copy built that way and moved to a PC without them says so when it starts. The instruction is to run the installer on that PC to build the game for its processor.

The install itself needs an x86-64 PC running Windows 10 or 11 or Linux, with a Direct3D 12 capable GPU and a processor with AVX, which the README dates to most processors from 2011 or later. About 25 GB of disk space is needed, 8 GB of it for the game and the rest for the tools and the build, and the first build takes 30 to 60 minutes depending on the CPU.

What the installer downloads is pinned and checksummed, per the README's dependency list: Xenia's third-party libraries and rapidjson, XenonRecomp, SDL 3, the AMD FidelityFX SDK with the signed FSR and frame generation libraries, the Intel XeSS SDK, and NVIDIA's Streamline SDK 2.14.1 for Reflex and DLSS. On the toolchain side it takes LLVM or Clang 22, or the system's LLVM 18 or newer when it has the right tools, plus CMake and Ninja, and MinGit on Windows without git. The Microsoft C and C++ runtime headers and the Windows SDK come from xwin under Microsoft's licence, which the installer asks you to accept, and no Visual Studio installation is needed.

One warning belongs in this story rather than a footnote. OptiScaler, and forks of it, can take over the temporal upscaling, but they are not included. Per the README you copy the files next to the game executable without replacing the AMD FidelityFX libraries already there, rename the OptiScaler library to dxgi.dll, and leave temporal upscaling on, because that is what it replaces. A dxgi.dll sitting there runs as part of the game and the launcher every time it starts, so the README says to use only a build you trust.

The DLC path and the title update check

The DLC flow is unchanged and worth restating for anyone new to the project. Awakening, Leliana's Song, The Darkspawn Chronicles, The Golems of Amgarrak and Witch Hunt need Title Update 6 or 7, and the other DLC works without it. You supply the title update package and the DLC packages from a console or your own backup of them.

Only packages in the read-only format Xbox Live delivered them in, LIVE or PIRS, are read, and the packages themselves are left alone. The title update is checked against the supported disc's media ID, extracted into the install folder, and the game's code is translated a second time from the updated executable, which takes about as long again. The program then holds both versions and runs the updated one.

At startup the build checks title_update/default.xexp to confirm it is Title Update 6's or 7's, and anything else is passed over in favour of the disc's own version. The launcher's Downloadable Content screen shows which DLC and title update are installed and whether the game can use them.

With the DLC check now recompiled, the "downloadable content is corrupt" message the game was supposed to show can actually appear. That is the whole point of the fix, and it is a better outcome than the alternative, which was the game stopping with nothing to say.

FAQ

What is new in Dragon Age: Origins Recompiled v0.10.0-dev.4?
Four jump tables the recompiler had missed are now recompiled, one of which was in the Title Update 6 downloadable-content check where the game stopped instead of showing its error message. It also fixes a render thread crash when loading a save while an area is still streaming, and stops temporal upscaling from jittering the screen border and full-screen 2D.

How do I get dev builds?
Choose the Dev channel in the launcher's Configure, Advanced, Update channel screen. An install made from a dev release starts on that channel. To go back, choose Release, and the launcher waits for the next release rather than going back to an older one.

Can I keep my character if I switch channels?
Your saves, settings and mods are kept, and an update only rebuilds what changed. What does not come back is a previous build, since going back to Release waits for the next release instead of downgrading.

What happens to my saves?
The version a save replaces is kept in the save_backups folder, one per save, and a save the game crashed while writing does not replace it. If there is no room to keep the old save, the game refuses the write and says so rather than losing the file. Restores are in the launcher's Save Backups screen.

Can I move my install to another PC?
Sometimes, with a catch. The build is compiled for your processor, so with AVX2 it uses instructions a 2013 Intel or 2015 AMD or newer has, and an AVX2 build moved to an older PC says so at startup. Run the installer on the destination PC to rebuild it for that processor.

Do I still need my own disc image?
Yes. The installer extracts the Xbox 360 disc image, translates the game's code to C++ on your computer and builds the program there, and the repository ships no game code or data. Supported discs are the English, Italian and Spanish edition, which is also disc 1 of that edition's Ultimate Edition.

Our take: The jump table fix is the kind of detail that says more about the project's maturity than any feature list. A recompiler that silently drops a piece of the original program's data will produce crashes whose error messages point nowhere near the cause, and the fix here restores a message the developers wrote years ago and never saw. The update channel work matters for a different reason: it lets a project ship test builds to people who want them without asking the people who do not to take them.

Bottom Line

Dragon Age: Origins Recompiled is a community static recompilation of the Xbox 360 version of Dragon Age: Origins into a native x86-64 Windows program, and its v0.10.0-dev.4 build, published on October 21, 2026, recompiles four jump tables the recompiler had missed, including the Title Update 6 downloadable-content check where the game used to stop instead of reporting the problem. The same build fixes a render thread crash on loading a save mid-stream and stops temporal upscaling from jittering the border and full-screen 2D. The launcher now carries Release and Dev update channels, keeps one backup of every save it replaces with a restore path in the launcher, and rebuilds the game for the processor you are standing at, which means an AVX2 build will refuse to run on an older CPU. It still needs your own Xbox 360 disc image, and it ships no game code or data.

Sources

96dot/Dragon-Age-Origins-Recomp repository README, including the install requirements, the update channel and update check behaviour, the save backup rules, the DLC and title update handling, the dependency list and the OptiScaler notes, verified October 21, 2026.

96dot/Dragon-Age-Origins-Recomp releases, including v0.10.0-dev.4 published October 21, 2026 with the jump table recompiles, the streaming-load crash fix and the temporal upscaling fix, plus v0.10.0-dev.1, dev.2 and v0.9.0, verified October 21, 2026.

GitHub repository metadata for 96dot/Dragon-Age-Origins-Recomp, verified October 21, 2026: 20 stars, 1 fork, 1 open issue, C, MIT, created October 10, 2026, last push October 21, 2026.

Related: Dragon Age: Origins Is Being Recompiled Into a Native Windows Build