Switchres: modeline generator engine

[Calamity]

Hi there, I notice there's a sudden interest for the XP64 thing Current support is only for XP32. Being targeted for the arcade context, I thought it would be enough for a decade, but I see many people moving to the 64 bits XP so I'm actually going to try and patch Catalyst 9.3 for XP64. Be aware there's no official support for the 9250 and older Radeon chipsets for XP64, for what I'm seeing in the AMD support site, so this will only support the newer cards (I might be wrong, if someone has better info on this please let me know!).

[bitbytebit]

Hi calamity, does your driver work with Windows XP 64 bit?

bitbytebit, I tried your distro but had some problems. I'll be back to that when I have more time.

When you have time, tell me everything that went wrong, I actually enjoy the negative feedback best because it always results in lots of improvements and bug fixes . 

[Calamity]

I tried the driver on my Xp64 cab about 50 minutes ago; did an 'update driver' from the control panel, and it booted into 640x480x4bit and wouldn't change resolution. I wasn't sure if it was an issue with the driver or if I needed to do a full uninstall/reinstall.

I always do a full uninstall/reinstall, and even use Catalyst Uninstaller in the middle, with my fingers crossed. There are MANY problems I've seen here and there that turned out to be produced by drivers not installing properly or just installing partially with no error message from the system. That's unfortunately a dirty area in Windows. This driver should actually not install itself in XP64 if run from its setup, I believe...

[newmanfamilyvlogs]

Well I'll look forward to seeing you have a patched up XP64 driver. On my setup I've got a 4350, so its a relatively newer card.

XP64, to me, seems like the ideal OS for a cabinet running an actual arcade monitor; you get the speed boost of 64bit mame along with proper support for Soft15kHz.

[rjpe]

Hi calamity, does your driver work with Windows XP 64 bit?

bitbytebit, I tried your distro but had some problems. I'll be back to that when I have more time.

When you have time, tell me everything that went wrong, I actually enjoy the negative feedback best because it always results in lots of improvements and bug fixes . 

I tried AVGA 9250, and installed the system to a 32GB SSD. I went the hard way, using my scart-tv as the monitor... so I had geometry problems and couldn't see the whole screen. I tried to lauch the free roms, but then the keyboard didn't respond anymore - that happens when the resolutions/sync are not ok. I didn't invest much time (It was late ...). As a first impression, the distro looks very good. I'd not consider the net config mandatory - my cabinet lies on the garage, without internet or network access, I think that I'm not the only one. It is my first Gento Linux experience   I stopped investing in Linux when Fedora arrived due to professional changes. I might have installed ubuntu and fedora a couple of times, but that was it! I've to refresh my Linux skills!  

I was using my current cabinet has the ginny pig (using dual boot). I have an old PIV 1.5GHz waiting for some action, I'll use this one as the testing suite machine.
Next weekend I'll be more patient, and start with a computer monitor, then test the TVs.

[rjpe]

Well I'll look forward to seeing you have a patched up XP64 driver. On my setup I've got a 4350, so its a relatively newer card.

XP64, to me, seems like the ideal OS for a cabinet running an actual arcade monitor; you get the speed boost of 64bit mame along with proper support for Soft15kHz.

You're reading my mind! 
Just kidding - I agree that XP64 + Soft15Khz is great for 64-bit CPU's, mame64 works much better than regular 32-bit. It is a shame that 9250 (and AVGA AGP) doesn't have 64-bit support. I imagine that many members of this forum would LOVE to have a 64-bit driver for any RADEON 9xxx.

[bitbytebit]

Hi calamity, does your driver work with Windows XP 64 bit?

bitbytebit, I tried your distro but had some problems. I'll be back to that when I have more time.

When you have time, tell me everything that went wrong, I actually enjoy the negative feedback best because it always results in lots of improvements and bug fixes . 

I tried AVGA 9250, and installed the system to a 32GB SSD. I went the hard way, using my scart-tv as the monitor... so I had geometry problems and couldn't see the whole screen. I tried to lauch the free roms, but then the keyboard didn't respond anymore - that happens when the resolutions/sync are not ok. I didn't invest much time (It was late ...). As a first impression, the distro looks very good. I'd not consider the net config mandatory - my cabinet lies on the garage, without internet or network access, I think that I'm not the only one. It is my first Gento Linux experience   I stopped investing in Linux when Fedora arrived due to professional changes. I might have installed ubuntu and fedora a couple of times, but that was it! I've to refresh my Linux skills!  

I was using my current cabinet has the ginny pig (using dual boot). I have an old PIV 1.5GHz waiting for some action, I'll use this one as the testing suite machine.
Next weekend I'll be more patient, and start with a computer monitor, then test the TVs.

Cool thanks, yeah the scart support with a TV isn't well tested or even tested at all actually.  So suspect there's issues there to be figured out.

Yeah I need to definitely redo some of the menu dependencies, thanks, I'll make the network one non-mandatory and look into some other similar changes there.

[dmarcum99]

I don't know if anyone has looked, but GURU3D has some 64-bit XP drivers that work with the 9200 series. 

I've used them and they're OK.  I can't remember which one worked though....somewhere between the 6.2's and 6.6 CATS.  YMMV  All of these said they work, but I only got one to install....and it wasn't signed.  But I bounced back to 32bit again and I can't remember which version it was.

Maybe CALAMITY can use one of these and make it work for the 64 bit'ers.

I've got both cards....a 9250 and a 4350 so I'm good either way when a CALAMITY'D 64 bit driver surfaces.   

[Calamity]

I don't know if anyone has looked, but GURU3D has some 64-bit XP drivers that work with the 9200 series. 

I've used them and they're OK.  I can't remember which one worked though....somewhere between the 6.2's and 6.6 CATS.  YMMV  All of these said they work, but I only got one to install....and it wasn't signed.  But I bounced back to 32bit again and I can't remember which version it was.

Maybe CALAMITY can use one of these and make it work for the 64 bit'ers.

I've got both cards....a 9250 and a 4350 so I'm good either way when a CALAMITY'D 64 bit driver surfaces.   

dmarcum99, thanks a lot for pointing that. I've found these ones:

http://downloads.guru3d.com/ATI-Catalyst-6.4-%28x64%29-download-1375.html#download
http://downloads.guru3d.com/Catalyst-6.5-Windows-XP-Pro-%2864-bit%29-download-1408.html

The Radeon 9200/9250 are not officially supported but I've read some people have managed to make them work by adding those models to the .inf file, so I think I'll be able to do that too. So there's a chance we can have that for x64, provided the binary patch actually works (have never patched 64bits binaries so this is new to me).

[rjpe]

Hi Calamity,

If you need, I can test 3 different RADEON 9250 on XP64 (Asus 128MB, Powercolor 256MB and Arcade VGA 128MB).
Waiting for your developments!

[Calamity]

Hi Calamity,

If you need, I can test 3 different RADEON 9250 on XP64 (Asus 128MB, Powercolor 256MB and Arcade VGA 128MB).
Waiting for your developments!

That will be great. Testing drivers requires to have a system with the specific hardware/software and sometimes it's hard for a single hobbyist man to have every variant ready for testing. I'll post the links in this thread when I have something done, may take me a while yet anyway.

[newmanfamilyvlogs]

I've been tinkering with the newest build with switchres incorporated. I do not have calamity's drivers installed since we're waiting on him to see if he can patch the 64bit drivers, but it should still generate and switch to modes correctly, right?

It still seems to be stretching the image in some instances. Bubble Bobble should run at 256x224. Once it's up and running the screen is set to 256x240, but the image is stretched to fill the extra lines, resulting in some ugly artifacting.

I've deleted and recreated my mame.ini, what setting should I check so it doesn't do this?

[bitbytebit]

I've been tinkering with the newest build with switchres incorporated. I do not have calamity's drivers installed since we're waiting on him to see if he can patch the 64bit drivers, but it should still generate and switch to modes correctly, right?

It still seems to be stretching the image in some instances. Bubble Bobble should run at 256x224. Once it's up and running the screen is set to 256x240, but the image is stretched to fill the extra lines, resulting in some ugly artifacting.

I've deleted and recreated my mame.ini, what setting should I check so it doesn't do this?

It's a bug that happened in porting the code.  I just fixed it, hopefully really is fixed, but at least from what I can tell it should be.  There were some useless height/width checks that set virtualization to happen, in the old code they were actually thrown away and in the new code I fixed that issue.  Well I guess in the old code the throw them away part was actually good, and so now I removed them completely.

It'll be up in a few minutes as version .004, the patches are updated already.

Thanks for finding that

[newmanfamilyvlogs]

Very nice. I'll be sure to check it on my cab as soon as I can. I only really have time to tinker with settings early in the morning, between 5:30am and 6:00am, before the family wakes up. Sometimes it's just too early to be motivated (:

[Calamity]

Very nice. I'll be sure to check it on my cab as soon as I can. I only really have time to tinker with settings early in the morning, between 5:30am and 6:00am, before the family wakes up. Sometimes it's just too early to be motivated (:

Reading this forum from GMT+1 time zone, messages timestamps are somehow disconcerting, sometimes you wonder if some people have any sleep at all 

This weekend hopefully I'll have some time to install x64 in my cab and try to do some patches to the drivers.

[bitbytebit]

http://mame.groovy.org/0141u3/

I've rewritten the cabmame patches completely, no longer really have any extra mame options and they automatically just enable themselves.  You can turn off soundsync though, and this has the separate changes to the hiscore patch from MKChamp that allow it to work with Linux.  Definitely aimed at Arcade Monitors and avoiding need for triplebuffer, utilizing the vsync of the ATI Radeon video cards.  Also the cleanstretch/changeres support should be better now, at least done in a way that seems to do a bit better than previously.

[newmanfamilyvlogs]

Looks good so far, with one issue.. When I exit from a game, Hyperspin doesn't seem to notice that it's exited until I've alt-tabbed off and back to it. I'll do more experimenting with it in the next few minutes to see what I can figure out.

[bitbytebit]

Looks good so far, with one issue.. When I exit from a game, Hyperspin doesn't seem to notice that it's exited until I've alt-tabbed off and back to it. I'll do more experimenting with it in the next few minutes to see what I can figure out.

Odd, might try to double check with using nomodeline in the config file too, and see if it also does the same when the code is disabled basically.  Not sure how it would cause it to do that on exit, might be a slight bit of extra time exiting because of having to reset the registry modeline, although I know that hyperspin does have an odd check at exit that might try and kill off the emulator instead of letting it exit peacefully . 

[newmanfamilyvlogs]

The 'kill off' feature is using Hyperlaunch, I think, which I am not using. I'll try with the modeline option off when I can.

I didn't get a chance to actually play a game with it, but I ran World Class Bowling before shutting it down for the day and it looked like it was having vsync speed issues.. It looked like it was running too fast. I'll follow up on this when I can.

[bitbytebit]

The 'kill off' feature is using Hyperlaunch, I think, which I am not using. I'll try with the modeline option off when I can.

I didn't get a chance to actually play a game with it, but I ran World Class Bowling before shutting it down for the day and it looked like it was having vsync speed issues.. It looked like it was running too fast. I'll follow up on this when I can.

Yeah might want to try turning off multithreading see if that makes a difference, otherwise vsync issues of course could be the card having issues with vblank working properly.  Also might try recreating the mame.ini to make sure the defaults, which are different, are mostly set right.  Will see how this version works for Calamity too since he has a working Windows setup known to work with previous versions, so can double check to make sure I've gotten everything working still in the latest patches/builds.

[Calamity]

I've tested the new GroovyMame and it's working perfectly here when launching it from AdvanceMenu. I have created a new mame.ini for testing. The new soundsync option is working great too, now it needs to be enabled from mame.ini.

There is a problem with games that switch their resolution, like Golden Axe II, for some reason the resolution switch fails and I have to shut the program from the taskbar. This already happened in the previous version, so it seems there is a bug with the changeres and ddraw combination, I'll keep testing.

[bitbytebit]

I've tested the new GroovyMame and it's working perfectly here when launching it from AdvanceMenu. I have created a new mame.ini for testing. The new soundsync option is working great too, now it needs to be enabled from mame.ini.

There is a problem with games that switch their resolution, like Golden Axe II, for some reason the resolution switch fails and I have to shut the program from the taskbar. This already happened in the previous version, so it seems there is a bug with the changeres and ddraw combination, I'll keep testing.

Yeah I've wondered about the resolution switching, seems odd how that's done in windows, did that really work smoothly in the past?  I am not actually repeating the modeline setup when the change happens, I'm not fully sure if that's necessary or what goes on but just know the ddraw instance is destroyed from being signaled by the change of resolution in the render/emu core. Right now it really should basically follow the same as cabmame would do it, I changed around the general structure and also now fixed the problems with it not allowing scaling to work (cleanstretch and changres together or separate should really be working better now, I completely recoded that a lot different than it had been done in cabmame).  If it doesn't work either in the last version, the at least good to know the current change didn't break it, but suspect it wouldn't and seems to possibly be something more to do with how that tear down of the drawing layer is supposed to bring it back up at a new resolution (does the logic really get redone to pick a new resolution, not sure how any of that would just happen in the code as I see it in mame).  I know in the Linux side it's a big headache to figure out what to do, how to exit/re-enter SDL which is required to get a new resolution into SDL to work.

[Calamity]

I'll have a look at the changeres option code and patches, I never really looked at that thoroughly. I believe I've seen it working in CabMame, but there was always the problem of not being able to recalculate the new modeline, and maybe the pick best mode logic used was the default one in Mame so you had no control on the results.

[bitbytebit]

I'll have a look at the changeres option code and patches, I never really looked at that thoroughly. I believe I've seen it working in CabMame, but there was always the problem of not being able to recalculate the new modeline, and maybe the pick best mode logic used was the default one in Mame so you had no control on the results.

Yeah to recalculate the modeline, shouldn't be difficult now at all, but of course there is the question of when to do so and when to let go and delete the old one.  So in the code it's pretty hard to tell what really will happen, but I'll look at it closer too since once understanding and getting the Windows side working, that would help me figure out the SDL/Linux side of things possibly. 

[ves]

Hi, I'm testing the new version 1495, passing logs.

Do not install if you do not set the network and sound.
At the Disco Option gasetup, I think the definition of Livecd Stateful, is confusing and should be home.
You should put one to reset the settings on the menu.

If groovymame included because it is still used and switchres.conf switchres?
Not in mame.ini switchres options, if you create the new mame.ini if there are options.

Fails to duplicate Wminput absolute axis, the error is in mamebuttons
Cassic.lstick.X / Y

I saw that you put on the git support suckle cwiid gun, have modified some of the code?
Because you have not put the gun to use 2 players?


Thank

[Calamity]

Hi bitbytebit. I'm having problems applying the new patches. I think I'm following the right order, I'm applying u1 -> u2 -> u3 -> hi_141u3 -> u3_hilinux and here is where the problems start. I normally use two trees: \a and \b, (\a for the original source, \b for the patched source). For some reason your new patches are creating a subfolder \b inside \b if I point to the same paths I use for the other patches. If I don't point to \b but to the parent folder where \b is, then the files seem to be properly targeted but I get some files patched in my \a folder! So maybe you're using a different logic there, anyway I'm not very good using these diff tools.

[bitbytebit]

Hi bitbytebit. I'm having problems applying the new patches. I think I'm following the right order, I'm applying u1 -> u2 -> u3 -> hi_141u3 -> u3_hilinux and here is where the problems start. I normally use two trees: \a and \b, (\a for the original source, \b for the patched source). For some reason your new patches are creating a subfolder \b inside \b if I point to the same paths I use for the other patches. If I don't point to \b but to the parent folder where \b is, then the files seem to be properly targeted but I get some files patched in my \a folder! So maybe you're using a different logic there, anyway I'm not very good using these diff tools.

I usually create the patches using a git repository.  If you go into the directory of mame (where the makefile is) itself, the run 'cat ../patch1.diff | patch -p1' for each patch in order (after the original uX patches and then the hiscore patch, which will require -p0), they should apply clean.  I'm not sure what it's doing, odd, but should work right if doing it this way instead. 

[bitbytebit]

Hi, I'm testing the new version 1495, passing logs.

Do not install if you do not set the network and sound.
At the Disco Option gasetup, I think the definition of Livecd Stateful, is confusing and should be home.
You should put one to reset the settings on the menu.

If groovymame included because it is still used and switchres.conf switchres?
Not in mame.ini switchres options, if you create the new mame.ini if there are options.

Fails to duplicate Wminput absolute axis, the error is in mamebuttons
Cassic.lstick.X / Y

I saw that you put on the git support suckle cwiid gun, have modified some of the code?
Because you have not put the gun to use 2 players?


Thank

Yeah I've changed that already for the next ISO, i'll no longer require sound/network setup to install.  The live stateful directory is kinda weird sounding, mostly was trying to say that it isn't really necessary unless your just wanting to use a liveCD and really a home directory is not necessary if your doing an install.

Switchres will be there for the other emulated games still, so it's necessary.  Mame will be the groovymame and eventually just be that, because I'm not going to maintain the old mame patches since they aren't really necessary now that it is built into mame, so mame itself won't use switchres anymore probably in the next ISO (but the option in the setup will setup mame in the mame.ini with the correct monitor and orientation still).

The cwiid support right now is really just to get it in there to allow setup and testing manually, I know there's definitely more to do with that but I haven't had time to figure out the setup for things like 2 players in the ISO.

[bitbytebit]

Note that the git repository has now changed.  The main mario.groovy.org page reflects the changes if wanting to checkout through git, or see the changelog or browse the repository.

http://git.groovy.org/trac/groovy_groovyarcade/log/

[Calamity]

Yesterday I finally installed x64 for testing, I've patched Catalyst 9.3 for XP64, I'm testing it here and seems to work well. The patch is slightly different from the other one, it allows up to 127 custom modes. It also has the other fix to disable doublescan for 320x and 400x modes. I've updated this .rar with the new VMMaker and ArcadeOSD. Although it's working here, bear in mind this is a beta version so in case you get a blue screen or something just restart with f8 and unistall. Try this link:

http://www.megaupload.com/?d=LXF3NDHL

The only problem I'm seeing is the usual with Hyperspin not loading. For some reason the patch has some side effect when the number of modes is above some limit, that prevents Hyperspin from loading.

If I get this version working I'll go on with the 6.5 one, to support the older cards.

Update: I updated the link, uploaded it to megaupload as my server is failing when downloading large binary files.

I've trying GroovyMame with this driver and it works great. You can just use the default mode table that the driver installs, no need to run VMMaker unless you want to tweak something. So just install the driver, restart and run GroovyMame, it will recognize the installed modes and recalculate modelines as required.

[bitbytebit]

Yesterday I finally installed x64 for testing, I've patched Catalyst 9.3 for XP64, I'm testing it here and seems to work well. The patch is slightly different from the other one, it allows up to 127 custom modes. It also has the other fix to disable doublescan for 320x and 400x modes. I've updated this .rar with the new VMMaker and ArcadeOSD. Although it's working here, bear in mind this is a beta version so in case you get a blue screen or something just restart with f8 and unistall. Try this link:

http://www.megaupload.com/?d=LXF3NDHL

The only problem I'm seeing is the usual with Hyperspin not loading. For some reason the patch has some side effect when the number of modes is above some limit, that prevents Hyperspin from loading.

If I get this version working I'll go on with the 6.5 one, to support the older cards.

Update: I updated the link, uploaded it to megaupload as my server is failing when downloading large binary files.

I've trying GroovyMame with this driver and it works great. You can just use the default mode table that the driver installs, no need to run VMMaker unless you want to tweak something. So just install the driver, restart and run GroovyMame, it will recognize the installed modes and recalculate modelines as required.

Sounds really cool, I like having the modeline table built in, will be great to have this and the 32 bit driver available to download with groovymame and make it simple as possible for people to use. 

[newmanfamilyvlogs]

The only problem I'm seeing is the usual with Hyperspin not loading. For some reason the patch has some side effect when the number of modes is above some limit, that prevents Hyperspin from loading.

Well that's certainly a dealbreaker there. Any clue what's going on? Why would Hyperspin even be polling video modes?

[Calamity]

Well that's certainly a dealbreaker there. Any clue what's going on? Why would Hyperspin even be polling video modes?

Yes I'm afraid it is, many people here using Hyperspin. I have no clue why that happens. The patch I do of course is not the cleanest thing possible, so it must be overflowing some memory buffers but surprinsingly it works and the only application that seems to be affected with each new version is Hyperspin. The workaround is to define less video modes but then the fun is over. I don't know much of the Hyperspin project or if it's even possible to contact the developers, anyway I'll have a look at it, the solution could be to patch Hyperspin itself...

[newmanfamilyvlogs]

Yeah the developers are very active on the forum over at www.hyperspin-fe.com and Dazz is active here a good bit:

Profiles:
http://forum.arcadecontrols.com/index.php?action=profile;u=8047
http://www.hyperspin-fe.com/forum/member.php?u=2


Care to share some of the technical bits about what you're actually patching?

[Calamity]

I've written to Dazz, hopefully he can figure out what is happening. It could be the buffer they use to retrieve the system video modes is not big enough, just to think of a possible reason...

The file I'm patching is ati2mtag.sys. Basically what I do is to increase the number of modes the driver polls from the registry, like this:

Code: [Select]

 '.text:0000000000052EE7                 lea     r8d, [rsi+3Ch]
  '.text:0000000000052EEB                 lea     rdx, aDalnonstandard ; "DALNonStandardModes"

  PatchFileByte ( TargetFile, &h000424EA, 127 )
So that replaces 3Ch (60) by 127. I can't use a bigger number there cause it's a signed char so 128 is already negative.

Then I patch the instances where 140h and 190h are checked (320 and 400) to disable doublescan for those modes. There many of them, look like this:

Code: [Select]

 '.text:00000000000D1369                 cmp     r8d, 140h
  '.text:00000000000D1379                 cmp     r8d, 190h

  DATA 000C096C, 40, 00,  000C096D, 01, 00
  DATA 000C097C, 90, 00,  000C097D, 01, 00
I wouldn't mind uploading the full patch code at some point so someone else can help with this.

[bitbytebit]

Updated the Groovy Arcade ISO, mostly just using 0141u3 now, but also utilizes groovymame instead of switchres for mame too, rest of the emulators still use switchres.

07032011 - 1.500 Release
         - Improved menu setup logic for install
         - Gasetup modifed to configure mame.ini for groovymame settings
         - Use groovymame directly instead of switchres for mame, renamed to groovymame
         - Mame version 0141u3 update

[newmanfamilyvlogs]

Neat, that's fairly straight forward then.. Are you actually disassembling the .sys, or do you have some tool to view it like that?


One thing I'm still a little fuzzy on is why exactly the patched drivers are being suggested to be used with Groovymame if it's generating the modelines and updating the registry itself on the fly. Did I miss a post somewhere that spells it out?

[Calamity]

Neat, that's fairly straight forward then.. Are you actually disassembling the .sys, or do you have some tool to view it like that?


One thing I'm still a little fuzzy on is why exactly the patched drivers are being suggested to be used with Groovymame if it's generating the modelines and updating the registry itself on the fly. Did I miss a post somewhere that spells it out?

Some time ago I coded some tools for a specific reverse engineering project but now for this driver stuff I use a normal disassembler. The problem with drivers is that you can't use a normal debugger as they run in the system layer, so it's terribly hard to find what they're doing.

The main reason this drivers are suggested and not the regular Catalyst is: 120 vs 60 custom video modes. 60 is just not enough to accomodate a decent video mode table for emulation. Bear in mind we can't really add new resolutions (HxW), what we do is to recalculate the existing ones for the refresh rate we want. That's why we need more than 100 resolutions available to have plenty of different resolutions to tweak. So, remember:

Resolution: [xres, yres] -> (we can't define new (xres, yres) pairs on the fly, we need to have them available when the system starts)
VideoMode: [xres, yres, vfreq] -> (using the (xres, yres) pairs available, we can define an infinite number of (xres, yres, vfreq) triads)

[bitbytebit]

Neat, that's fairly straight forward then.. Are you actually disassembling the .sys, or do you have some tool to view it like that?


One thing I'm still a little fuzzy on is why exactly the patched drivers are being suggested to be used with Groovymame if it's generating the modelines and updating the registry itself on the fly. Did I miss a post somewhere that spells it out?

It can only change the refresh rate of an existing modeline, just like with powerstrip you must first have one with the same height and width in there as a resolution to alter the refresh rate.  I am not adding new modelines from groovymame itself, just utilizing existing ones custom added via another app like Soft15khz, VMMaker, PowerStrip or with the new driver from Calamity which is nice because it avoids adding them manually at all.  I really didn't want to mess with the registry that much, and it'd have to be a separate command to mame to generate the modeline table and you'd have to reboot to activate it.  I figured trying to manage the custom modelines in the registry for the user is getting a bit too overbearing, they can set it up  or have another program do so.  With a default Soft15khz install, things still work ok, just not fully amazing as when you have many more modelines to play with and alter refresh rates and match the height width more accurately.  

[newmanfamilyvlogs]

I see I was totally misinterpreting what the software was doing then. That makes much more sense; thanks.