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

Welcome back!

Your last post here was thirteen years ago.
What happened meanwhile?
Why are you back now?

---
Forum admin

> Now use only last DJGPP port of FFMPEG 5.1.2 as video decoder!
> it support most codecs including webm animated GIF ...
It is fabulous to have another DOS video player which supports modern codecs. Thanks very much. This is a logical progression of the DUGL picture viewer. I seem to recall you released a DUGL player over a decade ago which supported MPEG1 and MPEG2, but not h.264 or h.265.

I tested it in raw bare-metal DOS 7.1, and it played a 640x480 6mbps h.264 .mp4 at about 55 fps with MTRR enabled and ~38 fps without MTRRs enabled. This is on an i5 3427 CPU @ 1.7 Ghz. Full-screen playing worked, but my 1366x768 and 1920x1080 VESA modes did not. (These use the native 16:9 AR of the screen). They were garbled. The only modes which worked for me were the 4:3 VESA modes.

The 55 fps was with Vsync enabled, full screen, and full screen "smoothing". Not sure what full screen smoothing does. Does it interpolate and do some sort of b-spline and / or lanzcos interpolation? Without any of these enabled, the player plays at 200-250 fps.

Really would like seeking in videos and playing sound. I loaded SB-Emu and DUGL player didn't crash with it loaded. So, this gives hope that when you enable sound with videos, it should work with on "modern" IHD PCI sound.

> Welcome back!
>

Thank you

> Your last post here was thirteen years ago.
> What happened meanwhile?

Well a lot , First I was disappointed (13 years ago) that there is no viable SOUND solution. As my goal was always bare metal DOS, no matter how beautiful/fast is your game/soft if there is no sound!
Then I lost my email linked to several things including dugl website, this forum.. I didn't tried to recover just kept following.
meanwhile I continued some developments, then got the Idea to port it to SDL Lib. Then Dust Ultimate Game Library is born DUST - DUGL hoping that SDL DOS/DJGPP port will happen.
..
Then the project SBEMU started, followed by VSBHDA (SOUND), and CSMWRAP (bare metal), I also discovered the MINGW/DJGPP cross compiler. so as I felt that OLD DUGL was a big waste and it was a bad idea to put it on hold (maybe for ever) and that the new DUGL was based on SSE4.1 so wiping out 10 years of computers .. so I given a try with cross MINGW/DJGPP and CodeBlocks, and it was wonderful, I can work 4 times faster than with RHIDE .. So I decided to bring back the OLD DUGL, and port as much as possible new features from NEW DUGL ..


> Why are you back now?

I among the poeple that sill beleave that DOS has all potential to go back main stream, not just retro gaming/dev inside a VM. all what we need now is a successfull VSHDA/CSMWRAP, a missing good PTHREAD lib with capability to use all CPU Cores (new DUGL is up to 300% faster thanks to rendering with 4 cores), maybe also a better HDD/SATA/SSD drivers that bring full speed ..
Well that's not going to be easy, but I'm here to contribute as much as I can, and without a doubt this is a long term hobby

> > Now use only last DJGPP port of FFMPEG 5.1.2 as video decoder!
> > it support most codecs including webm animated GIF ...
> It is fabulous to have another DOS video player which supports modern
> codecs. Thanks very much. This is a logical progression of the DUGL picture
> viewer. I seem to recall you released a DUGL player over a decade ago which
> supported MPEG1 and MPEG2, but not h.264 or h.265.
>

Thank you I'm not sure about the support of the FFMPEG DJGPP Port of networking, it would be cool if we could play youtube/ or any stream channel .

> I tested it in raw bare-metal DOS 7.1, and it played a 640x480 6mbps h.264
> .mp4 at about 55 fps with MTRR enabled and ~38 fps without MTRRs enabled.
> This is on an i5 3427 CPU @ 1.7 Ghz. Full-screen playing worked, but my
> 1366x768 and 1920x1080 VESA modes did not. (These use the native 16:9 AR of
> the screen). They were garbled. The only modes which worked for me were the
> 4:3 VESA modes.

Thanks for testing on bare-metal, Curious about your [VideoMode] settings on DUGLPLAY.CFG which worked, I maybe have to bring the list of available video modes for selection on new config dialog.
I think this caused by a buggy VBIOS, using another screen maybe solve the problem.

>
> The 55 fps was with Vsync enabled, full screen, and full screen
> "smoothing". Not sure what full screen smoothing does. Does it interpolate
> and do some sort of b-spline and / or lanzcos interpolation? Without any of
> these enabled, the player plays at 200-250 fps.

yes, smoothing do just merge RGB of each pixel with RGB of pixels around it. but fine tuned with 16bpp RGB565 to avoid getting greener.



It's useful particularly for low res video to increase quality, as you can see on the screenshot the left/before right/after smooth
but it can be improved further for better downsizing of videos, as DUGL Viewer did on the past, so it's kind of Soft anti-aliased rendering, relying the on the fast assembly implementation to be only 30% to 70% solwer, but depends !

>
> Really would like seeking in videos and playing sound. I loaded SB-Emu and
> DUGL player didn't crash with it loaded. So, this gives hope that when you
> enable sound with videos, it should work with on "modern" IHD PCI sound.

Yes seeking is within easy goals, I'm just playing with FFMPEG to see how to do it. I already struggled for a week with FFMPEG to successfully implement fast frames dropping ..
I need then to improve DUGL SB16 driver/then rely on VSBHDA to bring me sound

> Thanks for testing on bare-metal, Curious about your [VideoMode] settings
> on DUGLPLAY.CFG which worked, I maybe have to bring the list of available
> video modes for selection on new config dialog.
> I think this caused by a buggy VBIOS, using another screen maybe solve the
> problem.
The [VideoMode] modes which work for me are: 640x480, 800x600, 1024x768. Those that do not work are: 1366x768 and 1920x1080. Yes, I think it's buggy vbios and / or buggy VESA detection of LFB in 16:9 modes. The 16:9 modes are garbled, they're still detected and don't crash, but the video is scrambled / garbled. Some programs work at my 16:9 VESA modes (for example SEA v1.3 picture viewer and Hexen 2 and Quake 2 DOS ports) but others don't. I think it's buggy vbios on my end, not your program. Although there might be another VESA-detection code you might try??. Perhaps.


>
> Yes seeking is within easy goals, I'm just playing with FFMPEG to see how
> to do it. I already struggled for a week with FFMPEG to successfully
> implement fast frames dropping ..
> I need then to improve DUGL SB16 driver/then rely on VSBHDA to bring me
> sound

Yes, VSBHDA is what I loaded. It didn't crash the system upon executing DUGL Player, but SB Emu did in every instance.

> meanwhile I continued some developments, then got the Idea to port it to
> SDL Lib. Then Dust Ultimate Game Library is born
> DUST - DUGL hoping that SDL
> DOS/DJGPP port will happen.
Are you aware of the DOS Diablo port?

https://www.bttr-software.de/forum/forum_entry.php?id=22726

This has some or all of an SDL port to DOS, I think. But not SDL2. It worked for me, but brightness / gamma is screwed up (too low).


>
> I among the poeple that sill beleave that DOS has all potential to go back
> main stream, not just retro gaming/dev inside a VM. all what we need now is
> a successfull VSHDA/CSMWRAP, a missing good PTHREAD lib with capability to
> use all CPU Cores (new DUGL is up to 300% faster thanks to rendering with 4
> cores), maybe also a better HDD/SATA/SSD drivers that bring full speed ..
> Well that's not going to be easy, but I'm here to contribute as much as I
> can, and without a doubt this is a long term hobby

I agree. DOS is going to become more and more powerful in a world of bloat and abstraction layers and walled gardens. What we also need is a "universal" vBIOS which fixes broken vBIOSes on cripped "newer" systems, such as from 2010-2019. Like VSBHDA, but for modern onboard video. The project Scitech Univibe 25 years ago was the idea. But it died on the vine in 1998 before onboard video became popular and Intel started chopping away at low-resolution VGA and proper VESA support (eg, 15-bit and 16-bit modes and low-resolution VESA support). This in tandem with CSMWrap and a solution of running 16-bit legacy code in post-2020 systems.

Supporting SMP in DOS is difficult, but will become necessary since most modern CPUs do not have strong single-core performance relative to the 2005-2010 timeframe when things were more optimized and single-core clockrates were higher.

> Are you aware of the DOS Diablo port?
>
> https://www.bttr-software.de/forum/forum_entry.php?id=22726
>
> This has some or all of an SDL port to DOS, I think. But not SDL2. It
> worked for me, but brightness / gamma is screwed up (too low).
>

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)

> I agree. DOS is going to become more and more powerful in a world of bloat
> and abstraction layers and walled gardens. What we also need is a
> "universal" vBIOS which fixes broken vBIOSes on cripped "newer" systems,
> such as from 2010-2019. Like VSBHDA, but for modern onboard video. The
> project Scitech Univibe 25 years ago was the idea. But it died on the vine
> in 1998 before onboard video became popular and Intel started chopping away
> at low-resolution VGA and proper VESA support (eg, 15-bit and 16-bit modes
> and low-resolution VESA support). This in tandem with CSMWrap and a
> solution of running 16-bit legacy code in post-2020 systems.

Maybe CSMWrap project could implement a good VESA BIOS using UEFI

>
> Supporting SMP in DOS is difficult, but will become necessary since most
> modern CPUs do not have strong single-core performance relative to the
> 2005-2010 timeframe when things were more optimized and single-core
> clockrates were higher.

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.

Hi! Thanks for working on DUGL

> 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 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.

---
FreeDOS / DOSEMU2 / ...

> 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.

> 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 ?

>
> 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.

> 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.

> 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.

> 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 ?

> > 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.

> 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.

> 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.

> 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.

> 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.

> 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.

> 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'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

> 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.

> 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.

>
> 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;

> > 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.

> 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!

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

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

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

> 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.

> 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

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 !

> 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.

> 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 ?) ..

> 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.

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

> 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.

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)

> 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
> >
>
> 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)

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.

> 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).

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.

>
> 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.

> 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.

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.

> 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.

> 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].

> 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

> 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.