GroovyMame for arcade monitors version 0.146u4_013f

[Calamity]

Any chance this method will work with 7 64 bit?

I'm afraid not, we can't use dynamic modelines with Win7.

[bent98]

Do you think there will ever be a way in win 7 or maybe window 8 when it comes out? What about Powerstrip?

[Calamity]

Do you think there will ever be a way in win 7 or maybe window 8 when it comes out? What about Powerstrip?

Old Catalyst (WinXP) based custom modes, like the ones we use in GroovyMAME with the ATI modified drivers, are, by far, the most versatile method that I know in Windows, and it's more stable than PowerStrip.

New AMD drivers have a different API to create custom modes on the fly, that could be a possibility, but it's limited to "normal" resolutions.

Powerstrip may eventually be the preferred way to deal with these things, but it's limited to the resolutions supported by the driver/windows. I've been testing last build of GroovyMAME in Win7 + Powerstrip and a LCD screen and it works great for me, but it's a fixed resolution.

So yes, there are chances to achieve something in Win7, but I seriously doubt it will match what we have in WinXP when it comes to CRT support.

[caskad]

Hello,

I try your magic resolution:

making new folder test MAme
put GM inside with fresh ini

autororL =1
Monitor orientation auto.


Create new crtemu folder with fresh zip inside.

followa your instruction for xml to 0

update registry  = 1

reboot:

magic resolution inside arcade OSD + 256*224 and some ?

test pacman, dk: Perfect 100% !

double dragon hit f11 (100% + update 40 lines ^^) full screen
robocop toki tmnt

work perfect

tested into hyperspin, perfect

Just one question d3d or ddraw works the same on gr'oovymame?

the second in double dragon update 40 lines for ? with old groovymame, i was able to going perfect with the same modeline with clone of ddragon.zip (perhaps ddragon (world) but not with US)??

excellent work, i keep that and try some games

i will make tutorial for french people

[Calamity]

Hi caskad,

Are you using the versions I posted here?
http://forum.arcadecontrols.com/index.php?topic=110905.msg1209299#msg1209299

These are the ones you need to use in order to test the "magic" resolution stuff (I highly doubt it'll work in Win7).

magic resolution inside arcade OSD + 256*224 and some ?

magic resolutions are the ones that start with 1234x (so probably you've just been using normal resolutions).

When you do the test, make sure to enable -syncrefresh so if F11 still shows 100% that means dynamic modelines are working.

Just one question d3d or ddraw works the same on gr'oovymame?

Mainly yes, though d3d is much faster when scaling is involved. If you're using magic resolutions, choose d3d.

the second in double dragon update 40 lines for ? with old groovymame, i was able to going perfect with the same modeline with clone of ddragon.zip (perhaps ddragon (world) but not with US)??

Just ignore the "partial updates" stuff, it's some info MAME is giving us but not related to fps.

[caskad]

Are you using the versions I posted here?
http://forum.arcadecontrols.com/index.php?topic=110905.msg1209299#msg1209299

These are the ones you need to use in order to test the "magic" resolution stuff (I highly doubt it'll work in Win7).

Yes, but for now trying XP

magic resolutions are the ones that start with 1234x (so probably you've just been using normal resolutions).

i ve 1234x... resolution + others  (256*224, 320*224.. 792*592(50i) about 20 modelines).

with normal resolution (old VMMAKER.exe), ddragon was not fullscreen

When you do the test, make sure to enable -syncrefresh so if F11 still shows 100% that means dynamic modelines are working.

i test !

[caskad]

 Here modeline text:

Modeline "256x224_60 15.66KHz 60.00Hz" 5.510 256 272 304 352 224 234 237 261 -hsync -vsync
Modeline "256x239_60 15.66KHz 60.00Hz" 5.510 256 272 304 352 239 241 244 261 -hsync -vsync
Modeline "256x240_60 15.66KHz 60.00Hz" 5.510 256 272 304 352 240 242 245 261 -hsync -vsync
Modeline "320x224_60 15.65KHz 59.98Hz" 6.630 320 336 368 424 224 234 237 261 -hsync -vsync
Modeline "320x240_50 15.65KHz 50.01Hz" 6.630 320 336 368 424 240 268 271 313 -hsync -vsync
Modeline "320x448_60 15.61KHz 59.94Hz" 6.620 320 336 368 424 448 466 471 521 interlace -hsync -vsync
Modeline "320x480_50 15.61KHz 49.96Hz" 6.620 320 336 368 424 480 535 540 625 interlace -hsync -vsync
Modeline "512x448_60 15.62KHz 59.98Hz" 10.510 512 536 584 672 448 466 471 521 interlace -hsync -vsync
Modeline "640x480_60 15.62KHz 59.95Hz" 12.980 640 664 728 832 480 482 487 521 interlace -hsync -vsync
Modeline "664x496_60 16.18KHz 60.06Hz" 14.090 664 696 760 872 496 499 504 539 interlace -hsync -vsync
Modeline "792x592_50 15.88KHz 50.03Hz" 16.360 792 824 904 1032 592 595 600 635 interlace -hsync -vsync
Modeline "1234x240_60 15.67KHz 60.04Hz" 25.090 1232 1280 1400 1600 240 242 245 261 -hsync -vsync
Modeline "1234x256_58 16.20KHz 58.49Hz" 26.180 1232 1288 1408 1616 256 258 261 277 -hsync -vsync
Modeline "1234x272_55 16.20KHz 55.29Hz" 26.180 1232 1288 1408 1616 272 274 277 293 -hsync -vsync
Modeline "1234x288_52 16.20KHz 52.43Hz" 26.180 1232 1288 1408 1616 288 290 293 309 -hsync -vsync
Modeline "1234x448_60 15.64KHz 60.05Hz" 25.030 1232 1280 1400 1600 448 466 471 521 interlace -hsync -vsync
Modeline "1234x464_60 15.64KHz 60.05Hz" 25.030 1232 1280 1400 1600 464 474 479 521 interlace -hsync -vsync
Modeline "1234x480_60 15.64KHz 60.05Hz" 25.030 1232 1280 1400 1600 480 482 487 521 interlace -hsync -vsync
Modeline "1234x496_60 16.17KHz 60.00Hz" 26.130 1232 1288 1408 1616 496 499 504 539 interlace -hsync -vsync
Modeline "1234x512_58 16.23KHz 58.49Hz" 26.230 1232 1288 1408 1616 512 515 520 555 interlace -hsync -vsync
Modeline "1234x528_57 16.23KHz 56.85Hz" 26.230 1232 1288 1408 1616 528 531 536 571 interlace -hsync -vsync
Modeline "1234x544_55 16.23KHz 55.28Hz" 26.220 1232 1288 1408 1616 544 547 552 587 interlace -hsync -vsync
Modeline "1234x560_54 16.23KHz 53.82Hz" 26.220 1232 1288 1408 1616 560 563 568 603 interlace -hsync -vsync
Modeline "1234x576_52 16.23KHz 52.42Hz" 26.220 1232 1288 1408 1616 576 579 584 619 interlace -hsync -vsync
Modeline "1234x592_51 16.23KHz 51.10Hz" 26.220 1232 1288 1408 1616 592 595 600 635 interlace -hsync -vsync
Modeline "1234x608_50 16.23KHz 49.85Hz" 26.220 1232 1288 1408 1616 608 611 616 651 interlace -hsync -vsync

for syncrefresh, it was enable in the mame.ini, i test with -syncrefresh, ok but for ddragon... 256*224 ...

i don't know why i 've so manay modeline ?

[Calamity]

Oh, I see, that's fine! I thought you were testing with Win7.

Yes, those 1234x are the "magic" modelines. The other ones (256x224, etc.) are added there into ReslList.txt for compatibility with Megadrive and SNES emulators.
You can test with -v -md 4 in other to get the logs and see if they're actually being used (they should).
So you tested with ddraw or d3d?

Thanks!

[caskad]

ddraw give black image but sound

D3d perfect

[Calamity]

ddraw give black image but sound

D3d perfect

Great. So same problem with ddraw reported by bent98.

Just something more, are you using Cat 6.5 or 9.3?

[caskad]

Winxp, hd4350 cat 9.3

ive try demule, kof 2011, and big bug

seems to have lost the sync, it's not groovymame, but ati catalyst 9.3  who have give up?

split image like 30 khz, vertical sync goes out, CTRL ALT sup ->  solve the problem.




one more thing, ive hantarex chassi (MTC 9000 (châssis in french) ), and a screen made by Videocolor.

the h9110 doesn't work in VMmaker.exe, it tells me monitor specs ignore or something else, only Custom works, why vmmaker ignore the H9110?

Code: [Select]

2. MONITOR
; ----------

; Monitor Type. Valid types: D9800, D9400, D9200, EGA, VGA, MULTI, H9110, PAL, NTSC, GENERIC, CUSTOM

MonitorType = "H9110"


; Monitor CUSTOM. These values will be used if MonitorType = "CUSTOM"
;
; monitor_specs_0-6 = "HfreqMin-HfreqMax, VfreqMin,VfreqMax, HFrontPorch, HSyncPulse, HBackPorch, VfrontPorch, VSyncPulse, VBackPorch, HSyncPol, VSyncPol, ActiveLinesLimit, VirtualLinesLimit"
;
; * HfreqMin-HfreqMax: Minimum and maximum horizontal frequency, in Hz. Defines the range of horizontal frequencies the monitor is capable to sync.
; The higher the horizontal frequency, the higher the vertical resolution available for the same vertical refresh.
; The higher the horizontal frequency, the higher the vertical refresh available for the same vertical resolution.
; The higher the horizontal frequency, the lower the horizontal amplitude of active video (narrower picture).
;
; * VFreqMin-VfreqMax: Minimum and maximum vertical frequency, in Hz, Defines the range of vertical frequencies the monitor is capable to sync.
;
; * HFrontPorch, HSyncPulse, HBackPorch: Horizontal timing and geometry, values in µs
;
; * VfrontPorch, VSyncPulse, VBackPorch: Vertical timing and geometry, values in ms
;
; * HSyncPol,VSyncPol: polarities, not in use! defaults to negative.
;
; * ActiveLinesLimit: Vertical resolutions until ActiveLinesLimit value included, are generated as progressive, regardless the possibility
;                           of obtaining the required vertical refresh value.
;
; * VirtualLinesLimit: Vertical resolutions above ActiveLinesLimit and below VirtualLinesLimit are virtualized, that is, an interlaced resolution
;                            bigger that the native one is generated, with the right refresh, and "hardware stretch" is applied.
;                            Vertical resolutions above VirtulaLinesLimit are generated as interlaced, without any stretching.

monitor_specs_0 = "15625-16200, 49.50-65.00, 2.000, 4.700, 8.000, 0.064, 0.160, 1.056, 0, 0, 288, 448"

; monitor_specs_0 = "29100-70000, 50-160, 1.000, 1.000, 3.000, 0.014, 0.044, 0.524, 0, 0, 1024, 800"


; Tolerance for horizontal frequency, in kHz, enables extending the range defined by [ HfreqMin, HfreqMax ]
; The resulting allowed frequency range will be [ HfreqMin - HfreqTolerance, HfreqMax + HfreqTolerance ]

HfreqTolerance = 0.010

ANd one more question


Modeline are based on screen (Videocolor)? or chassi (in case MTC hantarex9100??)

..by defaut with "CUSTOM"  it work great but can i expected better ?

very low resolution on AracdeOSd are fine, but .. in OSd menu, 192*224, the words are cut on the left.

like:

de number  -> mode number
rizontal geometry -> horizontal geometry

etc etc...

doesn't matter or can be adjust?

thx

PS: Making acronis image and test 6.3 if you want !

[Calamity]

Winxp, hd4350 cat 9.3

Good to know.

ive try demule, kof 2011, and big bug

seems to have lost the sync, it's not groovymame, but ati catalyst 9.3  who have give up?

But that's not MAME. You need to find which resolutions those programs are trying to set, and then add them to ReslList.txt so they are calculated as custom modes with the right frequencies. "Magic" resolutions are only a GroovyMAME feature, don't work for other programs.

the h9110 doesn't work in VMmaker.exe, it tells me monitor specs ignore or something else, only Custom works, why vmmaker ignore the H9110?

Yes H9110 works, it's only telling you that the monitor_specs line is being ignored. Just comment (add an ";") that line and that message won't happen. In VMMaker, monitor_specs lines only are read if you specify monitor type as CUSTOM. This is slightly different in GroovyMAME, where monitor_specs always override the values of the selected monitor.

Modeline are based on screen (Videocolor)? or chassi (in case MTC hantarex9100??)

..by defaut with "CUSTOM"  it work great but can i expected better ?

The chassis is what matters.
H9110 allows a somewhat higher hfreq than the default monitor_specs in VMMaker.ini (the one used when you select CUSTOM), that allows games with 256 lines run at 60Hz, otherwise they would run at 58Hz or so. It also allows higher virtualized resolutions: better detail for stretched vertical games.

very low resolution on AracdeOSd are fine, but .. in OSd menu, 192*224, the words are cut on the left.

Yes that's normal  
I didn't find smaller fonts in Windows that looked fine, anyway you can press P2 to disable full screen edit and then enter to test changes.

[caskad]

so:

Yes H9110 works, it's only telling you that the monitor_specs line is being ignored. Just comment (add an ";") that line and that message won't happen. In VMMaker, monitor_specs lines only are read if you specify monitor type as CUSTOM. This is slightly different in GroovyMAME, where monitor_specs always override the values of the selected monitor.

i 've read that mtc 9100 have the same value of mtc9110.. if i want to have the "best" result, i must  add comment in the monitor_specs AND edit mame.ini to avoid groovymame override it?

so far, thx for the explaination, chassis is what matter

for demul, it's just 640/480@60khz? other game runs fine, i must dig it

and ok for the fonts but need to find smaller !

edit added ";" and perfect with h9110 !) but no 192*224 ^^

[thefooz]

Calamity, I just tried your experimental version with the magic resolutions and it's rock solid. Is there any chance you could compile us a 64-bit version? I'm dying for that extra little bit of juice it gives me to run blitz at full speed.

[Calamity]

Calamity, I just tried your experimental version with the magic resolutions and it's rock solid. Is there any chance you could compile us a 64-bit version? I'm dying for that extra little bit of juice it gives me to run blitz at full speed.

Sounds great! I'm leaving for the weekend now, anyway I don't have the system here set up for 64 bits so I can't build it, hopefully we'll update the mainline groovyMAME soon with both builds.

[thefooz]

Enjoy your weekend. If you have a quick minute before you leave. I just realized that the only way the new version runs at 100% (as opposed to 104 or 110 or whatever) is if sync refresh is set to 0. Is that normal?

[Edit: Nevermind, after playing around with the new build for a few hours, I've got everything straightened out, though I think I'm gonna hold off on making it my primary emulator until it's out of beta. This version doesn't play nice with hyperspin at all (in xp x64). Maybe the 64 bit version will be different? Anyway, cheers for making an amazing product, Calamity.]

[Calamity]

Enjoy your weekend. If you have a quick minute before you leave. I just realized that the only way the new version runs at 100% (as opposed to 104 or 110 or whatever) is if sync refresh is set to 0. Is that normal?

[Edit: Nevermind, after playing around with the new build for a few hours, I've got everything straightened out, though I think I'm gonna hold off on making it my primary emulator until it's out of beta. This version doesn't play nice with hyperspin at all (in xp x64). Maybe the 64 bit version will be different? Anyway, cheers for making an amazing product, Calamity.]

So what was the issue with HS? Did it even run at all or was something wrong with games themselves?
I can't build 64 bit binaries at the moment as my only 64 bit machine is in the cab and I don't seem to be able to compile 64 bit mame from my Win32 systems, hopefully I'll have another x64 system soon, by now I will post diff files in case someone can build the 64 bit binaries.

[thefooz]

So what was the issue with HS? Did it even run at all or was something wrong with games themselves?
I can't build 64 bit binaries at the moment as my only 64 bit machine is in the cab and I don't seem to be able to compile 64 bit mame from my Win32 systems, hopefully I'll have another x64 system soon, by now I will post diff files in case someone can build the 64 bit binaries.

HS would run, but when it opened groovymame, it would pick completely different resolutions than if you just opened groovymame by itself and ran the games. For instance, it would choose a very low resolution for rampage: world, and nfl blitz (it seemed to mostly be affecting higher resolution games). I tried pretty much everything and it just kept doing it. Ran with hyperlaunch as well as without and both did the same thing. Pretty bizarre stuff. Also, I noticed that the beta versions seem to like having ini files to, I don't know, guide them a bit? For instance, with an ini, pacman would run at 100% at a progressive resolution, which was just great. Without it, it ran at an odd interlaced resolution.

I also noticed a difference if you used the old mame.ini (non-beta) with the new (beta) groovymame. It seemed to choose cleaner looking resolutions than with the new mame.ini or the old groovymame with the old ini. Kind of interesting.

[AndyWarne]

On the subject of the ArcadeVGA card:
The ArcadePerfect utility for this card creates resolutions on the fly by writing directly to the card. It will work even without any drivers installed. It works in all Windows versions.
I could create a DLL based on this, which would accept a modeline timing as an input, and the card would display the mode. This would allow infinite modes to be displayed.
Just wondering if that would be of any interest to be used in conjunction with Groovymame?

Andy

[newmanfamilyvlogs]

sounds like a pretty must-have feature to me.

[Calamity]

On the subject of the ArcadeVGA card:
The ArcadePerfect utility for this card creates resolutions on the fly by writing directly to the card. It will work even without any drivers installed. It works in all Windows versions.
I could create a DLL based on this, which would accept a modeline timing as an input, and the card would display the mode. This would allow infinite modes to be displayed.
Just wondering if that would be of any interest to be used in conjunction with Groovymame?

Andy

Hi Andy,

That would be awesome. Just provide us with a way to interface with your card and we'll support it, that's sure.

So would it accept any dotclock we request (assuming there's always some granularity)? I mean, is your software already dealing with pll dividers and stuff so we won't need to care?

[Calamity]

HS would run, but when it opened groovymame, it would pick completely different resolutions than if you just opened groovymame by itself and ran the games. For instance, it would choose a very low resolution for rampage: world, and nfl blitz (it seemed to mostly be affecting higher resolution games). I tried pretty much everything and it just kept doing it. Ran with hyperlaunch as well as without and both did the same thing. Pretty bizarre stuff. Also, I noticed that the beta versions seem to like having ini files to, I don't know, guide them a bit? For instance, with an ini, pacman would run at 100% at a progressive resolution, which was just great. Without it, it ran at an odd interlaced resolution.

I also noticed a difference if you used the old mame.ini (non-beta) with the new (beta) groovymame. It seemed to choose cleaner looking resolutions than with the new mame.ini or the old groovymame with the old ini. Kind of interesting.

Sounds weird. There's probably something wrong with your setup there. Get me some logs and I'll be able to diagnose what's the issue. It must be possible to add the -v -md 4 >romname.txt somehow into the HS command-line for launching GroovyMAME so we can see what it's doing.

[bent98]

Andy, If you could just come out with wirless Aimtrak guns so I wouldnt have to buy TopGun III's Id be a happy man.

[AndyWarne]

On the subject of the ArcadeVGA card:
The ArcadePerfect utility for this card creates resolutions on the fly by writing directly to the card. It will work even without any drivers installed. It works in all Windows versions.
I could create a DLL based on this, which would accept a modeline timing as an input, and the card would display the mode. This would allow infinite modes to be displayed.
Just wondering if that would be of any interest to be used in conjunction with Groovymame?

Andy

Hi Andy,

That would be awesome. Just provide us with a way to interface with your card and we'll support it, that's sure.

So would it accept any dotclock we request (assuming there's always some granularity)? I mean, is your software already dealing with pll dividers and stuff so we won't need to care?

Yes the software deals with that, just would require the modeline including dot clock. In its current form the software does not need a dotclock specified as it accepts a vertical and horizontal refresh rate so it calculates the required clock but I could change that to make it closer to a standard modeline.

But how would a pre-defined modeline be able to deal with the feature which ArcadePerfect has, which allows the picture to be moved and resized with the arrow keys? Or is that implemented already?

[Calamity]

Yes the software deals with that, just would require the modeline including dot clock. In its current form the software does not need a dotclock specified as it accepts a vertical and horizontal refresh rate so it calculates the required clock but I could change that to make it closer to a standard modeline.

But how would a pre-defined modeline be able to deal with the feature which ArcadePerfect has, which allows the picture to be moved and resized with the arrow keys? Or is that implemented already?

What we do is to is to first figure out the porch values that a given monitor needs in order to show a perfectly centered picture, and build one or more "monitor_specs" lines like this:

   monitor_specs_0  15625-16200, 49.50-65.00, 2.000, 4.700, 8.000, 0.064, 0.160, 1.056, 0, 0, 288, 448

As new modelines are calculated on the fly using those values, all resolutions should automatically fit the screen without further re-adjustment.

[Quinny]

On the subject of the ArcadeVGA card:
The ArcadePerfect utility for this card creates resolutions on the fly by writing directly to the card. It will work even without any drivers installed. It works in all Windows versions.
I could create a DLL based on this, which would accept a modeline timing as an input, and the card would display the mode. This would allow infinite modes to be displayed.
Just wondering if that would be of any interest to be used in conjunction with Groovymame?

Hi Andy,

Would something like that work in Linux too?

Since Linux does not use DLLs, is this possible already?

Cheers,
Quinny

[Calamity]

On the subject of the ArcadeVGA card:
The ArcadePerfect utility for this card creates resolutions on the fly by writing directly to the card. It will work even without any drivers installed. It works in all Windows versions.
I could create a DLL based on this, which would accept a modeline timing as an input, and the card would display the mode. This would allow infinite modes to be displayed.
Just wondering if that would be of any interest to be used in conjunction with Groovymame?

Hi Andy,

Would something like that work in Linux too?

Since Linux does not use DLLs, is this possible already?

Cheers,
Quinny

Hi Quinny,

Yes, GroovyArcade for Linux already supports AVGA 3000.

[Calamity]

A new GroovyMAME binary is available here:

http://mario.groovy.org/GroovyMame/WindowsATIDrivers/

groovymame32_0143u7.013d.rar
0143u7_groovymame_013d.diff

Features
--------

- Core updated to v0.143 u7.
- All features from GroovyMAME_013c_test version included: magic resolutions, auto-scaling and support for LCD monitors via Powerstrip*. Refer to this thread for details: http://forum.arcadecontrols.com/index.php?topic=110905.msg1209299#msg1209299
- Now video settings are properly applied even when launching games from Mame's internal frontend.

* Although GroovyMAME's default video option is "video ddraw", we recommend to use "video d3d" instead if any of the newer options is used (actually magic resolutions don't work with ddraw in some systems).

Compiling notes:
---------------

Apply patches in this order:

1) 0143u1.diff -> 0143u2.diff -> 0143u3.diff -> 0143u4.diff -> 0143u5.diff -> 0143u6.diff -> 0143u7.diff
2) hi_143u5.txt (http://mamestuff.lowtrucks.net/MKChamp/)
3) 0143_hilinux.diff (http://mario.groovy.org/GroovyMame/0143/)
4) 0143u7_groovymame_013d.diff (http://mario.groovy.org/GroovyMame/WindowsATIDrivers/)

I've done basic testing of this build and it seems to work, anyway take care. Specially, don't use the powerstrip settings until you're sure this binary doesn't crash in your system (in case of crash during game or on exit GroovyMAME won't be able to revert Powerstrip settings to your desktop defaults and you may end up with a garbled display).

One of the aims of this build was to get rid of some HLSL stability problems they claim to have solved in u7 revision. Well, I'm afraid there're still some problems with HLSL in this build, at least in my machine (WinXP32, DirectX 9.0c, HD4350) it shows this exception on exit:

Code: [Select]

-----------------------------------------------------
Exception at EIP=01E056E7 (not found): ACCESS VIOLATION
While attempting to read memory at 40C90FDB
-----------------------------------------------------
EAX=40C90FDB EBX=06F9A8E0 ECX=7FFDC000 EDX=00034C50
ESI=0031BE58 EDI=003201F6 EBP=00000000 ESP=06C7F8B4
-----------------------------------------------------
Stack crawl:
  00000000: 01E056E7 (not found)


I've downloaded and tested another MAME 0.143u7 binary just to double check and it's the same story, so I guess it's not GroovyMAME related. It's interesting that if I rename the 'artwork' folder the crash doesn't happen... I need to test this build in W7 too.

However that problem only happens if you enable HLSL, that's not the case if you're using an arcade monitor.

[caskad]

THx !


Ive just test this release, but some strange issue with the mame's game selection. Aniway, work's perfect with command line !

[Calamity]

THx !


Ive just test this release, but some strange issue with the mame's game selection. Aniway, work's perfect with command line !

Yep, I've seen that in some systems too. Even plain u7 binary (not GroovyMAME related) will crash if the internal frontend is used with d3d selected. It happens even without hlsl enabled. I guess the whole d3d interface has become buggy since the integration of hlsl. I'd love they would add a new video interface for hlsl experimental stuff instead of messing with the existing d3d one, so we could use a clean d3d interface as it was right before they added the hlsl thing. Considering the current binary size it wouldn't mean such a difference.

[caskad]

Asking about one thing:

Cave games are fine on mame 143u8, when groovymame diff or compile 

[lettuce]

Asking about one thing:

Cave games are fine on mame 143u8, when groovymame diff or compile 

Wicked!!!!  Have you complied a GroovyMAME 143u8 64bit yourself???, if so please share! 

[Calamity]

http://mario.groovy.org/GroovyMame/WindowsATIDrivers/

groovymame32_0143u8.013d.rar
groovymame64_0143u8.013d.rar
0143u8_groovymame_013d.diff

Compiling notes:
---------------

Apply patches in this order:

1) 0143u1.diff -> 0143u2.diff -> 0143u3.diff -> 0143u4.diff -> 0143u5.diff -> 0143u6.diff -> 0143u7.diff -> 0143u8.diff
2) hi_143u5.txt (http://mamestuff.lowtrucks.net/MKChamp/)
3) 0143_hilinux.diff (http://mario.groovy.org/GroovyMame/0143/)
4) 0143u8_groovymame_013d.diff (http://mario.groovy.org/GroovyMame/WindowsATIDrivers/)

[lettuce]

Thanks Calamity!!! Quick question how do i get the High Scores to save in groovyMAME, they dont seem to save themselves?

[caskad]

Thx calamity

[lettuce]

Any news on the 64bit release?

[Calamity]

Any news on the 64bit release?

Hi lettuce, today's been a terrible day, hopefully I can have it tomorrow.

[caskad]

Like me terrible day since 30 Days :s


anyway, if time to considered how to speed up perhaps this CAVE GAMES?

Any suggest? (not to slow but not 100%)

Have a GOOD hallowen day !

[lettuce]

Apparently the Cave game run better on the 64bit version of mame, so hopefully Calamity will release the 64 bit version soon

[senorchris]

Thanks Calamity!!! Quick question how do i get the High Scores to save in groovyMAME, they dont seem to save themselves?

Grab the unofficial hiscore.dat file from highscore.mameworld.info, and put it in the /hi/ directory in groovymame (create the directory if it doesn't exist).  Then edit mame.ini in the groovymame root and make sure the line about disabling the hiscore patch isn't set (I forget the exact line - it's close to the bottom).