Revert "Remove Boot from DVD Backup" #11462
Conversation
|
For comparison, here are some DiscIO-related features that each individually have been more of a maintenance burden than DriveBlob:
If these don't seem like maintenance burdens, that's because they've only been small maintenance burdens. And DriveBlob has been even less of a maintenance burden than them. |
|
Here's the more important question imo when it comes to removing this feature - how does anyone get a playable experience with the DVD drive stuff? The amount of extra lag and issues seems pretty ridiculous. |
|
I have been using the boot from backup disc for years and have never had issues with it. I have many games Wii games on single layer DVD+R disc and a few on dual layer DVD+R discs. All my GameCube games are burnt onto mini DVD-Rs discs. I tried starting at new thread over at https://forums.dolphin-emu.org/ to see how much interest this feature really has but the post never appear most likely because it was not approved by a moderator. Is there any benefit from removing the option to boot from backup discs? That is another important question. |
|
For me the question is not how do you find it playable or if you use it, its why do you use it? Is there any advantage to you booting from dvd backups apart from the fact that you are currently doing it? |
It's really not. If that's the threshold, then I guess we're never deprecating anything. If this was new code I would not support adding this feature to Dolphin, and that's really how I'm looking at it now. See my last comment on the removal PR: it's confusing for users who think they can actually use GC/Wii discs (they can't), and even if you use the feature right (which ~nobody does) it just leads to bad experience because of seek times causing significant stuttering as we've observed testing this pre-removal. Strong -1 from me for reintroducing this.
OK, then let's keep the DiscIO code and not burden the DolphinQt code with it? :) |
I like popping discs into the disc drive. Can I go out, buy a drive and dump all my discs to it. Assuming I have the money for a drive, I guess I can do that but why? What is wrong with having options? For my PS1/2 and Sega CD games, I also use emulators that can boot from discs. I understand those systems are a little different since you can easily use the backup discs in modified consoles and the emulators will read retail discs but unless being able to boot from backups in Dolphin is blocking some sort of progress with another feature, what is the problem with having the option there for those of us that it works for? |
|
Can anything be done to remove (or at least significantly reduce) the stuttering caused by seeking the disc, and, more importantly, is there anyone wiling to do that work? That's something I actually tried to do off-record a few years ago but I clearly had no idea what I was doing, so I gave up. From my point of view, between having the option available with the severe stuttering it always had and not having it anymore, I'd probably pick the latter (which was already done by PR #11456). Dolphin improved a lot over the years and I feel this implicitly raised the bar regarding how well features we ship are expected to work. Boot From DVD Backup may have a minimal maintenance burden but it also never worked well, so unless something can be done to improve it, I'd leave it out... |
|
The disc content could be aggressively cached ahead of time. On modern devices loading the entire fs into memory is probably not a big deal. dolphin should have something like this anyway to deal with things like playing images from network/internet locations (and modern internet speeds are probably faster than disc readers …). Am I going to do it? No :p but an idea… having said that, I also don’t think boot from disc is a frequently used or critical feature. |
|
If anyone wants to run games off DVDs backups, they should reimplement this feature in a way that's actually good. The ancient boot from dvd backup is incredibly primitive and old, and there are dozens of ways to make something that beats it. Just like Hybrid Wii Remote and countless other features, removing a bad feature is the perfect opportunity for someone who liked it to reimplement it in a better way. All reverting will do is keep it bad. Reverting is not the answer. |
It's more than we usually get when we remove support for something. The last time I recall getting a response like this was when removing fractional IRs. Let me compare the two to explain why I think we don't have much reason to remove this feature. For fractional IRs, what pushed us to remove it was the graphical problems it had been causing for years, combined with in the end discovering that it could corrupt save files. We knew that there were users that liked the feature for performance reasons, but we considered the drawbacks of the feature to be big enough to outweigh what those users thought. For this feature, aside from the feature being confusing, the reasons to remove it are that it doesn't work with real discs, that the performance sucks, and that most people nowadays don't use DVD-Rs. In other words, that we don't think the feature is useful for people. But as soon as we merged it, people showed up complaining, which means there are people for who the feature very much is useful (which I wouldn't really have expected). Of course, we can discuss how many additional users like this there really are, but my point is: Unlike most feature removals, we have no technical reason to remove the feature.
That's a good point. I also wouldn't have added it if it was a new feature.
It's only 19 lines of code, and they just add some menu items. But if this compromise means we could re-add the feature, I would be fine with it. Maybe not having the feature in the GUI (forcing users to go through the command line) would be a good tradeoff for the problem of users being confused?
The performance problems with this feature have nothing to do with the DriveBlob code. The core problem is that seeks are slower than Dolphin's emulated disc drive timing model expects them to be. This could be addressed by making the timing model more flexible (non-deterministic), or maybe by caching like shuffle2 mentioned (not sure how well that would work in practice, since it takes a good while to read the whole disc). Doing either of these two would touch completely different parts of the code base than the code that was removed by the feature removal. |
|
Someone just posted on the forums that they've been able to use this feature without any stuttering, which would explain a lot regarding why there are people who willingly use this feature: https://forums.dolphin-emu.org/Thread-boot-from-dvd-backup-has-been-removed?pid=528676#pid528676 Perhaps May's disc drive is slow at seeking for some reason? (Or this person's disc drive abnormally fast?) |
Same (only?) person who's been reporting this result here, fwiw. Just in case you're keeping count.
JMC also did some testing and claims he wasn't able to run FMVs in Metroid Prime at full speed on his DVD drive. |
Yes, they're one of the people who have been posting here on GitHub. I just don't recall reading any clear statement that there was no stuttering before.
Okay, I wasn't aware. Thanks for letting me know. That's interesting, FMVs shouldn't use any seeking... So maybe my idea of what the issue is was a bit too simple. |
|
The last time I tried this feature (years ago, to be clear), I remember having stuttering issues only when seeking, sequential data streaming worked fine. I haven't tried a lot of games, though, just Zelda Twilight Princess GC and DKC Returns. Drives tested at the time included a Lite-On DH-20A4P (desktop) and a Panasonic UJ160 (laptop). Nowadays I have access to a LG BU50N, but I've never really tried Boot from DVD Backup with it.
That's what I've tried to do at the time (ignore emulated disc timings when running off a DVD Backup), but couldn't as I didn't understand that part of Dolphin's codebase. Yes, that would make Dolphin non-deterministic when using a DVD backup and thus prevent some features that relies on determinism from working (NetPlay, TAS tools, etc.) but as far as playability is concerned, I think it's reasonable to expect GC/Wii titles to be programmed handle such cases, as slower than expected seek/reading performance definitely could happen on a real GC/Wii (e.g. dirty or scratched discs)... |
I've tested some games using my Plextor PX-716A instead of my ASUS BW-16D1HT and I had a smoother experience overall. |
|
My drive sucks for this, but I don't have any computers with a DVD drive here. I do have some old DVD drives... but nowhere to plug them in. |
|
I've access to a few drives, they're all laptop slim drives, though. I'll try to test a few games on them this weekend and see if any pattern emerges from the results... |
|
I want to clarify the main point of the removal. I didn't make it due to maintenance burden (there was basically none) or because no one used it (I knew there'd be a couple). Those are factors of course, but that's not what I focused on. I removed it because it is bad. That's it. Removing bad features because they are bad is always a justified reason for removing a feature. It doesn't need to have a maintenance burden. Plus, the act of removing it opens a road for replacing it with something better. Like all of the discussion happening now on ways to make it better, that wouldn't have happened without the removal. I was my hope that after some initial complaints, someone who cared would come and make a new version that's better. Or it would simply die because no one cared. In either case, Dolphin would be better for it. Reverting outright does not do anyone any favours here.
Though that approach is nice in that it relieves the tiny support burden for the feature, this just means that the few users who still use this feature will keep using the feature in its bad form. This doesn't make anything better, and there will be no reason for the situation to improve. It will just sit there, festering, but now swept under a rug so we don't have to see it anymore. The only thing this route accomplishes is getting the tiny number of users of this feature to leave us alone. We can do that, however, that sets a terrible precedent and frankly, that's not how we should run an emulator. We should be allowed to remove bad things. Obviously as the person who removed it, I think it should stay gone entirely, in the hopes that someone will try to improve it. |
|
Let me try to figure out if we can reach a consensus with the following suggestion: I am fine with this feature being reintroduced if it meets the standards we would expect for a Dolphin feature these days. I think this would minimally be the following:
I'd let @MayImilae decide on what (1) and (2) mean precisely in terms of implementation, if she's interested in contributing there. I don't know off hand how technically complex implementing (3) would be, but I assume we already process I/O requests in a separate thread and it might just be a matter of accounting for the time the emulation code spends blocked waiting for results. @JosJuice @JMC47 @MayImilae thoughts on this proposal? |
|
I'm absolutely ok with a better version being merged. However I do not think that restoring it in its bad form is the correct choice, it should stay gone so a good implementation can actually happen. |
Yes, to be clearer about my previous comment: this would be a necessary set of conditions for me supporting the feature coming back, not something optional. I believe the current implementation does more harm than good in aggregate. |
|
@delroth That sounds reasonable. Personally I can't think of good ideas for what the UX should be like for those three points, but if @MayImilae (or someone else) wants to design the UX for this, I can implement it. @Sam-Belliveau Perhaps we would be able to make use of the profiler idea you're planning for detecting stutter caused by the disc drive?
I agree. I think that the point where we differ is just that I've valued the input of these three users enough to flip the feature into a "not bad" in my mind. Whether that's the right thing to do or not, I'm not 100% convinced of. |
|
Regarding the UX, honestly the best UX I can think of is something super simple - the user presses Open, navigates to their DVD drive with a DVD backup inserted, selects it, and it runs. Simple and clean. I'm not sure if that's possible but if so, that would be fantastic. |
|
I don't think that's possible, since the Open dialog is for selecting a file. |
|
Would calling it Run from DVD+/-R instead of Boot from DVD Backup help clear up the confusion about playing games from retail discs? |
|
If it can work with backups on CD and Bluray discs, I guess "backup disc" should be used instead. I have never used this feature but do multi-disc games work when loaded with this? |
|
If it’s not too intrusive for Dolphin to check your DVD drive, just have it boot the game when a GC/Wii backup is detected.
Another option is to generate a placeholder in your library window when a disc is inserted. Then you can treat it like any other game.
I prefer the second idea since the UI is consistent and serves as a library for what you own even if the game data is not present. I’m sure this will require a lot more work though. |
This sounds like a lot of work to implement. Not to mention that if the user already has Dolphin open and the disc inserted (perhaps they already played the game and now want to play it again), they would have to either restart Dolphin or eject and reinsert the disc. I'm against this one.
I vaguely recall DolphinWX having this as a feature. I guess it never got brought over to DolphinQt. |
Yeah, forget that one. I only brought it up because it seemed like the most straight forward but it can turn into a lot of guessing on how to launch it.
Never heard of DolphinWX but I’ve seen this type of UI for cataloging CD’s ages ago. The nice thing is that it works based on the existing UI. There’s little room for confusion. |
|
I notice today while playing a Wii game from a disc and then going into the Wii Menu that you can boot back into the game using the Disc Channel. Is it possible to make the Wii Menu the only way to boot disc games? It would free up the GUI from having the option in it, no? Maybe have an option to check the disc drive whenever loading the System Menu or opening the Disc Channel? |
|
That does not sound like good UX. Either we would have an option in the GUI to change disc to a DVD-R but not to boot a DVD-R (kind of strange...), or if we do like you say and change disc to the DVD-R when starting the Wii Menu, what if the user happened to have a DVD-R inserted from before but wants to run an ISO this time, or what if the user has two disc drives? |
This reverts commit 37859ec.
This reverts commit dcc10cf. The ability to boot DVD backups is in my experience as a maintainer of DiscIO really not a maintenance burden at all, since it's very compartmentalized. I had assumed that few people would be disappointed about this feature going away, but we ended up receiving three disappointed comments on GitHub not long after the removal was merged, which is quite a lot. Therefore I would like to bring back this feature. I do agree with the argument that nobody who's maintaining Dolphin is testing this feature. But since it seems like there is a vocal minority actually using this feature, I'd say let's keep the feature until it actually breaks or actually becomes a maintenance burden.
JosJuice
force-pushed
the
revert-remove-boot-from-dvd
branch
from
94d6493
to
72cafa5
Compare
Can there be an option to select which disc drive to check or an option to always default to the first detected drive? I feel like this would stimulate an experience closer to how a real Wii appears operate to the user. |
|
If we need a setting, I don't think it's worth the complexity. |
|
Is a yes/no toggle for something like "check first optical drive for disc" too complex? |
|
How do you determine which drive is the "first"? |
|
To be honest, I am not sure. If we are talking about Windows then I guess you can go by drive letter? I remember ePSXe having the option, that is where I got the idea from.
|
|
Closing since it seems like there is consensus around the proposed resolution in #11462 (comment) . If you want the feature back, that comment outlines the way forward, I don't think we're reverting the removal at this point. |
This reverts PR #11456.
The ability to boot DVD backups is in my experience as a maintainer of DiscIO really not a maintenance burden at all, since it's very compartmentalized. I had assumed that few people would be disappointed about this feature going away, but we ended up receiving disappointed comments on GitHub from three different people not long after the removal was merged, which is quite a lot. Therefore I would like to bring back this feature.
I do agree with the argument that nobody who's maintaining Dolphin is testing this feature. But since it seems like there is a vocal minority actually using this feature, I'd say let's keep the feature until it actually breaks or actually becomes a maintenance burden.