TPD4 Borders

mush

G'day All,

Does anyone know how to create AMX TPD4 borders?
I've trawled through the threads and there is a lot of leads, some of which helped me get where I am, but no difinitive information.

I've been trying to create my own borders for TPD4.
So far I've been fairly successful but not perfect.
I can make a border and edit the draw.xma file and it works fine, except for transparency.
I've played, fiddled, poked and prodded all I can with the files but I cannot get the same result as AMX.
Since I am in no way, shape or form competent with graphics and only know the basics when it comes masks
and alpha channels, I thought I'd throw this out there as I'm sure some others may be able to work out the steps and describe them acurately.

Here's what I have so far.
1. Border png images are located in C:\Program Files\Common Files\AMXShare\G4SupportFiles\__system\graphics\borders
2. The file that describes the borders to TPD4, draw.xma, is located in C:\Program Files\Common Files\AMXShare\G4SupportFiles\__system\graphics (more on draw.xma below)
3. There are either 8 or 16 image files that make up a border in TPD4 depending upon if alpha or image partners are required.
One image for left, right top, bottom, top left, top right, bottom left and bottom right which is repeated with an alpha image.
The naming convention is image-name_tr.png or image-name_tr_alpha.png. tr being top right, there is also l, r, tl, bl etc.
4. Any border that extends to and touches the edge of the button all the way around does not normally have a corresponding alpha image. 'AMX Elite' for example.
5. Any border that does not define a border, and does not touch the edge of the button all the way around normally has an alpha image but no corresponding border image.
All the Circle buttons are like this.
6. The borders seem to work with a greyscale mask and work similarly to a button with a chameleon image, but not quite. (This is were I am getting lost)

Draw.xma
Draw.xma has three elements that have to be edited to make a new border appear.
These are all under root\borderData and they are borderFamily, borderStyle, and border.

borderFamily has the attributes, name and member. Name is the description of the family of borders eg 'Bevel' and is a single entry.
The member attribute is required for each border available in the border family eg. 'Bevel -L', 'Bevel -M'

borderStyle has the attributes, name, off, on, drag, drop and g3Equiv. There must be 1 borderStyle entry for each borderFamily member defined.
name = the name defined in borderFamily (must match that name exactly eg. 'Bevel -L')
off = the name defined in border family of the border that is to be drawn when the button is off. eg. 'Bevel Raised -L'
on = the name defined in border family of the border that is to be drawn when the button is on. (Can be different to the name above eg. 'Bevel Inset -L')
drag = the name defined in border family of the border that is to be drawn when the button is dragged. (Can be different to the name above eg. 'Bevel Inset -L')
drop = the name defined in border family of the border that is to be drawn when the button is dropped. (Can be different to the name above eg. 'Bevel Inset -L')
g3Equiv = ?? (I presume something to do with importing a G3 panel?? usually a number)

There must be 1 border entry for each borderFamily member defined. border has the following attributes,
name = the name defined in borderFamily (must match that name exactly eg. 'Bevel -L')
basefile = the name of the actual image file eg 'Bevel -L' has the file name bevelL-off
There are numerous other attributes to this element but they don't seem to have a major effect on anything.

Okay, so who's willing to have a fiddle to try and make their own borders? (And then share the info).
I know you all are diligent at backing up your data etc ;P but if you are going to attempt this make sure you copy all the existing borders and draw.xma to a safe place.

I look forward to seeing what people come up with. Who knows we may end up with a custom borders section!

Cheers

Mush

ericmedley

If you have photoshop or whatever flavor of graphic editor, create the borders (and for that matter buttons) you want and don't use the AMX TPD built-in graphics. This is what I do for almost all TPs. It is rare for me to use the built in borders or background colors.

Put the border/button of choice in a transparent button.

mush

ericmedley wrote: »

If you have photoshop or whatever flavor of graphic editor, create the borders (and for that matter buttons) you want and don't use the AMX TPD built-in graphics. This is what I do for almost all TPs. It is rare for me to use the built in borders or background colors.

Put the border/button of choice in a transparent button.

Thanks for the input Eric.
This is what I already do and what I'm trying to avoid!
Instead of creating a new button every time you need a slightly different size, wouldn't it be better to create the borders once and then use them forever more at any size you desire?
I certainly think so, which I guess is obvious from the trouble I've gone to so far.

It sounds like you have more graphical experience than me. Perhaps if you had a look at the border images you might be able to see what I've missed.

Cheers and thanks again.

Mush

DHawthorne

Doesn't seem to me to have enough of a percentage to warrant all the work ... but if you do manage it, and produce some good enough designs, there may be a market for it.

What I would rather see, however, is AMX to release the API for such things and allow us to develop and share our designs.

jjames

Matthew, you can and cannot at the same time. Have you seen this thread from a while back?

I guess one *could* replace all sorts of borders, rename them, or even add your own - all the information is in C:\Program Files\Common Files\AMXShare\G4SupportFiles\__system\graphics\draw.xma; A lot of work like Dave said, but it is possible to define your own borders using your own images.

Good luck! Change at your own risk.

mush

jjames wrote: »

Matthew, you can and cannot at the same time. Have you seen this thread from a while back?

I guess one *could* replace all sorts of borders, rename them, or even add your own - all the information is in C:\Program Files\Common Files\AMXShare\G4SupportFiles\__system\graphics\dr aw.xma; A lot of work like Dave said, but it is possible to define your own borders using your own images.

Good luck! Change at your own risk.

G'day Jeremiah,

That thread actually helped me get to this point. I only wish JoeyJoeJo1200 a.k.a "TP God" was still around. I'm sure he knows the answer!!!

I already have 18 of my own borders installed and working!
Several of them work perfectly, some do not, which, of course, is the reason for my post.
Whilst it did take some time to do the first border the rest only took slightly longer than creating a button in GIMP.
A border after all, is only slices of a button that are added together to create the size you want.
I reckon that any style of button that you have to create more than 5 different sizes of gives justification for turning it into a border.
Creating one border would take less time than those 5 buttons and then you have it in infinite sizes, forever. (You can then also resize it on the fly with code!)

The only risk I can see is if I lose/misplace the borders I create and have to do them again.
Worst case scenario is a re-install of TPD4 if I really break it. Can you see any other risk?

Cheers and thanks for your time.

Mush

jjames

Well - I'd obviously back them all up first. Don't forget that upgrades to TPD4 *AND* NS3 could most likely replace the graphics.

BTW - my previous post proves that I should 1) read the thread before posting, and 2) not post right when I wake up. All the information I told you . . . well, you already said . . . I feel like a schmuck.

mush

jjames wrote: »

Well - I'd obviously back them all up first. Don't forget that upgrades to TPD4 *AND* NS3 could most likely replace the graphics.

BTW - my previous post proves that I should 1) read the thread before posting, and 2) not post right when I wake up. All the information I told you . . . well, you already said . . . I feel like a schmuck.

Yep, have them all safely tucked away in more than one place.

LOL, don't feel bad, we've all done it! At least you're honest about it. A lot of people are oblivious, even when it's pointed out to them.

Thanks again for your input.

PhreaK

Nice work Mush! I've got a few GIMP scripts I use to dump out buttons of a certain style in different dimensions but like you said, having the ability to resize on the fly with code is just damn sexy.

mush wrote: »

Can you see any other risk?

Only other risk I could see is what happens when you pull that file from the panel sometime in the future and your border toolkit is slightly different to the one you were using at the time?

Ideal situation would be for AMX to update TPDesign to support GUI packs that could include things such as different border definitions. Although I'd settle for an update that just made it stable first.

mush

PhreaK wrote: »

Nice work Mush!

Ta, although I'm not the only one involved.

PhreaK wrote: »

Only other risk I could see is what happens when you pull that file from the panel sometime in the future and your border toolkit is slightly different to the one you were using at the time?

Hmm... good point. Very good point.
This means you need to back up the draw.xma and all your border images and hand them over with the panel file.
A bit messy and not for the faint hearted!

mush

PhreaK wrote: »

I've got a few GIMP scripts I use to dump out buttons of a certain style in different dimensions.

Sounds like your just the man to have a crack at these alpha/mask channels?????

mush

I think I have it!

Okay, I have some more.

For a Border Image on it's own
Any object in the alpha channel is visible
Anything else is the button border colour

For an Alpha Image on it's own
Anything that is white and masked makes that part of the button transparent.
Anything that is black and masked is the button fill colour.
Anything that is un-masked is the button border colour.
To fade from the border colour to the fill colour or from the border colour to transparency a gradient mask needs to be applied and saved to the alpha channel.
Where the gradient opacity is 100% the border colour will be seen.
Where the gradient opacity is 0% the full border fill colour or transparency will be seen depending upon whether the alpha image colour is black or white. (Black = button fill colour, white = transparent).

When there is a border and an alpha image.
Anything that is white and masked makes that part of the button transparent, including the border image.
Anything that is black and masked is the border fill colour, including the border image.
Anything that is un-masked is the border colour except for the border image.
Fading with both the border and alpha images is very complex.
To fade, the same applies as above, a gradient mask needs to be applied and saved to the alpha channel.
Fading occurs as above where there is no border image present.
When the border image is present fading can be from the border image to the button fill colour. This occurs if the alpha image colour is black.
When the border image is present fading can also be from the border image to transparency. This occurs if the alpha image colour is white.
Where the gradient opacity is 100% the border image will be seen if it is present otherwise the border colour will be seen.
Where the gradient opacity is 0% the full border fill colour or transparency will be seen depending upon whether the colour below the gradient is black or white. (Black = button fill colour, white = transparent).

Whew!
Some of this may be wrong, I''ll edit it if I find errors.

Cheers

jjames

Nice work! I wish I had the ambition to toy around with this stuff again . . . for me now, my number one priority is to just get the job done.

Keep up the hard work!

mush

jjames wrote: »

Nice work! I wish I had the ambition to toy around with this stuff again . . . for me now, my number one priority is to just get the job done.

Me too JJ, hence the want/need to reduce panel design/build time!

jjames

mush wrote: »

Me too JJ, hence the want/need to reduce panel design/build time!

Something I'm thinking about getting into is PanelBuilder . . . it's an old program that I'm sure very few people use - but building your own templates could really speed up the design time.

BTW - could you post a few screenshots of your work? I'd be interested in seeing exactly what you're doing.

DHawthorne

jjames wrote: »

Something I'm thinking about getting into is PanelBuilder . . . it's an old program that I'm sure very few people use - but building your own templates could really speed up the design time.

BTW - could you post a few screenshots of your work? I'd be interested in seeing exactly what you're doing.

I thought that too, until I saw what was involved in building a template. Honestly, it is far easier to make a generic panel file and populate it yourself, then copy and edit it per job. In many cases, as long as the design is appropriate, I just use the panel from the last similar job I did, and go from there.

jjames

DHawthorne wrote: »

I thought that too, until I saw what was involved in building a template. Honestly, it is far easier to make a generic panel file and populate it yourself, then copy and edit it per job. In many cases, as long as the design is appropriate, I just use the panel from the last similar job I did, and go from there.

Yeah . . . just looked at the requirements (I haven't looked at them in years TBH), and I agree that it'd be cumbersome. Besides, I'm a one page / many popup kind of guy, and it appears that G4PB is aimed towards the opposite.

Anyway - I think I'm beginning to drift!