This is an update for dizzy-meters.lua, which it replaces in the MAME-rr SVN repo. A full description of supported games and functions can be found on the new wiki page. That page still needs some screenshots.
Besides the name change, this one is easier to read and edit. The old file was one of the worst coded scripts I've ever written: I was experimenting with keeping the usage of if
to an absolute minimum, which led to some strange arrays of functions. Plus it was too rigidly geared towards drawing specific elements, whereas the new script is more versatile. Part of the motivation behind this was just to replace that ugly thing.
I still haven't gotten around to adding some SF3 stuff.
I'd like it if people could verify the omissions; e.g., are there really no dizzies in kof2001 & kof2002? And aren't there escapable combos in the Marvel games?
I can verify that there are no dizzies in KOF2002, and since KOF2001 was developed by the same people (Eolith) I wouldn't be surprised if that game didn't have dizzies either.
Posted by: PhoeniX | 10/09/2011 at 04:03 AM
dying to see some SF3 stuff. good stuff!
Posted by: alexander | 10/09/2011 at 06:13 AM
Dizzies are DM specific in 2001 and 2002 like Ryo's HDSM (In max mode and red life qcfx2+2p). The development stun counter is still there but only goes down on certain moves.
Posted by: jedpossum | 10/09/2011 at 10:17 AM
I see, so it's special cases only, like vsav. I'll see if I should do anything about that.
SF3 has some interesting numbers grinding under the hood...
Posted by: dammit | 10/09/2011 at 10:15 PM
Hi, dammit.
Can you update the main pages of mame-rr and fbarr, please? It looks like you've made many new scripts since I last updated them. (You can change or remove anything/everything there, or do with them whatever you think is better.)
Also, it seems there's a typo in fighting-OSD.lua:
print("Lua hotkey 1: toggle numbers")
print("Lua hotkey 1: toggle bars")
(Should be "hotkey 2" for "toggle bars", I believe.)
Posted by: mz | 10/10/2011 at 01:58 AM
OK, done. All I did was consolidate the script links a bit, and added links to the main MAME/FBA pages. They finally released a new mainline FBA, btw.
I'll fix that typo in the next commit.
Posted by: dammit | 10/11/2011 at 12:40 AM
Thank you, it looks much better now.
Oh, wow... They finally fixed the crashes in Neo Geo games and the others. And they cleaned up the source code a bit... It might be worth it to update FBA-RR now.
Hopefully you've already learned how to compile it. :P
Posted by: mz | 10/11/2011 at 08:46 AM
=/
BTW, good job on the CQ3 translation! (For some reason I can't leave comments on Blogger right now.)
Posted by: dammit | 10/11/2011 at 04:15 PM
Hehe, thank you. :)
What do you mean with "=/"?
You still don't know how to compile FBA? Or Neo Geo games still crash for you when you try to load a savestate in them? (Or something else, perhaps.)
Posted by: mz | 10/11/2011 at 08:09 PM
Yeah I'm nowhere near being able to compile and maintain those binaries...
Posted by: dammit | 10/11/2011 at 11:09 PM
OK, then. I'll try to update FBA-RR by myself now. (There are three guides to compiling at barryharris.me .uk... You should read (one of) them. :D)
There's been three different releases of FBA in the last few days... I hope this won't be too hard.
By the way, let me know if you can think of any features easy to add or bugs that don't require too much effort to fix.
Posted by: mz | 10/12/2011 at 01:45 AM
If you use Enhanced blitter with one of the hitbox lua scripts it crashes FBA-rr. That is the only bug I can think of at the moment.
Posted by: jedpossum | 10/12/2011 at 08:38 AM
ESN found why some of the 3S hitboxes don't show up in FBA: Lua (and memwatch) won't read past a certain point in memory.
This might also be why some NeoGeo hitboxes don't work in FBA (e.g. garou): the bank control at ~0x2FFFC0 can't be poked.
And I know you said it's a hassle because each driver would need its own implementation, but if you could get Lua-native breakpoints working in at least the major drivers it would be awesome.
Posted by: dammit | 10/12/2011 at 11:27 AM
lets see marvel explicable combos.
the main ones are rollable otgs, you can recover after a knockdown and avoid a lot of otgs. No idea how that works tho
the other explicable combos are pretty evident. combos on assists and throw teching, that kind of thing, don't really need an indicator for that kind of thing.
Actuality come to think of it I remember from the joo dvd that you have a small amount of directional influence of where you go during hit stun in certain situations. Might be mvc2 only and pretty imposable for something like this.
I think an otg indicator would be the only useful thing
Posted by: error1 | 10/12/2011 at 01:24 PM
So... I spent many hours trying to find what was making FBA-RR crash at game start after updating it to 0.2.97.11. It turns out that this new mainline FBA crashes if you disable auto frameskip, and FBA-RR has that option disabled by default.
It seems whenever FBA fixes some crashes, it always add some new ones elsewhere...
Thanks for the bugs/features, I'll see what can I do; although I'm a bit demotivated now. (And sorry for the off-topic. :P)
Posted by: mz | 10/12/2011 at 09:24 PM
error1: So it's all about the OTGs then. If we're lucky there's just a "can roll now" byte.
mz: Sorry to hear that. Hope you figure out how to deal with it. But isn't auto frameskip not a big deal to leave on?
Posted by: dammit | 10/13/2011 at 03:01 AM
It isn't really a big deal, but is ugly and annoying.
Anyhow, I found that the crashes only happen when using the DirectSound driver... So I reverted some code in it and fixed most of the crashes (it still crashes sometimes when auto frameskip is disabled and you load a savestate during movie playback, which means it still is a piece of shit.)
Eh... I'll try to forget about it for now.
Posted by: mz | 10/13/2011 at 06:32 AM
Hey, I think I know why SFIII only reads up until a certain point in memory in FBA: the search engine of FBA only reads the memory of the first CPU, and here:
http://maws.mameworld.info/maws/romset/sfiii
it says: "Main CPU : Hitachi SH2 (possibly 2)", so maybe SFIII uses more than 1 CPU. :D
Posted by: mz | 10/13/2011 at 08:10 AM
If you open a membrowser window in MAME's debugger, there's only the main SH-2 option in the dropbox, and you can browse freely past 0x04000000 and 0x06000000, so I don't think that's it.
(Of course, the real answer to the problem is in the source, if I could understand it.)
Posted by: dammit | 10/13/2011 at 06:20 PM
OK, I think you may be right. That's better for me, since I couldn't really understand how FBA handles multiple CPUs for its cheats.
What seems to have worked is just disabling the "IsHardwareAddressValid(address)" check in the memory-reading functions: http://img403.imageshack.us/img403/600/030ds.png
This means that FBA is not reporting the correct RAM size for the CPU in this game. And this also means that the bug in garou is not related, since FBA doesn't have any check when it writes to memory. Maybe you're writing to memory using writeword or writedword while using the wrong endianness? (Unlike MAME, FBA can't detect the correct endianness automatically, and you may have to specify it.)
I'll leave a build of v0.0.6 including that change here if you want to try it: http://www.mediafire.com/?9bb6g68f362rr46 (If you try it sometime, please let me know if you find v0.0.6 more crashy, less crashy, or maybe just the same as v0.0.5.)
Posted by: mz | 10/14/2011 at 04:09 AM
The test version is reading from the CPS3 rom region nicely. Crashiness seems about the same here. Looks like 0.2.97.12 just came out, and:
Fixed crash when (de)selecting auto-frameskip and using the DirectSound audio module [Barry]
Here is a little script that shows the bank address is not getting written to. (Compare the results in FBA and MAME in garou.)
Also, it shows it's not an endianness problem, at least in reading.
Posted by: dammit | 10/15/2011 at 01:07 PM
That bank address is in the ROM region? Maybe FBA can't write to ROM using its cheats... (There's a huge mess of function pointers that I can't follow.) There also seems to be a WriteByte function and a WriteByteROM function; maybe the cheats use just the regular WriteByte.
(Sorry for the very slow progress. That crash that happens when one loads a state, during movie playback, makes this version completely unusable; and it feels like just a waste of time to keep working on this. And it still occurs after updating to 0.2.97.12...)
Posted by: mz | 10/18/2011 at 05:23 AM
I don't think the bank address is in ROM, since the program is constantly writing to it, but it's not typical RAM either. When it gets written to, a bunch of other addresses throughout RAM change immediately.
Not much I can do to help, sorry. Up to you to decide to hang in there, either way that test build has been very useful.
Posted by: dammit | 10/19/2011 at 01:59 AM