VOGONS


DOSBox ECE (for Windows & Linux)

Topic actions

Reply 461 of 1116, by Dracolich

User metadata
Rank Newbie
Rank
Newbie

After some more testing with vanilla DOSBox r4168 I figured out that it does happen but only after running my AUTOEXEC.BAT. Then I narrowed it down to DOSLFN.COM. So, this is not specific to ECE, but somehow r4168 is not playing well with DOSLFN.

Reply 462 of 1116, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author

DOSLFN has never really worked with DOSBox's emulation of DOS -- internal DOS structures are not sufficiently emulated. However, r4168 adds enough emulation of the DPB that DOSLFN is actually trying to work now; whereas before it decided the drive is an unsupported type and did nothing. The moral of the story: don't use DOSLFN unless booting real DOS. There are unofficial builds of DOSBox that feature LFN, but those aren't supported here.

Reply 464 of 1116, by NewYears1978

User metadata
Rank Newbie
Rank
Newbie

Can someone tell me how to use Reshade with ECE? I installed it as usual with OpenGL but it doesn't launch - unsure if you have to do anything special to make it work and cannot find any info.

Reply 465 of 1116, by Yesterplay80

User metadata
Rank Member
Rank
Member

That's not really a ECE related question, but DOSBox wise you only have to make sure that you have set output=opengl or output=openglnb in your .conf file for DOSBox.

My full-featured DOSBox SVN builds (without debugger) for Windows: Vanilla DOSBox and DOSBox ECE (Enhanced Community Edition)

Reply 466 of 1116, by NewYears1978

User metadata
Rank Newbie
Rank
Newbie
Yesterplay80 wrote:

That's not really a ECE related question, but DOSBox wise you only have to make sure that you have set output=opengl or output=openglnb in your .conf file for DOSBox.

Sorry I could not find anything anywhere on the net so asking here was my last resort. I assumed openGL was how it ran automatically. Since I am using premade configs will have to look into it.

Thanks for your reply - much appreciated.

Reply 470 of 1116, by Yesterplay80

User metadata
Rank Member
Rank
Member

What's the use of ISO/WAV/CUE images anyway? Why not just use BIN/CUE?

My full-featured DOSBox SVN builds (without debugger) for Windows: Vanilla DOSBox and DOSBox ECE (Enhanced Community Edition)

Reply 472 of 1116, by AlexRK

User metadata
Rank Newbie
Rank
Newbie
Yesterplay80 wrote:

What's the use of ISO/WAV/CUE images anyway? Why not just use BIN/CUE?

I would like to be able to hot swap the music in the Heroes of Might & Magic II game (I have images of the original Succession Wars game and the addon Price of Loyalty). This can be done, switching of the CDs works with Ctrl+F4. Unfortunately, with BIN/CUE format the music tracks are not played from the beginning after hot swapping of the CD (I suppose DOSBox caches information about the locations of the tracks after start of the game). It is the main reason of my question.

And ISO/WAV/CUE format is more convenient for me personally because I rip music tracks (from mixed mode CDs) separately with Exact Audio Copy. But it is minor reason.

Thank you for your reply.

Reply 473 of 1116, by VGA

User metadata
Rank Newbie
Rank
Newbie

I have memsize set to 64 and I get a message in the console about it being out of the accepted range of 1-63 and using the closest accepted number which is 63. Huh? Why can't I set the available memory to 64mb? The site of ECE says "Supports up to 384 MB of memory, required for running Windows 9x on top of DOSBox ECE"

And a second question, I think I have stuff in my conf files which are obsolete or depend on patches that ECE may not have, for example the [vsync] section ... does it do anything? Is there a reference conf file for the ECE build so I am not confused?

Reply 474 of 1116, by krcroft

User metadata
Rank Oldbie
Rank
Oldbie
AlexRK wrote:

Unfortunately, with BIN/CUE format the music tracks are not played from the beginning after hot swapping of the CD (I suppose DOSBox caches information about the locations of the tracks after start of the game). It is the main reason of my question.

The MSCDEX interface plays red book audio tracks using an absolute CDROM sector position (measured from start of the CDROM) and a duration, measured in in number of sectors.

Some games only query the CDROM's table of contents once to get each track's absolute sector positions, and they use those track sector positions for all subsequent playback events (regardless if DOSBox cached them or not). These games as-programmed won't query the TOC again. This is the majority of games.

Some games are pre-programmed with their CDROM's track positions (or hardcoded), and some even go a step further and compare their expected positions to those queried from the current CDROM - as a form of copy protection (Destruction Derby).

Other games, like Jazz Jackrabbit, perform many checks after every playback event: asking MSCDEX where the current read position is at, asking MSCDEX if the CDROM had been changed/cycled, and, regardless if the tray was cycled or not, requerying the CDROM's TOC (which DOSBox does cache for BIN/CUE and ISO/AUDIO-FILE/CUE).

DOSBox currently doesn't have a "cycle CDROM" function that would mimic a hardware tray cycle for the same CDROM drive letter, and thus flush and regenerate the active TOC. If it did, you could hot-swap audio files of different length or change the CUE and, assuming your game behaves like Jazz Jackrabbit, achieve correct playback of tracks after the swap.

If however the game is like the first two types that don't requery the TOC, then your only option is to hot swap a BIN of identical track layout (but with different audio content) to ensure tracks still play from their starting positions.

Last edited by krcroft on 2018-11-05, 18:15. Edited 1 time in total.

Reply 475 of 1116, by krcroft

User metadata
Rank Oldbie
Rank
Oldbie
awgamer wrote:

Were some game cds were produced with wavs?

Essentially yes; games eventually started storing large volumes of PCM music, effects, and speech in files instead of being limited to CD Red Book audio tracks. This allowed them to store more content at lower bit depths, lower frequencies, and single-channel. It allowed for "fat installs" to HDD where seek latency is orders of magnitude better than CDROM. It also let them play and mix multiple audio tracks simultaneously (ie: music + speech), where as previously they might be held as separate Red Book tracks.

Reply 476 of 1116, by AlexRK

User metadata
Rank Newbie
Rank
Newbie
krcroft wrote:

If however the game is like the first two types that don't requery the TOC, then your only option is to hot swap a BIN of identical track layout (but with different audio content) to ensure tracks still play from their starting positions.

Thank you very much for the detailed answer. I checked HoMM 2 behavior with separate OGG tracks (from GOG distributive) and it looks like the game query the table of contents only once.

Reply 477 of 1116, by exofreeze

User metadata
Rank Member
Rank
Member

Maybe someone can help me with this.

I've got Tomb Raider setup with a file that allows me to choose between the regular version, unfinished business, the regular version w/ 3dfx, and unfinished business w/ 3dfx.

When running through ECE, all versions work except the base Tomb Raider 3DFX (Unfinished Business 3DFX works fine). If I run Tomb Raider 3DFX, the game starts (eidos/core logos), 3dfx splash screen, then main menu. When I choose laura's house or the game, the screen goes to black and dosbox closes.

What's odd, is if I run the exact same files with DAUM, the game works. It just stutters like crazy. So it has to be somewithing with the way ECE and my files are getting along.

I've imaged my disc and mounted the cue/bin pair. Installed it directly from there, etc...

edit: as I was typing this, I changed my output from direct3d to opengl, and then suddenly the game worked. I hadn't thought to try this since the expansion pack worked fine under direct3d. It seems overlay and surface work as well.

Is that something specific to this game? I haven't had that issue with other 3dfx games.

Reply 478 of 1116, by AlexRK

User metadata
Rank Newbie
Rank
Newbie

Hello Yesterplay80, I'm sorry to bother you again. I searched for a bit and found this small patch: FLAC playback in DOSBox. It looks like this patch brings support for separate sound files (not just OGG) to the DOSBox. If I understand correctly, in the current implementation, the problem of playing separate audio tracks is the incorrect operation of the "Sound_Seek" SDL function (which this patch replaces with the "Sound_GetDuration" function). Tell me please what do you think about including this patch in the DOSBox ECE? Thanks.

P.S. I know that support ot the ISO/wav_mp3_etc/CUE format is implemented in DOSBox-X, but I vastly prefer the ECE because of its non-redundancy and absence of bells and whistles. 😀

Reply 479 of 1116, by krcroft

User metadata
Rank Oldbie
Rank
Oldbie
AlexRK wrote:

Hello Yesterplay80, I'm sorry to bother you again. I searched for a bit and found this small patch: FLAC playback in DOSBox. It looks like this patch brings support for separate sound files (not just OGG) to the DOSBox. If I understand correctly, in the current implementation, the problem of playing separate audio tracks is the incorrect operation of the "Sound_Seek" SDL function (which this patch replaces with the "Sound_GetDuration" function). Tell me please what do you think about including this patch in the DOSBox ECE? Thanks.

P.S. I know that support ot the ISO/wav_mp3_etc/CUE format is implemented in DOSBox-X, but I vastly prefer the ECE because of its non-redundancy and absence of bells and whistles. 😀

Unfortunately SDL_Sound's FLAC and MP3 backends have their own issues beyond the seek and get duration calls. (see here for a similar FLAC attempt that Yesterplay80 added back in 2016 but had be backed out of the ECE build due to issues: FLAC support)

Here's a working and up-to-date patch if you're interested in FLAC support: AUDIO Patch supporting FLAC, Opus, and MP3 audio tracks

You also mentioned keeping dosbox simple and elegant, which this patch does by eliminating the need for libFLAC, libMp321, libVorbis, and libVorbisFile, resulting in a much smaller statically linked DOSBox binary.

(Yesterplay80: the above includes exact MSF handling mentioned in DOSBox ECE (for Windows & Linux), which I also developed, so you can drop/reverse that patch before applying the FLAC-Opus-Mp3 support patch)