forums.marpirc.net

http://www.macmame.org/files/MacMAME-0.66.sit

Barry, or any other MARP editor, can you please add macmame 0.66(mac66) to the version menu on the submit form page?

Thx.

Man, for certain game CPUs though like the pacman type games, 0.66 must have resorted to strictly c-core code cuz it's almost 3 times slower than it is for me in 0.60.

For my older slow 450MHz mac, it means I can't even play pacman in 0.66 with audio on without needing to use frameskip 2 or 3....sad.

However, testing others games the performance in 0.60 vs 0.66 is the same...which is good.

Anyway, it finally will be cool to play these games I have seen tons of uploads for at MARP over the past year with 0.62 and newer versions.

I can finally compete for those also! Lookout!

Done.

thx Barry... This first release of 0.66 has a serious speed throttle issue though. According to Brad(the macmame guru), it's actually a change in the mame core code for how the speed throttle is done.

In this current macmame 0.66 build even with speed throttle on the game speed is varying 92-108%....making it unplayable for many games that depend on precise movement. This also affects any use of frameskip. Even a use of a small frameskip like 2 or 3 makes the motion really jittery. That's likely from lack of sync of the frameskip with the throttle not being at a steady 100%.

Do you have these throttle problems in the pc versions of 0.65 and/or 0.66? Brad states it's seems to be from a rounding issue in the treatment of the throttle now that results in that variance.

I would guess the pc versions don't have that issue...cuz it's quite noticeable where few gamers could tolerate it for most games. Brad's working on it so hopefully can find a quick fix or find the bug/problem.

I tried Ultimate Tennis in both DOS and Win32 builds, and both ran it at a steady 100% (50fps) at frameskip 0.

thx.... Brad already has a fix for the speed throttle issue. I'm guessing he is fixing a couple other issues first before releasing this fixed version.

I hope it's soon though cuz most games aren't very playable with the speed varying from 92-108%. It gets hard to impossible to judge the timing of anything.

new version with speed throttle issue fixed...

http://www.macmame.org/files/MacMAME-0.66.1.sit

I think except for the new games supported since 0.60 I likely will keep using 0.60 though because for many games it runs them close to 3 times faster. My mac just doesn't have the power to play hardly any games in 0.66 without using frameskip or turning off or down the audio settings. For games that play fine in 0.60 I'll just use that for performance so I can play without any frameskip.

It's fantastic to see a macmane 66 - good work!

Rick Carter's joyman recording doesn't playback using mame66 - so I guess the new MAME random number changes do not solve the incompactibility between INPs on mac and pc systems (unless the joyman driver hasn't been updated with them yet).

Any ideas?

Kranser.

Very few games make use of a randon number generator. Most generate them in software. Thr problem with MacMAME is that it uses very different code, particularly CPU cores. Obviously the 68000 core in MAME can't be used, and I don't know about other CPU cores, whether or not they're the same and MAME, or optimised with PowerPC ASM. Rick will know. :)Oh, and Rick, has an OpenGL build of XMAME been tried with MacOS X?

yeah screw the regular macmame build go to osx and the C core :) BTW, i tried flagrantly to compile xmame-66 with the asm 68k core and it playedback the ln2 joyman thing the same lame way, with header or with out: chomps two ghosts and that's about it.

A lot of this is c-core now I think.

First release my above announcement was just announcing it was released. I had ZERO to do with this macmame.

There almost aren't any games I can run at full speed with frameskip 0 with 0.66. Even for pacman games I have to use at least frameskip 4 for it to stay at 100% speed. pacman runs 3 times slower in 0.66 than it did in 0.60 so I'm guessing that might be using just the c-code for that game cpu core now.

I have not experimented a lot yet to see if any games where the inps were previously totally incompatible where you get the service mode crap etc. are maybe now ok. That's on my list sometime.

It's only been out a few days. I'm having fun playing right now.

When I tested my Birdie King inps in VirtualPC they actually were playing back fine...but lose sync from wind timing changes not being quite the same or that bird not being quite the same...so it loses sync.

When I tested a couple pacman ones it seemed fine until the first energizer hit...and loses sync. In that 4in1-g4 one for ghostmucncher, pt3, when pacman hit the first energizer playing that back in mame66 resulted in pacman just sitting there doing nothing for several seconds. I'm not sure what's going on there....very odd.

All playback fine in macmame66 though which is what matters the most.

Barry, as far as the xmame code...not sure if that would be any better or not for inp compatiblity. It's too much of a pain to go playing with xmame that runs even slower versus macmame just to maybe have a few more inps be compatible. Anything that's slower than what 0.66 already is would be unacceptable for playing on my system. I'm not going to play with a frameskip larger than 6.

I will continue to note which inps are compatible with pc-mames when I submit them....like the Fire Truck inp I uploaded yesterday is cross-platform compatible....oddly enough.

It would be nice if another macmame player could also be a confirmer. Tech-D has played enough to do that but I haven't seen any signs of him in several months.

another new release with more fixes...

http://www.macmame.org/files/MacMAME-0.66.2.sit

Barry: if you forward me the alphamame source with only encryption/decryption stubs, i would make a patch file (between the orig mame source and alphamame source) to send to the mac mame dude. If the mac guy accepts the diff file, and is able to "patch -p1" macmame with potential porting issues, and picks a good encryption/decryption routine to link it and agrees to keep the choice of encryption/decryption to himself, then alphamacmame is born.

man, that's a lot of "ifs".

plus, except for new games supported by 0.66 I would doubt many macmamers would use version 0.66.

On my 450MHz G3 I can't even play pacman in 0.66 without having to use frameskip to get it running at speed.

I have pacman in mame66 in VirtualPC running almost as fast as it does in the MacOS with version 0.66.

Add encryption to that and you slow it down all that much more.

pacman runs 3 times slower in 0.66 than it did in 0.60. Go back to even older versions like 0.37, I could get 600fps on pacman with audio off.

Now with 0.66 with audio off I get about 63 fps. In 0.60 I get about 185 fps.

Perhaps you have noticed with my recent uploads the only ones I have used 0.66 with are games that weren't supported by any older versions of macmame(0.60 and earlier).

Some games however perform just as well in 0.66 as they did in 0.60.
For example with punchout with audio on I can get 75fps. I get about 45fps in pacman with the audio on.

In version 0.60 I also get 75fps with punchout, but about 130fps with pacman.

I haven't seen one case in reviewing all the macmame inps of anything suspect in tampering with an inp. Mac gamers in general just don't cheat at games like you see with PC users.

Part of that is perhaps where we just don't have any tools/utils for working with macmame and inps etc. like you have on the PC.

I'm sure most others are like me where I would rather use an older version and frameskip 0 than have to use 0.66 and use frameskip 6 or even higher.

I still think the "average" mac user has only about a 450-500MHz CPU.
It's not worth using 0.66 for games not needed taking a 67% hit in performance and having to use a high frameskip where no skip was needed before.

LN2 wrote:man, that's a lot of "ifs".

I'm a programmer what do you expect :)

LN2 wrote:On my 450MHz G3 I can't even play pacman in 0.66 without having to use frameskip to get it running at speed.

Still with a source patch, it can virtually be applied to ALL mac mame versions not just 66... but oh well, you know just keep an eye on the fps %'s if your computer is slow... mac and xmamers have a free unblocked ride for now. well not free, since we can still estimate slow mac/x recordings, but close.

yes...however Barry hasn't applied this to make any older versions of an alphamame like 0.58 or 0.53 etc. which some had requested cuz some games run a lot faster in that version than 0.66.

Well, you can always approach the macmame developer(Brad) to see..but my guess is he would only do this for the current version. Then you add the blocking thing so alphamacmame is required and we are stuck using a version that is a lot slower.

I seriously doubt he would do a rebuild of an older version with the alphamame stuff added also unless at least Barry had already done that as well....then with some persuading from Barry it could maybe be done. Even then I'm guessing it would be unlikely.

However, I think our developer looks at mame as totally about just playing the games and having fun. He as most mac gamers wouldn't see any need to have protection against cheating just because it generally doesn't happen in mac gaming.

Think of it this way also...let's say there is an alphamacmame made.

I am the only mac confirmer for MARP at this time. I would be viewing the inps with that. PC confirmers wouldn't be able to verify those inps without a mac even for games where the inps in regular mame are compatible...cuz alphamacmame would have a different encryption thing.

It also wouldn't allow others to even do whatever checks you do on suspect inps for autofire etc. because you wouldn't be able to decrypt the alphamacmame inp file to run it through whatever utils you use to calculate that stuff and see the dip switch settings etc.

I'm not sure you really gain anything overall. MARP still wouldn't be able to confirm any of my scores in alphamacmame for example unless you added another mac confirmer you could trust.

The only real issues we have for real scores in macmame is an honor system that people are playing the game at 90+% speed and don't pause. Any macmame contests I have seen actually only use the final screenshot of the score as verification. I think that shows just how much mac gamers are trusted. It would be very easy to fudge a different score on most screenshots compared to tampering with an inp...but I haven't seen or heard of 1 case where that has happened in any macmame contest.

I think pausing and game speed are more of an issue than any inp tampering form of cheating. As you said you can already look at an inp and get an overall average fps the input was being saved at....if you only know how long the game took to play.

I have no idea how you detect autofire use etc. so can't comment on that.

A big part of the issue is the changes to the macos the past couple of years. Brad(the macmame dev) has already stated 0.66 is likely the last "carbon" version of macmame. That means the last to run in either os 9 or os x. Future versions will be OS X builds only.

He has developed and built the various versions using various versions of Codewarrior Pro over the past few years. He isn't using gcc compiler etc. that is in OS X dev tools.

Because of that that 1 macmame build is really about all there is. A couple did rebuild the xmame code to run within Apple's X11 for OS X but that was just a pure c-core port and remake within the X11 dev environment.