Newpuc2

[Weehawk]

the frameskipping/analogue issue/bug there isn't really an excuse other than mame already emulates these games acruately

Not sure if you're referring to the "analog overflow" problem here or not. If so, MAME does NOT accurately emulate some games because of it.

Ask Don Hayes how accurately MAME emulates Centipede and Millipede.

Ask Mark Alpiger how accurately MAME emulates Crystal Castles.

Try playing Kick-Man seriously with a recent MAME version.

I'm sure there are lots of others.

[LN2]

Not sure if you're referring to the "analog overflow" problem here or not. If so, MAME does NOT accurately emulate some games because of it.

No, he wasn't. He is referring to issues of the replay file...playing back of replay files specifically for analog control games.

That's totally separate from the overflow-controller issue.
I definitely have plans on tackling the controller overflow issue too.

There are a lot of analog games that would be tons more playable...and play much closer to the arcade(which isn't that the point of MAME?!?).

[mahlemiut]

There are a lot of analog games that would be tons more playable...and play much closer to the arcade(which isn't that the point of MAME?!?).

MAME is a documentation project - being able to actually play the games is just a happy side effect.

*tries hard not to sound like a MAMEdev*

[Weehawk]

There are a lot of analog games that would be tons more playable...and play much closer to the arcade(which isn't that the point of MAME?!?).

MAME is a documentation project - being able to actually play the games is just a happy side effect.

*tries hard not to sound like a MAMEdev*

If the emulation isn't accurate, the documentation is flawed.

[The TJT]

MAME is a documentation project - being able to actually play the games is just a happy side effect.

*tries hard not to sound like a MAMEdev*

*Failing miserably*


I don't believe mamedevs actually believe that themselves either.
As someone said at mamenet forums...Nobody would be interested in "documenting" those awkward circuits without this "side effect". Then a circuitry schematics would be better for only documenting.

That's actually a lame excuse to ignore requests or feedback from users.

*trying not to sound like a mame lamer/lame mamer at mame.net - and failing miserably*

[mahlemiut]

*trying not to sound like a mame lamer/lame mamer at mame.net - and failing miserably*

Could be worse - you could have said "Gibb0rz me KOF2007 r0mz0rs"

[mahlemiut]

speaking of nvram...if a snapshot of that nvram was saved at the header of the replay file...then THAT used on playback instead of whatever nvram file existed in the nv folder, then most of those nvram playback issues would be resolved. it wouldn't make things any harder either...since it's all part of the same file. Play it again..different nvram? no problem....cuz each replay has that snapshot of the nvram at the start of play.

MAME Plus (and thusly, WolfMAME Plus) ignores NVRAM when recording and playing back inps... issue solved.

all of what things? The data maybe is there..but in a form a user can read? In a form where on inp playback the info is displayed for the user?

There is this thing called the console... but I guess that's something new for you Mac users.
Most of the stored info is printed out to the console. I haven't added this to the GUI as it would be awkward to implement, and most GUI users probably wouldn't care anyway.

it doesn't? Well, "many" games being relative... if you mean 50-100+ out of 5000 isn't many...fine. From what I read for games like centipede, millipede, Major Havoc, etc., if you record with the sound on then that same person on that same system then tries to playback that just-recorded replay they will not be able to do it!

Not with Major Havoc, as far as I know... I seem to remember that it was using the GUI vs. commandline, and also using keyboard LEDs... why those affect it, I have no idea whatsoever - they shouldn't. MAME does weird shit like that.

I can have lots of stuff running...and launch macmame and it not affect anything...except potentially the performance cuz of the other processes perhaps using some CPU.

Potentially? There's not a lot that would run full speed at 400MHz as it is, let alone with other CPU using processes running.

I have no issues with any of those games in recording and playback. I just have to make sure I use the same sound frequency setting on playback as I used when recording is all.

I hope you've tested these on numerous Macs... just on yours alone is not enough to say for sure.

I want to develop this using X-Code with the gcc compiler so odds are it's more cross-platform compatible with gcc from other platforms...as well as using supported dev tools that will likely be able to develop apps that also run just fine in the soon coming "Tiger" OS. I have the dev tools for Jaguar which would work...but that's an entirely different IDE with different frameworks etc. versus what X-Code has...especially in relating to GUI/front-end development.

Why not just build using GCC as it is? Should work on any OS X version. And it's simple to compile X-MAME - edit makefile.unix to set up for your system, then type 'make -f makefile.unix' then grab a cup of tea while it compiles.

[LN2]

MAME Plus (and thusly, WolfMAME Plus) ignores NVRAM when recording and playing back inps... issue solved.

Well, that would be my default when recording...but an option to save a snapshot and use the current nvram should be there for things like 5-man TGTS Robotron game....or a game (Joust I think is like this) where you must go into service mode to change the difficulty setting of the game to match TGTS. It also allows special cases like potentially Hyper Sports.

it would allow for special settings for some event/contest as well...for a particular game. It's not an option that maybe is used a lot..but it would be nice for it to be there.

IMHO it makes the "documentation" of the arcade games a tad more accurate as the arcade game wouldn't be reverted back to the default settings before each game.

Saving the snapshot of nvram in the inp to then use on playback also eliminates the playback issue for most games that caused MARP to stop allowing use of nvram to start with.

Think of this....if there was no playback issue with nvram, I'm guessing MARP would still be allowing use of nvram for games.

...given that...why not incorporate it into the replay file?..or at least have it as an option? if you use nvram when making a recording...that snapshot gets saved to the replay and used on playback. That is better than the current situation of nvram.

I could even add a feature where on launching a game that nvram snapshot from an inp is used for your "new" play so you have the exact same nvram to play with as they had. That goes beyond just playback there. It makes for some interesting possibilities for some games too where you could use someone else's nvram so at the end the high score table shows your name and your competitor's name below it. That would be sort of cool!...and potentially handy for a tournament type event like the Deca.

There is this thing called the console... but I guess that's something new for you Mac users.
Most of the stored info is printed out to the console. I haven't added this to the GUI as it would be awkward to implement, and most GUI users probably wouldn't care anyway.

No, it's not new...but when a game ends that console window closes before you have a chance to read anything in it! The CLI version should have an autopause on escaping back where you have to hit another key to quit the application. Maybe you have added that in recent wolfmame versions..if so that's great. It's been 7 months since I last launched any pc-mame in VPC on my mac. I think I had only watched 1 wolfmame replay...to co-verify it for TG.

I can see your next reply....just make a batch file to do that pause where you launch the .bat instead.

Yeah, that would work..but is that convenient for any user to do? I don't think so. Again most ideas I have are for the ease of use of mame for the gamers and for others to view/playback inps. Oh wait...only mac users like ease of use...right? ALL users regardless of platform want ease of use.

Not with Major Havoc, as far as I know... I seem to remember that it was using the GUI vs. commandline, and also using keyboard LEDs... why those affect it, I have no idea whatsoever - they shouldn't. MAME does weird shit like that.

Yeah, that's really weird stuff...and one of the reasons I always preferred using Macs...cuz it goes far beyond MAME.
Major Havoc has the sound playback issue cuz QT Quazar told me about it in the competition we had going back and forth topping each other's scores on that game.

He then got to try playing Major Havoc on his dad's mac one evening so he could watch my replays as well as try and play it some himself. He found as I already knew that recording and playback worked on the mac for Major Havoc while it didn't on his PC. The only way he could get even his own inps to playback was to record and playback with sound off.

...similar to centipede and millipede and at least 10-15 other games that were posted about in the MARP forums with this issue. I tried them all in macmame using sound and had no issues with any of them.

Potentially? There's not a lot that would run full speed at 400MHz as it is, let alone with other CPU using processes running.

hehe...good point...especially for most of the newer games added...which is why most of my play was with the golden era classics. I don't play any of those 3d-ish scrolling shooters cuz I have to use at least frameskip 6 or 8 for them to run at speed.

This is where the assembly optimizations in macmame really come in handy though. For some game CPUs it results in a factor of 5+ speedup versus if only the c-cores are used. Pacman slowed down by a factor of 6 when macmame 0.66 came out that had pacman only using the c-core. version 0.60 still had the assembly. This change was done cuz the dev felt macs were fast enough now where just using the c-core was good enough for that game CPU.

This especially applies to arcade games using 680x0 CPUs....easily adapted to run very well on Macs....but requires some assembly to do it.

I hope you've tested these on numerous Macs... just on yours alone is not enough to say for sure.

I'm not the only mac gamer to play games like Centipede and make recordings. Odds are any mac user would play with sound ON...and not even think of playback issues. A year ago when I was in contact with a few other mac users I did get a couple of them to test a few of my inps made with some finicky games that depend on sound settings. They had no issues playing them back.

There are quite a few macmame inps from other gamers here at MARP I had confirmed as well.

Sure, perhaps the research isn't enough to be 100% conclusive. However, that doesn't change the fact I have not seen 1 case yet.

For games like Centipede, it seems ALL pc users...regardless of the specific MAME build version or type(mame vs mame32 vs xmame vs mame+ vs wolfmame vs alphamame etc.) can't get playback to work centipede and other similar analog games unless -nosound is used.

So...logically I should have easily run into the issue given it's a 100% problem on PCs....meaning all PC users have that same issue. The issue is that the same gamer can't even get their own replay to playback unless they recorded and play the replay file back using -nosound. Is there 1 case where a pc user doesn't have that sound issue for centipede, millipede or major havoc..or the others mentioned in the forums? It seems to be an issue regardless of what CPU type PC you have and what OS you are using etc.

Why not just build using GCC as it is? Should work on any OS X version. And it's simple to compile X-MAME - edit makefile.unix to set up for your system, then type 'make -f makefile.unix' then grab a cup of tea while it compiles.

I might try a CLI version at first myself. My big plans though are mainly front end related. Mac users wouldn't likely use a CLI version if that is all I made. They would just use the current GUI build. There are tons of requests on the macmame forums for a new GUI.

Plus a CLI version isn't exactly "ease of use" for the users. Oh, let's go memorize a lot of arguments to use. Sure, it's trivial for many users....but I would think even intimidating for an average PC user nowdays that never used MSDOS or another CLI based OS as a primary OS.

Until I dive into all of this I have little clue what it will take to make a CLI version work. I would hope the frameworks are setup so it is pretty trivial...relatively. Some that are more experienced at programming than I am haven't been successful. That's not a good sign. I think most of the issues are video related.

X-Code has far superior frameworks to what the older dev tools had for use of gcc. Earlier versions if gcc for OS X had some limits and issues that have since been resolved with later versions. I have very little direct use of compilers in that form so I would need to learn all the ins and outs of make files etc. I have used IDEs which make making the makefiles pretty trivial cuz they make them for you.

Also FYI...the macmame dev still makes his releases using Codewarrior builds cuz it still generates faster code than Apple's dev tools/gcc or X-Code/gcc generates...although he reported that gap is closing with the latest gcc version with new libraries which now supports a lot of the CW-assembly and other CW constructs.

It could be the code base just needs a little more tweaking to have it perform as well from a gcc compile.

[mahlemiut]

Well, that would be my default when recording...but an option to save a snapshot and use the current nvram should be there for things like 5-man TGTS Robotron game....or a game (Joust I think is like this) where you must go into service mode to change the difficulty setting of the game to match TGTS. It also allows special cases like potentially Hyper Sports.

Don't even think about using save states in inps... They can be awfully large.
There's no reason why players can't just change settings at the beginning of play, you also then get to see what settings are changed.

No, it's not new...but when a game ends that console window closes before you have a chance to read anything in it!

Only if you're a moron and run it by double-clicking an icon, or run it from the Run... function. If you really must run it that way, you could also redirect the console output to a file. It's not like MAME exits after the end of the inp is reached, either.

This is where the assembly optimizations in macmame really come in handy though. For some game CPUs it results in a factor of 5+ speedup versus if only the c-cores are used. Pacman slowed down by a factor of 6 when macmame 0.66 came out that had pacman only using the c-core. version 0.60 still had the assembly. This change was done cuz the dev felt macs were fast enough now where just using the c-core was good enough for that game CPU.

So they should be. The speed difference between the C and x86 ASM 68000 CPU cores is negligible on any system faster than about 800MHz. The only other CPU core that has an ASM version is the 68020, which doesn't really work very well, so it's not worth talking about. Then there's also the dynarec MIPS III core. There is a major speed difference over the C version, but other than Killer Instinct 1 and 2, nothing else that uses that CPU is decently playable (speed-wise) on any system. (Trust me, I've tried Fatal Fury: Wild Ambition, and can get about 24fps in-game).

[LN2]

Don't even think about using save states in inps... They can be awfully large.

I haven't said a thing about using save states. I was only talking about nvram. Given MARP once allowed nvram..where you just zip the nvram along with the inp file to submit...later stopped allowing it cuz too many issues on playback...cuz the nvram changed on them or wrong nvram file etc.

I definitely would not allow save states to be saved or loaded while recording.

There's no reason why players can't just change settings at the beginning of play, you also then get to see what settings are changed.

How would they know what settings to change? They would need a readme..or check the TG settings etc. to see what to do...oh, then learn how to do it for that game.

Sure, gamers can learn that stuff...but it's not convenient. Given the typical playback issues I see from TG members are from very basic things, I can't see them handling a more advanced level of using MAME.

Only if you're a moron and run it by double-clicking an icon, or run it from the Run... function.

ok, I'm a moron I guess. I use the RUN to launch CLI-mame. I do this though cuz if I launch an MSDOS shell first and try and run mame from that it does NOT work. I get some lack of memory thing or something. I don't get that using the "run". Perhaps this is specific to my using it in VPC though on my mac.

If you really must run it that way, you could also redirect the console output to a file.

yes, that's actually a good idea...but still not overall convenient. You have to know how to do it(most PC users likely don't even know that) and then a separate text file to open up to view the data.

My build will display this information similar to what you see when you first launch a game in MAME...hit any key to continue.

It's very convenient to the user...and can be BEFORE the actual playback begins...so a user can see the settings used, etc. so if any still have to be manually set they at least have a start on it.

It's not like MAME exits after the end of the inp is reached, either.

So they should be. The speed difference between the C and x86 ASM 68000 CPU cores is negligible on any system faster than about 800MHz.

The speed of a system doesn't affect the speed difference. The issue is if that difference matters or not. I think that is what you mean...on PCs of at least 800Mhz, it can run pacman with c-core at likely 600+% anyway with the throttle off...so who cares if with assembly you could run it at 2000+%?

The only other CPU core that has an ASM version is the 68020, which doesn't really work very well, so it's not worth talking about.

true...68020 game CPUs are one thing currently broken in the latest macmame build...at least in the x-code build.

[mahlemiut]

The speed of a system doesn't affect the speed difference. The issue is if that difference matters or not. I think that is what you mean...on PCs of at least 800Mhz, it can run pacman with c-core at likely 600+% anyway with the throttle off...so who cares if with assembly you could run it at 2000+%?

That's rather difficult to test when MAME doesn't even have an ASM Z80 core.

So instead, I tested Rastan, the first game emulated in MAME that used a 68000. I used WolfMAME Plus 0.87u1 as it has all the 68000 cores compiled in and are selectable via a commandline switch.

C core: Average FPS: 355.877695 (5000 frames)
Dynarec core: Average FPS: 348.872082 (5000 frames)
Dynarec+ASM core: Average FPS: 368.523959 (5000 frames)

I'll do a test on my slower Linux PC later.
EDIT: Test done. 139fps for the C core, 144fps for the ASM core. X-MAME 0.87, X11 build, Xv not enabled. System is a 950MHz Athlon w/ 128MB RAM and a 32MB TNT2 M64.

[LN2]

for those differences I agree...the assembly isn't worth it for the example you give.

However, for pacman as I discussed above differences aren't just a few percent as you show for rastan above but more like 300-600+%.

I will have to do some becnhmarks in older versions. Maybe my memory is faulty and I am just remembering it all wrong.

...although I clearly remember moaning to the macmame dev with 0.66 cuz many games ran a factor of at least 2-3 times slower in 0.66 versus what they ran in 0.60. He said that was because he removed the assembly from those game CPUs in 0.66.

For other games there was no performance difference going from 0.60 to 0.66 cuz there were no assembly optimizations in either version.

The similar framerates though show there is consistency from 0.60 to 0.66 with just the c-core.

[tar]

I think I had only watched 1 wolfmame replay...to co-verify it for TG.

if you watched an .inp , how is it that you are unable to record the videogame ?

& please do not include the slang word cuz in the answer. because...

CEH said the word weather.
correct spelling is- Whether - if it is the case ; introducing alternatives.
Websters dictionary


mahlemiut , is the 68000 CPU made by motorolla / the cellular phone manufactuer ?

[Weehawk]

mahlemiut , is the 68000 CPU made by motorolla / the cellular phone manufactuer ?

No, it's Motorola, with one "l".

[mahlemiut]

mahlemiut , is the 68000 CPU made by motorolla / the cellular phone manufactuer ?

There are likely many different manufacturers who produce the same or similar CPU, but yes, I think Motorola were the ones that originally developed the CPU.