Boxer vs ScummVM
Moderator: ScummVM Team
-
Alun Bestor
- Posts: 1
- Joined: Sun Feb 14, 2010 1:52 pm
I'm the creator of Boxer and stumbled across this thread, and I thought I'd pitch in with some thoughts about this.
Firstly, it's important to note that Boxer is (no longer at least) a frontend in the style of DFend, DBGL or ScummVM's builtin game launcher.
The current 0.8x release branch of Boxer is a separate wrapper application around a standard DOSBox binary. This wrapper streamlines the process of installing and launching games, defines custom filetypes to implement "single-file" game packages, and configures the DOSBox emulator based on the current OS environment and the game being launched. Once a DOSBox session has been started, Boxer is out of the picture and DOSBox is responsible for the entire user experience. Between the OS X Finder and DOSBox itself, there is no frontend Boxer UI to speak of. This approach keeps the friction very low, and would certainly be possible with an OS X ScummVM wrapper (given ScummVM's commandline parameters), but it has limited returns.
The 1.0 development branch of Boxer is quite a different beast. It's more like a native OS X fork of DOSBox, which directly integrates the DOSBox emulation core and DOS shell code into a larger OS X application. This level of integration enables Boxer to provide a truly native Mac user experience (menus, HUD panels, automatic self-updating, Terminal-like commandline features, extensive drag-and-drop etc.), and allows it much finer control over the emulation context: permitting realtime graphical adjustment of game settings and rendering and responding seamlessly to changes in the OS environment.
All this simply was not possible without *major* platform-specific rewrites, and wouldn't be possible without them for ScummVM either. In order to achieve its goals, Boxer had to take over or replace most of the SDL framework, which is the cross-platform API layer that both ScummVM and DOSBox rely on for presenting a GUI and talking to the host OS. SDL is neither intended for nor capable of creating a seamless native user experience, and I know of no cross-platform library that is capable of that. In short, there's no substitute for platform-specific code.
This kind of rewrite is no small undertaking - Boxer 1.0 has taken over a year for me as a sole developer, and still no official release - and the resulting code is not directly portable to other platforms. Neither the DOSBox team nor (as they have indicated) the ScummVM team have the resources to do that, especially for a platform with a smaller userbase, so this kind of work naturally has to fall to 3rd-party developers.
I think it would be very beneficial for people to do this with ScummVM for each platform, especially for the Mac (my chosen platform, obviously). But in my opinion, trying to pull off Boxer-style UI improvements in a single project targeted at multiple OS platforms would be a fools' errand, when the tools and the platforms have non-trivial differences in UI paradigms and user expectations.
To generalise: a satisfying interface for a Windows user would feel cluttered and bloated to a Mac user; a satisfying interface for a Mac user would seem trivialising and pompous to a Windows user. There are, after all, reasons why each prefers his or her platform, and the differences behind those reasons should be preserved and respected in the applications themselves.
Firstly, it's important to note that Boxer is (no longer at least) a frontend in the style of DFend, DBGL or ScummVM's builtin game launcher.
The current 0.8x release branch of Boxer is a separate wrapper application around a standard DOSBox binary. This wrapper streamlines the process of installing and launching games, defines custom filetypes to implement "single-file" game packages, and configures the DOSBox emulator based on the current OS environment and the game being launched. Once a DOSBox session has been started, Boxer is out of the picture and DOSBox is responsible for the entire user experience. Between the OS X Finder and DOSBox itself, there is no frontend Boxer UI to speak of. This approach keeps the friction very low, and would certainly be possible with an OS X ScummVM wrapper (given ScummVM's commandline parameters), but it has limited returns.
The 1.0 development branch of Boxer is quite a different beast. It's more like a native OS X fork of DOSBox, which directly integrates the DOSBox emulation core and DOS shell code into a larger OS X application. This level of integration enables Boxer to provide a truly native Mac user experience (menus, HUD panels, automatic self-updating, Terminal-like commandline features, extensive drag-and-drop etc.), and allows it much finer control over the emulation context: permitting realtime graphical adjustment of game settings and rendering and responding seamlessly to changes in the OS environment.
All this simply was not possible without *major* platform-specific rewrites, and wouldn't be possible without them for ScummVM either. In order to achieve its goals, Boxer had to take over or replace most of the SDL framework, which is the cross-platform API layer that both ScummVM and DOSBox rely on for presenting a GUI and talking to the host OS. SDL is neither intended for nor capable of creating a seamless native user experience, and I know of no cross-platform library that is capable of that. In short, there's no substitute for platform-specific code.
This kind of rewrite is no small undertaking - Boxer 1.0 has taken over a year for me as a sole developer, and still no official release - and the resulting code is not directly portable to other platforms. Neither the DOSBox team nor (as they have indicated) the ScummVM team have the resources to do that, especially for a platform with a smaller userbase, so this kind of work naturally has to fall to 3rd-party developers.
I think it would be very beneficial for people to do this with ScummVM for each platform, especially for the Mac (my chosen platform, obviously). But in my opinion, trying to pull off Boxer-style UI improvements in a single project targeted at multiple OS platforms would be a fools' errand, when the tools and the platforms have non-trivial differences in UI paradigms and user expectations.
To generalise: a satisfying interface for a Windows user would feel cluttered and bloated to a Mac user; a satisfying interface for a Mac user would seem trivialising and pompous to a Windows user. There are, after all, reasons why each prefers his or her platform, and the differences behind those reasons should be preserved and respected in the applications themselves.
-
Harrypoppins
- Posts: 124
- Joined: Sat Apr 25, 2009 1:23 pm
While I aknowladge that doing a truly native UI on the same level of Boxer is impossible for a project like ScummVM, I do think there are some concepts that could be easily used. Specifically the concept of game packages, and the process of creating those packages from the user's original media.
Supporting a package type format for game data would allow launching specific games directly from the OS's file manager as well as make organizing and transferring games between systems and devices easier. It also helps differentiate between static, required game data and user data to the average person and reduces the chance for user error when transporting them to new devices.
Because of the cross platform nature of ScummVM, using OS X's built-in "folder looks like a single file" type of packages wouldn't be an option obviously. In place I would suggest using a very basic zip file with a different extension -- something like "Monkey Island 1.scumm". This would allow ScummVM to register a file extension and be able to "open" the game packages, either via a new command line argument or the OS level file association. Another file (i.e. scumm.config) could also be added within these packages to define metadata and game-specific configuration settings for the game (in the same way that Boxer 0.8.x used the game-specific dosbox.conf files). The package would also be easy to open on all platforms, simply rename the extension and open it with your archive manager of choice.
The second concept is the one that is the most problematic with the current system, and that is the process of importing game data from the user's original media. For Scumm this would mean developing a new user friendly utility based on the current scummtools to automate the process of copying the neccesairy files for a game, compressing the audio / video, and bundling it into a packaged format. Ideally this would be as simple as ripping a Music CD: the user puts in their original Full Throttle CD, and the application takes care of the rest and splits out "Full Throttle.scumm"
Supporting a package type format for game data would allow launching specific games directly from the OS's file manager as well as make organizing and transferring games between systems and devices easier. It also helps differentiate between static, required game data and user data to the average person and reduces the chance for user error when transporting them to new devices.
Because of the cross platform nature of ScummVM, using OS X's built-in "folder looks like a single file" type of packages wouldn't be an option obviously. In place I would suggest using a very basic zip file with a different extension -- something like "Monkey Island 1.scumm". This would allow ScummVM to register a file extension and be able to "open" the game packages, either via a new command line argument or the OS level file association. Another file (i.e. scumm.config) could also be added within these packages to define metadata and game-specific configuration settings for the game (in the same way that Boxer 0.8.x used the game-specific dosbox.conf files). The package would also be easy to open on all platforms, simply rename the extension and open it with your archive manager of choice.
The second concept is the one that is the most problematic with the current system, and that is the process of importing game data from the user's original media. For Scumm this would mean developing a new user friendly utility based on the current scummtools to automate the process of copying the neccesairy files for a game, compressing the audio / video, and bundling it into a packaged format. Ideally this would be as simple as ripping a Music CD: the user puts in their original Full Throttle CD, and the application takes care of the rest and splits out "Full Throttle.scumm"