Dosbox DBPs


Wally

I am a banana!
Joined
Jan 31, 2006
Messages
3,213
Age
37
Location
Melbourne, Australia
I will be over time uploading DOS DBPs that may be of interest to people which are marked as freely & legally distributable by their publishers with licensing intact. (Might be able to do some ScummVM stuff as well by the looks of it!)

The reason i'm doing this is:

a) Minimise directory corruption
b) Allow the games to be distributable freely without having other peoples modifications added.
c) Allow people to easily backup savedata from appdata without having to take the whole game.
d) Allow people to add their own custom savedata / level data and whatever to the appdata folder.
e) Compression to allow more games!

Each DBP will be custom mapped to the Pyra Keymap but leaving the keyboard intact for high score entry etc (Can I see a compo4all brewing? :) )

The DOSBox DBP on the repo is required for all this fun to happen as each game talks to that for the magic to happen


So far i've added:
Supaplex & Skyroads.

I won't be adding many games for now as we're still waiting for the Pyra to play them on and the scaling isn't full screen yet
 
Stop making things that I can't try out !!! YOU PACKAGERS !!!111!11!

Maybe this could be a remote issue, but in the past I had to deal with some games that required a specific (older) version of DosBox to run correctly, and this is something that also frontends like DBGL manages, so how this could work with DBP packages ?
Can a single package contain more than one version ? Or there could be different packages ?
 
Stop making things that I can't try out !!! YOU PACKAGERS !!!111!11!

Maybe this could be a remote issue, but in the past I had to deal with some games that required a specific (older) version of DosBox to run correctly, and this is something that also frontends like DBGL manages, so how this could work with DBP packages ?
Can a single package contain more than one version ? Or there could be different packages ?

What game are you talking about? I don't think we can facilitate multiple versions per dosbox package.
 
What game are you talking about? I don't think we can facilitate multiple versions per dosbox package.

I don't remember... too may years have passed... anyway the DosBox compatibility list does have some clues (not so easy to find those few games, because you have to read the detail of every game)

Example (not tested by me) from that list, that show a game that was working in previous version and is broken in the last
http://www.dosbox.com/comp_list.php?showID=3830&letter=A
 
What game are you talking about? I don't think we can facilitate multiple versions per dosbox package.
You could, by defining multiple apps inside each package in the metadata. They'd need to be built in separate folders, and be given different app names if you want them both to be runnable independently, but it should be doable. Might make more sense to have different packages though, one for dosbox_latest and one dosbox_old or something, then people would only need to download dosbox_old if they want it.
 
Thats also the point if theses packages. They have been tested and known to work.
Building dosbox isnt complex. You could build a specific version for given game in like 10mn.
Beside debian do provide it's own version (older than the one on the repo). So there's already 2 versions available.
 
I don't remember... too may years have passed... anyway the DosBox compatibility list does have some clues (not so easy to find those few games, because you have to read the detail of every game)

Example (not tested by me) from that list, that show a game that was working in previous version and is broken in the last
http://www.dosbox.com/comp_list.php?showID=3830&letter=A

These games might be fixed now, just look at the date of the broken reports, I use the latest SVN (yes they're still using flipping subversion) and everything I throw at it works (even Hugo)

For a small handful of games, it's not worth it.
 
These games might be fixed now, just look at the date of the broken reports, I use the latest SVN (yes they're still using flipping subversion) and everything I throw at it works (even Hugo)

For a small handful of games, it's not worth it.

Yeah, maybe in the worst case could be made a single package that contains both the game and the required dosbox version.
 
Yes, but this is the thread for Wally's dosbox+games releases. I assume they've all been open sourced or something equivalent for our needs, though to be fair I've not checked.

You could bundle an old specific version of dosbox with a specific game that demands it, but why not go for the slight extra effort of making a package for the old dosbox and one for the game such that the game depends on the old dosbox. Then, if it turns out anything else runs better under than old version, you can reuse the old dosbox package.
 
From OP : "...which are marked as freely & legally distributable by their publishers...".
Legally, ED is responsible for the content of the repo since he hosts it. Wally would never put ED in trouble for uploading grey area stuff to the repo.

About your concern, sure if someone show there is indeed some use of an old version of dosbox.dbp, it will happen. As I said earlier, dosbox is easy to build (there's only a few configuration to do compared to the doc I put in my toolchain thread like enabling the dynarec from M-HT, (part of dosbox code, just not enabled by default)).
Clearly a "Notaz level" of skills is not required here so it will happen because there will be someone willing to build such easy hanging fruit. (as I said, it's a 10mn job)
Then for the dependency, all that will need is to use a different ID than the one in the lastest version (currently "dosbox"). But something like "dosbox_oldergames" or anything else can do...

EDIT: about grey area stuff on the repo, I'll be harsh. If anything do popup on the repo that could potentially put ED in trouble, it *will* be purged. And the need show up, I'll build a moderator team (doubtful since there's none for the pandora repo, milkshake is not anymore with us, and still everything is clean). I just want thing cristal clear on that side.
 
Yeah, sorry - I didn't mean to cast any aspersions, and I'm sure Wally isn't doing anything wrong. You're right to clear anything that could get ED in trouble.

And yeah, you've shown how easy it is to build Dosbox. But that doesn't mean you should have a copy in every game that doesn't work well with the published version already, as PowerGod was suggesting above. To me it makes more sense to create a dosbox_oldver dbp as you say, even if so far only one game has been identified that needs it.
 
The DOS games are either all going to be distributed as per their license status which should really be freeware or shareware. Abandonware material is a no-no.

The games remain intact as per what they come from their publisher and are just squashed and distributed (Where as some of my personal packages have been completely modified to save space / make the game work properly however I have purchased the game from GOG who make their packages bloaty as all hell.

I don't believe we should be too worried about compatibility as if you look at the results from the compatibility page, they're from 2003 or so and haven't been updated since. DOSbox has matured a lot and I don't believe there will be any major issues. (Hugo's house of horrors works in ScummVM anyway)
 
Maybe also check out Dosbox Enhanced Community Edition. It comes with a lot of extra stuff, I use it for Roland MT32 emulation.
 
Back
Top