Chad wrote:
Marp does not need recordings that playback once even out of 4 or 5 attempts, we can be patient and wait till mame is fixed before we allow such impotent recordings.
In those cases if that is the case with a certain game then that game should be archived until a future mame does play it back reliably IMHO. I'm sure you have archived a few because of that already. If a game's inp plays back reliably in pcmames then it should in macmame also.
yeah, true, but if we don't adopt a plan like this why even have a marp for mac?
Well, I view MARP 2 ways. It is a repository for recordings for various games. Anyone can download the inp and watch it to see how it's done etc. However, the other part of MARP is it does serve as a scoreboard where you can show and compare your scores against those from all over the world that have submitted scores here.
I think of the 6 months I have been a MARP member, I have only viewed a handful of inps. That is just because I generally just view the scores and see what I have to beat. I personally think it's cheap for some games like Loderunner or tons of other games you can download and watch the inp of someone else to learn the patterns to complete the levels then play it yourself and submit a high score also. I develop my skills for a game from my own play...not based on someone else's.
Therefore, I put more weight on MARP being a scoreboard than it being a library of inps that anyone can view.
kind of pointless to post a score that the "general mac public" (being that one person wanted to see it) can't see played out. most recording problems are SIMPLE to fix (i.e. nvram or games that need or can't have sound to record)
Yes, this point is valid. However, I would hope the confirmer or person that couldn't play it back correctly would have tried a few options or would have contacted the player or macmame confirmer if a confirmed score to see exactly what macmame settings were used to get the inp to playback correctly.
Many macmame players...as I'm sure PCmame players as well, aren't aware of the tricks to ensure good inp recording and playback or just viewing someone else's inp. MARP has that info but not where it's easily seen. Given MARP is based on inps the welcome message you get from MARP after you first sign up should have info on the main tips for inp recording or a link to the page that has all of that. The same advice you give for PCmames is exactly what macmame players need to do also. I have no NVRAM folder. I always use a fixed frameskip. Those 2 are the big ones. That would cover 95+% of the games.
so the confirm/deny rule is mostly to get the communcation out before someone starts uploading tons of recordings that won't playback because of lack of reading the rules.
Oh, I agree there. I'm guessing confirmers if unable to playback an inp on that same mame version e-mails the user though to get more info or ask if nvram or auto-frameskip or what specific frameskip was used etc. That would take care of someone making the same mistake in future recordings they perhaps made on that first one or few.
There aren't many games that are picky overall for playback. Of all the games I have submitted to MARP only 1 is quite picky on playback and takes a few attempts before it plays back correctly. You can tell if it is within the first 5-10 seconds though so it only takes 30-60 seconds to do multiple attempts to see if it's "ok" that time. I'm sure it's the same way on the PC side also.
Are you a confirmer right now? I guess you (and someone else in the mac world) should be. Ask ***PL***, pat, for that. Marp is open to all recordings for all oses provided they playback consistantly with known settings/oses. And Barry can add the macmame versions to the list.
Nope, I'm not. I have inquired about it in these forums previously but didn't get any helpful info of how to proceed. I'll check the site to see what it states for becoming a confirmer. I also had pointed out in these forums only mac36 was listed and it would be nice to list 58 and 60 also. I got replies saying that was pointless cuz only a couple mac users submit here. Well, perhaps seeing only mac36 and no macmame confirmers is part of the problem there.
Lets hope Brad gets the version with the new random number generator, it's possible that could help some issues between pc/mac but the architecture is another thing to get around.
Is that 0.64 or 0.65 with that added?
It certainly would be nice if mac.inps had a header, (still don't understand why they lost the header, it's such an OLD mame thing to not have a header in the inp, almost like they are not using the same code base) with out it there's no way it'll ever be compatible.
Yeah, I have commented about that at the macmame forums. There is no reason really to change the inp file format versus what it is on PCmames. My guess is perhaps with the mame updates he hasn't bothered noticing or caring about that change to the inp format as for macmame it really doesn't matter. Given he is working on 0.64 currently I'll point that out to him to check for the current inp file format and please use that for macmame also.
Brad seems to generally do his own thing though and doesn't really care about cross-platform compatibility. I think for many games the inp playback not working isn't cuz of some random number generation, but because of that missing header or because like I have noticed in many games, the bytes are swapped as written to the file. It seems this is specific to certain game CPU cores as for some games the macmame inp plays back fine on other platforms.
xmame(whatever the latest for that was) has been ported to OS X to work within Apple's X11 for OS X. I have not tried it yet though to see how well it runs. It will take a bit to just learn how to properly build and get it running. If inps in that xmame are compatible with xmame for linux on PCs for games that where regular macmame isn't compatible, that right there shows it's within a few cpu cores he has the bytes swapped which results in them being swapped in the inp.
For example, for a marble madness inp, any PC inp of that attempted to be played in macmame just results in the game going into service mode. If a macmame inp of that is played in any pcmame that results in same thing. However, for 1 inp I removed 8 bytes near the beginning to make the initial input data align properly and then it did playback correctly at least for the first maze instead of going into service mode. It got out of sync on the 2nd maze but that likely was cuz the shift I had done to the input resulting in a close-call where the slightly shifted time of the input resulted in my ball hitting that ball and getting knocked off whereas in the actual game I barely missed it. Anyway it was an interesting test.
It seems most likely the inp compatibility issues will generally remain for macmame. I'll see what the site says about becoming a confirmer etc. and contact one of those guys. I think if we got a couple macmame confirmers and had the submit page showing the few mainly used macmame versions announcing that at the macmame forums would perhaps get a few more participating in MARP. More participation is a good thing.