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.
Source of WolfMamePlus
Moderators: mahlemiut, seymour, QRS
I have the feeling that (some of) you don't really like it that this thread was (re)bornChad 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.
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++.
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.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.
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.
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.
-skito
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.
-skito
