DOS ain't dead

Now use only last DJGPP port of FFMPEG 5.1.2 as video decoder!
it support most codecs including webm animated GIF ...

The screenshot is under DOSBOX-Staging the only DOSBOX able to run MMX mostly smoothly without crashing.



download DUGL Player 1.0 Alpha1

2 march 2026: 1.0 Alpha2
- Add experimental seeking using horizontal progress slider (video is paused once seeking is used)
- Save/Restore current directory at startup/close to avoid changing user current dir.
- Few other fixes cleanup

download DUGL Player 1.0 Alpha2


DUGL Player GITHUB repo

> 14 June 2026: 1.0 Alpha6
> - Now use FFMPEG 5.1.8 with pentium-MMX CPU enabled including assembly
> optimizations.
> - Add support of Aspect Ratio with built-in list that could be
> overwritten by config file.
> - Add fast video decoding (could be switched by config file), to
> improve decoding speed of old Hardware (Thanks ThorKa!)
> - Add Aspect Ratio widget, with capability to switch next one with
> Mouse Click
> - F11 keyboard button now switch between Blitting video frame to full
> View or blitting according to current Aspect Ratio
> - F12 Keyboard button now switch Aspect Ratio to next one on the List.
> - Fix Not working VSync on GUI Mode.
> - Severals other fixes and speed improvement.
>
>
> download
> DUGL Player 1.0 Alpha6
>
> DUGL
> Player GITHUB repo

if some one is willing to run DUGL Player under DosBox variants I do recommend DosBox staging as the fastest or DosBox-x as the most stable. but both seems to have some File i/o bugs that would make it crash triggered by using fast the seek slider or looping a video. In both you need install HDPMI as cwsdpmi replacement for better performance/stability specially for DosBox-x which crash occasionally or could fail at all to start DUGL Player.

> Did you have FDAPM installed ? 70fps is too low for an I5-8250.
> with last alpha 6, a dpmi_yield call (energy saving) is always performed
> (need to be configured in CFG file).
> This dropped fps from 6000 to about 500fps on my ryzen 7700x.
No, but my system does not allow LFB writecombing because MTRRs can't be modified, as discussed above. So, the max frame rate is slowed by 10x-100x as a result of that.

I get about 70 fps on a 640x480 mp4 ~8000 kbps file. With 1920x1080 and a 20-30 mbps .m2ts file I get about 25 fps. With writiecombining disabled.

On a system with Intel Broadwell (intel i7-5600) chip which does allow LFB write combining since MTRRs can be written / changed, I get about 300 fps with 1366x766 with similar .m2ts file.

Both of these tests are using onboard intel graphics GPUs.

>
> At 640x480 at 1.5 Ghz I got about 28 fps with sound enabled, about 33 fps
> without any sound. At 3.4 Ghz, speeds increase to 70 fps without sound and
> 65 fps with sound. (This is without MTRRs set for LFB writecombining, which
> my Dell laptop with i5-8250 laptop can't set in DOS -- immediate hard
> system freeze when I try, perhaps due to USB boot or other embedded BIOS
> code which loads on top of DOS in bare metal).
>

Did you have FDAPM installed ? 70fps is too low for an I5-8250.
with last alpha 6, a dpmi_yield call (energy saving) is always performed (need to be configured in CFG file).
This dropped fps from 6000 to about 500fps on my ryzen 7700x.

> on the DUGLPLAY.CFG we have two fields linked to AR:
> - [AspectRatioList] : describing the list of possible AR the DUGL Player
> will allow to select/use
> - [DefaultAspectRatio]: which is the index of default Aspect Ratio used,
> for example here if you need "16:9:HD Video" as default one, you need to
> set it to 2
>
> [AspectRatioList]     ; Possible Aspect Ratios List
> [w:1..99]:[h:1..99]:[Name], ...
> 1:1:Square Grid,4:3:Standard Monitor,16:9:HD Video,3:2:Classic
> DLSR,9:16:Vertical Video,21:9:Ultrawide Monitor
> [DefaultAspectRatio]
> 2
OK, thanks for the clarification. I was unsure what [w:1..99] and [h:1..99] meant, but now I see there are three AR options to be set with [DefaultAspectRatio], so I can choose 1,2,or 3 at my leisure depending correct AR of the video or film material viewed in DUGL Player.

> 15-20% slow down is too much, you can reduce that by setting sampleRate to
> lower frequency, or selecting mono. Sound Driver could be further optimized
> by using MMX for up/downsampling. but this is currently a low priority
> todo.

At 640x480 at 1.5 Ghz I got about 28 fps with sound enabled, about 33 fps without any sound. At 3.4 Ghz, speeds increase to 70 fps without sound and 65 fps with sound. (This is without MTRRs set for LFB writecombining, which my Dell laptop with i5-8250 laptop can't set in DOS -- immediate hard system freeze when I try, perhaps due to USB boot or other embedded BIOS code which loads on top of DOS in bare metal).

> DUGL Library currently do not support bankswitched mode, but this could be
> implemented in futur. all rendering will happen inside a FLAT memory Surf
> as usually, then I need to implement the function that do copy to
> bankswitched VRAM.

Thanks for considering bankswitched mode in future. Flat memory model for direct bankswitched access will be almost like vidix in UNIX, on old 32-bit video cards like 3dfx Voodoo 3).

> Thanks for this new release and your continued work on the project. Aspect
> ratio feature feature works well. I am unclear how to set which AR I prefer
> in the config file, however. I see the AR options described there, but
> unsure how to "set" it in that config file.
>

Thanks for testing
on the DUGLPLAY.CFG we have two fields linked to AR:
- [AspectRatioList] : describing the list of possible AR the DUGL Player will allow to select/use
- [DefaultAspectRatio]: which is the index of default Aspect Ratio used, for example here if you need "16:9:HD Video" as default one, you need to set it to 2

[AspectRatioList]     ; Possible Aspect Ratios List [w:1..99]:[h:1..99]:[Name], ...
1:1:Square Grid,4:3:Standard Monitor,16:9:HD Video,3:2:Classic DLSR,9:16:Vertical Video,21:9:Ultrawide Monitor
[DefaultAspectRatio]
2


> Speed is improved from alpha 5 release about 10% on my system. Enabling
> sound slows the video speed somewhat (about 15-20%, but I'm using VSBHDA v.
> 1.9 on an Intel IHD PCI built in card to emulate SB16).

15-20% slow down is too much, you can reduce that by setting sampleRate to lower frequency, or selecting mono. Sound Driver could be further optimized by using MMX for up/downsampling. but this is currently a low priority todo.

>
> One technical question: Do you know if it's possible to switch from LFB
> writeback combining to using bankswitched mode on DUGL player? My system
> does not allow writeback cache combining by changing the MTRRs (for example
> with RayeR's MTRRLFBE utility), but does support bankswitched cache write
> combining (As tested with the XVESA 2.0 utility).
>
> Using bankswitched writecombining instead of LFB will massively improve
> speed for me, by factor of 10x or more.

DUGL Library currently do not support bankswitched mode, but this could be implemented in futur. all rendering will happen inside a FLAT memory Surf as usually, then I need to implement the function that do copy to bankswitched VRAM.

> 14 June 2026: 1.0 Alpha6
> - Now use FFMPEG 5.1.8 with pentium-MMX CPU enabled including assembly
> optimizations.
> - Add support of Aspect Ratio with built-in list that could be
> overwritten by config file.
> - Add fast video decoding (could be switched by config file), to
> improve decoding speed of old Hardware (Thanks ThorKa!)
> - Add Aspect Ratio widget, with capability to switch next one with
> Mouse Click
> - F11 keyboard button now switch between Blitting video frame to full
> View or blitting according to current Aspect Ratio
> - F12 Keyboard button now switch Aspect Ratio to next one on the List.
> - Fix Not working VSync on GUI Mode.
> - Severals other fixes and speed improvement.
Thanks for this new release and your continued work on the project. Aspect ratio feature feature works well. I am unclear how to set which AR I prefer in the config file, however. I see the AR options described there, but unsure how to "set" it in that config file.

Speed is improved from alpha 5 release about 10% on my system. Enabling sound slows the video speed somewhat (about 15-20%, but I'm using VSBHDA v. 1.9 on an Intel IHD PCI built in card to emulate SB16).

One technical question: Do you know if it's possible to switch from LFB writeback combining to using bankswitched mode on DUGL player? My system does not allow writeback cache combining by changing the MTRRs (for example with RayeR's MTRRLFBE utility), but does support bankswitched cache write combining (As tested with the XVESA 2.0 utility).

Using bankswitched writecombining instead of LFB will massively improve speed for me, by factor of 10x or more.

14 June 2026: 1.0 Alpha6
- Now use FFMPEG 5.1.8 with pentium-MMX CPU enabled including assembly optimizations.
- Add support of Aspect Ratio with built-in list that could be overwritten by config file.
- Add fast video decoding (could be switched by config file), to improve decoding speed of old Hardware (Thanks ThorKa!)
- Add Aspect Ratio widget, with capability to switch next one with Mouse Click
- F11 keyboard button now switch between Blitting video frame to full View or blitting according to current Aspect Ratio
- F12 Keyboard button now switch Aspect Ratio to next one on the List.
- Fix Not working VSync on GUI Mode.
- Severals other fixes and speed improvement.


download DUGL Player 1.0 Alpha6

DUGL Player GITHUB repo

> > If possible, one other feature request: Will it be possible to have an
> > option to play stereo audio files or movies with mono audio which has
> been
> > mixed from L+R? This is for one-speaker systems. Realtime mixing left
> and
> > right channels into a single mono channel is a valuable feature to have
>
> Feature already exist, the sound output is always set into DUGLPLAY.CFG by:
> [SoundSampling],[SoundStereo] and [Sound16Bits]. Any selected audio/video
> file will be resampled/played with this output.
I see. Thanks for clarifying. So if I set [SoundStereo] to 0 (disabled), the mixer will mix both channels of a stereo stream into a mono output at 50% L+R? I'll test it.

> With [EnableSound] set to false in the .cfg file, the raw video display
> speed is increased, but not as fast as Alpha1.
>

Ok I will compare, maybe there is useless handling added that I can remove to recover alpha1 performance.

> I also did more tests with audio-only files. They all played fine, and I
> could play at speed 1x, 2x, 4x, 0.5x but I could not seek using the slider
> bar in GUI-mode. I can seek in video files (eg, .mp4 and .mpeg2). For
> audio-only, the slider seems grayed out, but it does move and reports the
> runtime correctly on the lower-right side of the screen.

I'm using av_seek_frame FFMPEG function, it succeed with some files and fail with other, still unclear why I tested with several mp3, ogg files, and seeking audio only files worked with me.
I successfully built FFMPEG 5.1.8 with arch pentium-mmx (pthread disabled) maybe this will make things better for next alpha release.


> Audio-only filetypes I tested: .WAV, .FLAC, .MP3, opus, .AC3. I did not test DTS-HD
> audio. Is it supported, or is only regular 24-bit DTS audio playable (eg,
> 1536 kbps 48 khz audio)?
>
> If possible, one other feature request: Will it be possible to have an
> option to play stereo audio files or movies with mono audio which has been
> mixed from L+R? This is for one-speaker systems. Realtime mixing left and
> right channels into a single mono channel is a valuable feature to have

Feature already exist, the sound output is always set into DUGLPLAY.CFG by: [SoundSampling],[SoundStereo] and [Sound16Bits]. Any selected audio/video file will be resampled/played with this output.

> could you try to set [EnableSound] to false on DUGLPLAY.cfg, to compare ?
> I thought sound emulation/decoding isn't that heavy, but it clearly depends
> on used system performance.
With [EnableSound] set to false in the .cfg file, the raw video display speed is increased, but not as fast as Alpha1.

I also did more tests with audio-only files. They all played fine, and I could play at speed 1x, 2x, 4x, 0.5x but I could not seek using the slider bar in GUI-mode. I can seek in video files (eg, .mp4 and .mpeg2). For audio-only, the slider seems grayed out, but it does move and reports the runtime correctly on the lower-right side of the screen. Audio-only filetypes I tested: .WAV, .FLAC, .MP3, opus, .AC3. I did not test DTS-HD audio. Is it supported, or is only regular 24-bit DTS audio playable (eg, 1536 kbps 48 khz audio)?

If possible, one other feature request: Will it be possible to have an option to play stereo audio files or movies with mono audio which has been mixed from L+R? This is for one-speaker systems. Realtime mixing left and right channels into a single mono channel is a valuable feature to have

> Also forgot to mentioned one issue - when I enabled frame dropping I see
> that image often goes blocking like if there's an error in the stream but
> as I disabled it disappeared and image was clean again.

Yes Frames dropping while fully decoding frames become VERY slow on HD videos, you could get even less than 1fps (almost player locked). So I tried to implement a much faster Frames dropping, ignoring completely frames, but this could lead to a bad image quality.
I will add an option on DUGLPLAY.CFG to enable/disable [Fast Frame Dropping].

> I have NEC 2190UXp since 2009 and hope it will last as long as possible. It
> has CCFL backlight, so it could be replaced when necessary. I don't know if
> the LCD matrix ages/degrade too. I dreamed that one day I could buy some
> perfect OLED monitor with real black and fast response but seems screen
> burning will be never solved on this technology so it's rather used on TVs
> with motion picture than monitors with more still picture... Unfortunatelly
> all moderns monitors turned to noodles and even lacks analog VGA input so
> I'm not much interested in "upgrade"...
I'm still using two 21" CRTs, Mitusbishi and an Ilyama for the genuine DOS 4:3 experience. But of course they're analogue VGA only and each over 20 years old by now - but phosphors still very bright and excellent picture.

But for "modern" DOS 4:3 I have only two 5:4 LCD screens which I found at thrift store years ago. 95% of DOS work is done on 16:9 laptop displays, sadly with their stretched distortions of DOS 4:3 screens. That's why AR correction is so critical for me when viewing videos in DOS.

Of course I also dream of cheap OLED 4:3 "modern" laptop for baremetal DOS, but now with UEFI only since 2020 it's lost dream, unless some niche $3000 ridiculous "retro" system is cobbled together with modern parts from some expensive boutique company.

Still the same good-old SandyB. as I reported here: https://www.bttr-software.de/forum/forum_entry.php?id=23247

Also forgot to mentioned one issue - when I enabled frame dropping I see that image often goes blocking like if there's an error in the stream but as I disabled it disappeared and image was clean again.

I have NEC 2190UXp since 2009 and hope it will last as long as possible. It has CCFL backlight, so it could be replaced when necessary. I don't know if the LCD matrix ages/degrade too. I dreamed that one day I could buy some perfect OLED monitor with real black and fast response but seems screen burning will be never solved on this technology so it's rather used on TVs with motion picture than monitors with more still picture... Unfortunatelly all moderns monitors turned to noodles and even lacks analog VGA input so I'm not much interested in "upgrade"...

---
DOS gives me freedom to unlimited HW access.

> What are your system specs? I noticed alpha 5 is slower as well. On
> baremetal DOS, but still fast enough to ensure a 24-30fps rate on film
> material even at 1920x1080 on my i5 - 8th gen CPU. On that system, your
> MTRRLFBE can't modify MTRRs for writecombining- system freeze every time.
> On an i7 - 5th gen laptop CPU I get about 60 fps at 1920x1080 with MTRRs
> enabled (MTRRLFBE doesn't freeze on this 5th gen Intel) and ~15-20 fps
> without MTRR writecombining @ 2.4 Ghz.

on my ryzen 7700x, with a small mpeg video 320x240, MTRRLFBE boost from 1500fps to an impressive 6000fps.

>
> Yep, I tried Frame Dropping too. It does feel like the lag between
> audio and video streams reduces with it, but it's still noticeable. Another
> thing that may be useful to know (or you may already know) - if suppose the
> audio and video streams go out of sync (they eventually do) but then I seek
> to another part of the video, then the vid and audio streams get back in
> sync (at least this was my experience with a particular mkv file)

Clearly synching video frames with playing audio (instead of timer) is a must to keep good synch audio/video. I will add it as an option enabled by default.

> Please could you add some option to keep video aspect ratio? When fitted to
> screen it's stretched to my 4:3 LCD (original format is usually 16:9 or
> wider).

Yes on todo list.

> Sound plays OK when used VSBHDA but I noticed that alpha 5 is significantly
> slower than alpha 1 I tested before (I got 40-250FPS before, now only
> 15-30FPS), maybe sound decoding and emulation is too heavy...

could you try to set [EnableSound] to false on DUGLPLAY.cfg, to compare ?
I thought sound emulation/decoding isn't that heavy, but it clearly depends on used system performance.

> Please could you add some option to keep video aspect ratio? When fitted to
> screen it's stretched to my 4:3 LCD (original format is usually 16:9 or
> wider).
>
> Sound plays OK when used VSBHDA but I noticed that alpha 5 is significantly
> slower than alpha 1 I tested before (I got 40-250FPS before, now only
> 15-30FPS), maybe sound decoding and emulation is too heavy...
I am often the opposite... trying to watch 4:3 material on the 16:9 display of a laptop. I agree a "keep aspect ratio" option will be very important. As well
as the keyboard-based fast-forward and rewind options while watching in fullscreen mode (no gui).

Trying to find a true 4:3 LCD now is very difficult, none are being made any longer, sadly. At least not in a general sense; some niche extremely expensive boutique 4:3 LED/LCD monitors may be produced for the gaming market in 2026, but they cost over a thousand dollars.

What are your system specs? I noticed alpha 5 is slower as well. On baremetal DOS, but still fast enough to ensure a 24-30fps rate on film material even at 1920x1080 on my i5 - 8th gen CPU. On that system, your MTRRLFBE can't modify MTRRs for writecombining- system freeze every time. On an i7 - 5th gen laptop CPU I get about 60 fps at 1920x1080 with MTRRs enabled (MTRRLFBE doesn't freeze on this 5th gen Intel) and ~15-20 fps without MTRR writecombining @ 2.4 Ghz.

Please could you add some option to keep video aspect ratio? When fitted to screen it's stretched to my 4:3 LCD (original format is usually 16:9 or wider).

Sound plays OK when used VSBHDA but I noticed that alpha 5 is significantly slower than alpha 1 I tested before (I got 40-250FPS before, now only 15-30FPS), maybe sound decoding and emulation is too heavy...

---
DOS gives me freedom to unlimited HW access.

> > I tested this and it blew my mind! Played an MKV file in bare metal DOS.
> > Amazing piece of software and finally something to supersede QVPRO
> >
>
> Thanks for testing
>
> > One thing though - I noticed the audio was gradually going more and more
> > out of sync as the video progressed - the video was lagging behind the
> > audio. Are there any particular codecs that this is optimized for?
>
> Did you tried to enable Frame Dropping (F10), even if FPS is very high
> dropping some frames is required to keep the sync between audio/video.
> Anyway, it's still on my todo list, I'm thinking to sync video output
> following the progress of audio instead of using timer. let's see
>
> >
> > Also, I personally didn't get any audio tears or glitches. Using VSBHDA
> > with the onboard HDA audio on X58 motherboard (ALC888)
>
> Good to know, so I'm currently the only one who get some nano-glitches,
> specially on audio only files.

Yep, I tried Frame Dropping too. It does feel like the lag between audio and video streams reduces with it, but it's still noticeable. Another thing that may be useful to know (or you may already know) - if suppose the audio and video streams go out of sync (they eventually do) but then I seek to another part of the video, then the vid and audio streams get back in sync (at least this was my experience with a particular mkv file)

> I tested this and it blew my mind! Played an MKV file in bare metal DOS.
> Amazing piece of software and finally something to supersede QVPRO
>

Thanks for testing

> One thing though - I noticed the audio was gradually going more and more
> out of sync as the video progressed - the video was lagging behind the
> audio. Are there any particular codecs that this is optimized for?

Did you tried to enable Frame Dropping (F10), even if FPS is very high dropping some frames is required to keep the sync between audio/video.
Anyway, it's still on my todo list, I'm thinking to sync video output following the progress of audio instead of using timer. let's see

>
> Also, I personally didn't get any audio tears or glitches. Using VSBHDA
> with the onboard HDA audio on X58 motherboard (ALC888)

Good to know, so I'm currently the only one who get some nano-glitches, specially on audio only files.

I tested this and it blew my mind! Played an MKV file in bare metal DOS. Amazing piece of software and finally something to supersede QVPRO

One thing though - I noticed the audio was gradually going more and more out of sync as the video progressed - the video was lagging behind the audio. Are there any particular codecs that this is optimized for?

Also, I personally didn't get any audio tears or glitches. Using VSBHDA with the onboard HDA audio on X58 motherboard (ALC888)

> Thanks for clarifying. Yes, I'm using on baremetal. I didn't get any
> glitches with audio.
>

Glitches maybe depends on emulated sound card, let's see once DUGL Player is more widely used and we get more feedbacks.
I get glitches on my ASUS PRIME B650M-A II with "Realtek 7.1 Surround Sound High Definition Audio CODEC" hopefully it has a CSM BIOS and work well with ryzen 7700x

> I doubt seeking problems is a fault of DUGL.

yes seems either DOSBOX-X/Staging bug with intensive I/O or FFMPEG 5.1.2, some times fast forward fail just with first trial.

25 april 2026: 1.0 Alpha5
- Add/implement new button to select playing speed with ratio 1/2, 1(default), 2, 4 (third button starting from left)
- Implement audio only files fast forward/rewind with slider
- Improve GUI design with progress slider at full window width and increasing precision to 1000 (was 100)
- Add possibility display audio curve for audio only files, with additional config file fields
(enable; background color; curve color; render mode: blit|transluent)
- Revert time display to hh:mm:ss instead of xxhxxmxxs
- Improve Open Dialog File filters



Download DUGL Player 1.0 alpha5 bin

DUGL Player GITHUB repo

> Yes no downsample happening at all, that was true on the very early version
> of DUGL Player without config file enabling higher res.
> I'm already updating docs for the upcoming alpha 5. which will come with
> more features ..
>
> >
> > 2. Seeking works very well by using the slider in non-fullscreen mode to
> > fast forward and rewind, but I can't seek in fullscreen mode. Either by
> > pressing right arrow, up arrows, etc. That's a feature request.
>
> Yes, seeking on fullscreen mode isn't implemented yet. it's planned once
> all core features are implemented.
> On my side, some video files don't seek at all. Some times playing same
> video several times make seeking not possible (maybe again related to
> buffer overflow on FFMPEG version ?) ..
Thanks for clarifying. Yes, I'm using on baremetal. I didn't get any glitches with audio.

Some video files don't seek because they contain I-frames only. It also might be that an mkv file has a corrupt index (at the end of the file), so they won't seek. Also, raw h.264 or h.265 elementary streams can't seek.

I doubt seeking problems is a fault of DUGL.

> Tested Alpha 4 and it's already very useful and improved. Audio only mode
> is a great, useful feature. Sound quality is excellent.

Thanks for testing
On my side, audio only file mode, some times generate nano-glitches.
under DosBox-Staging or DosBox-X I get some crashes (but strangely not in baremetal) that seem to be related to the OLD version FFMPEG 5.1.2.
let's see if a contributor can build a newer version of FFMEG and why not with MMX enabled.

>
> Two questions:
>
> 1. Docs state that all files higher than 640x480 are resampled to this
> resolution. Does this still apply in Alpha 4? I can play 1920x1080, and it
> appears to be very sharp genuine 1920x1080 material. Why downsample?

Yes no downsample happening at all, that was true on the very early version of DUGL Player without config file enabling higher res.
I'm already updating docs for the upcoming alpha 5. which will come with more features ..

>
> 2. Seeking works very well by using the slider in non-fullscreen mode to
> fast forward and rewind, but I can't seek in fullscreen mode. Either by
> pressing right arrow, up arrows, etc. That's a feature request.

Yes, seeking on fullscreen mode isn't implemented yet. it's planned once all core features are implemented.
On my side, some video files don't seek at all. Some times playing same video several times make seeking not possible (maybe again related to buffer overflow on FFMPEG version ?) ..

> IMHO this is the first really useful version, but still lot of work to be
> done !
Tested Alpha 4 and it's already very useful and improved. Audio only mode is a great, useful feature. Sound quality is excellent.

Two questions:

1. Docs state that all files higher than 640x480 are resampled to this resolution. Does this still apply in Alpha 4? I can play 1920x1080, and it appears to be very sharp genuine 1920x1080 material. Why downsample?

2. Seeking works very well by using the slider in non-fullscreen mode to fast forward and rewind, but I can't seek in fullscreen mode. Either by pressing right arrow, up arrows, etc. That's a feature request.

13 April 2026: 1.0 alpha 4
- Implement decoding for audio only files
- Add master volume control widget
- Implement the three usual time progress modes (progress, remaining time, progress / total time)
user can switch between modes by mouse clicking on the time
- Implement seeking of audio track with video track
- Improve playing mode widget, now image Button (looping or single play)
- severals parameters added to config file
- Improved sound quality, bug fixes



Direct Download DUGL Player 1.0 Alpha4

IMHO this is the first really useful version, but still lot of work to be done !

> Thank you! I tested 1.0 alpha 3, and it worked well for me under Intel HDA
> sound and VSBHDA. Videos worked all the way up to 1920x1080. Frame rate was
> slow (23 fps) at that resolution, with all quality options turned on.
>
> I increased the sound buffer from 8000 to 16000 and the sampling rate to
> 44100 hz in the .ini file.
>
> This is great progress.

Thank you for testing!
23fps with (1920x1080 /sound at 44100 (16bits ? stereo ?) /smoothing/YUV interpolation enabled) seem to be quiet good with a single CPU core.

However, sound is still on very alpha stage, no time synch yet, sound driver has some bugs. lots of fixes to come for alpha 4. additionnally it will be able to play both video/audio files

> 26 march 2026 : 1.0 alpha 3
>
> - Add experimental sound decoding/support using Sound Blaster 16 driver
> - Improve config file with new sound audio paramters, true|false to
> enable/disable,
> - Add reverting to 640x480 if selected config file video resolution isn't
> available ...
> - Keyboard 'P' now pause continue playing current video
>
> Tested successfully with freedos/csmwrap/vsbhda baremetal with two
> machines
> Core i5-4570 and ryzen 7700x
>
> The quality of sound sometimes isn't perfect, I configured the sound buffer
> to about 0.3 sec with [VoiceSampleSize] in config file.
>
> my audio decoding ffmpeg algorithm require more tuning!
>
>
> Download
> DUGL Player 1.0 Alpha 3

Thank you! I tested 1.0 alpha 3, and it worked well for me under Intel HDA sound and VSBHDA. Videos worked all the way up to 1920x1080. Frame rate was slow (23 fps) at that resolution, with all quality options turned on.

I increased the sound buffer from 8000 to 16000 and the sampling rate to 44100 hz in the .ini file.

This is great progress.

26 march 2026 : 1.0 alpha 3

- Add experimental sound decoding/support using Sound Blaster 16 driver
- Improve config file with new sound audio paramters, true|false to enable/disable,
- Add reverting to 640x480 if selected config file video resolution isn't available ...
- Keyboard 'P' now pause continue playing current video

Tested successfully with freedos/csmwrap/vsbhda baremetal with two machines
Core i5-4570 and ryzen 7700x

The quality of sound sometimes isn't perfect, I configured the sound buffer to about 0.3 sec with [VoiceSampleSize] in config file.

my audio decoding ffmpeg algorithm require more tuning!


Download DUGL Player 1.0 Alpha 3

In my VESA lib I have separate drawing routines for 15/16bpp and 24/32bpp modes...

---
DOS gives me freedom to unlimited HW access.

> The most crtitical ressources for performance is memory writes bandwidth.
> packing 5:6:5 or 8:8:8 is mostly same overhead with assembly.
>

Hm, I also use in my graphic library VenomGFX the 16-bit modes for exactly same reason like you and I have the exactly same limitations with it. It is hardly usable for applications like graphic editors and image manipulations.
However there is one advantage woth 16-bit modes that you have not mentioned.
It works on every computer since 1992 to now (or almost now).
But the "truecolor modes" are sometimes 24-bit and sometimes 32-bit.
It would need two branches of the graphic library. (or four branches - with LFB and noLFB modes)
So this is the main reason why I stay in 16-bit.

---
DOS-u-akbar!

> > Ok let's hope that a developer will port again the last FFMPEG for DOS,
> it
> > will be nice if it's mmx optimized to get more performance.
> glennmcc compiled FFMPEG 5.1.4 for DOS.
>
> This the thread:
>
> https://www.bttr-software.de/forum/board_entry.php?id=21424&page=0&order=time&category=0
>
> The problem with compiling the latest version 6 for DOS is that pthreads is
> required. glennmcc had same problems as you finding a working pthreads
> implementation or source code for DOS. So couldn't compile FFMPEG 6 for DOS
> due to this hard wall.

I see only FFMPEG.EXE, I need libs and headers of FFMPEG to be able to use it.

>
> I understand but mabye, 16b FB is less data but packing/unpacking bits like
> 6:5:6 in 2 Bytes may take extra overhead when creating such image, e.g.
> drawing a line... In case that video decoder can already decode in such
> packed format it's not problem then...

The most crtitical ressources for performance is memory writes bandwidth.
packing 5:6:5 or 8:8:8 is mostly same overhead with assembly.

I remember an intel performance hint for reducing memory writes. to set a boolan to true check the value before writing.

so:

if (boolVal == false) boolVal = true;

is faster than setting value directly:

boolVal = True;

> As DUGL is mainly for games, performance is the highest priority. Plain
> RGBA will need twice memory bandwidth as 16bpp with a little improvement in
> quality.

I understand but maybe, 16b FB is less data but packing/unpacking bits like 6:5:6 in 2 Bytes may take extra overhead when creating such image, e.g. drawing a line... In case that video decoder can already decode in such packed format it's not problem then...

---
DOS gives me freedom to unlimited HW access.

> The problem with compiling the latest version 6 for DOS is that pthreads is
> required. glennmcc had same problems as you finding a working pthreads
> implementation or source code for DOS. So couldn't compile FFMPEG 6 for DOS
> due to this hard wall.

BTW there's some pthread lib for DJGPP but as I never used it I don't know the limitations, maybe outdated or incomplete for recent ffmpeg req.
https://groups.google.com/g/comp.os.msdos.djgpp/c/RNeA2ZUAhmI

And here's Sherpya FFMPEG build that works on WinXP-32b and supports h266 including ffplay
https://sourceforge.net/projects/mplayer-win32/files/FFmpeg/git-N-118711-g1bce40cb73/
https://github.com/sherpya/FFmpeg

And here was old article of M.Ch. who even created DOS API extension for launching tasks on multiple cores - I cannot find it on webarchive but was here (I have a local copy)
https://main.codeproject.com/articles/The-Low-Level-M3ss-DOS-Multicore-Mode-Interface

---
DOS gives me freedom to unlimited HW access.

> yes I'm aware of it, it's an SDL2 port as I understand, but no binaries
> provided, neither instruction how to build.
> It would be nice if he provide DJGPP/DEV package so I can give it a try,
> but still the OLD DUGL with MMX+ CPU is relevant as it allow any CPU from
> 1997+
> if successfully, it would be nice to have two variants SSE4.1 and MMX, as
> SSE4.1 is much faster, smooth for example is 100% faster (in single core)
Re: Diablo and SDL2: Laaca provided a compilation for me in the thread mentioned above. (I also couldn't find a binary or source to compile). But, the link is now dead. I got it. Ask him in the "SDL and diablo" thread if you want the DJGPP compiled binary. It's based upon DevilutionX:
https://github.com/diasurgical/DevilutionX

> Ok let's hope that a developer will port again the last FFMPEG for DOS, it
> will be nice if it's mmx optimized to get more performance.
glennmcc compiled FFMPEG 5.1.4 for DOS.

This the thread:

https://www.bttr-software.de/forum/board_entry.php?id=21424&page=0&order=time&category=0

The problem with compiling the latest version 6 for DOS is that pthreads is required. glennmcc had same problems as you finding a working pthreads implementation or source code for DOS. So couldn't compile FFMPEG 6 for DOS due to this hard wall.

> Yes I set this and expected blindly 32bpp, why DUGL use only 16bpp? I
> rather work with plain RGBA than packed pixels. Maybe some dithering filter
> could improve color banding...

As DUGL is mainly for games, performance is the highest priority. Plain RGBA will need twice memory bandwidth as 16bpp with a little improvement in quality.
Same, using RGB (24bits) will make pixels not memory aligned which is very bad for performance.
My estimation for example for your i7 as you reached 250 fps (about 0.5G texel/s), with RGBA you will never cross 150fps, which isn't small loss.
Anyway I agreee that supporting RGBA will make DUGL more generic for any usage, like making paint, video editing or any application requiring high definition colors.

> I gave up my FFPMEG builds at version 2.x as it requires more and more new
> stuff that was hard to handle on my DJGPP WinXP build system. I see some
> year ago here someone posted compiled FFMPEG 5.x but not sure if with
> sources too. H266 support was added probably in quite new version. I tested
> it on WinXP, there's MPCHC/LAV with h266 support and also some build of
> ffmpeg includes ffplayer that also could play h266...

Ok let's hope that a developer will port again the last FFMPEG for DOS, it will be nice if it's mmx optimized to get more performance.

> I understand but making regular SMP pthread DOS port would take more
> effort, you cannot expect someone would do it for fun. So I think it's more
> realistic to code some very basic proprietary SMP routines yourself but I
> understand it wouldn't be easy to connect it with ffmpeg code that rely on
> pthreads...

An SMP pthread for DOS will be a BIG step forward, like VSBHDA and CSMWRAP projects, let's hope a developer will do it for a better/mainstream DOS.
If I have time as I will take a look how to force a DUGL::DWorker to run fully on a specific core if exist and shortcut pthread implementation.

> DUGL support only 8bpp/16bpp video modes, so you configured DUGLPLAY.CFG
> with [VideoMode] 1600,1200 ?

Yes I set this and expected blindly 32bpp, why DUGL use only 16bpp? I rather work with plain RGBA than packed pixels. Maybe some dithering filter could improve color banding...

> any planned port of the new FFMPEG ?

I gave up my FFPMEG builds at version 2.x as it requires more and more new stuff that was hard to handle on my DJGPP WinXP build system. I see some year ago here someone posted compiled FFMPEG 5.x but not sure if with sources too. H266 support was added probably in quite new version. I tested it on WinXP, there's MPCHC/LAV with h266 support and also some build of ffmpeg includes ffplayer that also could play h266...

---
DOS gives me freedom to unlimited HW access.

> could be interesting idea for DOS DUGL to create several static rendering
> cores and harcode linking each render core with a CPU core if it exist.
> But honestly I prefer a generic PThread lib SMP aware, with a scheduler
> that distribute charge over available cores.

I understand but making regular SMP pthread DOS port would take more effort, you cannot expect someone would do it for fun. So I think it's more realistic to code some very basic proprietary SMP routines yourself but I understand it wouldn't be easy to connect it with ffmpeg code that rely on pthreads...

---
DOS gives me freedom to unlimited HW access.

> May I suggest also a way to seek during fullscreen playback using
> keyboard:
>
> arrow keys: left: 2x fast-rewind
> right: 2x fast-forward
> up: 8x fast-forward
> down: 8x fast-rewind
> P for pause.

I'm thinking too about a transparent toolbar that contain all required functions, it will disappear once mouse is on the bottom edge of the screen

>
> I didn't test yet if .FLAC, Wavpack, DTS-HD, ALAC, or other lossless audio
> codec are supported.
>
> Is lossless h.264 supported? (Eg, videos created with FFMPEG's -crf 0
> setting). Obviously this would require a powerful i7/i9 and very high
> processor speed to decode without framedrops.

FFMPEG version 5.1.2 should be able to play all those video codecs, but not sure about h.265

>
> I see F2 disabled fast 5:6:5 decoding. Does this enable 32-bit colors
> decoding? What does disabling it do. Framerate slows about ~10% when I use
> F2.

Most Video codecs bring back Y,U,V arrays for each pixel instead of R,G,B. (requiring a conversion later)
but depends on the video file, it could return :
- full Y,U,V arrays for each pixel "YUV444"
- full Y array, but half arrays for U,V "YUV422"
- full Y array and a quarter arrays U,V "YUV420"

to increase rendering quality, instead of taking the missing U,V from the nearest pixel, we do an interpolation between the surrounding pixels, creating then a full YUV44 arrays.
According to my tests the quality gain is very little if none, maybe because of the 16bpp color space.

> > Really would like seeking in videos and playing sound.
>
> experimental seeking is now implemented on 1.0 alpha2, thought not perfect.
> I have even a sample ogg that fail to seek at all, but it should be fine
> for most videos.
Seeking worked OK for me via the slider. This is very welcomed!

May I suggest also a way to seek during fullscreen playback using keyboard:

arrow keys: left: 2x fast-rewind
right: 2x fast-forward
up: 8x fast-forward
down: 8x fast-rewind
P for pause.

I didn't test yet if .FLAC, Wavpack, DTS-HD, ALAC, or other lossless audio codec are supported.

Is lossless h.264 supported? (Eg, videos created with FFMPEG's -crf 0 setting). Obviously this would require a powerful i7/i9 and very high processor speed to decode without framedrops.

I see F2 disabled fast 5:6:5 decoding. Does this enable 32-bit colors decoding? What does disabling it do. Framerate slows about ~10% when I use F2.

> I tried on my i7-2600K and it seems to run fine. I played some h265 FHD
> videoclip in 1600x1200/32bpp

DUGL support only 8bpp/16bpp video modes, so you configured DUGLPLAY.CFG with [VideoMode] 1600,1200 ?

> and got 40-250FPS, mostly around 100FPS.

yes some frames are slow to decode

> Seeking work reasonable (only P-frames?).

I'm using FFMPEG function av_seek_frame, this function try to set the video position to nearest frame to selected frame, I'm not aware how ffmpeg do the seek, but currently I failed to get the right seeked frame number. This could lead to some precision lost that we can see later if sound enabled.

> I can see that image quality is
> significantly worse than under windows with MPC-HC, probably coz it use
> some post-proc filters like deblocking while in DUGL I see visible
> blocking...

as DUGL use 16bpp video mode there no doubt of quality loss, but I can see for more than 90% of videos tested the quality is hardly distinguishable from 24bpp

> I'm forward to version with sound support (at least basic SB16 that could
> play via VSBHDA).
>

yes it will be challenging to synch between video/audio specially after a seek.

> Also it would be challenging implement new h266 codec (new FFPMEG should),
> it's significantly more CPU-demanding and probably no available GPU
> acceleration yet...

any planned port of the new FFMPEG ?

> experimental seeking is now implemented on 1.0 alpha2, thought not perfect.
> I have even a sample ogg that fail to seek at all, but it should be fine
> for most videos.

I tried on my i7-2600K and it seems to run fine. I played some h265 FHD videoclip in 1600x1200/32bpp and got 40-250FPS, mostly around 100FPS. Seeking work reasonable (only P-frames?). I can see that image quality is significantly worse than under windows with MPC-HC, probably coz it use some post-proc filters like deblocking while in DUGL I see visible blocking...
I'm forward to version with sound support (at least basic SB16 that could play via VSBHDA).

Also it would be challenging implement new h266 codec (new FFPMEG should), it's significantly more CPU-demanding and probably no available GPU acceleration yet...

---
DOS gives me freedom to unlimited HW access.

> Really would like seeking in videos and playing sound.

experimental seeking is now implemented on 1.0 alpha2, thought not perfect. I have even a sample ogg that fail to seek at all, but it should be fine for most videos.

>
> I agree that avoiding parallel calls to the kernel is a good solution for
> now. There even were games or demoscene demos which just loaded all data
> before switching to protected mode, so they needed no DOS extender to call
> the kernel from protected mode.
>
> The kernel already has the InDOS flag which helps you to avoid calling it
> while it already is busy. And It is okay to lock the kernel to the first
> CPU core.
>
> If you want to handle multiple parallel kernel calls, you can use the same
> strategy as Windows 3.x in 386enh mode and swap all swappable data of the
> kernel to create relatively independent instances of the running kernel. It
> used that to be able to run multiple DOS windows seemingly in parallel. You
> would have to use a very modern WfW 3.11 compatible FreeDOS kernel
> version.
>
> Of course multi-core DOS could be made arbitrarily complex - there already
> are Jack's UDMA drivers for SATA, but modern disks and SSD support
> multithreaded I/O with several transactions being active at the same time.
> I do NOT think that a DOS kernel should try to do this.

I think that an updated Pthread lib could handle all this. then for any external user it will be completely transparent if it's SMP or not.

> I don't think that multithreading DOS would be necessary for such
> application. It's not so complicate to program APIC to start more CPU cores
> and there is a demo code to do this for many years (by Michael Choudarkis
> or so?) but there was not real usage in DOS/nobody wanted to mess with it.
> I think that a video decoding/player is a typical application that can
> benefit from SMP and if you have time to mess with it can be done. You can
> offload some computing functions to other cores which wouldn't need to call
> DOS/BIOS services - this would very simplify things as DOS/BIOS wouldn't
> need to know that anything else is running on other cores. I think that you
> just allocate some memory for code and buffers, start some decoding
> functions on cores and in main thread poll when decoding done. I think that
> ffmpeg use pthreads or such library so you would need to write some wrapper
> for it that may be the harder part...

could be interesting idea for DOS DUGL to create several static rendering cores and harcode linking each render core with a CPU core if it exist.
But honestly I prefer a generic PThread lib SMP aware, with a scheduler that distribute charge over available cores. This will make DUGL DWorker concept (layer over pthread) SMP aware too, so any soft using it become SMP aware.

>
> BTW playing youtube would be hell-endless fighting with google
> anti-downloading. Have a look at youtube downloader project what they have
> to challenge (e.g. running some javascr*** crap) and how often they need to
> do some changes to keep it working.

yes it's an endless challenge with youtube. but what about tcp streams ? could cuurent DJGPP FFMPEG do it, does it rely on WATTCP ?

> yes SMP with DOS isn't easy, as we need to make DOS kernel threading
> aware/reentrant, but a first SMP impementation that just use the other
> cores, and save the state of MMX, XMM registers on thread switch and with
> the constraint to never call DOS/BIOS functions outside a single thread.
> should be doable. let's see.

I don't think that multithreading DOS would be necessary for such application. It's not so complicate to program APIC to start more CPU cores and there is a demo code to do this for many years (by Michael Choudarkis or so?) but there was not real usage in DOS/nobody wanted to mess with it. I think that a video decoding/player is a typical application that can benefit from SMP and if you have time to mess with it can be done. You can offload some computing functions to other cores which wouldn't need to call DOS/BIOS services - this would very simplify things as DOS/BIOS wouldn't need to know that anything else is running on other cores. I think that you just allocate some memory for code and buffers, start some decoding functions on cores and in main thread poll when decoding done. I think that ffmpeg use pthreads or such library so you would need to write some wrapper for it that may be the harder part...

BTW playing youtube would be hell-endless fighting with google anti-downloading. Have a look at youtube downloader project what they have to challenge (e.g. running some javascr*** crap) and how often they need to do some changes to keep it working.

---
DOS gives me freedom to unlimited HW access.