forums.marpirc.net

Haze, strictly for debuging purposes, why can't you apply the wolf88.diff? This one i really want to know the answer for, since wolf mame truly sucks if it makes it's inps not usable for debuging. The ONLY reason (besides the mame open source disclaimer), i feel the source should be available is for mamedev purposes. Is there something about debuging with a wolfmame patch distastefull? It's certainly easy to apply and "un"-apply for debuging purposes with the patch program. so, What is the hangup? ok that's my third wording of the same quesiton, i'll stop, but barry (and i) would do anything to make wolf mame more mamedev friendly.

I guess maybe the patch is suited for a mameplus build and not a mame build, that's my best guess, but I would gladly patch in the differences for you if that were the case.

And now that I think about it... why is wolf's extra info stored in the inp?
Wouldn't it be better to write that to a separate file? (like the wlf)
That would solve the incompatibility problem, and without the need of a converter.

Not requesting, just asking/suggesting!

I want to soften things I say before...

MJS wrote:And now that I think about it... why is wolf's extra info stored in the inp?
Wouldn't it be better to write that to a separate file? (like the wlf)

It is. More for double checking now, than anything.

Chad wrote:so why don't you submit a patch for that F3 thing, that would be cool for everyone to use, where's the source for it? on your site i hope, lol.

I have the feeling that (some of) you don't really like it that this thread was (re)born
Anyhow, if I made that 'F3-change', and it works fine, I will certainly let everyone enjoy it. But be patient: I'm not an expert programmer, like some of you possibly are, and I'm more into C# then C/C++.

The TJT wrote:I want to soften things I say before...

Well, that definitely explains a lot.

LN2 wrote:

The TJT wrote:I want to soften things I say before...

Well, that definitely explains a lot.

Would being drunk explain more

Chad wrote:Haze, strictly for debuging purposes, why can't you apply the wolf88.diff? This one i really want to know the answer for, since wolf mame truly sucks if it makes it's inps not usable for debuging. The ONLY reason (besides the mame open source disclaimer), i feel the source should be available is for mamedev purposes. Is there something about debuging with a wolfmame patch distastefull? It's certainly easy to apply and "un"-apply for debuging purposes with the patch program. so, What is the hangup? ok that's my third wording of the same quesiton, i'll stop, but barry (and i) would do anything to make wolf mame more mamedev friendly.

I guess maybe the patch is suited for a mameplus build and not a mame build, that's my best guess, but I would gladly patch in the differences for you if that were the case.

Applying and unapplying diffs all the time gets messy, and if files change is prone to failure and an added inconvenience the fact that wolfmame is based on mame32plus which has many code changes of its own increases the chances of it failing.

As a developer I have many source trees, having to remember to take the additional step of applying another diff over of the source tree in question is quite frustrating.

The most useful thing would be a simple drag+drop converter which dewolfs the inps, while it might not work for everything (not everything playsback correctly in a debug build anyway) many of the inps would be useful for debugging again.

no problem, i will start working on that asap, unfortunatley it won't work for analogue inps/games, but most aren't. Of course you aren't garaunteed to have it playback the same but at least i can dewolf/dealpha it to get to what was input and try in a official mame env.

Now if you could convince the powers that be to store the analogue inp data within the 120 byte frame (by using some of the 800 or so bits that aren't used for particualr games) ... too much to ask i'm sure.

what is the motivation for dewolf/dealpha a replay file?

debuging, haze would have trouble patching in and out with wolf source (because of source tree broken branches) just to test a wolf recording in debug mode with official mame. Marp was originally designed to help mamedev's with a harvest of inp test files, btw. I sent a dewolfer to him, that will work with non analogue recordings, i may make it public as long as it appears to work ok.

I wrote a small simple app like this simply to watch some BBH leetness under X-MAME while my current PC was in use.

Please share!

And for future wolfmame versions please consider not changing the inp structure... or is there any disadvantage to having all the extra information in a separate file?