I'm afraid I had to vote No.
There were some good moments, and I'm sure you put a lot of effort into the run, and it may also be a good technical demonstration or combo video, but I wouldn't know about that. The problem I had with the run was that the fighting was way too one-sided and repetitive for a run that doesn't aim for shortest time.
I guess you might reasonably dismiss me as having insanely high standards or whatever, but I feel that this kind of run needs more showmanship to be effective.
I don't know. Maybe the option Dromiceius changed to ignore SRAM, also ignores input config?
Ferret wrote:
Custom input maps don't get saved.
The reason for both problems (as far as I can tell; I can't actually run the program) is that you patched over "nConfigMinVersion" so that the emulator thinks all config files are outdated and ignores them.
I think it's best referred to as an algorithm. We want the code, not just the logic.
Anyway, how's it going, antd? If you're still trying to get inside kernel.bin you might try Daemon-tools. Though, unless I'm very much mistaken, all you'll find in there is a less intelligible version of what the debugger gives you.
Looks precise, but a bad game choice, IMO. It's kinda like a regular Mega Man game, but with all the glitchy platforming removed, leaving the re-fights and Wily. Voted Meh.
compiles fine, but doesn't run for me on Linux. As soon as I try and run it, it segfaults.
I think I found that awhile ago. Fixed it locally, but I guess I should have sent in a patch. In the future, I'd be glad to do so, but I don't know exactly how SVN works, or if I have the necessary permissions.
But basically, someone goofed in x11.cpp around 1025:
READONLY_MOVIE_TOGGLE,
FRAMEADVANCE,
SEEK,
LUA_CONTROL,
FUNC_LAST = LUA_CONTROL /* update this to match the last token */
};
FUNC_LAST is set to SEEK in the SVN code, causing a segfault elsewhere in x11.cpp.
I'm not sure how to explain your difficulties, or the GDB output you posted, other than that maybe you didn't use debugging symbols when you built.
Having played this to some extent, I was tempted to like the movie, but had to vote No. Too much grinding. The use of glitches to skip parts of the game made it doubly unsatisfying, because it creates a proportional increase in grinding over the rest of the gameplay.
A more optimized movie made with modern tools (i.e., subtitles) and maybe with an appropriately defined 100%/completionist goal would be entertaining, but this one fell short for me.
Wondering if there are any emulators for Mac OS X that can read .gmv files?
I haven't tried it myself, but I'm given to understand that Linux users use Wine to run Gens, our rerecording Genesis emulator. Wine apparently works on OSX, so maybe you're in luck.
Hope that works out for you.
Play and steal ideas from Nethack, because they've already done pretty much everything you can do with a maze, I think.
Since you didn't forbid outlandish ideas, I also suggest learn about Tim Conway's "Game of Life" and related topics, and consider how you could exploit the properties of a maze as a kind of organism to create interesting (as opposed to random) structures for players to navigate.[/handwave]
Also, your SVN appears to be empty as of revision 34.
I met a pornstar. Very hot, not to mention a contortionist who could bend herself into positions that are unnatural even for real contortionists. I don't remember the details of our exchange, but later on I discovered that her back was a giant mouth with concentric rows of razor-sharp teeth.
So I asked, "can you eat with it?" but she just snorted disdainfully and I woke up.
Edit for fridge logic: the correct question would have been "what kind of porn do you do?"
Had another weird dream a week ago. Google had invented an AI that could simulate every human being who had ever used the internet. I looked at what I thought was the source, but it was a just a black and white picture of a brain. I zoomed in (this was a PDF, I guess) and noticed that each of the black pixels of the brain was another picture of a brain, and that each of these brainlets were themselves not really code, but reams and reams of (obviously machine-generated) XML, shaped into a brain!
Ostensibly, this XML would consist of emails, forum posts, google searches, YouTube activity, shopping habits and whatnot.
Remember: Big Brother is watching.
:/ It's a real pity this game is so obscure. It seems no one's checking this thread because no one knows the game.
Sounds like my cue to chime in. :)
I've been a fan of this game since playing it in ZSNES on a 200mhz pentium II. It's a bit of 90s nostalgia to me... which I guess is why I was surprised and impressed by the action so far. It's always weird to see a familiar game played using jump-kicks as locomotion and such.
It's shaping up to be a great submission.
You don't often see a guy work so hard to get pegged in the head by a bird. Maybe all those concussions explain the epileptic fit Keith seems to have after defeating the last boss.
The precision looks solid, considering some of the remarks in the submission text. The only thing that really looked like a mistake was the cat-grinding segment, where some of the cats don't drop anything. Is the drop RNG is deterministic, or somesuch?
Either way, I definitely think this should be published. Yes vote.
It works so far, in the sense that I can predict when a critical hit will happen without having to try manually on every frame
(95% of the time, very rarely it fails, no doubt it's the other 1 byte addresses messing with something)
Does this make sense? Perhaps someone with experience of RNGs in games can say if this is plausible or not?
What you've shown makes sense, as far as it goes. Disassembly might still be useful here; even if you don't trouble yourself with the opcodes, you can still breakpoint those 1-byte addresses and learn about other addresses used in the same functions (and which thus influence or are influenced by the mysterious RNG bytes.) Figuring out what those addresses are for then gives you a broader picture of what's going on.
I don't recommend doing that, though- if your disassembly is generally reliable at this point, then going ahead with the TAS seems best. You probably wouldn't want to spend another weekend decoding that last 5%, only to find that the algorithm drastically changes later on, or doesn't work with Deathblow, etc.
antd wrote:
Thanks FatRatKing for your PM. Your advice was extremely useful.
Surprised by this, I am not. :)
Also, FatRatKnight, I want to apologize for volunteering your assistance without your knowledge, or permission. That was a bit thoughtless on my part. :/
What Derakon said.
Also, shouldn't this have been played on level (i.e., difficulty) 8? I don't remember exactly how it worked when I released 0.0.2, but I thought FBA would allow you to access the dipswitch screen?
That's kinda sad. It looks like everything that's been implemented actually works, but they ran out of time before they could do collision detection or physics... or fix the infinite reverse acceleration.
I vote Yes.
The platforming looked tight, and the camera work was good. I even laughed once or twice during the on-a-rail section. Though the game curiously lacks much of a climactic finish, its music and graphics make for interesting viewing, IMO.
Also, no prancing werewolf in this run.
Much thanks to ShinyDoofy for re-uploading his encode.
Hmm, I see. This seems way over my head. I'm seeing most of this for the first time, and it doesn't seem easy :p
The hard part is getting your head around it. After that, it's actually pretty simple. But yeah, it's more than a weekend endeavor.
I have just private messaged him, hopefully he can get back to me about that. What would be your guess?
He is a genius, but I hadn't counted on the RNG being so complicated. 40 bits to be reckoned with, apparently. That seems like a lot. I'm not really sure how the time spent decoding the RNG would compare to manipulating the old fashioned way, even over the course of the entire run.
It's too bad my computer fails at PSX emulation, or I'd have figured this out myself by now. If PCSX had Lua support, I could feasibly write a script to find criticals by brute force... Now that I think about it, there IS another option. LSS: L. Spiro Script. It's a scripting language inside MHS. I can't just wink an LSS script into existence and send it to you as I could with Lua, but it's worth a shot if FatRatKnight can't offer any better ideas.
I believe the enemy health address is at 800F8614. I put that under 'Set Breakpoints' on the bottom right. I'm not sure what 'Reg' should be set to...?
Leaving it unset seems the sensible thing to do there. I believe 'Reg' refers to 'register', which is like a memory address located inside the CPU. All the data being processed has to go through one of the 32 registers.
Once I press Run, it brings me back to this screen. And the address 800B007C is selected and shown in various boxes. I guess the enemies HP is being written on every frame by 800B007C?
To be clear, you need to set the breakpoint during battle, preferably immediately before Cloud's sword hits an enemy and the numbers appear. If you set it while the ROM is booting up, you'll get false positives as the PSX does some stuff we don't care about.
800B007C is the "execution pointer". It's the address in the ROM where the code currently being executed is. In this case, "ADDU" is the opcode being executed, and s1, r0, and r0 are the operands being read or written. The CODE column, incidentally, is just the DISASM column rendered in hexadecimal. It's not important.
I notice that s7 holds the address used in the breakpoint. It also happens to be used as an operand in the op that preceeds the one hilighted in the screenshot: 800b0078 SW v1, 0000(s7)
It might load the value held by the address in s7 into register v1. You're going to need to learn the MIPS architecture to decipher this.
If you press Run repeatedly and the execution only advances a single frame each time, that would suggest you may have the wrong address. If there's a way to lock/poke it, you should verify that it is what you think it is. It's also probable that the enemy HP would be loaded into one of the registers as you step through the execution upon hitting the breakpoint.
I'm not entirely sure what's going on here. Some reading up on the subject should be helpful. Are there any general things I should be doing?
One thing that's probably not immediately obvious is that all functions exist to operate upon certain memory addresses. Knowing what those addresses are and what they do in the game is crucial to understanding why a function exists, and how it fits in the program as a whole. In other words, a big part of this task will likely involve watching memory addresses to see what they're for.
Do you mean that I should find the address for the enemies health? And set a write breakpoint on that?
It depends on the capability of the debugger. If there's a "backtrace" button, then yes; breaking on the enemy HP being written to, and getting a backtrace at the instant when it changes will narrow down the relevant code to a few functions, one of which will have the formula we're looking for. If not, it gets hairy. You'll need, first, to find the frame on which the HP is written, and then find the RNG read that immediately preceeds the HP write. It'll be there that the criticalness and damage are determined. The problem is, the RNG might be read and written a dozen times before the execution passes through the crit formula.
A problem is that the addresses I've found are not the same address with other programs. I think it has something to do with the offset.
Basically, PCSX-debugger uses different addresses, in the format of 800xxxxx
In my memory hacking program the address is 00BF8634.
Can I convert it or find a way to know what the address is in PCSX-debugger, or even pSX emulator for that matter..?
Yes, but read on.
another thread wrote:
Sometimes when I close and re-open PCSX emulator all my addresses in MHS will have changed...
This is because PCSX's RAM chunk is "dynamically allocated". What you need to do is find the "static pointer" to the 0th byte of the RAM. Whereas dynamic memory will be different every time you run the program, the static pointer will point to the dynamic memory.
There's a special checkbox that searches for "static pointers only" or something, and the range would be set thusly:
from: 0xBF0834-10000
to: 0xBF0834
...So that the static pointer to the 0th address would be listed among a (hopefully very small) set of found addresses.
I think there's actually a tutorial in the help files that explains how to do this in more detail.
Once you know the 0th byte, you should be able to calculate the in-emulator address of the enemy HP by subtracting the MHS RAM base address from the MHS Enemy HP address. The calculation will look something like this:
0xBF0834 - 0xBF0000 = 0x834
In which case, the emulator address would probably be 0x80000834
Eh... hopefully some of that made sense. This is getting rather complicated, so I wouldn't blame you if you wanted to give up and just luck manipulate by hand, at least for the time being. :/
Edit: also, regarding using MHS' debugger, I think even L. Spiro advised against using it for emulator debugging, somewhere on his forums. It would complicate the disassembly a whole lot, adding emulator stuff like input handling, GUI, threading, and whatever else. It would also give you the PSX assembly after it had been converted to PC assembly, which I think would be much harder to read.
You'd be much better off in the long run using a native debugger.
Edit2: The PSX processor uses a "reduced instruction set", which can apparently be described in a few pages, unlike x86 assembly. I'm adding this because that link is going to be handy later.
Glad to hear you've been working on this, antd. I hope I can provide some answers.
antd wrote:
The only problem is, I don't know when a critical hit will happen. In battles, I will have to keep trying each 4frame set to see if there will be a critical hit. This takes a long time, and I think it's possible to defeat this problem with RAM watching + some sort of formula.
You're correct that you need both a RAM address and a formula. From what you've reported, the RAM address (the RNG- random number generator) in this game is 2 bytes, and advances every four frames. If the RAM tools allow it, you'll want to search for values "not equal to previous" every four frames until you see some address (or possibly a set of addresses, but let's hope not) whose value changes to another random number every fourth frame. With a little luck, that's the RNG you're looking for.
Now you need the formula. There are a few ways to get this. The way I'd do it to run the game in a debugger, setting a breakpoint on the enemy HP being written, and backtracing up to the point where the damage/critical-ness is determined.
There is another method, but I've only heard about it from FatRatKnight. IIRC, he uses trial and error (i.e., statistics) to infer the critical hit formula. I could venture a guess at how he does that, but you'd probably want to ask FatRatKnight himself.
If you need clarification on any of the above, go ahead and ask.
After reading Lag's, I have to share my own method of not getting any work done:
10 Find a game that is impractical to TAS by hand
20 Clearly define the problem of TASing the game
30 Figure out a solution to the problem in Lua, probably using bogo-heuristics, that doesn't involve me having to do any actual TASing
40 Hunt down necessary memory addresses
50 Work on implementing the solution until the theory is proven sound, but still lacks practical usability
60 Take a short break from the project
65 Wait six additional months
70 Find that the code has somehow been deleted
80 GOTO 10
Has anyone worked on putting Controller Support on one of these emulators as of yet?
Peripherals aren't a priority, as there are no games that I know of that need a stick for practical TASing in the way that the N64 does. I'll keep this suggestion in mind, though- I know some TASers prefer a gamepad, and it shouldn't be too hard to add to a program that already uses SDL.
As for FBA-RR, if you really want to use a gamepad, you can always use AutoHotkey to map the joypad to the emulator keys. It's no more complicated than the example I posted above. More info -> http://www.autohotkey.com/docs/misc/RemapJoystick.htm
The issue of rom versions seems to be under control, I'm pretty sure they're compatible with this emu. Could video settings or something be the culprit?
Any development on this issue?
It doesn't look like anyone has been working on this lately, and I'm afraid I have no idea why FBA would fail to detect your ROMs, other than because of the generally spaghetti-like nature of FBA's codebase.
However, after my last post in this thread, I found a version of FBA that "works" on both Linux and Windows. And by "works" I mean that it compiled, but it took a few hours of debugging to get it to actually do anything. I've spent the last week or so redesigning it for less random failure and intractable misbehavior. It's a monstrous task compared to just hacking in a few features, but progress has been nice and steady.
I'd rather not speculate on a release date, as I seem to have a habit of saying one thing, and then doing the opposite. ;)
I'd say we're probably outdated. I don't read Wired, but I doubt they care much about retrogaming, which is what we've been primarily about until recently.
