DOS ain't dead

FFK

12.08.2009, 12:58
(edited by FFK, 12.08.2009, 16:28)

DUGL 1.15 + DUGL Plus 0.3 (Announce)

I wanted to announce here before updating my ugly website :-P

Mainly DUGL 1.15 Add transparency functions ..
DUGL PLus 0.3 Add GUI support for 16bpp graphics + many bug fixes + two new GUI objects + sound blaster pro sound driver
I added two samples "sound" a very simple demo of the DUGL sound API
and "trans16" a very simple demo of the new transparency function
I also opened the ugly sources of the tool EdCHR the editor of the DUGL font format.

Here a link to a full package 3.5MB with DUGL 1.15 + DUGL Plus 0.3 + demos + tools + application

http://www.hotlinkfiles.com/files/2739171_zkzge/DGL115P3.zip]DGL115P3.zip

I'm waiting for feedbacks :-)
Enjoy!

Rugxulo

Usono,
12.08.2009, 17:30

@ FFK

DUGL 1.15 + DUGL Plus 0.3

Post reply

> I wanted to announce here before updating my ugly website :-P
>
> Mainly DUGL 1.15 Add transparency functions ..
> DUGL PLus 0.3 Add GUI support for 16bpp graphics + many bug fixes + two
> new GUI objects + sound blaster pro sound driver
> I added two samples "sound" a very simple demo of the DUGL sound API
> and "trans16" a very simple demo of the new transparency function
> I also opened the ugly sources of the tool EdCHR the editor of the DUGL
> font format.
>
> Here a link to a full package 3.5MB with DUGL 1.15 + DUGL Plus 0.3 + demos
> + tools + application
>
> http://www.hotlinkfiles.com/files/2739171_zkzge/DGL115P3.zip]DGL115P3.zip

(downloaded)

> I'm waiting for feedbacks :-)
> Enjoy!

This probably isn't the feedback you wanted, but ...

I've been playing a lot of FreeDoom lately, and all the DOS ports of Boom-compatible engines are old and bitrotted, hard to compile, buggy, etc. They all use Allegro (except one), and Allegro 4.22 (last DOS version before DOS support was dropped) is buggy as hell, many regressions (pat2dat, packed files, SB 2.0 mixing). Most of them use older Allegro 3.12, which works okay (patches.dat, vbeaf.drv), e.g. on my P166 (ATI Mach64 1 MB VRAM, AWE64) or DOSBox.

In short, DUGL is a games lib, no? So it could probably be used instead. Not that I'm volunteering, mind you, but it should be possible and probably is a good idea. I mean, it can't be that hard. :-)

FFK

13.08.2009, 14:37

@ Rugxulo

DUGL and FreeDoom

Post reply

> I've been playing a lot of FreeDoom
> lately, and all the DOS ports of Boom-compatible engines are old and
> bitrotted, hard to compile, buggy, etc. They all use Allegro (except one),
> and Allegro 4.22 (last DOS version before DOS support was dropped) is buggy
> as hell, many regressions (pat2dat, packed files, SB 2.0 mixing). Most of
> them use older Allegro 3.12, which works okay (patches.dat, vbeaf.drv),
> e.g. on my P166 (ATI Mach64 1 MB VRAM, AWE64) or DOSBox.
>
> In short, DUGL is a games lib, no? So it could probably be used instead.
> Not that I'm volunteering, mind you, but it should be possible and
> probably is a good idea. I mean, it can't be that hard. :-)

Yes DUGL is a games lib, but no game was released yet using it :-D
I started working on a 2D game, but it will take time as i don't want to reproduce what was already done on the past.
I made look to the source code of FreeDoom yesterday, and i think that we need
a volunteer that have good knowledge of the source code. And he will be helped by me. We need a list of graphic functions needed by FreeDoom and see if DUGL is able to provide them all.
By first look DUGL is missing :
- Perspective corrected texture mapping : solution is to split near/big triangles into several triangles to reduce the bad effect.
- Texture wrapping : we have two solutions, make bigger textures with replicated image, or again detect texture wrapping and split the triangle into several triangles.
- VGA : not all VESA give access to low resolution graphic mode (320x200..)
I'm not sure if freedom require low res mode, but if so we need to emulate them, by rendering to small RAM Surf and then resizing into 640x400 or so.
- Sound : What are the sound requirement of FreeDoom ? Currently only SB16 and SBPro are supported, does this cover enough PC ? each driver has an internal mixer capable of mixing up to 32 voice, i guess enough ?

Now come the legal issue. As DUGL is a free but not GPL and closed source. Can we use it into a GPL software ? maybe it's covered by the the system library exception ?

By the way i'm curious to know how much fps you get with "fog16" demo on your
P166 (ATI Mach64 1 MB VRAM, AWE64) :-D does the sound work for you ?

Rugxulo

Usono,
15.09.2009, 10:48

@ FFK

DUGL and FreeDoom

Post reply

Sorry for not replying to this post directly, I must've missed it!!

> > I've been playing a lot of FreeDoom
> > lately, and all the DOS ports of Boom-compatible engines are old and
> > bitrotted, hard to compile, buggy, etc. They all use Allegro (except
> one),
> > and Allegro 4.22 (last DOS version before DOS support was dropped) is
> buggy
> > as hell, many regressions (pat2dat, packed files, SB 2.0 mixing). Most
> of
> > them use older Allegro 3.12, which works okay (patches.dat, vbeaf.drv),
> > e.g. on my P166 (ATI Mach64 1 MB VRAM, AWE64) or DOSBox.
> >
> > In short, DUGL is a games lib, no? So it could probably be used
> instead.
> > Not that I'm volunteering, mind you, but it should be possible and
> > probably is a good idea. I mean, it can't be that hard. :-)
>
> Yes DUGL is a games lib, but no game was released yet using it :-D
> I started working on a 2D game, but it will take time as i don't want to
> reproduce what was already done on the past.

Perhaps something simple at first?

> I made look to the source code of FreeDoom yesterday, and i think that we
> need
> a volunteer that have good knowledge of the source code. And he will be
> helped by me.

James "Quasar" Haley (Eternity co-maintainer) would probably help, but he rewrote the backend, so it hasn't compiled on DOS/Allegro since r94? (2006?) or so.

> We need a list of graphic functions needed by FreeDoom and
> see if DUGL is able to provide them all.
> By first look DUGL is missing :
> - Perspective corrected texture mapping : solution is to split near/big
> triangles into several triangles to reduce the bad effect.
> - Texture wrapping : we have two solutions, make bigger textures with
> replicated image, or again detect texture wrapping and split the triangle
> into several triangles.
> - VGA : not all VESA give access to low resolution graphic mode
> (320x200..)

Really? :no:

> I'm not sure if freedom require low res mode, but if so we need to emulate
> them, by rendering to small RAM Surf and then resizing into 640x400 or so.

I don't know exactly if original Doom was 320x200 only, but almost all the modified Doom ports support higher resolutions (e.g. Eternity 640x400, even pageflipped) but only with VBEAF.DRV on my Mach64 (probably due to old VESA 1.2 support only).

> - Sound : What are the sound requirement of FreeDoom ? Currently only SB16
> and SBPro are supported, does this cover enough PC ? each driver has an
> internal mixer capable of mixing up to 32 voice, i guess enough ?

Yes, that should be plenty good enough. Doom was originally able to even run on old 386s, I think, so it should support old hardware. (CDoom is really fast but seems 320x200 only, no Allegro, uses MusLib.) Of course, FreeDoom needs a Boom-compatible port, most of which are buggy, hence I suggest Eternity although 3.31b7 still used old Allegro 3.0 (patches.dat only, no vbeaf.drv support, needs recompile with 3.12).

> Now come the legal issue. As DUGL is a free but not GPL and closed source.
> Can we use it into a GPL software ? maybe it's covered by the the system
> library exception ?

Yes, I forgot about that, but actually the "original" (pre-1999 re-release) of DOOM was non-commercial only, not GPL, and I think some rare projects (ZDoom???) still use that (for whatever reason).

> By the way i'm curious to know how much fps you get with "fog16" demo on
> your P166 (ATI Mach64 1 MB VRAM, AWE64) :-D does the sound work for you ?

I think I tried and failed due to no MMX. Adlib seems to require some initialization but pure wave sounds work fine. For FreeDoom I think I get about 20 fps on average. (Although ironically I still don't get full speed of Atari800 [recently updated] but fairly close with "improved Pokey sound" turned off. Annoying that I can't even emulate such a weak cpu on such a "powerful" machine as a P166, oh well. :rotfl: ).

FFK

17.09.2009, 04:25

@ Rugxulo

DUGL and FreeDoom

Post reply

> Perhaps something simple at first?

You are right DUGL require at least a simple game.

> > We need a list of graphic functions needed by FreeDoom and
> > see if DUGL is able to provide them all.
> > By first look DUGL is missing :
> > - Perspective corrected texture mapping : solution is to split near/big
> > triangles into several triangles to reduce the bad effect.
> > - Texture wrapping : we have two solutions, make bigger textures with
> > replicated image, or again detect texture wrapping and split the
> triangle
> > into several triangles.
> > - VGA : not all VESA give access to low resolution graphic mode
> > (320x200..)
>
> Really? :no:

Here my reasons :
- Perspective corrected texture mapping :
Current algorithm of Perspective corrected are at best only 50% as fast as linear mapping.
This mean for example a bandwidth drop from 0.4GB/s to 0.2GB/s on my P4 D925.
If we take in account that inside a 3D Scene, only about 5-10% of triangles really require a perspective corrected mapping. I will choose the linear mapping, and split big/near triangles as said up.
- Texture wrapping :
It's a symbol of bad looking walls, terrain, water .. As the user can easily distinguish the repeated texture.
In fact when I started working on DUGL I got two choices : (1) supporting texture wrapping but only pow of 2 textures resolution (2) not supporting texture wrapping but any texture resolution. I choosed the second as it gives much more flexibility/speed for textured triangles (using a 640x480 screen directly as texture, optimized texture memory usage...)
- VGA :
Who want to play a game in 320x240 in 2009 ? Unless we make, as SONY PSP, a DPGS (DOS Portable Games Station) with a 320x240 LCD maybe powered by both FreeDOS and DUGL :hungry:
Any way emulating low res mode isn't hard as we can emulate them easily with the fast DUGL texture mapping.

> Yes, I forgot about that, but actually the "original" (pre-1999
> re-release) of DOOM was non-commercial only, not GPL, and I think some
> rare projects (ZDoom???) still use that (for whatever reason).

I downloaded ZDoom sources and I will see what I can do. And yes it's license is non-profit as DUGL, then usable.

Khusraw

Bucharest, Romania,
12.08.2009, 23:12

@ FFK

DUGL 1.15 + DUGL Plus 0.3

Post reply

> I'm waiting for feedbacks :-)

Great work indeed. Keep it high! If you need help for the non-implemented features we both know, please ask.

---
Glory to God for all things

FFK

13.08.2009, 15:16

@ Khusraw

DUGL 1.15 + DUGL Plus 0.3

Post reply

> Great work indeed. Keep it high!

thanks :-)

> If you need help for the non-implemented features we both know, please ask.

A game library is a never ending project there is always missing features.
But mainly DUGL miss :

- SOUND : I designed sound driver based on my knowledge of ISA sound cards,
is this design enough good for PCI sound cards ? If so we need volunteer to
implement drivers. Maybe i have to learn PCI then implement a first clean/well commented PCI sound driver. Then it will be easier for others to add more driver.
- JOYSTICK : currently there is no support of joystick at all.
- FILES packaging : as the allegro DAT, to store the resources needed for a game on a single FILE, maybe they can be also protected by a password.
- IMAGE : PNG, animated/entralaced GIF, ..
- FONT : Currently DUGL support only an own bitmapped font format. What would be the best choice for a free font format ? (CPI, TTF, FNT ..) I'm willing to write an importer to convert the chosen format to the internal bitmapped DUGL format.
- ...

Laaca

Czech republic,
14.08.2009, 13:45

@ FFK

DUGL 1.15 + DUGL Plus 0.3

Post reply

From the begining of your project I was quite skeptic about DUGL.
But now when it has so many features I am really impressed. Good work.
If I would be a C programmer I would prefer it over allegro.
About topics you mentioned:

Joystick: not needed. Only few people use joysticks. Only for few specializated genres are still popular but generaly are obsoleted by mouse

Files packaging: In my Freepascal projects I started to use .GRP format used in games like Duke3D, Blood, etc. It is extremely simple and described on pages of Ken Silverman, author of the Build engine:
http://advsys.net/ken/build.htm (search "What is .GRP file format")

Images: as DUGL supports 16 bits modes it also should support some decent compressed HiColor (Truecolor) image format. PCXs are problematic, JPEGs not good for all purposes, so you should support at least some subformats of TIFFs or PNGs.
Supports of transparent and animated GIFs would be cool.
I would be espetially appreciated if you write a simple tool which displays .GIF and interactively let you choose color for transparention. And then saves it as a transparent GIF. I painful miss such program in DOS.

Fonts: you should definitely support some common bitmap font. The CPI files are OK, FNT files too. Much more complicated are vector fonts. At least .TTF fonts are extremely complicated. But you could try to add support for .CHR fonts from Borland.

Sound cards and graphics acceleration: The best solution is to use an external modules. I strongly advocate to adapt sound interface from Miles sound system because it allows to use lot of existing sound drivers and opens a possibility for adding a new drivers. Alternative could be the use of sound drivers from Quick view.
It would be cool if you could add the support of use the VESA AF drivers used in allegro via VBEAF.DRV file.
http://www.talula.demon.co.uk/freebe/
I looked into loader code in Allegro and it seems to be quite simple.

And it would be cool to modify some existing Allegro game into DUGL. Like DOOM which was already mentioned.

---
DOS-u-akbar!

FFK

15.08.2009, 15:07

@ Laaca

DUGL roadmap

Post reply

> Joystick: not needed. Only few people use joysticks. Only for few
> specializated genres are still popular but generaly are obsoleted by
> mouse

I think you are right. This is low priority missing features.

> Files packaging: In my Freepascal projects I started to use .GRP format
> used in games like Duke3D, Blood, etc. It is extremely simple and
> described on pages of Ken Silverman, author of the Build engine:
> http://advsys.net/ken/build.htm (search "What is .GRP file
> format")

Will see

> Images: as DUGL supports 16 bits modes it also should support some decent
> compressed HiColor (Truecolor) image format. PCXs are problematic, JPEGs
> not good for all purposes, so you should support at least some subformats
> of TIFFs or PNGs.

DUGL is able to load 24bpp BMP files but they are directly converted to 16bpp.
DUGL Plus is also able to load JPEG using libjpeg but also converted to 16bpp.
Will use more open source library with DUGL PLus to add more image format support.

> Supports of transparent and animated GIFs would be cool.
> I would be espetially appreciated if you write a simple tool which
> displays .GIF and interactively let you choose color for transparention.
> And then saves it as a transparent GIF. I painful miss such program in
> DOS.

256 colors paletted GIF ? this is currently the only supported by the DUGL gif loader.

> Fonts: you should definitely support some common bitmap font. The CPI
> files are OK, FNT files too. Much more complicated are vector fonts. At
> least .TTF fonts are extremely complicated. But you could try to add
> support for .CHR fonts from Borland.

CPI and FNT are mostly easy. For TTF i think that i have to use an open source library to be able to import it.

> Sound cards and graphics acceleration: The best solution is to use an
> external modules. I strongly advocate to adapt sound interface from Miles
> sound system because it allows to use lot of existing sound drivers and
> opens a possibility for adding a new drivers. Alternative could be the use
> of sound drivers from Quick view.
> It would be cool if you could add the support of use the VESA AF drivers
> used in allegro via VBEAF.DRV file.
> http://www.talula.demon.co.uk/freebe/
> I looked into loader code in Allegro and it seems to be quite simple.

I think that we don't need much graphic acceleration, as they are fixed,
consume VRAM(slow in modification), reduce DUGL flexibility and the most important is that DUGL is enough fast for most needs. For example on my P4 dual core D925, 3GHz, DUGL Player show some 1200fps with smooth disabled when playing an mpg video. The new transparency functions show a bandwith RAM to RAM of some 400 Millions pixels/sec, ... The only case that will make you feel slow is when you use/try a function that need to read from VRAM. And this is why i dropped on all my new demos any direct VRAM rendering. I render to a RAM Surf, when every thing done, I copy it to VRAM.

I'm not sure about the architecture of all the existing sound driver. But i'm guessing that with some modifications the sound driver format i designed is superior and faster :-D ok internal mixer isn't great and very primitive, but he can be enhanced.
BTW, The sound drivers that seem interesting for me are the "Quick view" sound driver, but i don't see any docs neither library how to use them.

> And it would be cool to modify some existing Allegro game into DUGL. Like
> DOOM which was already mentioned.

Will see ? Any suggestion ?

BTW DUGL website updated :-)

Laaca

Czech republic,
15.08.2009, 21:06

@ FFK

DUGL roadmap

Post reply

> BTW, The sound drivers that seem interesting for me are the "Quick view"
> sound driver, but i don't see any docs neither library how to use them.

Approximately two years ago Alex Hint (author os these drivers) sent me a source of SBLive! driver.
I uploaded it here:
http://www.laaca.borec.cz/emu10k1.zip

I hope it helps you. You can also contact Wolfgang Hesseler, author of Quick view - he will send you the API description.

---
DOS-u-akbar!

FFK

15.09.2009, 00:58

@ Laaca

DUGL Sound drivers

Post reply

> I hope it helps you. You can also contact Wolfgang Hesseler, author of
> Quick view - he will send you the API description.

Thanks. I finally decided to develop sound drivers with DUGL sound driver format. Maybe I'm reinventing the wheel or wasting time But I think that DOS still miss a good Sound drivers API/FORMAT. I hope that this format will succeed :-)
I'm now on my way working on an AC97 driver maybe at 30%.
Once done I'm planning CMI, intel HDA and more ...

RayeR

CZ,
23.10.2009, 17:50

@ FFK

DUGL Sound drivers

Post reply

> Thanks. I finally decided to develop sound drivers with DUGL sound driver
> format. Maybe I'm reinventing the wheel or wasting time But I think that
> DOS still miss a good Sound drivers API/FORMAT. I hope that this format
> will succeed :-)
> I'm now on my way working on an AC97 driver maybe at 30%.
> Once done I'm planning CMI, intel HDA and more ...

And will be the driver interface freely available? Would be possible to use it from other progs without using DUGL? I would like to test SB live driver if something will be available. BTW MPxplay contains many soundcards drivers, sources are available for watcom...

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

Khusraw

Bucharest, Romania,
23.10.2009, 18:50
(edited by Khusraw, 24.10.2009, 03:13)

@ RayeR

DUGL Sound drivers

Post reply

> And will be the driver interface freely available? Would be possible to
> use it from other progs without using DUGL? I would like to test SB live
> driver if something will be available. BTW MPxplay contains many
> soundcards drivers, sources are available for watcom...

OSS is another great source of information, and its drivers could be ported with some efforts on DOS. Michael Kostylev managed to do such a thing. But few people have his interest and his disposition to consume time on such things.

---
Glory to God for all things

DOS386

24.10.2009, 03:31

@ Khusraw

TIFF | DUGL Sound drivers

Post reply

Khusraw wrote:

> > TIFF is very complicated and messy, and useful in very rare cases only,
> TIFF isn't complicated or messy

It IS.

> and is very useful, but not in a game programming library.

It is useful when you badly need non-RGB colorspaces or multipage stuff. ;-)

> PCX problematic?? I thought those were really simple

YES, but poorly designed and poor compression, no trans, simply obsolete.

> wouldn't exactly call PNG too simplistic myself, but at least we have ZLIB for it.

It isn't simplistic, but it isn't more "messy" than necessary to get the required features.

> SEE (written in XPL0) can also show animated GIFs and is open source.

And Arachne can display AGIF also, still, the "decode and drop onto a Surf" concept can't be used for AGIF nor APNG.

> "Windows 7 needs 1 gigabyte (GB) RAM (32-bit) or 2 GB RAM (64-bit) and
> 16 GB available hard disk space (32-bit) or 20 GB (64-bit)

Thanks, I didn't test myself :-D

RayeR wrote:

> And will be the driver interface freely available?

It might be open source, this doesn't mean that FFK will supply a high quality manual also, as you night have noticed, writing English text is not something he would love to do or be expert in.

> Would be possible to use it from other progs without using DUGL?

Sure (?) :-) . AFAIK the ISA drivers don't really depend on anything, so the PCI drivers won't I hope. Especially, I would like to have dependence on DGJPP and DPMI avoided.

> drivers could be ported with some efforts on DOS. Michael Kostylev
> managed to do such a thing.

What thing ? He ported some FFMPEG derivatives and some more app stuff, but no drivers AFAIK.

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

Khusraw

Bucharest, Romania,
24.10.2009, 09:41
(edited by Khusraw, 24.10.2009, 15:38)

@ DOS386

TIFF | DUGL Sound drivers

Post reply

> What thing ? He ported some FFMPEG derivatives and some more app stuff,
> but no drivers AFAIK.

He ported OSS, but has no intention to make it publicly available, as too much publicity gives a lot of trouble with the dummies, he thinks. So he will keep it "offline".

---
Glory to God for all things

Rugxulo Usono, 24.10.2009, 15:23 @ Khusraw	TIFF \| DUGL Sound drivers Post reply
	> > What thing ? He ported some FFMPEG derivatives and some more app stuff, > > but no drivers AFAIK. > > He ported OSS, but has no > intention to make it publicly available, as too much pulicity gives a lot > of trouble with the dummies, he thinks. So he will keep it "offline". God, forgive us our trespasses, as we forgive those who trespass against us ...

Rugxulo Usono, 24.10.2009, 15:18 @ DOS386	TIFF \| DUGL Sound drivers Post reply
	> > "Windows 7 needs 1 gigabyte (GB) RAM (32-bit) or 2 GB RAM (64-bit) and > > 16 GB available hard disk space (32-bit) or 20 GB (64-bit) > > Thanks, I didn't test myself Me either, but that's what they claim. Kinda enormous! Why oh why?? (Even Mac OS X no longer includes all printer drivers by default.)

FFK

24.10.2009, 19:22

@ DOS386

TIFF | DUGL Sound drivers

Post reply

> > Would be possible to use it from other progs without using DUGL?
>
> Sure (?) :-) . AFAIK the ISA drivers don't really depend on anything, so
> the PCI drivers won't I hope. Especially, I would like to have dependence
> on DGJPP and DPMI avoided.

There is no dependency in DJGPP but DPMI dependency can't be avoided. As the driver require an API to lock/unlock memory, allocate/free DOS memory, install/uninstall Interrupt handler ....

DOS386

30.10.2009, 06:45

@ FFK

DUGL Sound drivers

Post reply

> There is no dependency in DJGPP but DPMI dependency can't be avoided. As
> the driver require an API to lock/unlock memory, allocate/free DOS memory,
> install/uninstall Interrupt handler ....

- Lock/Unlock is a problem specific to DGJPP & CWSDPMI ;-)
- DOS low memory ... OK
- Interrupt ... OK
it it all ???

Still, the dependency could be minimalized ;-)

> Planned sound card are AC'97, HD

What is HD ??? Intel HDA AKA ICH8 and above?

> I'm open for discussion about this driver format license

???

> If some one want to contribute.
> I'm just not thinking about GPL/LGPL as they force to release source code.

GPF is for code, not for format spec. So you can set the format spec license to public domain, optionally reserving the right to personally control the "official" spec.

Also, a GPL'ed driver wouldn't infect the spec nor other drivers following the same spec, however it could conflict with DUGL core.

So a BSD license would be a good choice for the driver code.

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

Khusraw

Bucharest, Romania,
30.10.2009, 14:11
(edited by Khusraw, 31.10.2009, 12:03)

@ DOS386

DUGL Sound drivers

Post reply

> - Lock/Unlock is a problem specific to DGJPP & CWSDPMI ;-)

CWSDPMI is not the only DPMI host with virtual memory support and the "-s-" switch disables virtual memory support in CWSDPMI.

---
Glory to God for all things

ecm

Düsseldorf, Germany,
30.10.2009, 14:25

@ Khusraw

DUGL Sound drivers

Post reply

> > - Lock/Unlock is a problem specific to DGJPP & CWSDPMI ;-)
>
> CWSDPMI is not the only DPMI host with virtual memory support

For example, HDPMI allows a program to provide virtual memory when the necessary exceptions are handled by the program.

---
l

FFK

31.10.2009, 11:04

@ DOS386

DUGL Sound drivers

Post reply

> - Lock/Unlock is a problem specific to DGJPP & CWSDPMI ;-)
> - DOS low memory ... OK
> - Interrupt ... OK
> it it all ???

The lock/unlock is a problem specific to virtual memory.
So to be safe it will be better to lock memory.
There is also the DPMI function get segment base address.

> Still, the dependency could be minimalized ;-)
>
> > Planned sound card are AC'97, HD
>
> What is HD ??? Intel HDA AKA ICH8 and above?

yes intel HDA :-) but seems that all HD sound cards are similar. not sure!

> > I'm open for discussion about this driver format license
>
> ???

Yes as making sound driver is not a task for one man :) so without contributers for testing and maybe also for coding it will take years to get
all the needed sound drivers.

> Also, a GPL'ed driver wouldn't infect the spec nor other drivers following
> the same spec, however it could conflict with DUGL core.
>
> So a BSD license would be a good choice for the driver code.

I don't really have a good idea about several license kinds.

A good license for me will :
1 - Encourage more developers testers to contribute without losing their rights about the contributions they made.
2 - Keep rights over the format spec and source code. So no one will come in future and pretend that he patented the format, or that he own the source code or part of it.

Here the DUGL Plus license :

1 -

THIS SOFTWARE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND EITHER
EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE IMPLIED
WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.

2 -

THE Author of DUGLPLUS grants you a non-exclusive, royalty-free right
to use, reuse, redistribute the Software, and all it's sources if you :

. Do not pretend that you made it.

. Acknowledge somewhere in your documentation and or website
that you have used the DUGLPLUS sources.

. Use it to develop a DOS and compatible operating systems based software.

end of license.

So is this license enough for what I want ?

FFK

24.10.2009, 14:01

@ RayeR

DUGL Sound drivers

Post reply

> And will be the driver interface freely available? Would be possible to
> use it from other progs without using DUGL?

Yes they are freely available for any purpose/ and open for contribution. You have just to tell that you used them.
They can be used in any plateform/langage as :
- DPMI 0.9 service available
- CPU is in 32bits Protected mode
- 486 CPU or more

driver don't care about stack / segment descriptor / ... the calling program will be responsible of that.

> I would like to test SB live
> driver if something will be available. BTW MPxplay contains many
> soundcards drivers, sources are available for watcom...

Planned sound card are AC'97, HD, and a CMI currently (this is what i have). So until I have an SBLIve card or maybe if you want to be bothered testing highly alpha drivers !
I'm open for discussion about this driver format license If some one want to contribute. I'm just not thinking about GPL/LGPL as they force to release source code. Maybe a hardware constructor will one day want to release a DOS driver with this format using existing source and he don't want to reveal his secrets :-D

Rugxulo

Usono,
24.10.2009, 15:22

@ FFK

DUGL Sound drivers

Post reply

> >
> > And will be the driver interface freely available? Would be possible to
> > use it from other progs without using DUGL?
>
> Yes they are freely available for any purpose/ and open for contribution.
> You have just to tell that you used them.
> They can be used in any plateform/langage as :
> - DPMI 0.9 service available
> - CPU is in 32bits Protected mode
> - 486 CPU or more

Why 486? There's very little difference between the 486 instructions and 386. Maybe you mean FPU required? (Surely I personally wouldn't require a 486 just for BSWAP, XADD, or CMPXCHG.)

FFK

24.10.2009, 17:42

@ Rugxulo

DUGL Sound drivers

Post reply

> Why 486? There's very little difference between the 486 instructions and
> 386. Maybe you mean FPU required? (Surely I personally wouldn't require a
> 486 just for BSWAP, XADD, or CMPXCHG.)

There is theoretically no problem to run on a 386, as there is no usage of FPU or special 486 instruction. But as 486 is the oldest CPU where some one reported to me that it worked there (i remember that it was you), I'm saying 486.

RayeR

CZ,
25.10.2009, 01:48

@ FFK

DUGL Sound drivers

Post reply

> Planned sound card are AC'97, HD, and a CMI currently (this is what i
> have). So until I have an SBLIve card or maybe if you want to be bothered
> testing highly alpha drivers !

I don't remember exactly but maybe Japhet said that SB live is kinda AC'97 hardware sot it may work. But I don't know near anything about modern sound hardware so I don't know what the AC'97 standard defines to a programmer...

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

DOS386

23.10.2009, 05:36

@ Laaca

DUGL roadmap | TIFF vs PNG | emu10k1

Post reply

Laaca wrote:

> Images: as DUGL supports 16 bits modes it also should support some
> decent compressed HiColor (Truecolor) image format.

YES.

> PCXs are problematic, JPEGs not good for all purposes, so you
> should support at least some subformats of TIFFs or PNGs.

TIFF is very complicated and messy, and useful in very rare cases only,
no PNG is much better here.

> Supports of transparent and animated GIFs would be cool.

There is little use for AGIF in a library, and it would be difficult to implement,
since "displaying" an AGIF would mean "playing", thus something would have
to "run" all the time. LXPIC and DISPLAY already can play AGIF.

> would be espetially appreciated if you write a simple tool which
> displays .GIF and interactively let you choose color for transparention.
> And then saves it as a transparent GIF. I painful miss such program in DOS.

Same (or even more ?) for PNG.

> > BTW, The sound drivers that seem interesting for me are the "Quick view"
> > sound driver, but i don't see any docs neither library how to use them.
> Approximately two years ago

maybe 4 ?

> Alex Hint (author os these drivers) sent me a source of SBLive! driver.
> I uploaded it here: http://www.laaca.borec.cz/emu10k1.zip

COOL.

> I hope it helps you. You can also contact Wolfgang Hesseler, author of
> Quick view - he will send you the API description.

:-)

EMU10K1.ASM 15'273 2003-05-11 D.BAT 192 2003-05-11 IO.C 23'031 2003-05-11 EMU10K1.H 29'142 2003-05-11 EMU10K1.INC 13'331 2003-05-07 VOLUME.INC 1'296 2003-01-06 EMU10K1.SDR 12'288 2003-05-11

@TASM32 emu10k1.ASM /M /zd /mx @bcc32 -c IO.C @TLINK32 -Af:0x10 EMU10K1.OBJ IO.OBJ

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

Khusraw

Bucharest, Romania,
23.10.2009, 09:34

@ DOS386

DUGL roadmap | TIFF vs PNG | emu10k1

Post reply

> TIFF is very complicated and messy, and useful in very rare cases only,
> no PNG is much better here.

TIFF isn't complicated or messy and is very useful, but not in a game programming library.

> There is little use for AGIF in a library, and it would be
> difficult to implement,
> since "displaying" an AGIF would mean "playing", thus something would
> have to "run" all the time.

?!

---
Glory to God for all things

Rugxulo

Usono,
23.10.2009, 09:51

@ DOS386

DUGL roadmap | TIFF vs PNG | emu10k1

Post reply

> > PCXs are problematic, JPEGs not good for all purposes, so you
> > should support at least some subformats of TIFFs or PNGs.
>
> TIFF is very complicated and messy, and useful in very rare cases only,
> no PNG is much better here.

PCX problematic?? I thought those were really simple (ignoring the optional RLE part). I also wouldn't exactly call PNG too simplistic myself, but at least we have ZLIB for it.

> > Supports of transparent and animated GIFs would be cool.
>
> There is little use for AGIF in a library, and it would be
> difficult to implement,
> since "displaying" an AGIF would mean "playing", thus something would
> have
> to "run" all the time. LXPIC and DISPLAY already can play AGIF.

SEE (written in XPL0) can also show animated GIFs and is open source.

P.S. to DOS386:

A: Got one VS 2008 license, paid 2'000 $ , installed on my PC, and it filled 8 GiB of my HD !
B: Got 2000 FASM licenses + 2000 CC386 licenses , installed all on one PC, filled 8 GiB of my HD, and all for free !!!

You might want to change that now that Windows 7 is out:

"Windows 7 needs 1 gigabyte (GB) RAM (32-bit) or 2 GB RAM (64-bit) and 16 GB
available hard disk space (32-bit) or 20 GB (64-bit)

Windows XP Mode (available in Windows 7 Pro editions only) requires an
additional 1 GB of RAM, an additional 15 GB of available hard disk space,
and a processor capable of hardware virtualization with Intel VT or AMD-V
turned on" :surprised:

FFK 15.09.2009, 00:46 @ FFK	DUGL 1.15 + DUGL Plus 0.3 update download link Post reply
	new download link as the last one is now dead DGL115P3.ZIP 3.4MB

DUGL 1.15 + DUGL Plus 0.3 (Announce)

DUGL 1.15 + DUGL Plus 0.3

DUGL and FreeDoom

DUGL and FreeDoom

DUGL and FreeDoom

DUGL 1.15 + DUGL Plus 0.3

DUGL 1.15 + DUGL Plus 0.3

DUGL 1.15 + DUGL Plus 0.3

DUGL roadmap

DUGL roadmap

DUGL Sound drivers

DUGL Sound drivers

DUGL Sound drivers

TIFF | DUGL Sound drivers

TIFF | DUGL Sound drivers

TIFF | DUGL Sound drivers

TIFF | DUGL Sound drivers

TIFF | DUGL Sound drivers

DUGL Sound drivers

DUGL Sound drivers

DUGL Sound drivers

DUGL Sound drivers

DUGL Sound drivers

DUGL Sound drivers

DUGL Sound drivers

DUGL Sound drivers

DUGL roadmap | TIFF vs PNG | emu10k1

DUGL roadmap | TIFF vs PNG | emu10k1

DUGL roadmap | TIFF vs PNG | emu10k1

DUGL 1.15 + DUGL Plus 0.3 update download link