GroovyMAME and vector games

[krick]

Due to the known problem with Tempest in GroovyMAME cropping the bottom off, I started digging deeper into vector games trying to understand what's going on and get a discussion on how to get the best results when running vector games under GroovyMAME.

I noticed that Space Fury runs too fast and is really hard to sync on my monitor.  I also noticed that Star Wars runs even faster.  so much that the voices sound really silly.

So I gathered some statistics from MAME 0.146 on the various refresh rates and orientations...

Vector games (parent sets only):

13 horizontal @ 38Hz - armora, boxingb, demon, qb3, ripoff, solarq, spacewar, speedfrk, starcas, starhawk, tailg, warrior, wotw
12 horizontal @ 40Hz - aztarac, bradley, bzone, elim2, esb, llander, omegrace, spacfury, startrek, starwars, tomcat, zektor
1 horizontal @ 45Hz - spacduel
1 horizontal @ 50Hz - mhavoc
6 horizontal @ 60Hz - astdelux, asteroid, bwidow, gravitar, redbaron, topgunnr

2 vertical @ 38Hz - barrier, sundance
2 vertical @ 40Hz - cchasm, tacscan
3 vertical @ 60Hz - quantum, raaspec, tempest

Are these refresh rates actually used by GroovyMAME?  Are they even correct?
It appears that GroovyMAME defaults to 640 x 480 for all vector games, regardless of orientation.

It also seems to me that we might want to (somehow) pick the highest interlaced resolution supported by the monitor as the vectors look less jaggy the higher the resolution.

Finally, I don't know if this is anything we can control, but I believe that vector games look far better with the following changes.  I usually make them in a separate vector.ini file, but I was wondering if it might make sense for GroovyMAME to apply these options automatically when a vector game is run.

#
# CORE SCREEN OPTIONS
#
contrast 2.0
gamma 2.0
#
# CORE VECTOR OPTIONS
#
beam 2.0

[Calamity]

Hi krick,

Thanks a lot for your post. I admit the vector games have been somewhat neglected in GroovyMAME, mainly because I just play raster games and are the ones I'm testing all the time.

Currently, a default resolution of 640x480 is used for all vector games. As you say, this ignores orientation, which is the problem of tempest and others. But we're also making a suboptimal use of the monitor's potential resolution. We should always go for the highest possible resolution, but this is refresh dependent. The 'virtualize' feature in GroovyMAME does right this: it calculates the highest possible resolution for a given refresh, within the monitor specs. So this is indeed what we should do for vector games: virtualized resolutions - now, most people are used to set an unique 'highest' resolution for all vector games, so they will complain about this behaviour, and specially about those crazy high resolutions above 640x480 they will want to remove with my-monitor-just-supports-up-to-640x480 kind of argument, but that's a different story -

On the other hand we have the odd refresh these games usually have. For raster CRTs we normally move in the 50-60 Hz range, so what GroovyMAME does with a refresh that's outside our defined limits is to set either the minumum or the maximum, depending on the value. Thus 40 Hz will become 50 Hz, etc. As -syncrefresh on is the default behaviour now, that means it will run at 125%. You can override this by enabling -triplebuffer manually, but it seems like a good idea to implement this programmatically.

As for using different specific rendering options for the vector games, it's something that should be easy to implement, just nobody had asked for.

So I think we could add all these features for the next release of the patch.

[Paradroid]

I don't play any vector games myself but these ideas sound really cool!

[Gravitar]

I also use 2.0 beam and very high contrast on MAME... it makes the games look a lot better.

Speaking of vector games, are you familiar with AAE? It's pretty awesome. While it can't substitute a real vector display it's much better than MAME in every regard.

I have managed to get AAE look really good... you have to play with the video settings a bit. I can't stress enough how amazing emulator this is... you won't even look at MAME after this... if you play vector games. Look at the brightness... you'll never see this kind of quality with any other emulator.

Here are the settings I use:



And these are the results:









I wonder how could we get in touch with the author... there's still a few little bugs to beat.

Biggest annoyance is the lack of mouse support in Star Wars. I'd LOVE to play it on AAE.

PS: PM me if you have trouble finding the stuff for it.

[krick]

Speaking of vector games, are you familiar with AAE? It's pretty awesome. While it can't substitute a real vector display it's much better than MAME in every regard.

Are you using AAE with a 15KHz arcade monitor?

[Justin Z]

AAE looks great--I just can't even get it to run on XP64. 

[jvlk]

AAE looks great--I just can't even get it to run on XP64. 

I have it running on xp64, if you are using AAE With Patch 2....you will have trouble running it if there are some controllers (joysticks, wheel etc) hooked up.
Solution unhook your controllers or use AAE with only patch 1.

[Justin Z]

Nope, still no luck . . .  thanks for the suggestion though!

[nexusmtz]

Justin,

Take a look at aae.log and see if that gives you a hint about what's going wrong.

If I have the device for my Saitek keyboard's extra keys enabled, AAE thinks I have a joystick (joy 1, below) with 10491984 sticks on it. That makes the program crash on Windows 7 x64

aae.log

Code: [Select]

Number of supported games is: 70
Setting timer resolution to Min Supported: 1 (ms)
Number of supported joysticks: 2
joy 0 number of sticks 3
stick number  0 flag 35
stick number  0 axis 0 pos 0
stick number  0 axis 1 pos 0
stick number  1 flag 0
stick number  1 axis 0 pos 10491984
stick number  1 axis 1 pos 10491984
stick number  2 flag 0
stick number  2 axis 0 pos 269210701
stick number  2 axis 1 pos 10491984
joy 1 number of sticks 10491984
stick number  0 flag 0
stick number  0 axis 0 pos 10491984
stick number  0 axis 1 pos 10491984
stick number  1 flag 0
stick number  1 axis 0 pos 0
stick number  1 axis 1 pos 0
stick number  2 flag 0
stick number  2 axis 0 pos 0
stick number  2 axis 1 pos 0
...
stick number  918 flag 0
stick number  918 axis 0 pos 0
stick number  918 axis 1 pos 0

Since disconnecting the keyboard isn't an option, I just disabled the HID device in Device Manager when I want to use AAE.

[Justin Z]

Sadly it doesn't even generate a log, because the program never loads at all, whether in compatibility mode or not.  I get the "application failed to initialize properly" dialog box and that's that.

[JODY]

It seems this version of Mame isn't the only one running some vector games too fast.  I have an Asteroids cocktail and the latest version of MameUI64 has Asteroids running a lot faster than my cocktail machine.  I didn't realize Mame had it so wrong.

[Gravitar]

It seems this version of Mame isn't the only one running some vector games too fast.  I have an Asteroids cocktail and the latest version of MameUI64 has Asteroids running a lot faster than my cocktail machine.  I didn't realize Mame had it so wrong.

I was wondering about that as well... MAME vector games feel too fast and they got faster compared to the previous MAME versions.

Can you please report it here.
http://www.mameworld.info/ubbthreads/postlist.php?Cat=&Board=mamechat&page=0&view=expanded&sb=5&o=

[krick]

Currently, a default resolution of 640x480 is used for all vector games. As you say, this ignores orientation, which is the problem of tempest and others. But we're also making a suboptimal use of the monitor's potential resolution. We should always go for the highest possible resolution, but this is refresh dependent. The 'virtualize' feature in GroovyMAME does right this: it calculates the highest possible resolution for a given refresh, within the monitor specs. So this is indeed what we should do for vector games: virtualized resolutions - now, most people are used to set an unique 'highest' resolution for all vector games, so they will complain about this behaviour, and specially about those crazy high resolutions above 640x480 they will want to remove with my-monitor-just-supports-up-to-640x480 kind of argument, but that's a different story -

On the other hand we have the odd refresh these games usually have. For raster CRTs we normally move in the 50-60 Hz range, so what GroovyMAME does with a refresh that's outside our defined limits is to set either the minumum or the maximum, depending on the value. Thus 40 Hz will become 50 Hz, etc. As -syncrefresh on is the default behaviour now, that means it will run at 125%. You can override this by enabling -triplebuffer manually, but it seems like a good idea to implement this programmatically.

Is there anything that can be done in a vector.ini (or game-specific ini files) to fix tempest and other vector games in GroovyMAME, or does it require programming changes?

If programming changes are required, are they complex, or is something I could fiddle with myself?  I've looked at the GroovyMAME code, but I don't really know what, specifically, needs to be changed to fix the problem with vector games.  It would be cool if we could get this worked out before MAME 0.147 is released.

[Calamity]

Hi krick,

By now, disabling -cleanstretch in the command line seems to do the trick, however it's important to notice that it's not the same thing as adding the option to an ini file. As you know, there are priorities for options in MAME, depending where they're stated. The Switchres patch in GM can modify some options on its own, overriding anything specified in an ini file. However, the Switchres priority was designed to be just below the command line priority. Now it seems reasonable to modify this so that the Switchres priority is below the game's ini but above the main mame.ini file. This should be particularly easy to modify in the code.

However, adding a dynamic resolution support for vector games, as explained above, will need a partial rewrite of the Switchres code. I've schedulled a full review of the Switchres code for this August, as soon as I am on vacation, hopefully the stars line up and I can finally get a spare week to mess with this stuff.

[krick]

I played around with GroovyMAME 0.147u3 SwitchRes v0.014 tonight.

I'm using XP x64, a Radeon X600XT, and a Hantarex Polo "standard" resolution monitor.
I'm using the "H9110" preset in VMMaker, as well as in my mame.ini.

I only tried three vector games, but the results seemed a little odd.  It's possible that I don't have something configured correctly, or that my monitor needs a cap kit or something.

Basically, with Tempest, the screen had to be squashed down (think mega-letterboxing) to get a clear picture.  If I tried to use my monitor adjustments to stretch the picture vertically, the convergence (I think that's what it's called) got all out of whack.  Basically a doubled, blurry image.

Space Fury, on the other hand was infinitely more weird.  The image was rotated 180 degrees and mirrored for reasons I don't understand.  It was also somewhat difficult to get a clear picture, but it seemed to be somewhat better than the last build of GroovyMAME where it was nearly impossible to get a picture that wasn't doubled.

I tried Star Wars, and the only problem was that it was very dark.  I created a custom vector.ini which seemed to make it much better.  So good job there.

I've attached logs for your viewing pleasure.

[Calamity]

Hi Krick,

The problem with tempest may be related to the Polo not supporting high horizontal frequencies properly. We're basically using the H9110 presets for the Polo. Try reducing HfreqMax to a more sensible value:

15625.00-16670.00,49.50-65.00,2.000,4.700,8.000,0.064,0.160,1.056,0,0,192,288,448,576

Try something like 16200.

Yes, the spacfury case is very odd but not the only one, I have the same problem here with some vectors. It seems to be related to the new management of the rotating options in GM. Enabling the -rotate option for this game fixes the problem.

As a note, there's some work going on for vector HLSL post-processing in MAME:
http://git.redump.net/mame/commit/?id=2395141d99941797e21421feb6368d2fe7fe252f

[krick]

The problem with tempest may be related to the Polo not supporting high horizontal frequencies properly. We're basically using the H9110 presets for the Polo. Try reducing HfreqMax to a more sensible value:

15625.00-16670.00,49.50-65.00,2.000,4.700,8.000,0.064,0.160,1.056,0,0,192,288,448,576

Try something like 16200.

I'll mess with that tonight if I get some time.
Are there any similar non-vector games that I should experiment with?

As a note, there's some work going on for vector HLSL post-processing in MAME:
http://git.redump.net/mame/commit/?id=2395141d99941797e21421feb6368d2fe7fe252f

Yeah, I saw that.  I hope that when they're done that vector games work on arcade monitors.  I'm a little worried.

[Calamity]

I'll mess with that tonight if I get some time.
Are there any similar non-vector games that I should experiment with?

Well now that you said that in the other thread that pacman looks good then I'm starting to doubt that hfreq is the problem here, as this one must be using the top hfreq available too, and still looks good.

I'm not sure what you mean when you say the image is doubled. The behaviour now for vector games is that GM will pick the highest possible resolution for a given refresh. This is usually going to be an interlaced resolution for standard arcade monitors, but other interlaced resolutions look properly on your monitor... So one thing you could try is to use a fixed resolution for vector games, defined in vector.ini (e.g. -resolution 720x480@60, however this one will still be recalculated so to achieve the different demanded refresh rates.

Yeah, I saw that.  I hope that when they're done that vector games work on arcade monitors.  I'm a little worried.

At the very least you're going to need an HLSL capable card to enjoy that feature.

[krick]

Well now that you said that in the other thread that pacman looks good then I'm starting to doubt that hfreq is the problem here, as this one must be using the top hfreq available too, and still looks good.

I'm not sure what you mean when you say the image is doubled. The behaviour now for vector games is that GM will pick the highest possible resolution for a given refresh. This is usually going to be an interlaced resolution for standard arcade monitors, but other interlaced resolutions look properly on your monitor... So one thing you could try is to use a fixed resolution for vector games, defined in vector.ini (e.g. -resolution 720x480@60, however this one will still be recalculated so to achieve the different demanded refresh rates.

I've attached a bunch of pictures to illustrate the issue.  Note that I jacked up the brightness and contrast so that you can see the vertical height of the image on the monitor more easily.

In the "good" pictures, I have the "Vertical Amplitude" adjustment on my monitor set so that the image is squashed vertically somewhat.  With the brightness turned up, you can see this clearly with the black "letterbox" areas at the top and bottom of the monitor.

In the "bad" pictures, I adjusted the vertical amplitude on my monitor so that the image fills the screen (i.e. no letterbox).  As I make the image taller, the convergence (if that's the correct word) gets really bad and the image doubles.  You can see it more clearly in the close-up shots of the text.

One other observation...  I notice that there appears to be a lot of extra space between the high score and the top of the display area.  You can see this best in the first picture (tempest-good-1.jpg) I don't know if this is related in any way.

[Calamity]

Hi krick,

This problem is totally new to me, it's like if the two fields of the interlaced mode were shifted vertically by several lines. I'm trying to imagine how this would happen from a low level/electronics point of view. Have you noticed if the vertical-shift control on your monitor's board has any affect on this? Both fields react the same? Just out of curiosity.

For practical purposes I would restrict the possibility of these resolutions being used by forcing the a fixed resolution in vector.ini.

[krick]

I'll fiddle with the vertical shift tonight when I get home.   It's possible that my monitor is just old and needs a cap kit.  It's on my to-do list, but I'm afraid that I'll end up with something worse than what I started with, so I've been avoiding it.

The effect is as you say, once I get beyond a certain point with the vertical amplitude control, the interlaced images start to diverge and get progressively worse and more jumpy.  Then if I keep going further, they align again, except it looks like there is a blank line, every-other line.  I'll have to post a picture so you can see what it looks like.    However,  the image is so large that the top and bottom are severely cut off, so it's not usable for anything.

I want to experiment with some non-vector interlaced games to see if it's a vector problem or an interlace problem.

Can you suggest some interlaced vertical (and horizontal?) games that would be good to test with?

You never commented on the extra space at the top above the score.  Is this normal, or is it a side effect of jamming a vertical game into a horizontal resolution?

[Calamity]

For interlaced non-vector games, try running vertical games like: twincobr (54.8 Hz), donpachi (57.55Hz), 1945kiii (60 Hz).

The black gap on top of the tempest game seems to be by design, I can see it here too.

[krick]

OK, I did a little more detective work with just vector games, and I think I figured out the problem.
My monitor has problems displaying certain interlaced resolutions over 50 Hz.

tempest, asteroid, and astdelux -- GroovyMAME picks: 768x512@60  --  all have the problem.

starwars, cchasm, mhavoc -- GroovyMAME picks: 768x576@50 (or 49.5)  -- all are fine.

I didn't test every vector game, but the pattern so far is that any game with a refresh at 60 Hz, horizontal or vertical, has the problem on my monitor.  So using my list of games in the first post of this thread, that would be...

horizontal @ 60Hz - astdelux, asteroid, bwidow, gravitar, redbaron, topgunnr
vertical @ 60Hz - quantum, raaspec, tempest

...again, this is just parent sets.  Many of them have clones.

I tried manually forcing tempest to run at a different resolution, both from the command line and also from vector.ini and I wasn't successful, as I think GroovyMAME ignores the refresh rate.

I assume that any raster games running at these interlaced resolutions @60 Hz will also exhibit the same problem, but I haven't done any testing to be sure.


Also, during my testing, I found more games that display upside down and mirrored...

starcas, wotw, zektor, startrek, and spacfury (which I mentioned before)

...it seems like they're all 38 or 40 Hz games.  The odd thing is that not all games in those two groups have the problem.  I think that omegrace and bzone were OK, so I'm not sure what to make of that.

[Calamity]

Hi krick, thanks for your tests.

OK, I did a little more detective work with just vector games, and I think I figured out the problem.
My monitor has problems displaying certain interlaced resolutions over 50 Hz.

tempest, asteroid, and astdelux -- GroovyMAME picks: 768x512@60  --  all have the problem.

starwars, cchasm, mhavoc -- GroovyMAME picks: 768x576@50 (or 49.5)  -- all are fine.

Well it could be that, or possibly the horizontal frequency (being the vertical frequency a derived factor but not the cause). In order to discard this, if you had a chance test tempest and starwars, and see which horizontal frequency is calculated for each of them. If it's more or less the same, then the problem is definitely vertical refresh related.

I tried manually forcing tempest to run at a different resolution, both from the command line and also from vector.ini and I wasn't successful, as I think GroovyMAME ignores the refresh rate.

Yeah, that will only work for the resolution, but the refresh is overridden by GM. There's something you can do however, you can define custom monitor specs in vector.ini that only affect the vertical games, and there redefine the vertical frequency work ranges.

Also, during my testing, I found more games that display upside down and mirrored...

I definitely need to have a look at that, adding it to my to-do list.

[krick]

Well it could be that, or possibly the horizontal frequency (being the vertical frequency a derived factor but not the cause). In order to discard this, if you had a chance test tempest and starwars, and see which horizontal frequency is calculated for each of them. If it's more or less the same, then the problem is definitely vertical refresh related.

I attached logs from both games earlier in this thread.  I'm not sure where in the logs the chosen horizontal frequency shows up.

However, when diff-ing the two logs with BeyondCompare, I see that Tempest actually starts out at 640x480, then does a resolution switch to 480x640.  Could this be relevant?

Also, why isn't Tempest defined with a vertical resolution in MAME in the first place?

[Calamity]

Hi krick,

According to your logs, the mode that's 50 Hz and looks good it's also on the lower Hfreq range around 15.70 kHz, so both things should be considered. With the new patch (014) you can create two ranges in order to have separate settings for progressive and interlaced games: 

crt_range0 15625.00-16670.00,49.50-65.00,2.000,4.700,8.000,0.064,0.160,1.056,0,0,192,288,0,0
crt_range1 15625.00-16000.00,49.50-65.00,2.000,4.700,8.000,0.064,0.160,1.056,0,0,0,0,448,576

Here crt_range1 is just for interlaced modes, and I'm lowering HfreqMax to a more conservative value. Another option is to limit the vertical frequency to, say: 50-55 Hz:

crt_range1 15625.00-16670.00,50.00-55.00,2.000,4.700,8.000,0.064,0.160,1.056,0,0,0,0,448,576

[krick]

Had some time to experiment with this tonight and I'm seeing odd behavior.

If I make a single line for both progressive and interlaced games like this, it works just like the h9110 preset...

crt_range0 15625.00-16670.00,49.50-65.00,2.000,4.700,8.000,0.064,0.160,1.056,0,0,192,288,448,576

...and tempest runs at 768x512@60 (interlaced) like normal

But if I split it into two lines, both with the same settings with one each for progressive and interlaced like this...

crt_range0 15625.00-16670.00,49.50-65.00,2.000,4.700,8.000,0.064,0.160,1.056,0,0,192,288,0,0
crt_range1 15625.00-16670.00,49.50-65.00,2.000,4.700,8.000,0.064,0.160,1.056,0,0,0,0,448,576

...then tempest runs at 344x256@60 (progressive)

It doesn't make any sense.  I would expect it to run at the same exact resolution/refresh as the first one.  Am I doing something wrong?

I was trying to establish a baseline before I started making frequency modifications, but it doesn't behave the way I expected.

[Calamity]

No, it shouldn't work like that, definitely. I'll need to have a look to it.

[Calamity]

Ok, just tested here and it's working fine regarding the different ranges, etc. I've attached my mame.ini and two logs, one with HfreqMax of the interlaced range set as 16.20 kHz, the other as 16.67 kHz. You can see how different resolutios are selected in either case due as an attempt to achieve 60 Hz as vertical refresh rate.

EDIT: I'm thinking you probably left one "crt_range1 auto" line uncommented, that might be the issue.

[krick]

EDIT: I'm thinking you probably left one "crt_range1 auto" line uncommented, that might be the issue.

/facepalm
Yep.  That's exactly what I did.  Once I comment that out, it works fine.  Sorry to waste your time on a goose chase.


With it working, I'm not entirely pleased with the results though, and I expect that there's not really anything that can be done.

Reducing the horizontal frequency range forces the game to run at 640x480@60, but it still has the problem that I can't adjust the monitor to vertically to fill the screen without getting that doubling effect again.

Reducing the vertical frequency forces the game to run at a low-res progressive resolution (I didn't take note of which one) but that's not appealing either.

So in the meantime, I'll just use the default h9110 preset and live with the smaller image at the higher resolution.  Eventually, I'm going to have to do a cap kit on this monitor and maybe (hopefully) it will fix the problem.

[Calamity]

No problem.

You can still force a given resolution like 1234x576@54 (make sure it exists) for all vector games through a vector.ini file. Use the -resolution option. That resolution will pass through the crt_range1 frequency filter.

[mm_can]

Also, during my testing, I found more games that display upside down and mirrored...

I definitely need to have a look at that, adding it to my to-do list.

I also found along with the upside down and mirroring, my spinner control for Zektor is backwards.  Makes for an interesting game!

MM

[rickarcade]

EDIT: I'm thinking you probably left one "crt_range1 auto" line uncommented, that might be the issue.

/facepalm
Yep.  That's exactly what I did.  Once I comment that out, it works fine.  Sorry to waste your time on a goose chase.


With it working, I'm not entirely pleased with the results though, and I expect that there's not really anything that can be done.

Reducing the horizontal frequency range forces the game to run at 640x480@60, but it still has the problem that I can't adjust the monitor to vertically to fill the screen without getting that doubling effect again.

Reducing the vertical frequency forces the game to run at a low-res progressive resolution (I didn't take note of which one) but that's not appealing either.

So in the meantime, I'll just use the default h9110 preset and live with the smaller image at the higher resolution.  Eventually, I'm going to have to do a cap kit on this monitor and maybe (hopefully) it will fix the problem.

Hi krick,

Have you changed the cap kit on your monitor ? Is the problem fixed ?
Or have you found a crt config values set that is OK?
I have exactly the same problem as you ! The image is good(too images are in sync) only if the height is adjusted too small(like you) or too big(out of screen), if i adjust height to fit the screen i got a doubled  image.

My monitor is a Nokia A51-250-x.
GroovyArcade.

I know this tread is 1 year old, but maybe .....

BTW: Thanks too all members, i have found a lot of good help in this forum.

arcaderick

[u-man]

I will *bump* this thread too .

I just wanted to know, how far the development in GroovyMAME has come, regarding Vector-Games, as the thread is a little old.

Just want to be up-to-date, because I actually have some plans, regarding vector-shader-development.

[krick]

Hi krick,

Have you changed the cap kit on your monitor ? Is the problem fixed ?
Or have you found a crt config values set that is OK?
I have exactly the same problem as you ! The image is good(too images are in sync) only if the height is adjusted too small(like you) or too big(out of screen), if i adjust height to fit the screen i got a doubled  image.

My monitor is a Nokia A51-250-x.
GroovyArcade.

I know this tread is 1 year old, but maybe .....

I don't know how I never saw this post.  Sorry about that.

I never did find a solution for Tempest.  I just run it as-is, which has a large-ish border at the top.  I think that's evidence that possibly something is wrong with the way the resolution for Tempest is coded in MAME.

I still haven't done a cap-kit on my monitor.  Most games are fine, so I'm thinking that Tempest is just an oddball.

[krick]

I know it's been a while, but I finally got around to rebuilding my MAME pc with the latest GroovyMAME...

Intel Pentium G3258 overclocked to 4.5GHz
Windows 7 64-bit
AMD HD 7750
Hantarex Polo 25 standard res arcade monitor
CRT_EmuDriver 2.0 Beta 8
groovymame64_0171.015m
"super" resolutions
"Arcade 15.7 kHz" preset

...and it looks like all of the vector problems I posted earlier in this thread are gone except for the back border at the top of Tempest, but I think that's a problem with mainline MAME.

The mame.ini setting options have changed so now I have (only) the following options in a file named vector.ini...

contrast 2.0
gamma 2.0
beam_width_min 2.0
beam_width_max 2.0

Thank you, Calamity for everything you do for this community.