BadPotato: Yeah, definitely one thing I have been viewing as an advantage of Python is having access to NumPy...
As far as LuaJIT goes, I *think* it's supposed to be a drop-in replacement for the normal Lua library. So if that were actually important I suspect it wouldn't be hard to swap in.
I think I am probably going to continue with my Python version. One thing I might consider trying later is hacking the same script engine I'm using with m64py into Bizhawk. That might mean I could use the same scripts on both, test them and do GUI stuff in m64py and then make videos in Bizhawk.
Hi. I'm goofing around with script-controlling an emulator and changing memory (I made a thread about my project here). I'm focusing on Mario 64 and there are some things I'm trying to figure out.
1. Looking I found RAM/ROM maps here and here. However, they only have the US release and one has the EU release. Is there a RAM map for the original JP release anywhere?
2. Is there any information on how to parse the level geometry information in ROM? The thing I really want to do is write a bot that can play the game by itself, so I'd need to be able to get the level polys and basic information about them (can they be collided with, can mario walk on them).
3. I'm seeing a weird thing controlling my emulator where if I alternate setting the A button pressed and then released every other vertical blank, Mario jumps only once and then does not jump again. In fact if I release the A button I have to leave it released for four full vertical blanks (I'm still confused about whether this is the same thing as a frame or not :sad:) before pressing A again, or it does not register. Is this something Mario 64 is doing? The information I'm finding about BLJs seems to suggest that you can totally hit A every other frame. I'm wondering about this because if Mario 64 isn't doing this it implies mupen64plus is debouncing my simulated input or something.
Thanks!
Hi! I've been doing a project with an N64 emulator the last couple of weeks and thought I should start trying to talk to people who know something about hacking N64 games. What I've done is extend the Python/Qt UI frontend for mupen64plus, so that it has a Python console and a setup for loading, starting and stopping scripts from disk. The scripts so far can read and write memory, can simulate controller input and can trigger code on mupen64plus breakpoints. So all stuff that as far as I know existing memory hacking tools can do, but I want to use this as a basis to make more complicated things. The two things I'm interested in doing are:
1. Automating searches for glitches, like the TTC upwarp glitch in Mario 64
2. I want to try to write a bot that can beat Mario 64 levels by itself.
What I've got so far:
I thought I'd post here to show what I've got so far, I also had a couple of questions.
1. I suspect I'm duplicating a certain amount of work here, actually until this weekend I didn't even know about the version of Bizhawk with the Lua scripting *_* I'm wondering how much I'm hurting myself by proceeding with Python+mupen64plus rather than switching to Bizhawk or something. Bizhawk is actually running mupen64plus on the inside, right? I glanced at the API for the Bizhawk lua scripting-- does anyone know, is it using Lua or LuaJIT (i.e.: does it have access to the luajit ffi mechanism or is it the api exposed with the stack interface)?
2. The biggest thing that worries me about proceeding with mupen64plus is that it does not currently support movie recording or playback, so I would have to hack that back into the core. The thing that worries me about this is save states. The m64 and bk2 formats both look pretty ?? simple to write, but in both cases the video starts with a savestate. Do Bizhawk and mupen64plus use the same save state format? Is there a way to convert mupen64plus save states to "old mupen64" save states?
Hm, well I can try to take a look at some point but no promises.
The source for my changes is posted though if anyone else wants to take a crack at it ;shrug;
It is exactly the same thing. I do basically that just I record to tracks of a Quicktime file instead of tracks of an AVI. I did this because it was easier :)
...
Then do you think it would be possible to implement this in a more normal AVI, instead of the propitary Quicktime format?
That alone would open up use to many more people.
I think that would be very possible. The problem is I do not have any experience with AVI, and I do not have a windows machine to do development on, so I do not know if I could do the port myself. Maybe if I had some AVI sample code I could try, I am not sure.
I would definitely like it if I had some way to open this up to windows/linux users.
(Side-note: your avatar is fairly annoying and probably violates rules. Consider removing it...)
OK, I am sorry about that.
...What is the purpose of "Export to Quicktime"? It seems like the same thing could be accomplished by using a 0-compression codec and recording directly to multiple tracks of an AVI.
It is exactly the same thing. I do basically that just I record to tracks of a Quicktime file instead of tracks of an AVI. I did this because it was easier :)
Hm, rereading this actually I guess I misread what amaurea/CtrlAltDestroy's original proposal was. Amaurea seems to be suggesting that the ghost would be visible while you were playing the game. Right? Whereas the thing I did just creates a video mixing things together after the fact. Amaurea's idea would be a little more complicated to implement.
But if someone were going to attempt Amaurea's idea, you could probably simplify it a lot by stealing the idea that makes my hack so simple: Don't bother with multiple emulators or trying to monitor RAM, just save a literal video and then composit things graphically. For example when recording the "reference" playthrough you could just dump to a file containing, for each emulator frame, the PPU scroll x, the PPU scroll y, and then (assuming that this is a snes emulator) a graphical dump of the sprite layer. When you do "playback" you could just keep track of the frames since you started, and draw the approriate frame from the file to the screen, slipped between the sprite layer and the bg layers. I don't think that would be too hard.
Hey!
Although FODA is correct that the ghosting feature in my custom SNES9X only overlays different savestates of a single video, rather than combining different videos, it would be very easy to adapt it to your original idea of combining many different videos into one. This is something I have actually been wanting to try at some point.
The way that my emu hack actually works is similar to what XKeeper suggests, but a little simpler. It has a group of snes9x "movies", one for each savestate, and it has the emulator play through each one one by one. When it does this it disables all the layers except the sprite layer, and makes the background behind the sprites transparent. It then slaps the result into the layer of a quicktime movie. Each playthrough is eventually slapped into the same quicktime movie, so that they are all visible on top of each other. The different layers are kept aligned by monitoring a value in the GPU-- because the SNES happens to handle scrolling in hardware, the X and Y scroll offsets within the level are actually known at all times.
So all that would have to be done to change this to work with speedruns for different people would be to add a feature that loads a "movie savestate" and immediately begins recording from that point. (This would ensure that the recordings from all the different people begin at the exact same point.) You could then collect the recordings from everyone and have the existing quicktime export code smoosh the recordings all together.
FODA wrote:
I wish I could try it with other games but I'm not on a pc :(
Um, do you mean you're not on a mac? The full version of the hacked emulator I used to make the videos is actually mac only. I did get a windows version compiled but it can only record the multipath speedrun videos, it cannot export them to Quicktime.
