Release Package dosBox Games as pnds


thatgui

Advanced Member
Joined
Apr 2, 2009
Messages
3,048
First things First: it's all milkshakes fault!


Several weeks ago he brought up the thought about making some kind of ginge like wrapper out of qemu. Not having the ability to take on such a complicated task a simpler idea came to my mind:


Why not stuff dosbox a single game and and a tailored dosbox config file together in one package and wrap it all up in pnd magic. But as a lot of the good old games are still under copyright, such pnds can't be shared. So my mind generated the need for non devs to have a "comfortable" way to create such "packages" - and tada:


The dosBox Game packager (haven't thought of any Name yet, suggestions are welcome)

pndcreator.png


Realizing that my orginal project won't be ready in time four days ago, I slapped this together in about 10-12 hours (not continuously) - so don't expect too much, this is an early beta (but will be improved - promised).


As always in life "there's two sides to every Schwartz":


  • currently only a basic pxml file is created, so things like author information, version, descriptions, etc. aren't there
  • a dosbox config file as to be provided - I'm planing to implement an editor for it, which is already trimmed down specifically for the pandora
  • the binary files for dosbox have to be provided also, the idea for the next version is, that the user just gives the filepath of the dosbox pnd he wants to use - could be difficult as I currently don't know if the set of dosbox files is identical in every dosbox build for the pandora thats floating around
  • I wanted to have everything self contained, so the games files are packaged within the pnd. But this means there's a risk of data loss when the pnd crashes or gets killed. I'm currently having a "save game feature" that just copies files with a specfied extension from the appdata directory to the pnds temporary mount directory before the game starts and vice versa after the game is closed. Currently I'm thinking about letting the user choose wether he wan'ts everything in one package, or just want's to define a directory on the SD Card that gets mounted.


some other things I thought about to implement:

  • setting the nubs to a certain mode before the game is run and setting it back after the game exits
  • using a (per game of course) mapper file to redefine the keys so that pandoras controls (action buttons, start, select, shoulder buttons) can be used in the game. If anyone has any information on how to do that, please turn my nose in the right direction.


Maybe someone has use for this
 
Last edited by a moderator:
This is excatly like the same idea of Mateo Godlikes' PS3 pkg dosbox mods lol :) i love it! Exellent idea! Thanks man!! :D
 
I really like the idea too :)


Especially if people could provide premade config files, so we'd only have to get the games files to inject into the final PND.
 
Last edited by a moderator:
I love this idea :)


I'm wondering if we can achieve the same thing with wine through Qemu
 
Last edited by a moderator:
I didn't think this was a good idea when people started doing this with Ginge and I don't think it is a good idea now either.


How will you tackle updating dosbox itself? Update each and every game packaged with it? Doesn't sound like much fun to me.
 
I didn't think this was a good idea when people started doing this with Ginge and I don't think it is a good idea now either.


How will you tackle updating dosbox itself? Update each and every game packaged with it? Doesn't sound like much fun to me.
Fair point, there are some possibilities to counteract this:

  • rewrite it, so the dosbox binary isn't included, and instead is called from the run scripts. not very favourable as externel depencies would counteract the purpose
  • automatically download the latest dosbox pnd from the repo before "building" the pnd, of course rebuilding every created pnd would still be necessary


But I do not think we're talking about a lot of games here - or do we ? even then, if you save the configurations, and keep the game files in the same place (like an external drive) this should not be too cumbersome. It would take me maybe an hour to extend the programm with an automatism to deal with that (something like rework every configuration file in directory x by using the dosbox build from directory y).


In the end its all about convenience (which always has its tradeoffs):


I played world of xeen before my Pandora got the ptod. And it was just nice, no starting the dosbox launcher, then choosing the right entry for it - just navigating to the minimenu entry. This gets even better when the game needs some system adjustments made beforehand (like setting the cpu clock higher, oder setting the nubs in a certain mode (not implented yet)).


dosBox builds aren't happening on a daily basis, so the updating each package should not be necessary very often. And there is the question if it is necessary at all to do this, if the game already runs fine with stock speed, there is no need to update.


@bagmouse7


Thanks for the list, didn't know of it till now.


Edit: submitted via eMail 20 min ago, hope I was not to late
 
Last edited by a moderator:
@Caine - A good point, but there are a few factors that still make this useful. History so far has shown us that there is a long gap between DOSBox updates. Just recently there was a major one; I'm betting it'll be a while before the next one. Also, I think most people would use this for just a handful of 'important' games, as opposed to their entire DOS collection, so upkeep wouldn't be too cumbersome. The user would have to keep this in mind of course; probably not wise to create dozens of PNDs unless you're willing to do a mass update later.


If an auto-update feature was included in the future, perhaps it could check for existing DOSBOx-wrapped PNDs and ask if you want to update those too.
 
Personally, I was thinking more about launching Dosbox externally. In a certain way, what this would do is leverage the PND system and Minimenu / XFCE menu to create an easy to use launcher for games. Such a solution would not be exclusive to Dosbox, but would function for all emulators.


Let's call our program which creates the game packages the Universal Launcher (UL). This easiest way is to have the UL handle the actual launching such that the created PNDs have as little logic inside them as possible (this will make updating a lot easier).


The launcher would perform the following tasks: (sequence chart in spoiler below)

  • Create launcher profiles. A launcher profile would associate a launcher script for a particular application with the path of the PND to that application and assign it a unique ID. Suppose we have two versions of Dosbox (Dosbox and Dosbox EX) each with their own PND. The UL would provide a dosbox script ("Dosbox.sh") which knows how to mount the PND, setup the application/game and launch it (typically the shell script would take two params, the path of the launcher PND (Dosbox.pnd in our example) and the path of an application (e.g. stunts.pnd).
  • Package a game, application or ROM into a launchable PND. Here you would associate the unique ID created in the previous step with the application. This generated PND will bundle the code and application data of the application along with a PXML file and a very simple starter script. The started script, when invoked, will start the UL and pass it the path to the apps PND along with the included unique ID and will do nothing more. The path to the UL could be either coded into the PND or registered on the NAND in a small configuration file in the users home directory(typically written only once, unless the UL path changes which should be really infrequent).
  • Launch a game. When a PND generated in the previous step is started, the UL will be passed the unique ID and path to the PND. At this point the UL is smart enough to know which steps to take and will mount the proper PNDs either internally or through invocation of a simple shell script (the latter have the advantage that emulator authors can provide their own scripts). Because the unique ID is associated with a profile, any special settings and/or the specific dosbox/emulator instance can be changed without having to modify any of the generated PNDs.


This should be fairly simple to setup and would make it trivial to update both the Universal Launcher as well as the emulators associated with it. It also avoids storing redundant copies of Dosbox or whatever emulator you apply this to. The biggest downside is that it does indeed break the no-dependency rule, but this is not without precedent. Java apps do the same.


A solution like this would allow any ROM, virtualized game or application and even documents to be added to the XFCE menu, minimenu and/or whatever launchers we will see in the future.


[edit]Sequence chart:

n9d3c.png

[/edit]


[edit2]@thatgui


Don't forget to allow the user to set the categories of the created PND.


[/edit]
 
Last edited by a moderator:
@Caine:


What is the point in updating a dosbox instance used only for one game, if the game actually works well with that version ?


I can have 10 pnds with 10 different version of dosbox, but I will update ONLY the version for games that maybe can run better with a newer one...


I think the only downside in thatgui's implementation is the space used...
 
Last edited by a moderator:
For updating, you can just put the newer dosboxexecutable into appdata. No big deal really.
 
@Caine


really thought through idea, but realization is beyond my abilities


I wonder if it would be legal to wrap some games that where released as freeware (like alien carnage from apogee) in pnds, and put it up on the repo.
 
@Caine


really thought through idea, but realization is beyond my abilities
No problem. I'm just thinking out loud here. I will add it to my someday/maybe projects list, don't expect it anytime soon.

I wonder if it would be legal to wrap some games that where released as freeware (like alien carnage from apogee) in pnds, and put it up on the repo.
In most cases, no. Freeware typically does not imply that you are granted the right to redistribute the content.


By the way, will there be a Linux port of your software?
 
In most cases, no. Freeware typically does not imply that you are granted the right to redistribute the content.
True, but even on the wikipedia page there is a link to dosbox bundled version - maybe they asked for permission.

By the way, will there be a Linux port of your software?
Can't tell right now, but I think it looks good. I have to make a test build with Monodevelop on a Linux machine to say for sure, but chances are high that a linux build (no porting necessary) will be possible. The Library I'm using to build the squash image is usable with mono under linux, and mono has Windows Forms support, so in theory it should be just a matter of clicks.


Edit: Tested it with a Live ubuntu 12.04, seemed promising at the start, but got a crash (without any exception message!) during the creation of the pnd - so some investigations seem necessary
 
Last edited by a moderator:
^ You should upload that to ED's FTP too so everyone gets it (if you haven't already).


Anyway, looking quite good. I'm just going to throw suggestions out willy nilly; some are a little important but others you can ignore if you don't like them!

  • Have the appdata path field autocomplete as you type the PND name
  • Have a default DOS icon that is used where people don't provide one.
  • Image conversion (imagemagick backend?) to ensure user selected icon is formatted properly
  • Games executable dropdown should show filenames only (no path). I am unable to see which executables I am selecting due to long paths.
  • Games executable dropdown should auto-refresh if you choose a new File Path
  • Can you provide a default dosbox.conf? Inconvenient having to go and acquire one.
  • Remember file paths in all file selection dialogues. Starting from Desktop each time is a bit annoying.


I can definitely see myself getting some use out of this. :)
 
^ You should upload that to ED's FTP too so everyone gets it (if you haven't already).
I wanted to wait for a little more user feedback of the new version, as I can't fully test the pnds it creates anymore (ptod)

Have the appdata path field autocomplete as you type the PND name
appdata path field is filled with the title fields content when the title field looses it focus, but only if the appdata path field is empty.

  • Have a default DOS icon that is used where people don't provide one.
  • Games executable dropdown should show filenames only (no path). I am unable to see which executables I am selecting due to long paths.
  • Games executable dropdown should auto-refresh if you choose a new File Path
  • Can you provide a default dosbox.conf? Inconvenient having to go and acquire one.
  • Remember file paths in all file selection dialogues. Starting from Desktop each time is a bit annoying.
should all be done with the attached Version 0.3

Image conversion (imagemagick backend?) to ensure user selected icon is formatted properly
could you elaborate on this, please ?


thanks for the feedback !

dosboxgamepndcreator_0.3.zip
 

Attachments

  • dosboxgamepndcreator_0.3.zip
    2.6 MB · Views: 177
Last edited by a moderator:
Good stuff, will try out the update soon.


Regarding icon processing, I just thought it might be cool if people without graphics skills could dump any old image in there, and the program would crop/shrink to size and convert to PNG. ImageMagick is commonly used for this task; it's often incorporated into website back ends for avatar processing etc.


Might be too much work for relatively small benefit though, dunno.
 
Back
Top