caiiiycuk / js-dos

The best API for running dos programs in browser

Home Page:https://js-dos.com

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Vanilla js-dos v7.x loses saved changes after 3rd / 4th persist

mrtnkl opened this issue · comments

For test I'm running latest js-dos from js-dos.com and Wolfenstein 3D bundle from dos.zone. But this issue happens on any game I test.

Starting a game, saving in-game (slot 1, I name it "1") and then pressing the js-dos disk icon to persist changes into indexedDB. This works as expected. Reloading, doing is again, saving a second time (slot 2, named "2"), works as well.

But after a 3rd or 4th time, this loop will result in losing earlier saved changes, like this:

Screenshot 2023-10-16 at 05 43 05 Screenshot 2023-10-16 at 05 44 47

I expected my save games 1 to 5 to remain present.
My hunch is that the actual changes on disk are not compared properly to the original bundle, but to an earlier "changed" state. As such, in this process, the newest ".changes" in indexedDB keeps on losing earlier save games.

This is the simplest html I run on localhost:

<!doctype html>
<html>
  <head>
    <style>
      html, body, #jsdos {
        width: 100%;
        height: 100%;
        margin: 0;
        padding: 0;
      }
    </style>
    <script src="https://js-dos.com/v7/build/releases/latest/js-dos/js-dos.js"></script>
    <link rel="stylesheet" href="https://js-dos.com/v7/build/releases/latest/js-dos/js-dos.css"/>
  </head>
  <body>
    <div id="jsdos"></div>
		<script>
			const wolf3d = "https://cdn.dos.zone/original/2X/a/ac888d1660aa253f0ed53bd6c962c894125aaa19.jsdos";
		  emulators.pathPrefix = "/v7/build/releases/latest/js-dos/";
		  Dos(document.getElementById("jsdos")).run(wolf3d);
		</script>
  </body>
</html>

Interesting, sounds like a bug.

By the way, does it reproduce on DOS.Zone? By default, it's using JS-DOS v8. (on desktop)

It also depends if you logged or not, in case if you are logged game is loaded from cloud not from indexeddb.

Haven't tested on dos.zone, but on v7 I could reproduce this by implementing a custom persist (localStorage instead of indexedDB). The results were the same, so my hunch is that there's an issue in properly detecting "changes" in a bundle, and it's not the storage/persist mechanism.