tudor wrote:

What do you think?

Never use an outdated DOSBox version.

In fact, if you're working on a frontend, you should tell your users the minimum DOSBox version supported of it, then

tudor wrote:

Then we could associate settings with each release

while writing the config file or even presenting settings available, you'll have to check the current DOSBox version used.

IIGS_User wrote:

tudor wrote:

What do you think?

Never use an outdated DOSBox version.

Correct. The frontend would check for the version of DosBox and upgrade as necessary. That's not my concern, tho. I'm more concerned with making sure that the sound, audio, and processor speed settings are appropriate for the game they are trying to play.

IIGS_User wrote:

In fact, if you're working on a frontend, you should tell your users the minimum DOSBox version supported of it, then

tudor wrote:

Then we could associate settings with each release

while writing the config file or even presenting settings available, you'll have to check the current DOSBox version used.

Understood. I still need some sort of hash to determine the game, tho. Without that I can't do much that would work consistently enough for people not to think it useless.

I suppose it doesn't have to be part of the existing database. I could put up my own games hash database somewhere else. It would be nice to have some way to link it back to the original database, tho. Maybe I can construct a mashup API to fulfill that need for now.

The bad part of this, is that so many games have regional european versions to catalogue. If you're going to work strictly with hashes, you have a long road ahead of you.

Though, I think a better way would be file detection with size approximates. Like to detect Quake, just something like this:

if quake.exe exists
if id1/pak0.pak exists && 16mb+
load quake.prof

Quake.prof would have

gus=false
memsize=32

😀

leileilol wrote:

The bad part of this, is that so many games have regional european versions to catalogue. If you're going to work strictly with hashes, you have a long road ahead of you.

Correct. I've been working on a project related to musicbrainz, which has exactly the same problem. CDs have variations by country. I'm expecting games to have the same problem. While it's difficult and definitely time-consuming, it's not impossible. If you give people an ability to send information back easily, then the database fills quite quickly. e.g. "This disc is not in the database. Please find the name of the game from the list: [Games] or enter the name here: [_____]" which then takes a hash of the disc and uploads it to the database.

leileilol wrote:

Though, I think a better way would be file detection with size approximates. Like to detect Quake, just something like this: […]
Show full quote

Though, I think a better way would be file detection with size approximates. Like to detect Quake, just something like this:

if quake.exe exists
if id1/pak0.pak exists && 16mb+
load quake.prof

Quake.prof would have

gus=false
memsize=32

😀

Um, maybe. That would depend on the ability to mount the image or disc first. If I can generate a hash without mounting an image that would be ideal. It would cover mixed-mode discs and images better, too, IMHO.

Wouldn't it be enough to have sth like d-fend has: a database of games arranged by names so you can choose you game's profile with settings yourself. After all everybody knows what game he is going to play. I think this database would be huge enough to build.

Also links to mobygames will help to determine the game better it there are simmilar names.