Aley Keprt wrote: > 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. > 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. > 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 clear. I would to know how does it work: > Do you create a whole 320x240 or 640x240 image everytime and then use > blt to put this stuff to videoram? Or do you put there line by line using > separate blt's? It generates the display in a back-buffer line by line, and blits the entire image to the visible display at the end of the frame. The image size is either 320x240 or 640x240 depending on whether the accurate mode3 option is enabled (actually, it's stightly taller now to show more of the vertical border as would see on a real SAM). Of course, if the frame is being skipped it doesn't do any generation or blitting. > Do you emulate on-line video changes? (I mean when the ray > is on line 100 and I change something on line 50, it shouldn't be > visible.) 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! > 2. Windows version is much faster generally since it uses video > acceleration. Video acceleration gives more than anything other can > take. Right? Most modern cards do support it but older and cheaper cards may well not, so they have to fall back to using the DirectX software emulation which is more CPU intensive. The new 5:4 aspect ratio option will be a breeze for system with hardware support or fast processors but will be appallingly slow on older systems! 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! Si
