So What Cause's The Stuttering Sound Problem With DirectDraw??

[lettuce]

What cause's mame's sound to start stuttering every so often if your using 'DirectDraw' and disabled 'Hardware Stretch' and have the following enabled,

Tripplebuffer
Wait On Vsync
Sync to Monitor Fresh

Is it just an error with the mame program, or its it down to system requirements. Would using a decent PCI soundcard and disabling the onboard sound cure the problem, or is it CPU related as doesnt direct draw use more cpu processing power? As i have noticed that when having either Tripplebuffer, wait on vsync or sync to monitor refresh enable seems to hamper the emulation speed.  If you press F11 within a game it shows the speed in the top right corner of the screen and is about 85% with either Tripplebuffer, wait on vsync or sync to monitor refresh enable, turn these off and it stays at 100% so im guessing a better cpu would improve this value? Just seems strange that with hardware stretch and tripplebuffer etc enabled the games run ok, but disable hardware stretch and it doesnt

Edit: Guess i should list my system stats

AMD 64 3400+
1 GB RAM
Onboard Soundcard

[Minwah]

Is it just an error with the mame program, or its it done to system requirements. Would using a decent PCI soundcard and disabling the onboard sound cure the problem

It probably won't cure the problem but it may help to some extent.

If you press F11 within a game it shows the speed in the top right corner of the screen and is about 85% with either Tripplebuffer, wait on vsync or sync to monitor refresh enable, trun these off and it stays at 100% so im guessing a better cpu would improve this value?

All those settings slow things down when enabled, so yes a better CPU would help.  I would go with just triplebuffer, for a comprimise between speed and 'looking nice'.

You could also try some different resolutions and refresh rates.  Make sure the refresh rate of the mode you're using is not less than that of the game - this causes some problems (or used to before the last major video changes).

[lettuce]

All those settings slow things down when enabled, so yes a better CPU would help.

Well the reason i use these settings is because im using a Ultimarc ArcadeVGA card, and thats how you have to set the ini files up to get an authentic arcade look and so the resolutions cant be change either really.

I would go with just triplebuffer, for a comprimise between speed and 'looking nice'.

Yeah i usually just have tripplebuffer enabled as this stops the screen tearing. The games dont slow down though, its just the sound that stutters so im not totally sure what the 85% when pressing F11 represents??

On a side note, just tried a few games on my Main PC (AMD64 X2 4800, Creative soundblaster X-fi  card, 3GB RAM) and they all ran 100% without no sound skipping, but i guess thats to be suspected considering the PC it was running on, still though i would have thought an AMD 64 3400+ and 1GB of RAM would of been plenty too!! So will later version of MAME iron out this problem?

I was just woundering if it was just one component that would fix the problem, and then i would upgrade whatever it was (cpu, soundcard or RAM). For instance i dont really want to spend money on getting a soundcard to find out it hasnt fixed the problem

[8way]

Try an older version of mame, that will solve your problem.

[Howard_Casto]

Try an older version of mame, that will solve your problem.

Actually no it won't.  An older version of mame is a work-around (which btw probably won't help as your processor is plenty fast enough), but not a solution.  You need to tell us which games specifically are giving you issues.  If you are using directdraw instead of direct3d then THAT is your problem most likely as directdraw is much slower.  If your card doesn't support direct3d then it must be the original arcadevga (based on a radeon 7000) and it needs to be upgraded.

See the directdraw code is very inefficient, regardless of the version of mame you are using.  It's a long-standing mame issue and was never really fixed when the new rendering system was put in place either.  That's why I shake my head when people around here still give advice like "it doesn't really matter which video card you use in mame".  Well it didn't (because you got poor performance regardless) but now it does!  My system specs are very similar to yours and with the exception that I use hwstretch, so are my settings.  Look into the things I said and I hope that helps!

[lettuce]

If you are using directdraw instead of direct3d then THAT is your problem most likely as directdraw is much slower.  If your card doesn't support direct3d then it must be the original arcadevga (based on a radeon 7000) and it needs to be upgraded.

I dont use D3D as you not surpossed to with a ArcadeVGA card, as then it doesnt give the correct look of an arcade monitor. This is quoted from Andy's site (ulitmarc)

'MAME Configuration (General)

This step is VITAL. If you do not do this you will not get any of the benefit of the ArcadeVGA card.
By default MAME is configured to stretch and re-process the picture to fit on whatever resolution your PC happens to be running at. YOU DO NOT WANT THIS TO HAPPEN because usign the ArcadeVGA card you can have un-distorted video with a one-to-one pixel mapping.
The basic changes you need to make are:

HARDWARE STRETCH MUST BE OFF
YOU MUST USE DIRECT-DRAW NOT DIRECT3D
SWITCH RESOLUTIONS MUST BE ENABLED

The command-line switches to do this if running Mame from a command line are:
-video ddraw -nohwstretch -switchres'

http://www.ultimarc.com/avgainst.html

Thats the only reason i use Directdraw, otherwise i would use D3D as very thing runs fine with D3D 

You need to tell us which games specifically are giving you issues.

Well every game seems to have a sound stutter problem if i enable triplebuffer, it doesnt stutter constantly though, just now and again, where it stutters once then be fine for 5 or 10 seconds then stutters again, some games are worse than other and stutters once every 3 or 4 seconds, but its NOT constantly stuffering, just now and then!

I just put 2 extra GB's of RAM into my mame PC, and that didnt cure the problem, still stuttered now and again, and still at 85% when pressing F11

[solid187]

Mine started doing this as well.  I think I'm going to go back to .104 and be done with it if I can't get it to run without that intermittent hiccup. 

[lettuce]

So was .104 the last version where the sound doesnt stutter?

[Howard_Casto]

I'm going to have to disagree with andy on this one.  You won't get pixel perfect results but literally as much as it would be off by is one pixel (pixel offset error inherient in d3d which I think is compensated for in mame atm). 
Also you need to set "effect" to none, so you don't get blending effects mucking up the picture.

Those other settings he mentioned are vital, but not so much the d3d/dd setting.

Here's the deal.... when you run dd mame automatically trys to find the best resolution, when you run d3d it does not.  So for a turn key solution you need to run dd. However!  If you manually send a resolution then mame will try to use it, even in d3d mode.  So you can run d3d, you just need to use one of those utilites out there that manually sets all the resolutions in ini files. 

I mean I could be wrong on this, mame's video system is being tweaked all the time, but that was how I understood it to work last time I checked.  Also of course the avga could have some special reason it needs to be turned off I'm not aware of.  All I'm saying is just try it and see what results you get!

[ahofle]

When I first got my arcade monitor hooked up I tried many times to get an accurate picture with D3D (because it was faster and also the 'preferred' renderer) and never had any luck.  I even asked about it on mame.net and Aaron himself said ddraw was the only way to run at native resolutions and avoid any scaling artifacts or antialiasing blurring.  I still don't really understand why that is.

[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.

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.

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

[headkaze]

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.

I have written part of a 2d engine in Direct 3D but I never bothered trying to get per pixel precision so I probably know as much as you do about it. From what I've heard people say there are ways to get that precision. Probably not in every resolution that Mame has to pull off though. Mame would bascially work one of two ways, rendering directly to a surface (most likely) which is locked and the pixels are written directly to video memory or as you say a quad with a texture and locked/written to like the surface. It's never an ideal scenario as Direct3D was never meant to work with pixels, so it wouldn't suprise me if it is slower than DirectDraw in some circumstances. Depends a whole lot on the video card though. Perhaps the future of Mame is to use more of the GPU (pixel shaders) to get the accuracy you mention.

DirectDraw has no future as far as Microsoft is concerned. Even the Vista WPF is based around Direct3D so there is no getting away from it. RIP Real 2d and the pixel?

[lettuce]

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.

Im not 100% sure, i take it it will say it i look in device manager, i got it about a year before Andy bought out the PCI-E version, with the PCI-E and AGP being based on the same GFX card??

In regards to not being able to stop D3D from doing some sort of scaling, have people tried the GDI rendering option within MAME, this seem to give a almost 100% display as DirectDraw, but takes up a bit of GFX and CPU power

[ahofle]

If I'm not mistaken, isn't Aaron Giles building a MAME cabinet?  If so, I think we should all pitch in to buy him a really nice arcade monitor.  I would guess we would then start seeing some serious improvements in pixel accuracy on arcade monitors in MAME. 

[Howard_Casto]

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.

I have written part of a 2d engine in Direct 3D but I never bothered trying to get per pixel precision so I probably know as much as you do about it. From what I've heard people say there are ways to get that precision. Probably not in every resolution that Mame has to pull off though. Mame would bascially work one of two ways, rendering directly to a surface (most likely) which is locked and the pixels are written directly to video memory or as you say a quad with a texture and locked/written to like the surface. It's never an ideal scenario as Direct3D was never meant to work with pixels, so it wouldn't suprise me if it is slower than DirectDraw in some circumstances. Depends a whole lot on the video card though. Perhaps the future of Mame is to use more of the GPU (pixel shaders) to get the accuracy you mention.

DirectDraw has no future as far as Microsoft is concerned. Even the Vista WPF is based around Direct3D so there is no getting away from it. RIP Real 2d and the pixel?

I've tried em both (dd and direct3d) when writing dk and I can tell you that direct3d is waaaay faster.  It does depend upon the video card of course but with directdraw most blending effects have to be done at the software level while d3d does it via hardware.  A few newer games in mame need alpha blending of sprites, which d3d helps with.  Also newer cards have built in geometry buffers (not sure if that is the right term to use, but that's how I explain it) which gives a significant speed boost even though it's really only using textures. Believe it or not, at least with my tests, direct surface mapping is actually a lot slower.  Also it's hard to scale and blend multiple textures with it.  This is probably because it's the last remnant of direct draw. 

As for the pixel accuracy, it's really not as bad as it sounds.  Due to the before mentioned floating point variables and a nasty glitch caused by overlapping polys the position can be off by as much as one pixel.  That's right, a whole pixel!  Whoopty do!  It can even be compensated for by adjusting the texture offset and only scaling to exact multiples of the base resolution.  Of course mame does both of these except when hwstretch is turned on and the resolution selected is NOT an even multiple.  In other words, in theory at least when running in d3d mode on an arcade monitor, mame should look pretty darn accurate.

I can't even begin to completely understand what is going on in mame but I guess what I'm trying to say is that if mame isn't doing pixel perfect  (or pretty darn close, which is actually what dd does too) d3d rendering, it should be and is quite possible. 

I'm going to have to go with the peanut gallery on this one... dd is dead.  It needs to be phased out of this community as eventually new hardware and m$ will phase it out for us. 

[headkaze]

I've tried em both (dd and direct3d) when writing dk and I can tell you that direct3d is waaaay faster.

We are talking about an emulator here. So you have to write the pixels to emulate the real hardware. That is slow in both DirectDraw and Direct3D. It's hard to say which is faster without doing tests, but they both work the same when it comes to writing pixels, and that's locking the surface and writing raw pixel data. Direct3D is faster at moving polys and textures around but locking a surface to write pixel information is slow. It's the only way Mame could possibly work in Direct3D. I'm not arguing with you here, but even writing a FE in DirectDraw or Direct3D dosn't necessarily mean you have experience writing pixel data to a surface. It's not something you need to do for most things, but with emulation you do. If you've done non-hardware accelerated video in DK you probably have though.

But yeah I think the idea of "being off by a pixel" is pretty much laughable. Who cares? Are arcade nuts really that anal about getting the accuracy. Has anyone tried the Arcade VGA card with Direct3D, how different is it really? And what is the hardware acceleration on the card like? I remember hearing earlier versions of the card didn't have it. I have the newer PCIE version of the card but havn't checked it out yet.

[RandyT]

I agree that being concerned about being "1 pixel off" is ridiculously anal.  However, that wasn't really the point of my statements.  As time marches on, leaving things like DDraw and CRT based displays in the decrepit past, there will be artifacting of the games display due to digital displays having a fixed resolution.  We aren't talking about "1 pixel" in these instances, rather hundreds of pixels that can range from being mostly unnoticeable to causing something to appear misshapen. 

Currently, and please correct me if I'm wrong, those with digital displays, who are looking for display accuracy, need to use DDraw.  Which is why I was suggesting that before DDraw is completely laid to rest that modifications somehow be made to the D3D side of things that would provide similar functionality.

BTW, it may very well be that the only solution to the "accurate image on a digital display" issue will be to use a larger monitor with a game image that utilizes only the portion in which  a multiple of the original resolution is able to fit.  That should add a few bucks to a cabinet project.

RandyT

[lettuce]

Well tried D3D and Ddraw, and there is no difference bewteen the 2, Super Contra still runs at 85% when triplebuffer is enabled regardless of if its using D3D or Ddraw

[Jouster]

Couldn't you simply turn off DirectDraw3D?  I was having the same stuttering sounds on my system until I disabled it through MaLa...no more stuttering and everything works fine.

I'm using a LCD PC monitor...don't know if that makes a difference.

Jouster

[AndyWarne]

When a normal card is being used, D3D is pretty much equal to Ddraw/hardware stretch in terms of quality, and is faster then Ddraw because the scaling of the screen is being done with later and more advanced hardware and software.
This does not apply when using the ArcadeVGA card in a native res since no scaling is being done. Using Ddraw anables all the scaling to be turned off and so the card works fast, pretty much as it does in DOS as the drivers and the Windows graphics interface are not having to do much work. At no point are there large amounts of data to process as there would be when scaling onto a high-res screen.
I have not yet found a way to turn off all scaling in D3D.
As an example, if you consider a game which runs at 304 X 256 and you run this at a screen resolution of 320 X 256, using Ddraw results in an exact map of the game pixels onto the screen, with an un-noticeable border of 8 pixels either side.
If you try this with D3D, it attempts to re-scale the 304 pixels onto 320. This results in vertical lines of pixels being duplicated to fill out the spare space. The result of this is a distorted picture and is very noticeable.
If anyone can find a way to disable all stretch in D3D this would be very useful.
Remember that in addition to disabling all stretching, the result must also be the addition of equal borders each side when needed, something that Mame/Ddraw does very well. This is particularly important on vertical games on a horizontal monitor.
Aaron already has an ArcadeVGA card but insists on using Vista 64 bit which I am still working on the drivers for. I'll get onto this and try to get them finished.
Andy 

[lettuce]

Yeah i though i didnt notice any difference between D3D & Ddraw. Andy i have the ArcadeVGA card based on the R9250 card, how much more of a performance increase does your new version 2 AGP card give over the AGP R9250 card i have now??

[AndyWarne]

No difference at all. Basically both versions are fine. Simply no performance issues when running at arcade resolutions.
The version 2 card is capable of running high resolutions on a PC monitor as well as an arcade monitor, so it could be argued that someone using the card in this way would find the 9250 card slow on recent PC games compared to more powerful cards. The PCIe X1050 version of the ArcadeVGA is best for PC games. We are planning to continue with the 9250 card for AGP for as long as we can get the chips from ATI. The higher-end AGP chips such as the 9550 have issues with older motherboards and are a compatibility minefield.
Andy

[ahofle]

I have not yet found a way to turn off all scaling in D3D.
As an example, if you consider a game which runs at 304 X 256 and you run this at a screen resolution of 320 X 256, using Ddraw results in an exact map of the game pixels onto the screen, with an un-noticeable border of 8 pixels either side.
If you try this with D3D, it attempts to re-scale the 304 pixels onto 320. This results in vertical lines of pixels being duplicated to fill out the spare space. The result of this is a distorted picture and is very noticeable.
If anyone can find a way to disable all stretch in D3D this would be very useful.

Exactly.  I'm no graphics programmer, but I would think it should be possible in software to use the difference between the game resolution and the selected screen resolution and slap on a little black border to compensate for the difference before sending the texture to the screen.  So basically make a texture for the game image, then if the texture resolution is not the same as the screen res, add the border before rendering to the screen.  Is that even possible?  This would make it so no scaling is required, right?

And all this 'one pixel complainers are anal' talk is just nonsense.  You can very clearly see the artifacts, even with one extra pixel stuck in.  We're not talking about 1280x1024 screens here, but closer to 320x240.  One extra line or pixel is very noticeable especially on text. For example, using D3D without bilinear filtering you can very clearly see distorted game text on high score screens.  The letter 'G'  will appear differently from one side of the screen to the other.  Here is an example of Puckman running at 400x300 with D3D and no bilinear filtering.  Look at how some of the dots are elongated one extra pixel.  Even the ghost mouths are clearly artifacted.  You don't have to be an anal freak to notice it or be annoyed by it.

[RandyT]

And all this 'one pixel complainers are anal' talk is just nonsense.  You can very clearly see the artifacts, even with one extra pixel stuck in.  We're not talking about 1280x1024 screens here, but closer to 320x240.  One extra line or pixel is very noticeable especially on text. For example, using D3D without bilinear filtering you can very clearly see distorted game text on high score screens.

I agree.

I'm having a hard time relating to the language being used by a few here. "One pixel" does not appear to equal one pixel.  A row or a column is not "one pixel" rather as many pixels as are present in that row, and there are usually a number of these extra rows or columns.  Your image is showing precisely the type of image artifacting I was referring to.  This is what needs to be addressed before  laying DDraw to rest should even be considered.  The filtering will make some of those extra rows less apparent by reducing their overall intensity, but they are still quite visible, especially on a digital display.

It should also be noted that MAME builders often use older graphics hardware / older PC's with onboard video.  The word "normal" does not equate to "modern" with this group, so DDraw can actually outperfom D3D on these systems where often times, if it exists at all, D3D is done quite slowly in software only to provide compatibility. 

RandyT

[headkaze]

Would you rather stuttering sound or pixel artifacts?

[2600]

Would you rather stuttering sound or pixel artifacts?

You assume they have to be related.

[headkaze]

Would you rather stuttering sound or pixel artifacts?

You assume they have to be related.

When somone has stuttering sound and switches from DirectDraw to Direct3D and the stuttering disappears, you assume it is related.

[AndyWarne]

"One pixel" does not appear to equal one pixel.  A row or a column is not "one pixel" rather as many pixels as are present in that row,

In the picture and the example AHofle is describing, one pixel is one pixel. Thats the point, and the reason the problem exists. If you look at the steps in the curved top of a Pacman, each step is one pixel, both in the original game and in graphics memory and on the screen when you are running at the native resolution.
There is another issue here as well, and possibly the reason for the sound problems.
In recent times, Aaron has been on a crusade to correct the vertical refresh rates of games to make them exactly as the original. This presents a problem with some games. If a game originally ran at, say 61 Hz and you are running it on a 60Hz screen thats fine, but if the game ran at 59.5 Hz this presents problems when locking V-Sync as it means waiting each alternate frame.
Nobody could ever tell the difference between 59.5 and 60Hz of course and I put this to Aaron but he stated the aim of the project was for 100% authenticity and he was not concerned with this problem.
So the poster above who mentioned using an older Mame version was on track.

[RandyT]

"One pixel" does not appear to equal one pixel.  A row or a column is not "one pixel" rather as many pixels as are present in that row,

In the picture and the example AHofle is describing, one pixel is one pixel. Thats the point, and the reason the problem exists. If you look at the steps in the curved top of a Pacman, each step is one pixel, both in the original game and in graphics memory and on the screen when you are running at the native resolution.

I think I know what a pixel is.  I designed computer graphics on graph paper in the 80's when that was the only way to do it. 

I was referring to the fact that, earlier in this thread, it was said a couple of times that being concerned about a 1-pixel discrepancy between the capabilities of DDraw and D3D was being "anal".  Using such language mis-represents the greater issue of the generation of extra rows and/or columns, i.e. the artifacting, that occurs and cannot currently be avoided when using D3D.

RandyT

[youki]

It should also be noted that MAME builders often use older graphics hardware / older PC's with onboard video.  The word "normal" does not equate to "modern" with this group, so DDraw can actually outperfom D3D on these systems where often times, if it exists at all, D3D is done quite slowly in software only to provide compatibility. 

Good point. that's the reason why i used DDRAW for Atomic instead of D3D.  Even if it would be lot easier to do all my special effect with D3D.    But that's clear for modern video card Direct3D is lot of more performant if you play with alphablending, rotation ,scaling , texturing...etc...   If you just need to "blit" , i think DDRAW is still faster.
In the context on a emulator, i think blitting is more important.   Then for an  emulated 3D game , if the emulator tranlate the native hardware api call to D3D api call it could better, if they don't do that, and they just "blit" at the end on the screen , no really advantage for D3D here.

[Konrad]

Just wanted to throw in that I also have the problems mentioned in the first post.
Athlon 3400, 1GB RAM, AVGA2-AGP.

There are some games which ran perfectly up to version .116 (i guess this was the last perfectly working version for me) and have problems since .117u?. Some games just have sound stuttering (Speed varies between 92% and 102%, throttle ENABLED), other suddenly have a frameskip of 3-5. I had to disable triplebuffer, vsync or synctorefresh for these games. I have a list of games for which I had to change the inis. I guess its around 20 games. I could post it tomorrow if you want.

[AndyWarne]

I think I know what a pixel is.  I designed computer graphics on graph paper in the 80's when that was the only way to do it. 

I know that you know what a pixel is!
What I was getting at is that a missing step in the top of a Pacman, or a double-width step is noticeable. One column is one pixel, not many pixels as you suggested, when native resolutions are being used.
Andy

[RandyT]

I know that you know what a pixel is!
What I was getting at is that a missing step in the top of a Pacman, or a double-width step is noticeable. One column is one pixel, not many pixels as you suggested, when native resolutions are being used.

No, a column is the number of vertical pixels in the native screen resolution, or in the case of Pac-Man, 288 extra pixels for each extra column that exists in the image.  Likewise, each extra row adds 224 extra pixels in Pac-Man each and every time it occurs.  When someone says "one pixel" it sounds very much like an insignificant thing, because one pixel out of the  64512 pixels present in that image is insignificant.  But we are talking about a thousand or more of extra (or missing) pixels which is very much a big deal. 

Semantics aren't a big deal until someone doesn't understand what all the fuss is about.

RandyT

[headkaze]

I know that you know what a pixel is!
What I was getting at is that a missing step in the top of a Pacman, or a double-width step is noticeable. One column is one pixel, not many pixels as you suggested, when native resolutions are being used.

No, a column is the number of vertical pixels in the native screen resolution, or in the case of Pac-Man, 288 extra pixels for each extra column that exists in the image.  Likewise, each extra row adds 224 extra pixels in Pac-Man each and every time it occurs.  When someone says "one pixel" it sounds very much like an insignificant thing, because one pixel out of the  64512 pixels present in that image is insignificant.  But we are talking about a thousand or more of extra (or missing) pixels which is very much a big deal. 

Semantics aren't a big deal until someone doesn't understand what all the fuss is about.

RandyT

"One pixel" might sound insignificant to someone who has no idea what is been talked about here. I think it does the job. I don't think "one vertical column of pixels" is necessary unless were trying to explain the concept to kindergarten children. If you look at the scaling problems in the picture "one pixel off" should suffice whether that be a vertical column or horizontal row of pixels. It's an excercise in futility.

And I don't think you were the first person here to design graphics using graph paper either It doesn't help prove your point either.

[RandyT]

"One pixel" might sound insignificant to someone who has no idea what is been talked about here. I think it does the job. I don't think "one vertical column of pixels" is necessary unless were trying to explain the concept to kindergarten children. If you look at the scaling problems in the picture "one pixel off" should suffice whether that be a vertical column or horizontal row of pixels. It's an excercise in futility.

And I don't think you were the first person here to design graphics using graph paper either It doesn't help prove your point either.

I never said I was and now you are just being snide.

Take a look at the image ahofle posted again.  There are no less than 8 extra rows of pixels, resulting in a total of 1792 extra pixels on the screen.  You don't have to be a "kindergartener" to know that this statement far better represents the situation than speech like "it's only one extra pixel."

It's reckless to assume everyone who reads these discussions has the same background you do.  If you do, you'll have individuals parroting what is written without fully understanding the ramifications, and the rest of the folks to whom these issues really matter will be the ones left in the cold or painted as "anal retentives".  If you don't care about artifacting and the damage it causes to the images presented in the games, that's fine.  It's your prerogative.  But please don't minimize the situation to others, who may not fully understand it, with incorrect language that they may not  have the experience to know is incorrect.

RandyT

[headkaze]

I have not yet found a way to turn off all scaling in D3D.
As an example, if you consider a game which runs at 304 X 256 and you run this at a screen resolution of 320 X 256, using Ddraw results in an exact map of the game pixels onto the screen, with an un-noticeable border of 8 pixels either side.
If you try this with D3D, it attempts to re-scale the 304 pixels onto 320. This results in vertical lines of pixels being duplicated to fill out the spare space. The result of this is a distorted picture and is very noticeable.
If anyone can find a way to disable all stretch in D3D this would be very useful.

Have you considered the artwork folder in Mame which is used for bezels? Perhaps writing some program to generate special bezels to create the borders required for each game so Direct3D will stretch the image into a rectangle to match the resolution (or an even multiple thereof for perfect scaling)?

Check out a normal *.lay file for 1942. Perhaps this could be used for this purpose?

Code: [Select]

<mamelayout version="2">
<element name="bezel">
<image file="1942_bezel.png" />
</element>

<view name="Upright Artwork">
<screen index="0">
<bounds x="1036" y="647" width="1860" height="2480" />
</screen>
<bezel element="bezel">
<bounds x="0" y="0" width="3960" height="4000" />
</bezel>
</view>
</mamelayout>