printz Posted December 1, 2015 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? 0 Share this post Link to post
RestlessRodent Posted December 1, 2015 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. 0 Share this post Link to post
Linguica Posted December 1, 2015 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: 0 Share this post Link to post
fraggle Posted December 1, 2015 This is a feature that has occurred to me too. But which cloud? 0 Share this post Link to post
RestlessRodent Posted December 1, 2015 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. 0 Share this post Link to post
jeff-d Posted December 1, 2015 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. 0 Share this post Link to post
chungy Posted December 1, 2015 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). 0 Share this post Link to post
fraggle Posted December 1, 2015 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. 0 Share this post Link to post
Maes Posted December 2, 2015 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? 0 Share this post Link to post
jval Posted December 2, 2015 Is there a port that saves games in editable text form? This should work with no problems. 0 Share this post Link to post
chungy Posted December 2, 2015 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. 0 Share this post Link to post
fraggle Posted December 2, 2015 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. 0 Share this post Link to post
Graf Zahl Posted December 2, 2015 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. 0 Share this post Link to post
Maes Posted December 2, 2015 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. 0 Share this post Link to post
fraggle Posted December 2, 2015 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. 0 Share this post Link to post
40oz Posted December 3, 2015 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. 0 Share this post Link to post