> > My should know that my technology is generally better. It uses > > the system of audio drivers, so it allows to do several advantages. > > Better in what sense? WinCoupe uses DirectSound, which uses specific > drivers (usually) written by the sound card manufacturers, so it should give > better support than the general DOS-style drivers. I can't imagine card > coverage isn't really too much of a problem anyway, as most people will have > something that's SB compatible.
No, I meant something different. Dave's emulator creates digital data which can be played on soundcard. This is simple. My emulator has a possibility to have more than one algorithm to create these data to be played, or to access a soundcard directly, regardless it is needed or not. I think the general structure of my emulator is better, but - obviously - Dave's emulator have far better sound output. So I think the best solution is to take Dave's algorithms and incorporate them into my SAAemu. Of course, you don't actually need it, since your computer can simply play the wave data created by existing Dave's emulator (SAAsound library). The thing I would to say (to be short) is that my emulator has some good ideas inside, and you can't compare the two emulators just by the listening to the sound. You know that software is more than the state how users look it, and when we want to make further new versions of that software we must look to how that software is designed. That's it. > > 5. It works with Aztech soundcards. I don't know why you tell that it > > doesn't. You probably misunderstood the documentation. > > The docs say: "Note that SAAemu currently support mixer in SBPro mode only, > so it doesn't work on some Aztech soundcard models." which seemed to > suggest that there'd be a problem with some cards. This is since that "some Aztech" soundcards are sold as soundbalster mono, but they can actually play stereo sound, if you know how to do it. And SAAemu plays stereo on these "mono"-soundcards. The documentations says that these soundcards, although they play stereo like SBPro, haven't got a (volume) mixer, which pleople know from SBPro. The result is that Aztech which are not compatible with SBPro aren't supported. This applies to the volume mixer, not the player. This is obvious, you can use only SB soundcards in DOS (and some others, when you have got the docs). > > Generally, current SAAemu can hardly match SAAsound's quality, > > but it can be enhanced. And that's it. You can say: "Enahance > > it and then I will include it in SimCoupe." But is this right way? > > If it was enhanced for envelope (etc.) support and to work on all platforms > then I feel it'd be a lot more useful and would be worth using it. Without > those I imagine it'd just generate too many support questions and source > code complications. > > Maybe I'm just too much of a perfectionist and don't want to settle for 2nd > best - I want the most accurate and complete emulation possible in every > respect! This is alright. But I surely won't continue work on SAAemu, when it won't be used in the real soft. I accept SAAsound as a good solution (as well as you does). But the things could be even better... > Yes, it uses a finer grained version of the original method, and follows the > raster scan down the display. If you change the palette/border/vmpr as it's > part way through a horizontal scan, the remainder of the line will be drawn > with the new settings (if applicable). It allows fancier effects to be > displayed correctly but is more likely to reveal flicker where the > instruction timings aren't quite correct yet - something the old updating > method masked. > > Data changes (writing to the display memory) are not updated as accurately, > but are still correct for within 1 scanline, so you will still see shearing > if you're updating the display as the raster passes the update position. > Without the current forced update at the end of a line (something I hope to > change for accurate data changes at some point) some demo star-fields are > not visible, as they have already been removed by the time the display is > updated at the end of the frame! I don't understand exactly what is wrong. You say that screen changes are correct within 1 scanline. So why starfields are not visible? Do they use some special timing inside a particular scanline? Imagine the ray is on line 100 and I put on that line something. Then the ray is on line 101 and I delete previous line (#100). What is shown on that line? > It's rather ironic that the machines least likely to have hardware video > assistance will also be the ones with slower CPUs that will struggle more > with software blitting! This is obvious. As far as I know all VLB/PCI/AGP videocards have some acceleration. I played with it when I made some DirectX (2D) games. Since Pentium (and later) mainboards are not based on old ISA, it seems that people with Pentium CPU's have accelerated video cards. (This is not 100%, but is shows you don't need to think much about software-video users.)
