Boxer vs ScummVM

[rented mule]

While I really much love the ScummVM project and how far it's progressed, there's something I very much hate about it: the interface.

ScummVM's engines are top notch and, honestly, I think that's the most important. But I do believe that now that support for many of the most popular 80s and early 90s games exist, some front-end love is in order. I'm presenting this as constructive criticism and not some insult to ScummVM, the ScummVM team or its fans.

I know that the most common reply in this thread will be something to the tune of "ScummVM is opensource...if you want to see something happen, do it yourself." I understand this there seems to be a tight leash around what is not strictly engine code. And while I would love to contribute to the interface front-end, it would require a departure from the "one-interface for all platform" ideology and embrace platform specific APIs. Unfortunately, I'm not convinced the ScummVM team is ready to do this.

Boxer seems to be the shining example of what could be done to improve ScummVM on the Mac. For people that don't know, Boxer is a DOSBox front-end for the Mac. The latest 1.0 alpha already shows that it is a first-class Mac app by having proper menus, a proper preferences window, package support (a way to encapsulate a bunch of related files into a single file) allowing the user to launch the game from the Finder or Spotlight, allows the emulation window to be resized to arbitrary sizes (something I've been hoping that ScummVM would get for a long, long time).

Of course, DOSBox will never be capable of fixing the bugs that existed in the original interpreters, games with dithered graphics have little chance of looking better unless the DOSBox team adds such an option, alternate platform versions will never work in DOSBox. So ScummVM has the advantage in that area having control over more aspects of the interpretation than DOSBox which is simply a single-platform emulator.

I fully expect some people to reject the idea. That's fine. I'm just putting these ideas out there every couple years in hopes that one day ScummVM becomes a first-class citizen on many platforms. I also realize that the amount of work involved to maintain different front-end interfaces would skyrocket. But the current front-end interface could always be the fallback on the less popular platforms.

[ezekiel000]

I would have to disagree I like the ScummVM gui it is clearly laid out and easy to use on any platform. That said I don't actually see it often as I created shortcut's to open each of my games fullscreen using scummvm.

[lazylazyjoe]

I never see the modern interface. Whenever I add a new svn copy it works great, but as soon as I do a mass add, I can only see the "classic" interface; which is still very easy to use. Never figured out why, but never really cared as it's just the frontend and I couldn't care less. I just want to play the games. It could be command line only for all I care.
Also, for anyone who uses both dosbox and scummvm, dfend reloaded will act as a frontend for both nicely. And it allows compressed storage of data files. (though I know that is frowned upon for scummvm)

[sev]

There are simply no resources in the team to do that. I, being the release manager, struggle even with the port builders, i.e. those folks who need to launch GCC on their respective platform and upload the binary.

Current trend which we are propagate is exactly the opposite: reuse the code as much as possible, leave platform-specific code to minimum. With this in mind we now have the buildbot, and check dozen of the ports for build-ness, thus mitigating the risk of platform getting lost in the release.

Thus, although the idea is not bad, it is simply unrealistic.


Eugene

[MeddlingMonk]

package support (a way to encapsulate a bunch of related files into a single file) allowing the user to launch the game from the Finder or Spotlight

Well, not exactly. A Mac application bundle isn't a file. It's a disguised folder, the top-level folder for a program with the actual binary and related files in subfolders within. Boxer takes advantage of this trickery but in reality the app bundle for Safari (as an example) is no more a single file than is the obvious top-level folder for Internet Explorer in Windows.

Of course, if someone could give ScummVM the Boxer-like ability to make folders of non-OSX programs look and act like app bundles, that'd be very nice but I suspect something that OS-specific would be very hard to implement in a cross-platform project.

[rented mule]

package support (a way to encapsulate a bunch of related files into a single file) allowing the user to launch the game from the Finder or Spotlight

Well, not exactly. A Mac application bundle isn't a file. It's a disguised folder, the top-level folder for a program with the actual binary and related files in subfolders within. Boxer takes advantage of this trickery but in reality the app bundle for Safari (as an example) is no more a single file than is the obvious top-level folder for Internet Explorer in Windows.

Of course, if someone could give ScummVM the Boxer-like ability to make folders of non-OSX programs look and act like app bundles, that'd be very nice but I suspect something that OS-specific would be very hard to implement in a cross-platform project.

Right, but this is just semantics. The app itself isn't composed of just the binary, it's composed of localization files, resources, etc. On OS X, every Carbon and Cocoa app is, as you say, a disguised folder but that's only because that's how the file system works. The notion of app or bundled file still remains. Apple's iWork creates document bundles, but people call them document files because they act as single files unless you use the "Show Package Content" option to reveal how the file system really stores all the related files.

It's not really trickery, it's simply the way Apple decided it would work.

[rented mule]

There are simply no resources in the team to do that. I, being the release manager, struggle even with the port builders, i.e. those folks who need to launch GCC on their respective platform and upload the binary.

Current trend which we are propagate is exactly the opposite: reuse the code as much as possible, leave platform-specific code to minimum. With this in mind we now have the buildbot, and check dozen of the ports for build-ness, thus mitigating the risk of platform getting lost in the release.

Thus, although the idea is not bad, it is simply unrealistic.

I understand. I wish it wasn't so, but I understand.

[KuroShiro]

I don't think there's anything strictly wrong with the current GUI, it just still needs to evolve and add more features.

Personally I would love to see some filtering options for the main menu (by company, platform, etc.) I'm sure it will keep getting better as development continues.

[marticus]

Since scummvm can start games from the command line, I don't see how it would be a problem if someone built an external frontend for limited platforms as a separate project.
That's what boxer is after all.

[Collector]

The only thing that I would like to see added to the GUI is the ability to generate Shortcuts/Aliases for the games. Easy enough to do manually, but would a great time saver when you have a number of games to do. Don't know how complicated it would be to implement with portability in mind, though.

[simplesimon]

A great solution for this would be to offer a DOS build of ScummVM. Seems like it shouldn't be too hard to do considering there is a build for most every other platform already. I'm suprised that there isn't one already. But then you could load up ScummVM in DOSBox using Boxer (or DOSBox Game Launcer for Windows) as a frontend. You would get the combined benefits of both programs that way.

[Collector]

A great solution for this would be to offer a DOS build of ScummVM. Seems like it shouldn't be too hard to do considering there is a build for most every other platform already. I'm suprised that there isn't one already. But then you could load up ScummVM in DOSBox using Boxer (or DOSBox Game Launcer for Windows) as a frontend. You would get the combined benefits of both programs that way.

Then you loose one of the main benefits of ScummVM over DOSBox. Since ScummVM a replacement interpreter instead of an full blown emulator, it has a much lower overhead, allowing it to run on lesser platforms, like many hand held devices. If you are going to use DOSBox, you might as well just run the DOS version directly in DOSBox.

There is a frontend for old games using both DOSBox and ScummVM. There was a post on VOGONS about it. I have not tried it, myself.

[fingolfin]

Not only that, but you'd also slow ScummVM down to a crawl, being emulated by DOSBox. Not to mention that DOS programs kind of have troubles using megabytes of RAM, which means a DOS port of ScummVM would be quite challenging (though not impossible). But who would want to hobble their legs on purpose by using DOS these days? That proposal just makes no sense

[maximus]

Not only that, but you'd also slow ScummVM down to a crawl, being emulated by DOSBox. Not to mention that DOS programs kind of have troubles using megabytes of RAM, which means a DOS port of ScummVM would be quite challenging (though not impossible). But who would want to hobble their legs on purpose by using DOS these days? That proposal just makes no sense

Maybe I'm missing the point here, but if you've got a DOS version of ScummVM to run games that were (in most part) written FOR DOS ... wouldn't you just run them natively instead of using ScummVM at all if your environment still happens to be DOS

[simplesimon]

In most cases ScummVM plays the games better than the original executables did, fixing bugs, dithering and such, so that would be the benefit of using ScummVM. But Dosbox as an environment to run games is superior because you can adjust screen resolutions to anything, setup gamepad and such, so by filtering the game files through both programs you get the combined benefits of both.

But that's really just a second best option until, or if ever, ScummVM adapts Dosbox's said attributes for itself.