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 !