|
Is it possible convert .lay to .art?
#310985 - 07/02/13 12:58 PM
|
|
|
Hi everybody,
I am working with the mame 0.106. I have the next file .art
[code]// 09/16/02 [your friendly neighborhood webslinger] // image borrowed from mamefans' museum section. // This bezel is the best I could do with the low res image, but it's better // than nothing :) Thanks to mamefans or the original bezel image. I encourage anybody // with a higher res image of this bezel to contribute it!
bezel: file = kungfum.png alphafile = kungfummask.png layer = bezel priority = 0 visible = 1 //right,bottom,left,top position = -0.1744,-0.3681,1.1783,1.3846 brightness = 1.001[/code]
The same file in .lay format is
[code]<!-- kungfum.lay -->
<mamelayout version="2"> <element name="bezel"> <image file="kungfum_bezel.png" /> </element> <view name="Bezel Artwork"> <screen index="0"> <bounds left="574" top="804" right="2922" bottom="2565" /> </screen> <bezel element="bezel"> <bounds left="0" top="0" right="3500" bottom="3396" /> </bezel> </view> </mamelayout> [/code]
Is it possible convert the .lay 2 .art format? Any program?
Thanks in advance!
|
|
|
|
Re: Is it possible convert .lay to .art?
[Re: empardopo]
#311005 - 07/03/13 10:01 AM
|
|
|
I've got it the next information about .art file
**********************************************************************
THE ART FILE
The .art file is very simply formatted. It consists of any number of entries that look like this:
[artname]: file = [filename] alphafile = [alphafilename] layer = [backdrop|overlay|bezel|marquee|panel|side|flyer] position = ,[top], ,[bottom] priority = [priority] visible = [visible] alpha = [alpha] brightness = [brightness]
Comments in the .art file follow standard C++ comment format, starting with a double-slash //. C-style comments are not recognized.
Fields are:
[artname] - name that is used to reference this piece of artwork in the game driver. Game drivers can show/hide pieces of artwork. It is permissible to use the same name for multiple pieces; in that case, a show/hide command from the game will affect all pieces with that name. This field is required.
file - name of the PNG file containing the main artwork. This file should live in the same directory as the .art file itself. Most PNG formats are supported. If the PNG file does not have an alpha channel or transparent colors, it will be loaded fully opaque. This field is required.
alphafile - name of a PNG file containing the alpha channel. Like the main file, this file should live in the same directory as the .art file. The alphafile must have the exact same dimensions as the main art file in order to be valid. When loaded, the brightness of each pixel in the alphafile controls the alpha channel for the corresponding pixel in the main art.
layer - classifies this piece of artwork into one of several predefined categories. Command line options can control which categories of artwork are actually displayed. The layer is also used to group the artwork for rendering (see discussion of rendering below.) This field is required.
position - specifies the position of this piece of artwork relative to the game bitmap. See the section on positioning, below, for the precise details. This field is required.
priority - specifies the front-to-back ordering of this piece of art. The various artwork pieces are assembled from the bottom up, lowest priority to highest priority. If you want a piece of artwork to appear behind another piece of artwork, use a lower priority. The default priority is 0.
visible - sets the initial visible state. By default, all artwork is visible. The driver code can change this state at runtime.
alpha - specifies a global, additional alpha value for the entire piece of artwork. This alpha value is multiplied by the per-pixel alpha value for the loaded artwork. The default value is 1.0, which has no net effect on the loaded alpha. An alpha of 0.0 will make the entire piece of artwork fully transparent.
brightness - specifies a global brightness adjustment factor for the entire piece of artwork. The red, green, and blue components of every pixel are multiplied by this value when the image is loaded. The default value is 1.0, which has no net effect on the loaded artwork. A brightness value of 0.0 will produce an entirely black image.
Once the .art file is loaded, the artwork is categories into three groups: backdrops, overlays, and everything else. Each of these groups is handled in its own way.
**********************************************************************
BLENDING
Conceptually, here is how it all fits together:
1. A combined backdrop bitmap is assembled. This consists of taking an opaque black bitmap, and alpha blending all the backdrop graphics, in order from lowest priority to highest, into it.
2. A combined overlay bitmap is assembled. This consists of taking a translucent white overlay and performing a CMY blend of all the overlay graphics, in order from lowest priority to highest, into it.
3. A combined bezel bitmap is assembled. This consists of taking a fully transparent bitmap, and alpha blending all the bezel, marquee, panel, side, and flyer graphics, in order from lowest to highest, into it.
4. Depending on the user configurable artwork scale setting, the game bitmap is potentially expanded 2x.
5. The combined overlay bitmap is applied to the game bitmap, by using the brightness of the game pixel to control the brightness of the corresponding overlay bitmap pixel, as follows:
RGB[mix1] = (RGB[overlay] * A[overlay]) + (RGB[overlay] - RGB[overlay] * A[overlay]) * Y[game];
where
RGB[mix1] -> RGB components of final mixed bitmap A[overlay] -> alpha value of combined overlay RGB[overlay] -> RGB components of combined overlay Y[game] -> brightness of game pixel
6. The result of the overlay + game blending is then added to the backdrop, as follows:
RGB[mix2] = RGB[mix1] + RGB[backdrop]
where
RGB[mix2] -> RGB components of final mixed bitmap RGB[mix1] -> RGB components of game + overlay mixing RGB[backdrop] -> RGB components of combined backdrop graphics
7. The combined bezel bitmap is alpha blended against the result of the previous operation, as follows:
RGB[final] = (RGB[mix2] * (1 - A[bezel])) + (RGB[bezel] * A[bezel])
where
RGB[final] -> RGB components of final bitmap A[bezel] -> alpha value of combined bezel RGB[bezel] -> RGB components of combined bezel RGB[mix2] -> RGB components of game + overlay + backdrop mixing
**********************************************************************
POSITIONING
The positioning of the artwork is a little tricky. Conceptually, the game bitmap occupies the space from (0,0) to (1,1). If you have a piece of artwork that exactly covers the game area, then it too should stretch from (0,0) to (1,1). However, most of the time, this is not the case.
For example, if you have, say, the Spy Hunter bezel at the bottom of the screen, then you will want to specify the top of the artwork at 1.0 and the bottom at something larger, maybe 1.25. The nice thing about the new artwork system is that it will automatically stretch the bitmaps out to accomodate areas beyond the game bitmap, and will still keep the proper aspect ratio.
Another common example is a backdrop that extends beyond all four corners of the game bitmap. Here is how you would handle that, in detail:
Let's say you have some artwork like this:
<============ 883 pixels ===============>
(1)-------------------------------------(2) ^ | ^ | | | 26 pixels | | | v | | | (5)-----------------------(6) | | | | | | | | | | | | | | | | | |<---->| | | | | 97 | Game screen | | 768 |pixels| 700 x 500 | | pixels | | |<---->| | | | | 86 | | | | |pixels| | | | | | | | | | | | | (7)-----------------------(8) | | | ^ | | | 42 pixels | | | v | | (3)-------------------------------------(4) v
If you're looking at the raw coordinates as might seem logical, you would imagine that they come out like this:
(1) is at (0,0) (2) is at (883,0) (3) is at (0,768) (4) is at (883,768)
(5) is at (97,26) (6) is at (797,26) (7) is at (97,526) (8) is at (797,526)
The first thing you need to do is adjust the coordinates so that the upper left corner of the game screen (point 5) is at (0,0). To do that, you need to subtract 97 from each X coordinate and 26 from each Y coordinate:
(1) is at (0-97,0-26) -> (-97,-26) (2) is at (883-97,0-26) -> (786,-26) (3) is at (0-97,768-26) -> (-97,742) (4) is at (883-97,768-26) -> (883,742)
(5) is at (97-97,26-26) -> (0,0) (6) is at (797-97,26-26) -> (700,0) (7) is at (97-97,526-26) -> (0,500) (8) is at (797-97,526-26) -> (700,500)
The final thing you need to do is make it so the bottom right corner of the image (point is at (1.0,1.0). To do that, you need to divide each coordinate by the width or height of the image
(1) is at (-97/700,-26/500) -> (-0.13857,-0.052) (2) is at (786/700,-26/500) -> (1.122857,-0.052) (3) is at (-97/700,742/500) -> (-0.13857, 1.484) (4) is at (883/700,742/500) -> (1.122857, 1.484)
(5) is at (0/700,0/500) -> (0.0,0.0) (6) is at (700/700,0/500) -> (1.0,0.0) (7) is at (0/700,500/500) -> (0.0,1.0) (8) is at (700/700,500/500) -> (1.0,1.0)
Alternately, you can also provide pixel coordinates, but it will still be relative to the game's native resolution. So, if the game normally runs at 256x224, you'll need to compute the division factor so that the bottom right corner of the game (point ends up at (256,224) instead of (1.0,1.0).
Basically, if you have the original coordinates shown right below the image, you can compute the values needed by doing this for X coordinates:
(X coordinate on artwork) - (X coordinate of game's upper-left) --------------------------------------------------------------- (width of game in artwork pixels)
And this for Y coordinates:
(Y coordinate on artwork) - (Y coordinate of game's upper-left) --------------------------------------------------------------- (height of game in artwork pixels)
*********************************************************************
Thanks!
|
|
|
|