Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
printz

Would it be possible to have cloud-synced Doom?

Recommended Posts

My main problem with playing Doom on mobile, aside from the clumsier controls, is that its savegames are never the same as on PC. This means that whatever progress I make on my PC at home, I won't be able to continue it on the go. Since we have PrBoom ported to all platforms (not checked if Windows Phone too), both desktop and not, how difficult would it be to store savegames on some cloud service like Dropbox (if not its own), automatically?

I already do it with vanilla Doom on DOSBox+DropBox, but only on desktop. It probably takes some apps to enable autosync and good DOSBox controls on Android, and on iOS it's even more restrictive. With a single PrBoom app handling synchronization and good controls, it may work.

Android has D-Touch and iOS has Gameception, correct? And they use the same savegame format as PrBoom+ for desktop, right? I assume the format will not change?

Share this post


Link to post

I believe Chocolate Doom supports loading/saving of Vanilla save games, I have not tested this however. Looking at the code it appears it does.

This does not work for PrBoom, because:

memcpy(dest, &players[i], sizeof(player_t));
*put++ = sec->ceilingpic;
th->function==T_MoveFloor    ? 4+sizeof(floormove_t):
Uses raw structure data, which means byte order and alignment issues. Just writes values directly thus endian issues.

EDIT: To answer, it is possible to have a cloud based savegame platform but you would need a standard save format or at least a deterministic regardless of architecture and such save game format.

Share this post


Link to post
GhostlyDeath said:

Uses raw structure data, which means byte order and alignment issues. Just writes values directly thus endian issues.

That's a good point. Not taking endianness into account would screw up ports on big-endian mobile platforms such as:













Share this post


Link to post
Linguica said:

That's a good point. Not taking endianness into account would screw up ports on big-endian mobile platforms such as:<brrrrrrrrrrrrrr. I feel so chilly.>


Not taking endian into account is laziness and bad programming.

Here are some common big endian systems:

  • Nintendo 64
  • Wii
  • Wii U
  • XBox 360
  • Playstation 3
  • IBM POWER Servers
  • Sun/Oracle SPARC Servers
  • PowerMacs, PowerBooks, iBooks (PowerPC), iMacs (PowerPC), and XServes
  • That Overpriced Amiga Continuation Board

fraggle said:

This is a feature that has occurred to me too. But which cloud?


Well the most popular clouds now are Amazon's Cloud, Microsoft's Cloud, Google's Cloud, and Apple's Cloud.

Share this post


Link to post

I still use a very ancient Hewlett Packard PA-Risc machine which is big endian. My port has always used non-endian specific save games, just needs a bit of care.
But it would have been much better if all the source ports used compatible files. Much too late now of course.

Share this post


Link to post
fraggle said:

This is a feature that has occurred to me too. But which cloud?

Maybe it's better to just provide an API and people can write a driver to support whatever cloud they want (maybe a "dummy" default driver that just saves to a file system normally... haha).

Share this post


Link to post

To be honest I think Chocolate Doom is likely the only port that has bothered with savegame compatibility to any serious degree. But I don't blame authors of other ports for not bothering.

Share this post


Link to post
GhostlyDeath said:

Uses raw structure data, which means byte order and alignment issues. Just writes values directly thus endian issues.


That's why in Mocha Doom I went to painstaking extremes to read and write FILE data with enforced little-endian order. Since there's no real "straight" equivalent to C's simply reading/writing a complex structure/object or array from/to disk without a lot of added fluff, everything had to go through marshallers/unmarshallers anyway, which also took care of the endianness. Of course, once loaded into memory, there's no difference.

fraggle said:

To be honest I think Chocolate Doom is likely the only port that has bothered with savegame compatibility to any serious degree. But I don't blame authors of other ports for not bothering.


Mocha Doom has a pretty good degree of savegame compatibility with vanilla, and even improves upon it by reconstructing infighting targets from the available data. If a Java-based port can do it, then why not "regular" C/C++ based ones?

Share this post


Link to post

Is there a port that saves games in editable text form? This should work with no problems.

Share this post


Link to post
Maes said:

Mocha Doom has a pretty good degree of savegame compatibility with vanilla, and even improves upon it by reconstructing infighting targets from the available data. If a Java-based port can do it, then why not "regular" C/C++ based ones?

That's fine and good if Mocha Doom has high vanilla compatibility in general, but for ports that don't, such as ZDoom, it doesn't really make sense.

Share this post


Link to post
Maes said:

Mocha Doom has a pretty good degree of savegame compatibility with vanilla, and even improves upon it by reconstructing infighting targets from the available data. If a Java-based port can do it, then why not "regular" C/C++ based ones?

Nice work. I realised a while ago that it would be possible to do this using the mobj_t prev/next pointers but I don't remember if I commented on it. Sounds like you've done the same thing.

jval said:

Is there a port that saves games in editable text form? This should work with no problems.

That would be an interesting project - the equivalent of UDMF for save games. Conceivably if done right you could even have savegame compatibility between different source ports.

The problem as it stands is that there really isn't any savegame "format" as such. Savegame files are essentially just memory dumps, and structures are different between source ports, source port versions, compilers and CPU architectures. So to get the kind of compatibility being discussed, you need to actually define a format. It could be in text format, or you could use a properly-defined binary format like protocol buffers for example. For Chocolate Doom I took the DOS vanilla encoding and turned it into an explicit file format, but that's not going to work for more advanced ports.

Share this post


Link to post
fraggle said:

Nice work. I realised a while ago that it would be possible to do this using the mobj_t prev/next pointers but I don't remember if I commented on it. Sounds like you've done the same thing.

That would be an interesting project - the equivalent of UDMF for save games. Conceivably if done right you could even have savegame compatibility between different source ports.



I tried this once, using JSON as storage container. Turned out to be way too slow for actual use.

Share this post


Link to post

Well, it could work if everybody agreed to add a text dumper/parser (following e.g. XML or better, JSON notation with hex numbers, logical values or strings where appropriate), and to always define/map at least the fields used in vanilla's structures, plus any of their own.

Any fields not recognized by a port, should simply be ignored during reading. This should allow ports to at least output a vanilla-compatible subset of their status. Obviously, loading savegames with just the minimal agreed upon amount of information might not be an accurate way to save e.g. ZDoom games, but it might be accurate enough to resume a game on Chocolate Doom, or viceversa.

Share this post


Link to post
Graf Zahl said:

I tried this once, using JSON as storage container. Turned out to be way too slow for actual use.

Understandable. Something like protobufs or our own Aardappel's FlatBuffers would probably work better.

Share this post


Link to post

For the last couple years I daydreamed about how convenient it would be to have Doom on the cloud. Day to day I'm away from my personal computer so being able to look at a wad from a computer or other mobile device other than my own from anywhere without having to actually download it would be super convenient.

Also to be able to play Doom from a remote server along with the largest wad archive would be pretty sweet.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×