rolloLG wrote:

Hori Fighting Stick Mini is natively compatibile with PS3/PS4/PC (seen as a custom XBox 360 controller).
Correct me if I'm wrong but Sony DualShock3 is not supported by Windows at default and requires some hacks (you already use MotionInJoy for example).
I'm not surprised Sony's has issues with DOSBox too. I've read someone suggested to use Steam to launch DOSBox, hence using Steam controller features to remap this kind of console-only controller on PC (Steam itself relies on SDL.dll who's author works for Valve ATM).

I'm thinking it's more of a SDL issue or DOSBox issue.

I wouldn't call using a DualShock3 as a hack. MotionInJoy is a set of drivers for run of the mill bluetooth dongles to make them read Sony's proprietary bluetooth protocol to communicate with PS3 wireless gamepads (which also has the side effect of rendering them useless for regular bluetooth).

Once setup (using using BetterDS3 as the front end for managing the key mappings as MotionInJoy's internal mapping software is terrible and riddled with ads), it works like any other DirectInput device. For emulators and most PC games (except those that prefer Xinput - then x360ce makes it work fine).

I was trying to find any other emulators or software that I have that uses regular SDL, but almost all that I have already moved onto SDL2 so I have nothing to test against for the SDL 1.2.15 that DOSBox ECE uses other than DOSBox.

However, I can confirm that the Y rotation axis does indeed work correctly in SDL2 per this gamepad tester, so it's not an issue with the gamepad communicating with Windows (and the fact that it works in everything else that I've thrown at it):

That image lists the right X and Y axes as 3 and 4, respectively, but DOSBox definitely sees the right "X rotation" axis as 5 so I'm guessing that's just what plain old SDL does.

Delfino Furioso wrote:

I've had an issue with GTA: the game cd-check failed. the ISO+OGG image mounted fine, the game refused to recognize it as its ow […]
Show full quote

I've had an issue with GTA: the game cd-check failed.
the ISO+OGG image mounted fine, the game refused to recognize it as its own cd
it works only if I comment-out every "index" entry in the cue sheet

I've had a similar issue with Destruction Derby in the past wich was resolved (url) with the integration in ECE of the krcroft patch, which was in early stages of development at the time
I've tested DD again with ECE r4267 and the cd check fails here too - though, unlike GTA1, there's no workaround in commenting the PREGAP and/or INDEX entries

krcroft wrote:

When investigating https://sourceforge.net/p/dosbox/bugs/497/ I wound up convincing myself that my minute, second, frame handling code was no longer needed and could use the baseline code plus the update suggested bt RibShark in the bug.
I recall testing my MSF-specific games at the time. I will revisit the testing and if needed re-add MSF control , but possibly with the syntax suggested by RibShark in the bug. Will keep this thread posted as to the progress.

krcroft wrote:

Regarding MSF handling for Destruction Derby, I've asked if this is something the core developers are interested in implementing in the near term:
Re: DOSBox Feature Request Thread

Still no updates on this, right?

thanks!

Delfino Furioso wrote:

krcroft wrote:

Regarding MSF handling for Destruction Derby, I've asked if this is something the core developers are interested in implementing in the near term:
Re: DOSBox Feature Request Thread

Still no updates on this, right?

Correct. I also haven't yet made progress on re-implementing this with RibShark's suggested format.

If there's interest and if anyone wants to try, the prior implementation can likely be applied to the current/latest SVN or ECE sources with a bit of leg work. The relevant change-block starts at line 721 and ends at line 929 in cdrom_image.cpp (right-hand side), and line 248 in cdrom.h (right-hand side)

The right-side pane is the implementation: changed or added lines are green. The left-side represents the prior/SVN code where delete or changed lines are red.

Hello,

I have problem to mount .cue file with last Dosbox-ece version. It worked ok with older version but now I can no more mount .cue file.
I compiled debug version but I obtained no more info.

I need help, it's a very troublesome issue.

Linux is case sensitive. Open the CUE file and check the file names.

Thank you for your answer, as I said it worked with older versions and dosbox is not case sensitive on Linux.
The error message is not "I can not find image or files" but "unable to open".

In dosbox image filenames in cue files are case sensitive in linux.
That is the error you get if the image file is for example rayman.bin but in the cue file you have rayman.BIN

@pantercat: I just verified case, everything is correct.
More info: I can mount .bin files, .iso, but not .cue files.

legluondunet wrote:

@pantercat: I just verified case, everything is correct.
More info: I can mount .bin files, .iso, but not .cue files.

I've implemented an automatic "cue fixer" in Boxtron to work around broken (or simply Windows-only) .cue files provided by game publishers. You can either try it yourself or simply attach a .cue file, a .conf file used for running the game, and output of tree command from game installation dir - that should be enough for me to "unbreak" the .cue file.

legluondunet wrote:

Thank you for your answer, as I said it worked with older versions and dosbox is not case sensitive on Linux.
The error message is not "I can not find image or files" but "unable to open".

Does it work in 0.74-3 ?
And which older versions did it work in (and in which not?)

legluondunet wrote:

Thank you for your answer, as I said it worked with older versions and dosbox is not case sensitive on Linux.

Ah, I missed this. That's not true. DOSBox is (and always was, as far as I can tell) case-insensitive only for files referenced from DOS prompt and programs being emulated. Paths referenced in builtins MOUNT, IMGMOUNT and in .cue files are case-sensitive on Linux and macOS (some windows dir separators are being converted from '\' to '/', but it won't make the path case-insensitive). That's why Boxtron converts all these paths to Linux-only versions (but, arguably, this conversion might fail in some specific edge-cases, but it's extremely unlikely in case of DOS games).

edit:
@legluondunet: if you have a situation, where .cue file does not work in ECE, but worked in DOSBox <= 0.74-3, then it's almost for sure case of broken INDEX values in .cue file; older parser, before krcroft's patch, was less strict about handling .cue files and accepted broken values for these fields. INDEX fields in .cue files have only 2 valid values: 0 and 1 (leading 0s are ok, too).

There is the directory separator conversion and the ability to use DOS paths.
Ideally though, people should use the the right file case for the files..

Maybe more workaround could be added, but I am not really sure which direction of workarounds I want to head to, as it are workarounds for a problem that should be ideally fixed at the publishers end.

I verified case possibility, I verified / and \...even if I didn't need to verify because it worked with older version.

"@legluondunet: if you have a situation, where .cue file does not work in ECE, but worked in DOSBox <= 0.74-3, then it's almost for sure case of broken INDEX values in .cue file; older parser, before krcroft's patch, was less strict about handling .cue files and accepted broken values for these fields. INDEX fields in .cue files have only 2 valid values: 0 and 1 (leading 0s are ok, too)."

this is one cue file example, rayman.cue:

FILE "rayman.bin" BINARY
TRACK 01 MODE1/2352
INDEX 01 00:00:00
TRACK 02 AUDIO
PREGAP 00:02:00
INDEX 01 10:17:40
TRACK 03 AUDIO
INDEX 00 12:45:40
INDEX 01 12:47:39
TRACK 04 AUDIO
INDEX 00 15:12:48
INDEX 01 15:14:47
TRACK 05 AUDIO
INDEX 00 18:14:21
INDEX 01 18:16:20
TRACK 06 AUDIO
INDEX 00 20:46:31
INDEX 01 20:48:30
TRACK 07 AUDIO
INDEX 00 23:15:55
INDEX 01 23:17:54
TRACK 08 AUDIO
INDEX 00 25:46:14
INDEX 01 25:48:13
TRACK 09 AUDIO
INDEX 00 30:29:32
INDEX 01 30:31:31
TRACK 10 AUDIO
INDEX 00 31:52:17
INDEX 01 31:54:16
TRACK 11 AUDIO
INDEX 00 32:27:41
INDEX 01 32:29:40
TRACK 12 AUDIO
INDEX 00 36:04:44
INDEX 01 36:06:43
TRACK 13 AUDIO
INDEX 00 36:15:27
INDEX 01 36:17:26
TRACK 14 AUDIO
INDEX 00 40:34:49
INDEX 01 40:36:48
TRACK 15 AUDIO
INDEX 00 45:29:22
INDEX 01 45:31:21
TRACK 16 AUDIO
INDEX 00 46:40:53
INDEX 01 46:42:52
TRACK 17 AUDIO
INDEX 00 50:08:27
INDEX 01 50:10:26
TRACK 18 AUDIO
INDEX 00 55:24:62
INDEX 01 55:26:61
TRACK 19 AUDIO
INDEX 00 56:33:51
INDEX 01 56:35:50
TRACK 20 AUDIO
INDEX 00 57:33:49
INDEX 01 57:35:48
TRACK 21 AUDIO
INDEX 00 59:36:20
INDEX 01 59:38:19
TRACK 22 AUDIO
INDEX 00 61:38:65
INDEX 01 61:40:64
TRACK 23 AUDIO
INDEX 00 63:41:39
INDEX 01 63:43:38
TRACK 24 AUDIO
INDEX 00 63:57:60
INDEX 01 63:59:59
TRACK 25 AUDIO
INDEX 00 64:14:01
INDEX 01 64:16:00

and my DOSBox conf file:

[autoexec]
mount c "."
imgmount d "rayman.cue" -t iso
d:
call d:\install.bat

As I said before, I can mount iso, bin, only cue files are no more recognized by Dosbox-ECE.

I will try to reproduce this issue with Dosbox vanilla.

I think I found the cause of my issue with help of someone of this forum, there should be a problem with my conf file. I will test more before to explain you.

There are some issues with CD Audio and DOSBox ECE that I have tested and verified.

I've been playing Betrayal At Krondor (the GOG release). If you replace the DOSBox version inside the game's DOSBox folder (which is 0.74) with DOSBox ECE the CD audio will not play. Note: You can select the CD Audio option in the games "Preferences" selection in the main menu. Replacing the DOSBox version inside the game's DOSBox folder with DOSBox SVN the CD Audio still plays properly.

The last working version of DOSBox ECE under this situation is DOSBox ECE r4168. That is, if you replace the DOSBox version inside the game's DOSBox folder with DOSBox ECE r4168 the CD audio plays properly. DOSBox ECE r4170 up until current DOSBox ECE r4288 the CD Audio will not play.

I think that the same applies here:

dreamer_ wrote:

@legluondunet: if you have a situation, where .cue file does not work in ECE, but worked in DOSBox <= 0.74-3, then it's almost for sure case of broken INDEX values in .cue file; older parser, before krcroft's patch, was less strict about handling .cue files and accepted broken values for these fields. INDEX fields in .cue files have only 2 valid values: 0 and 1 (leading 0s are ok, too).

First, I want to say you all thank you for your numerous and very pertinent answers.
I think I found the reason CD cue did not mount anymore with Dosbox ECE on my computer:
in all my Dosbox config files, I have set midi like this:

1[midi]
2mpu401=intelligent
3mididevice=default
4midiconfig=

Until recently this config, I didn't even remenber where I found this settings, it just worked.
But now this midi settings avoid my cue files to mount...don't ask me why as I don't see the link between midi and mount cdrom...
A member of this forum sent me his config file for Rayman and all worked as expected on my computer.
The only difference was the midi settings:

1[midi]
2mididevice=none

All others DOS cue games that didn't launch anymore with Dosbox ECE work now I changed the midi settings mididevice to "none"...

legluondunet, happy to hear that knocking out MIDI solves this!

Unfortunately I suspect there something else at play, likely specific to your environment.

This is the first report that ECE requires mass-disabling of midi in order to mount CDROM images (if this issue was specific to ECE or SVN, we would have seen a flood of reports).
Second, I've re-added midi to my config and the game continues to play, and we're both running the same binary and Ubuntu 19.04.

In the meantime, you're up and running! Interested to hear more though, especially if you can get to the bottom of it.