Main > Software Forum
So What Cause's The Stuttering Sound Problem With DirectDraw??
headkaze:
To continue on from what Howard has been saying... I'm not sure how Mame's video system works exactly but there are ways to get pretty close texel to pixel conversion so it's almost exact (perhaps even per pixel precision). Something to do with the rounding or adding 0.5f, which is because Direct3D works with floating point numbers, surfaces, polys and textures. It is after all a 3D API.
Direct Draw is a depreciated API and is no longer supported by Microsoft. No more releases have been made since Direct Draw 7 I believe. I'm not even sure if the latest versions of the DirectX SDK has Direct Draw in it.
Video card drivers are not optimizing performance for Direct Draw anymore and may eventually remove some functionality for it as time goes on. In fact often you need to revert back to older video card drivers to get better rendering in Direct Draw. This is probably part of the reason for moving Mame to Direct3D in the first place and I think it was a good move.
Again Howard basically explains most of this already, but the Video card is important for Mame even if the CPU is considered more important. You will get sound stuttering using Direct Draw if you have A) Slow CPU B) Bad video driver support for Direct Draw C) Crappy video card such as onboard video D) Other; settings such as VSync, monitor refresh rate, hardware stretch etc. The same can be said for Direct3D. There is no point in moving to it if you have a ---smurfy--- video card with no decent hardware acceleration support.
The sound card on the other hand is much less likely to be the cause. But it doesn't hurt to have a hardware sound card. They are cheap as chips these days for a bottom line card. I just don't think it would make much of a difference though.
MAME TIME:
let me suggest you something, i had the same problem which is now fixed, some of the resolutions in the ini's need to be changed because the monitor is having a hard time putting it out, use the ddraw and tbuffer, turn off hwstretch, and your going to have to try using a lower res 321*240 and so on, the echo will go away, and the games run smoothly. It may take a couple of try's to get the game to display correctly on the screen, Your just going to have to play around with the ini's for each game. It worked for me, K7000 WG monitor
http://www.ultimarc.com/avgainst.html
Howard_Casto:
Ok I've got a dumb question we probably should have asked earlier. Are you using a classic Avga card (based on the 7000) or the newer one? The reason I ask is the 7000 had really bad directdraw/direct 3d support but the newer ones perform much better. You'd have to ask around the ultimarc forums to see if it is a noticable boost though.
MAME TIME:
To be honest i've had both, and i can't really tell if one can out preform the other in mame, for other applications yes, but mame its hard to tell
RandyT:
FWIW, and maybe the only part of this post to be somewhat on-topic, a couple of years back my setup started hiccuping as described. It was driving me nuts. It turned out that a piece of malware had somehow found it's way onto my cabinet (from web surfing most likely). Whatever code it was attempting to execute was hogging processor cycles and doing it at pretty regular intervals. Once I found it and shut it down, everything was smooth again. Probably not related to your problem, but it might be worth a look.
--- Quote from: headkaze on August 10, 2007, 04:33:10 am ---To continue on from what Howard has been saying... I'm not sure how Mame's video system works exactly but there are ways to get pretty close texel to pixel conversion so it's almost exact (perhaps even per pixel precision). Something to do with the rounding or adding 0.5f, which is because Direct3D works with floating point numbers, surfaces, polys and textures. It is after all a 3D API.
--- End quote ---
I wonder about this. Just because MAME may be rendering with sub-pixel precision, it doesn't mean that it can be displayed that way. Moving images like scrolls will be smoother with SPP, but static images will still have some manner of artifacting. As computing power and display resolution continue to advance, it's likely that MAME will be able to evolve into something very interesting down the road. I predict that we will eventually see virtual dot-triads, "monitor emulation" if you will, that will allow 100% original display accuracy on ultra-modern hardware. That will take some horsepower and serious developer dedication to pull off, but should eventually be possible.
At the moment, however, there is a poor fit between the documentation aspect of MAME (perfect 1:1 displays) and the current crop of display technologies, namely digital. Even with conventional high-res computer monitors, some artifacting will probably be present with D3D, because there doesn't currently seem to be a way to prevent it from scaling in a manner that is disproportionate to the display resolution. The recent changes allowing pre-scaling have cut down on the excessive anti-aliasing, which is definitely a step in the right direction. But unless there is a method introduced to prevent artifacting, such as an option to limit the screen "object" to a render size which is the largest exact multiple of the original that can fit to the resolution of the user's display, it's difficult to fathom how DirectDraw can be abandoned. It's hard to stay true to the "documentation" aspects without being able to show a full-screen, full-motion display that doesn't exhibit artifacting.
Understand that I am not a D3D programmer, but I am assuming based on my experience with 3D rendering programs that the game "screen" is a polygon (or two) which is mapped in real-time with the images generated by the graphics engine within MAME. If this is the case, why not allow the user to define the extents of the screen object in order to allow one to shrink or expand the game screen beyond the edges of the display in order to maintain a non-artifacting image.
If I'm all wet on the concept, I'm curious to know why. Otherwise, it seems like simple way to get rid of DirectDraw once and for all. And as a side note, Aaron seems too imply that DirectDraw is faster, particularly on less capable video cards, than D3D. I think the reason it's still around revolves as much on the minimalist hardware approach to machine building as anything else.
RandyT
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version