MAME 0.146 tag

Author: mmicko

.gitattributes

@@ -0,0 +1,89 @@
+HLSL-Related Enable Switches
+----------------------------
+
+Name                    Values		Description
+hlsl_enable             0/1             Enables HLSL post-processing in Direct3D 9 modes.
+yiq_enable              0/1             Enables YIQ-colorspace post-processing. Causes a
+                                        performance drop but gives a much more authentic
+                                        NTSC TV appearance on TV-based systems when configured
+                                        properly.
+hlslpath                [path]          Path to the .fx files that are in use. (default: hlsl)
+hlsl_ini_read           0/1             Enable HLSL INI reading.
+hlsl_ini_write          0/1             Enable HLSL INI writing.
+hlslini             	%g              HLSL INI file name for running game. (default: %g)
+hlsl_prescale_x         [horizontal]    HLSL pre-scale override factor for X (0 for auto).
+hlsl_prescale_y         [vertical]      HLSL pre-scale override factor for Y (0 for auto).
+hlsl_preset             0-3             HLSL preset to use.
+hlsl_write              0/1		Enable HLSL AVI writing (huge disk bandwidth suggested).
+hlsl_snap_width         [width]         HLSL upscaled-snapshot width. (default: 2048)
+hlsl_snap_height    	[height]        HLSL upscaled-snapshot height. (default: 1536)
+
+
+Surface/Color Processing Parameters
+-----------------------------------
+
+Name                    Values		Description
+shadow_mask_alpha       0.0 to 1.0      The ovearll darkness of each shadow mask pixel.
+shadow_mask_texture     [filename]      A PNG that defines the shadow mask for each pixel.
+shadow_mask_x_count     1+              The count of shadow mask elements, X (usually 640-ish)
+shadow_mask_y_count     1+              The count of shadow mask elements, X (usually 480-ish)
+shadow_mask_usize       0.0 to 1.0      These parameters define the *in-use* pixel count on the
+shadow_mask_vsize       0.0 to 1.0      X and Y axes of the shadow mask texture.
+curvature               0.0 to 1.0      Screen curvature. Affects borders and shadow mask.
+pincushion              0.0 to 1.0      Image curvature. Affects the source image only.
+scanline_alpha          0.0 to 1.0      The overall darkness of each scanline furrow.
+scanline_size           0.0 to 4.0      The overall height of each scanline.
+scanline_height         [height]        Individual height scaling value for scanlines.
+scanline_bright_scale   0.0 to 2.0      The overall brightness multiplier for each scanline.
+scanline_bright_offset  0.0 to 1.0      The overall brightness additive value for each scanline.
+scanline_jitter         0.0 to 2.0      The relative scanline movement per field.
+defocus                 [xval,yval]     This defines the overall defocus radius for the three
+                                        post-converged beams.  Values allowed range from 0.0 to
+                                        32.0.
+converge_x              [r,g,b]         Convergence in screen-relative X direction.
+converge_y              [r,g,b]         Convergence in screen-relative Y direction.
+radial_converge_x   	[r,g,b]         Radial convergence in screen-relative X direction.
+radial_converge_y   	[r,g,b]         Radial convergence in screen-relative Y direction.
+                                        Allowed values for convergence: -150 to 150 for each color.
+red_ratio               [r,g,b]         These parameters define a 3x3 matrix which is multiplied 
+grn_ratio               [r,g,b]         by the incoming RGB signal. This can be used for any
+blu_ratio               [r,g,b]         standard matrix convolution, including H/S/V or simply
+                                        affecting the TV-style tint.
+saturation              0.0 to 4.0      This parameter defines the amount each color channel is
+                                        raised above said channel's baseline grayscale value.
+                                        A value of 0.0 gives a gamma-correct grayscale image,
+                                        whereas 1.0 is full saturation, with each channel being
+                                        oversaturated equally beyond that.
+offset                  [r,g,b]         These parameters define a value for each color channel
+                                        that is added to said channel after scaling and after
+                                        matrix convolution. (-2.0 to 2.0)
+scale                   [r,g,b]         These parameters define a value for each color channel
+                                        that is multiplied with said channel after matrix
+                                        convolution.  (-2.0 to 2.0)
+power                   [r,g,b]         These parameters define the exponent for each color
+                                        channel that is applied after scaling, offsetting,
+                                        saturation and matrix convolution. (-4.0 to 4.0)
+floor                   [r,g,b]         These parameters define the lower limit of each final
+                                        color channel value; 0.05, for example, raises the
+                                        minimum to 0.05 but re-scales to leave the max at 1.0.
+phosphor_life           [r,g,b]         These parameters define the phosphor lifetime for each
+                                        channel, with 0.0 representing no phosphorescence and
+                                        1.0 leaving the channel on indefinitely. Values allowed
+                                        range from 0.0 to 1.0.
+
+
+NTSC Processing Parameters
+--------------------------
+
+Name                    Default Values  Description
+yiq_cc                  3.59754545      Color Carrier frequency for NTSC signal processing
+yiq_a                   0.5             A value for NTSC signal processing
+yiq_b                   0.5             B value for NTSC signal processing
+yiq_o                   0.0             Outgoing Color Carrier phase offset for NTSC signal processing
+yiq_p                   1.0             Incoming Pixel Clock scaling value for NTSC signal processing
+yiq_n                   1.0             Y filter notch width for NTSC signal processing
+yiq_y                   6.0             Y filter cutoff frequency for NTSC signal processing
+yiq_i                   1.2             I filter cutoff frequency for NTSC signal processing
+yiq_q                   0.6             Q filter cutoff frequency for NTSC signal processing
+yiq_scan_time           52.6            Horizontal scanline duration for NTSC signal processing (in usec)
+yiq_phase_count         2               Phase Count value for NTSC signal processing (3 for NES, else 2)

trunk/artwork/aperture.png

@@ -0,0 +1,35 @@
+Unless otherwise explicitly stated, all code in MAME is released under the
+following license:
+
+Copyright Nicola Salmoria and the MAME team
+All rights reserved.
+
+Redistribution and use of this code or any derivative works are permitted
+provided that the following conditions are met:
+
+* Redistributions may not be sold, nor may they be used in a commercial
+product or activity.
+
+* Redistributions that are modified from the original source must include the
+complete source code, including the source code for all components used by a
+binary built from the modified sources. However, as a special exception, the
+source code distributed need not include anything that is normally distributed
+(in either source or binary form) with the major components (compiler, kernel,
+and so on) of the operating system on which the executable runs, unless that
+component itself accompanies the executable.
+
+* Redistributions must reproduce the above copyright notice, this list of
+conditions and the following disclaimer in the documentation and/or other
+materials provided with the distribution.
+
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
+LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+POSSIBILITY OF SUCH DAMAGE.

trunk/artwork/white.png

@@ -0,0 +1,81 @@
+MAME(tm), the Multiple Arcade Machine Emulator
+Copyright (c) 1997-2007 by Nicola Salmoria and the MAME team
+MAME is a trademark owned by Nicola Salmoria
+
+
+----------
+I. Purpose
+----------
+MAME is strictly a non-profit project. Its main purpose is to be a
+reference to the inner workings of the emulated arcade machines. This is
+done both for educational purposes and for preservation purposes, in
+order to prevent many historical games from disappearing forever once the
+hardware they run on stops working. Of course, in order to preserve the
+games and demonstrate that the emulated behavior matches the original,
+you must also be able to actually play the games. This is considered a
+nice side effect, and is not MAME's primary focus.
+
+It is not our intention to infringe on any copyrights or patents on the
+original games. All of MAME's source code is either our own or freely
+available. To operate, the emulator requires images of the original ROMs,
+CDs, or hard disks from the arcade machines, which must be provided by
+the user. No portions of the original game code are included in the
+executable.
+
+
+--------
+II. Cost
+--------
+MAME is free. Its source code is free. Selling either is not allowed.
+
+
+----------------
+III. Image Files
+----------------
+ROM, CD, and hard disk images are all copyrighted material. They cannot
+be distributed without the explicit permission of the copyright owner.
+They are not "abandonware", nor have any of the games supported by MAME
+passed out of copyright.
+
+MAME is not intended to be used as a tool for mass copyright
+infringement. Therefore, it is strongly against the authors' wishes to
+sell, advertise, or link to resources that provide illegal copies of ROM,
+CD, or hard disk images.
+
+
+--------------------
+IV. Derivative Works
+--------------------
+Derivative works are allowed under the MAME license. However, you are
+discouraged from providing specific functionality that goes against the
+philosophy of the MAME team. Specifically:
+
+* Do not add games which are more recent than 3 years old, or which are
+still being sold new by the company that produced them. MAME is not
+intended to be a platform that competes with arcade games that are still
+being actively sold.
+
+* Do not provide a means of generating a list of games that specifically
+identifies those games for which the user does not have image files. This
+only encourages users to seek out sources for illegal ROM, CD, and hard
+disk images in order to "complete" their collection.
+
+* Do not remove the startup screen that contains information about why
+certain non-working games don't work. This only serves to generate a
+bunch of useless email traffic to the developers asking why the games
+don't work.
+
+Because the name MAME is trademarked, you must abide by the rules of the
+trademark usage if you wish to use "MAME" as part of the name your
+derivative work. In general, this means you must request permission,
+which requires that you follow the guidelines above.
+
+The version number of any derivative work should reflect the version
+number of the MAME release it was derived from.
+
+
+-------------------------------
+V. Official Contact Information
+-------------------------------
+For questions regarding the MAME license, trademark, or other usage, go
+to http://www.mamedev.org/

trunk/docs/config.txt

@@ -0,0 +1,146 @@
+This article originally appeared in a slightly different form at
+http://aarongiles.com. You should read this if you are used to how
+MAME's video system worked prior to 0.107 and you want to understand
+how you should configure MAME with the new rendering system in place.
+
+
+The New Video Landscape
+
+Since its inception 9 years ago, MAME's video system has defaulted to
+a mode where it tries to change resolutions on you. And since the
+first port of the core to Windows 5 years ago, it has defaulted to
+using your graphics card to stretch the video to that resolution.
+
+I'm sure a lot of you out there have taken a lot of time to tweak the
+current set of video options to make them work the way you like. But
+every once in a while, you need to take a step back and re-evaluate
+the situation. The current video system has been in place for 5 years
+now without much substantial change. And with the recent rewrite,
+you're almost certainly going to want to rethink the way you have
+things configured.
+
+At the highest level, there are really three different ways you can
+configure the new system. Placing yourself into one of these three
+categories will help you get the initial settings right. From there,
+you can tweak with the settings to figure out what works best.
+
+
+Category 1: Bells and whistles. People who fall into this category
+would include anyone with a modern system and a decent video card
+(decent in this context means at least 16MB of VRAM and built in the
+last 5 years or so -- we're not talking cutting edge here). Any decent
+video card will be able to render the simple MAME graphics at pretty
+much any resolution without breaking a sweat. Configure your desktop
+to the video mode you want (preferably something high like 1024x768
+or greater with a high refresh rate, unless you are running on a
+fixed-mode LCD, in which case just match what your LCD panel is),
+and tell MAME to leave the resolution alone. In this day and age,
+there is little reason to switch resolutions at all, unless you
+fall into Category 3, below. In this mode, you will have full access
+to artwork options, and you'll get your artwork scaled to full
+resolution and with full alpha blending effects. Vector games will
+look crisp, you can use decent fonts, and you can see a whole lot
+more of the world when using the graphics/tilemap viewer. This mode
+uses Direct3D, so you should configure yourself like this:
+
+   -video d3d -noswitchres [-triplebuffer] [-nofilter]
+
+The -noswitchres option tells MAME to just run at the current
+resolution. Although you can let MAME pick a resolution for you, it
+doesn't really make much sense in D3D mode, and in fact I may even
+remove that feature altogether. To avoid tearing artifacts, I
+recommend using the -triplebuffer option as well. Just make sure your
+monitor's refresh rate is higher than the game you are running. If
+you dislike the blurry look of the graphics, you can specify the
+-nofilter option to disable bilinear filtering, though that will
+produce blocky artifacts. Alternatively, you can use the -prescale
+option which is described at the end of this article.
+
+
+Category 2: Like the old days. I really didn't even want to support
+this mode at all, but certain vocal MAMEdevs would have skinned me
+alive otherwise. People who fall into this category include those who
+have weak systems that worked fine with previous versions of MAME,
+but who don't run well with Direct3D rendering. (Note that just
+because Space Invaders runs unthrottled at 2000fps with DirectDraw
+and 1000fps with Direct3D doesn't mean that Direct3D is going to be
+a serious issue when playing at a regular 60fps, so if you're unsure,
+give the Direct3D route a try for a while.) In this mode, MAME will
+draw the game screen and artwork at the game's resolution, just like
+it did in MAME 0.106 and earlier; however, some artwork options,
+such as -artcrop, won't work as you might expect, and some alpha
+blending artwork modes (specifically overlays) will operate with a
+performance penality. MAME will then use your video card to stretch
+the video to the proper aspect ratio.
+
+   -video ddraw -hwstretch [-switchres] [-triplebuffer]
+
+The -switchres is optional here. If your video card is really ancient
+and struggles expanding the screen to fit your desktop resolution,
+you might want to turn it on. Again, to avoid tearing artifacts, I
+recommend using the -triplebuffer option as well, but make sure your
+monitor's refresh rate is higher than the game you are running
+(-switchres will do that for you if you use it). If your video card
+produces blurry pixels which you don't like, try the -prescale option
+described at the end of this article.
+
+
+Category 3: Anal video mode types. These are the guys who have
+generally built their own cabinets and set them up with a CRT display
+where they have several dozen carefully hand-tweaked video modes that
+approximate the original video modes the games ran at. They want MAME
+to pick that hand-tweaked mode and use it, drawing one pixel on the
+screen for each pixel in the original game. They don't give a whit
+about artwork or anything other than the raw pixels going to the
+right place. Fortunately, you can still configure MAME for this case
+as well:
+
+   -video ddraw -nohwstretch -switchres [-triplebuffer]
+
+Obviously in this case, the -switchres is required. You also want to
+disable hardware stretching, otherwise you won't get that "perfect"
+1:1 pixel mapping. Triple buffering may or may not help.
+
+
+So, I recommend starting with these initial options and then tweaking
+from there. One additional option you might want to try in
+combination with the above is the -prescale option. -prescale takes
+an integer parameter from 1 to 8, and specifies a magnification
+amount by which the screen pixels are expanded before they are drawn
+to the screen. Why is this useful? And how much of a performance
+impact does it have? Well, that depends on the mode you are running
+in.
+
+If you are running in Category 1 (-video d3d), then -prescale will
+use your video card to scale the game graphics up before rendering
+them to the screen. Depending on the video card, this is usually a
+small performance hit, but not too significant. The benefit is that
+each prescale factor reduces the blurriness of the pixels.
+-prescale 1 is the default, which does no scaling. -prescale 2 will
+double each pixel, -prescale 3 will triple each pixel, etc. For my
+money, -prescale 2 is sufficient, but people with super high
+resolution displays claim that larger -prescale factors work even
+better.
+
+If you are running in Category 2 (-video ddraw -hwstretch), then
+-prescale will cause MAME to compose the screen graphics at the
+specified scale factor. This is unfortunately done in software, but
+carries the benefit that artwork, fonts, and the graphics viewer can
+take advantage of the additional resolution to produce nicer results.
+The end effect is that you will get less blurry pixels, just like the
+Category 1 case, plus higher quality artwork, fonts, and more visible
+area in the graphics viewer.
+
+If you are running in Category 3 (-video ddraw -nohwstretch), then
+-prescale will cause MAME to pick a video mode that is the prescale
+factor times the raw screen resolution, and then MAME will, in
+software, compose the screen graphics at the specified scale factor.
+This has all the advantages of the Category 2 case, except that since
+there wasn't any pixel blurring to begin with, there is no additional
+crispness that comes about as a result.
+
+Finally, you may be wondering about effects (and yes, scanlines are
+an "effect"). Effects are no longer hard-coded into the system.
+Rather, you can provide a PNG file in the artwork directory that will
+be loaded and overlaid on top of screen bitmaps. See the description
+of -effect in windows.txt for more details.