forums.marpirc.net

skillful results , Notman 376,460

you took first place from pac-mac (Ln2).

Thanks Tar! Also, thanks for pointing out the '666' the Number of the Beast screenshot that I didn't noticed that before.

Originally, my old high score was 492k back in early '80s. I don't even remember that version was harder than I used to played back then. Maybe the dip switches are wrong. Normal = Harder???

Later,

NotMan

oh, do you want me to try and top that? it would be in macmame 0.77u2.

I can easily top it...but given it would be in macmame I hesitate to participate here with it anymore.

I think that was a 1-time play score for me for this clone....just to set a score for it.

Notman

the dip switches are wrong. Normal = Harder???

Sinistar is like that.

LN2 wrote:1-time play score

i noticed that you scored an even 370,000
a sign of mastery
no mere halt. purposeful .
i like numbers.
example ; lord gaz in his invaders recordings.

rick , produce one of your added info .inp conversion to windows from macintosh ?
perhaps you can list the ones you have already done.
pirahnah
joyman

I tink those 2 and the pacman one Kord Gaz did first are the only converted ones.

It didn't seem to help the editors here...so I felt there was little to no point to convert the rest of my inps...at least the pac-man game type ones. mspac are my only ones that wouldn't convert properly cuz the pseudo-random choice of where the red and pink monsters go at the start of a board. Perhaps with later versions using mame_rnd that has been "fixed" so cross-platform compatible.

anyway...sure..if I set a new newpuc2 score, I also could have the pc-converted inp available for download and viewing...using pc-mame77u2 of course.

I can't remember if I just stopped or not. I would have to watch my own inp there. I can't see why I would stop at 370,000....so I'm guessing it was just a coincidence. I would have stopped at an even 500,000 or higher if I wanted to have an interesting stopping score.

I actually came in to check this thread before going ahead and trying a game of newpuc2. It will be my first MAME play of any kind other than a few games of Mario Brothers in the past 7 months!...so I am not sure what to expect.

LN2 wrote: I also could have the pc-converted inp available for download and viewing

Crazy Climber wrote:Go For It

the only problem the editors had was that the .inp was not on the marp site.
Just say it is for mame32 windows 77

no, the problem was they wanted me to submit that converted inp as the "real" play..thus replacing the macmame one at the MARP site with the pc one. They wanted me to have the macmame one as a secondary URL given in the description...

IMHO that's deceiving cuz then players see it as a pc-mame score and really played on a PC...and wonder why the hell I didn't use wolfmame etc.

...when it's really a converted macmame replay file.

I also thought that was lame cuz it essentially states screw the MacOS platform and macmame. I would have never gotten into MARP if it didn't accept macmame replays...but it did...even though there aren't many of them. I figured I can still compete with the scores...and PC users see my scores....even if they can't watch most of my replays. Mac users would be able to do so...which is largely what has kept macmame players from participating here in the past before I even came along.

I even thought of the idea to submit the PC-conversion...then get the link for it...then "delete" it...so the score reverts to the older macmame submission. As we all know when you "deleted" something it really isn't deleted at all...just removed from the scoreboard. The zip file for all submissions are here. Then the URL for the conversion would reference the "deleted" replay...so it would actually be on the MARP site.

I still think there should be a method to truly delete replays from here. For example, a contest like QRS and I had on Cameltry...we likely have 10-15+ replays for a few of those rom sets and courses that we submitted. It's silly they are all on the HD...wasting HD space....likely never viewed. You could still have an option on deleting to preserve the file(perhaps a checkbox) so you could potentially reference it in the description of your new one...or reference it in a forum post etc. cuz perhaps it shows something cool from that particular game.

However, the above didn't seem to be good enough for them also...even though the net result is almost exactly what they wanted.

believe me tar...even with the converted ones, they were still on me for other things...like asking me to play a game of pacman using wolfmame where I only play the first few boards...and submit that....yeah, let's replace my 3.3 million one with a 50k one. That works. It shows very little also. You would see the exact same gameplay.

It went beyond just the inp being on the MARP site.

if that is how MARP is going to be, then outlaw MacMAME and XMAME while you are at it...since most don't have xmame.

far more mac users out there versus linux users for sure...

...and only accept wolfmame. delete all other scores...only accept submissions with wolfmame.

...cuz last I checked xmame replays for the most part can't be watched using wolfmame or a windows mame. I only say this cuz the biggest excuse used against me is most of my replays aren't viewable on a PC version of mame.

it got old...and spoiled the fun I was having here.

I almost wonder if I do have a mac-wolfmame in the future if MARP will even accept it.

Odds are I will go beyond what wolfmame does to make it even more feature filled etc. ...like having a fixed value of frameskip when recording....not allow dynamic/autoframeskipping....among other things.

..that might require having a slightly different replay file format versus what wolfmame currently has.

no, the problem was they wanted me to submit that converted inp as the "real" play..thus replacing the macmame one at the MARP site with the pc one. They wanted me to have the macmame one as a secondary URL given in the description...

They? If you mean the editors, show me where this was said, because I sure don't remember that.

far more mac users out there versus linux users for sure...

Linux users would debate that. There are certainly more active Linux users at MARP than Mac users.

...cuz last I checked xmame replays for the most part can't be watched using wolfmame or a windows mame. I only say this cuz the biggest excuse used against me is most of my replays aren't viewable on a PC version of mame.

For the most part, MAME, DOS MAME and X-MAME inps are "compatible", you just have to be sure to have the same CPU cores compiled in, which should be the same across each version.

Odds are I will go beyond what wolfmame does to make it even more feature filled etc. ...like having a fixed value of frameskip when recording....not allow dynamic/autoframeskipping....among other things.

..that might require having a slightly different replay file format versus what wolfmame currently has.

So much for wanting compatible inps then...

mahlemiut wrote:They? If you mean the editors, show me where this was said, because I sure don't remember that.

Well, it didn't directly involve you I think....but this person "represented" the MARP editors where his statements didn't seem like his personal requests...but what the MARP editors along with the backing of many members have requested.

Linux users would debate that. There are certainly more active Linux users at MARP than Mac users.

at MARP perhaps...

That's flawed though. Oh, I'd bet there are more mac users at the apple.com site forums versus windows users....duH.

For the most part, MAME, DOS MAME and X-MAME inps are "compatible", you just have to be sure to have the same CPU cores compiled in, which should be the same across each version.

This seems to follow for macmame also. The issue being as stated before it's actually where the macmame code has older code in it for the inp file formats etc. I think the timing differences like for pacman are from the assembly code for particular game engines being used.

...although I was told since 0.66 that macmame is using the c-core code for most game CPUs....especially the pacman one....yet that timing difference is still there....easily corrected in the code I'm sure.

even if that was specifically corrected that wouldn't change anything from where I sit...cuz otherwise you all would have been satisfied with my conversions.

When I get my own project going...just getting an x-mame core to build using the mac video, sound, controller code and drivers etc. only...otherwise all the ported c code. I then would add assembly from the official macmame to one game CPU at a time...and see if/when replay playback is affected. I'm guessing a lot of those issues are from the assembly.

So much for wanting compatible inps then...

no..cuz I would have an export feature to wolfmame of that same version base number...where it generates a wolfmame compatible inp.

The differences mostly would be extra stuff....like more info in the header...likely needing a larger header...and perhaps something like the frameskip value saved in each frame of data.

I have discussed various features I would want in my build of MAME at the TG forums. Other refs love my ideas. One for example is if the user wants it...in the preferences having general info that often is in a readme instead...but have that in the replay file...and displayed on playback of the replay file. Date played...time of the game...overall stats like average speed, #frames, player name, Tg username, etc. all optional for the gamer to include in the replay file.

This would require a change in the format of the inp where perhaps the first 2 or 4 bytes are a number for how large the header or the next variable in the header is....versus having any limits on it...although that could be set also....or special delimiting characters in the replay file.

The differences would all be to simplify playback of inp files....just play it...the front end reads the header info and sets all the mame settings to match the original recording...sound, frameskip, version, and perhaps more like personal info given above...although sound and frameskip values are all I have seen affect playback.

If recorded in a different version you could easily see that from the raw inp data...or later versions would recognize the format and alert the gamer of which version was used to record.

It really leads to making it easy for TG refs to playback and verify replays. Many refs are having all kinds of issues getting replays to playback successfully. MARP has a history of reporting various playback issues also.

...yet dev of MAME for PC seems not to be addressing this. Most issues along those lines that pc-mame has has never been an issue with macmame(like no OS or library version dependencies which result in things like you can't use sound to record for certain rom sets if you want the playback to work. I have never seen this issue with MacMAME.).

IMHO, this points to it being potentially sound driver related for pc-mame. That also makes sense in terms of some replays for some games being OS dependent. it maybe isn't OS dependent but dependent on the version of direct-x/3d's sound libraries installed or something along those lines.

This also makes sense for why it isn't an issue in macmame....different drivers...sound dependencies etc.

so.. when will your macmame build be ready?

LN2 wrote:no..cuz I would have an export feature to wolfmame of that same version base number...where it generates a wolfmame compatible inp.

that doesn't seem like a productive thing to do for those analogue inps when you're assuming frameskip values per frame will make a difference in playing something back. and that's not really a mame function it's an after the fact "conversion" program's job.

LN2 wrote: The differences mostly would be extra stuff....like more info in the header...likely needing a larger header...and perhaps something like the frameskip value saved in each frame of data.

The frameskip value per frame is an intriguing idea and a good one to try out. You will have to be very carefull recording that value because it will make a difference weather the current frameskip value is the value that was skipped for the current frame or the NEXT frame. More importantly it's not really the frameskipping value, it's which frame's are skipped, i.e you should store a boolean (yes or no) for which frames were displayed or skipped (since all frames are always recorded but not all are displayed and it might make a difference which of the 5 of 12 frames might be skiped in a frameset.) I fear even this might not get these recordings to playback properly if the problem is in the timing of analogue inputs. The frames that are being skiped might be the timing that makes a bad analogue input frame. This could be why fs0 is used to display ALL frames and it works. I've seen a constant fs6 work recording and playing back but i've also seen it NOT, and thus fs0 is recommended.

LN2 wrote: I have discussed various features I would want in my build of MAME at the TG forums. Other refs love my ideas. One for example is if the user wants it...in the preferences having general info that often is in a readme instead...but have that in the replay file...and displayed on playback of the replay file. Date played...time of the game...overall stats like average speed, #frames, player name, Tg username, etc. all optional for the gamer to include in the replay file.

If recorded in a different version you could easily see that from the raw inp data...or later versions would recognize the format and alert the gamer of which version was used to record.

tagging of inps would be convenient with a larger header. but love is a pretty big word. all of these things (save the tg username) are already in a marp wolfmame inp if you include the zip file name.

LN2 wrote: ...yet dev of MAME for PC seems not to be addressing this. Most issues along those lines that pc-mame has has never been an issue with macmame(like no OS or library version dependencies which result in things like you can't use sound to record for certain rom sets if you want the playback to work. I have never seen this issue with MacMAME.).

IMHO, this points to it being potentially sound driver related for pc-mame. That also makes sense in terms of some replays for some games being OS dependent. it maybe isn't OS dependent but dependent on the version of direct-x/3d's sound libraries installed or something along those lines.

This also makes sense for why it isn't an issue in macmame....different drivers...sound dependencies etc.

there's no need to brag about who is the better operating system here, we always refer this as the 98/xp bug but we've revealed this is a true mame bug (will have to search for that thread) that chooses different randomizations based upon where mame is loaded into memory and this bug "I garuantee" will happen in macmame if you use it with enough macs with different programs loaded while playing. mame dev isn't interested in it because it doesn't show up in many games. and more importantly it would never show up recording and playing back your own recordings.

QRS wrote:so.. when will your macmame build be ready?

About the same time as Ben Jos' MAME TE (inside joke)

QRS wrote:so.. when will your macmame build be ready?

I will let you know when it even gets off the ground. I am at the start of the process of backing up everything on this mac so I can reformat the main bootup HD and see if I can get Panther OS installed on it and running. If so, then I can install the X-Code dev tools and get started on the project. If the new OS doesn't like my system(officially the OS doesn't support my system...but there are 3rd party assistant type things to get it working for many systems), then I won't be able to start this project until I get a new Mac.

As stated if my job goes as I hope it will then in a few months I would be able to get a new mac....likely one of those new G5 iMacs. Those come with Panther...and X-Code etc. plus much more HD space so I could get started on the project then.

Unfortunately, a new stop which at first was felt would go o my route...thus making my route a more substantial route which means more money...this new stop will be running separately from my route. ...so things will continue for now as they have been. I still might be able to get a new mac but it just might be a few more months down the road versus what I hoped for.

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.

The current "official" MacMAME is a CW based project....but the last version actually also has an X-Code base as well...with the release build done with CW though.

There are still many issues and bugs in that X-Code base. I am hoping over the next month or so before I really get into this project these bugs will be fixed....and if really lucky a good enough X-Code build to just start with that as a foundation. I likely will be doing that anyway...but nice to not have lots of bugs in the foundation.

Chad wrote:that doesn't seem like a productive thing to do for those analogue inps when you're assuming frameskip values per frame will make a difference in playing something back.

why not? The frameskip value saved per frame was an idea for a future version to perhaps allow automatic/dynamic frameskip again. I consider it a fairly low priority though as it's trivial for a gamer to play the game a few times and figure out a frameskip value to use.

For now, for recording that would be deactivated automatically so a fixed value of frameskip would be used when recording. I would offer this in the preferences as an option....with the default of it being checked. If unchecked the user would get a warning that it might result in replays from some games not being able to be played back.

and that's not really a mame function it's an after the fact "conversion" program's job.

What's the difference between a conversion and "live" progressing during the gameplay to the exact same file format? Having it live would put it into the game frame cycle...thus slowing down performance a tad....so having it separate from that is better IMHO. It could be an auto thing that happens at the end of play that only happens when that option is checked by the user....so it's post-game but not some separate converter application or function a user could do after the fact.
it certainly isn't changing any of the game input data...but just would be adding/removing bytes per frame....or reordering if I have the byte swap endian issue. hehe

I often have wondered if a macmame build was built that actually uses the CPU in little-endian mode similar to VPC if that would get rid of many of the differences resulting in non-compatible replays.

...so the result would be from a run you could have a tgmame replay file generated...and a separate wolfmame replay file generated as well...for MARP's convenience or some contest that requires wolfmame be used.

Ideally, things will stay compatible. I will do my best to try and stay compatible. I hope any header changes can be done where wolfmame would be able to discern the differences and still playback the replay successfully.

That's only if wolfmame and this planned build deviate at some point. most things I have proposed as ideas at the TG forums are mostly front-end handled stuff anyway...like not even allowing autoframeskip when recording. That can be a front-end thing....not changing the replay format at all.

Another idea I had posted was a display on playback showing the game settings...well, the dip switch ones at least...but could be potentially customized so even service mode settings stuff gets saved somehow(which normally might get saved in nvram). This makes it easy for anyone viewing the replay to see the game settings used.

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.

This would make things like the HS discussion almost moot...and play more similarly to the arcade anyway which would have valut records already set. I guess the remaining issue then would be if cheating was used to set extremely high and unrealistic heights first. Nothing is perfect here.

Many of these common issues that result in difficulty of playback can easily be addressed by adding to the inp format...or control via the front-end.

The frameskip value per frame is an intriguing idea and a good one to try out. You will have to be very carefull recording that value because it will make a difference weather the current frameskip value is the value that was skipped for the current frame or the NEXT frame.

definitely... This is down the road a bit though. My first builds wouldn't even address this...but just disable the automatic-frameskip when recording or playing back a recording and use whatever fixed frameskip value is saved in the replay file.

More importantly it's not really the frameskipping value, it's which frame's are skipped, i.e you should store a boolean (yes or no) for which frames were displayed or skipped (since all frames are always recorded but not all are displayed and it might make a difference which of the 5 of 12 frames might be skiped in a frameset.)

yes...this makes sense.

The frames that are being skiped might be the timing that makes a bad analogue input frame. This could be why fs0 is used to display ALL frames and it works. I've seen a constant fs6 work recording and playing back but i've also seen it NOT, and thus fs0 is recommended.

yep..definitely. I haven't seen one replay file in macmame though not playback if the same fs value was used on playback versus the actual gameplay. ie. I can play centipede with fs10 if I wanted and it will playback just fine in macmame. I can also record with sound on....works fine on playback as long as same sound settings used(includes the same freq. setting).

all of these things (save the tg username) are already in a marp wolfmame inp if you include the zip file name.

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?

It seems you guys use analinp to view this information in the header in a usable form. Most of that can be done on playback...like game settings. Yes, mame and wolfmame have long had that in the inp....to use the same on playback...but a user can't just view that inp and know wtf they are looking at.

A TG ref has to be able to get these game settings to know the game was played using TGTS or not. It might be useful to MARP confirmers also to check the settings easily. Most scores are confirmed at MARP without a clue of what settings were used. I'm guessing in several cases they aren't mame default and aren't TG settings...but something else. Once in a while a knowledgeable player will post suspecting this or that about certain replays.

A build which displays the settings used (at least the dip switch ones) will certainly help.

I have also considered whether to record F2 and all input within the F2 mode. This would allow playback to show this also...and allow special settings for some games...like 5-men only Robotron for TG. For games that reset/reboot after exiting F2 this might be impossible...but many games don't reboot coming out of F2 mode.

Even here, if nvram is saved(which usually is for games with a service mode) then saving that nvram in the input file as noted above will auto-set all of that stuff...so same settings used for sure.

These ideas and potential additions are all for making the playback experience better for gamers...as well as the tgmame build for ease of use of verifying by TG referees...or refs for other contests.

I have gotten way too many e-mails and seen far too many posts here about playback issues for these types of things which overall would be fairly simple to add to the code to remain undone. These changes certainly won't fix all playback issues...but likely would remedy 90+% of the issues.

A brand new user for mame should be able to get it...get a replay file made with that version...and play it back without any additional knowledge or twiddling of the settings necessary...with a few exceptions.

there's no need to brag about who is the better operating system here

Why is it when something like tons of versions of direct-x/3d is discussed from that others think I am bragging about one OS vs another? I wasn't doing that at all.

we always refer this as the 98/xp bug but we've revealed this is a true mame bug (will have to search for that thread) that chooses different randomizations based upon where mame is loaded into memory and this bug "I garuantee" will happen in macmame if you use it with enough macs with different programs loaded while playing.

If it's a true mame bug you are right...but I have not seen one case of this yet in macmame.

I can play pc-mames in VPC on my mac...where odds are through that emulation things like memory locations used aren't the same...and mame behaves versus OS used exactly the same way in VPC as on a real PC.

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.

How memory was addressed etc. is far different in MacOS 8.x and 9.x versus the 10.x yet I have no issues playing back replay files...as long as the same version of macmame is used for playback as was used for recording.

There are a handful of versions of macmame which were carbon apps and ran in OS X.x and 9.x. I can easily watch the same replay file for any game in either OS and it works fine. I quickly tested this quite a bit after I first saw the OS version issues discussed for pc-mames.

mame dev isn't interested in it because it doesn't show up in many games. and more importantly it would never show up recording and playing back your own recordings.

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!

...or have I read that wrong?

These are major titles from the golden era and it's a shame they have those issues in pc builds of mame.

If I have read that right...that is what I am saying has never happened with macmame.

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.

If that was a real mame bug then wouldn't it happen in macmame also?
Since it's sound related...I then said this issue points to the sound-engine aspect of mame...which for pc-mame likely uses the libraries for directsound or whatever they call it nowadays.

WOW, that was a long one....sorry guys. hehe

To get back on topic...hehe...I tried a couple games of newpuc2 last night.

I did semi-as-expected...I sucked. hehe

It will take a bit to get back into things...like my fingers actually doing what my brain tells them to do. hehe

anyway, I did manage to get around 275k. I figure a few more games of it and I should be back up around the 350-400k range.

that last mame dev ignorance message was about the 98/xp/memoryloading bug, the frameskipping/analogue issue/bug there isn't really an excuse other than mame already emulates these games acruately, the inp is mearly a feature of mame not the goal of mamedev :(