Posted: 11/26/2006 10:03 PM
Post subject: RFC: emulator scripting
Quote
IdeaMagnate
Player (80)
Joined: 3/11/2005
Posts: 352
Location: Oregon
I'd like some comments on integrating a scripting language with an emulator. My plans are so distant I doubt they'll ever happen, but this may be worth implementing to someone else. Alternately, I may mave my priorities bass-ackwards. My idea is that a scripting language (compiler, interperter, vm, etc) could be integrated with an emulator so that code written in the target language can effect the emulator. The script would be able to look at emulated memory, keep an arbitrary amount of internal state information and decide whether the emulator loads or saves a state, or what buttons get pressed. Lua is an example of a language that's designed for integration like this, but I'm sure there are others like Io or Pawn that'd work. There are some advantages to this. Adding scripting to an emulator would be a good way to make robots less frustrating and easier to use. It'd minimize the need for recompiling and restarting the emulator and would also allow for less code to control the robot (since n lines of a scripting language can do more than n lines of C/C++), which would mean less time coding and debugging. Having a scriptable robot would make everything from fuzz testing and prerecorded macros to an AI easier to write. Depending on the implementation, it could also be used to automatically find RAM values or implement simple features like custom frame counters or a camhack. The disadvantages are that even the best scripting language is usually slower than C/C++. This might be a significant issue or it might be an acceptable trade-off. I don't know know if this would be helpful or if it's just a solution looking for a problem. I'd appreciate some thoughts either way.
ideamagnate| .seen aqfaq <nothing happens> DK64_MASTER| .seen nesvideoagent * DK64_MASTER slaps forehead
Posted: 11/27/2006 7:34 AM
Quote
Warp
Banned User, Former player
Joined: 3/10/2004
Posts: 7698
Location: Finland
I think that the only situation where the speed of the language may be an issue is when making a robot which searches for optimal keypresses: If there's a huge amount of sequences to test, the speed of the program may indeed play an important role. On all the other regards such a scripting language sounds like a great idea.
Posted: 11/27/2006 8:44 AM
Quote
Bisqwit
Editor, Active player (296)
Joined: 3/8/2004
Posts: 7469
Location: Arzareth
Typical conditions to test: - Whether a RAM address has some value - ― (examples: HP left, frames until random battle) - Whether a certain location in game ROM was executed during the last frame - ― and what were the values of the CPU registers (A,X,Y) at that time - ― (examples: damage registered, item acquired) - Whether a certain formula has a value in certain range - ― for example, a scalar coordinate built from several bytes (three in case of Rockman) - ― (examples: reached some location, value of power meter) Typical loops: - Loop through a set of values (brute force) - Loop indefinitely (random input) - Find the best score - ― (examples: farthest distance covered, fastest success) - Forward-iterative loop (progress one frame at time, testing until a certain condition becomes available) - ― (examples: walk forward until a platform can be reached by a certain height jump; idle until the game accepts Start button) Loops may be written in series or nested. - ― (example (series): push B until game registers it, then release B and wait until game registers that) - ― (example (nested): for each possible angle, and for each possible velocity, try what that particular shot would do) That's all I have in my mind for now. The "whether some address was executed last frame" thing is somewhat difficult to implement efficiently, for it requires a hook in the CPU emulator, tracking code execution. One of the things I considered was an XPath style formula expressing different conditions, and a dynamic compiler that creates the hooks based on the XPath expressions found in the script. No such thing was implemented though. (By the name of this thread, I expected to find a fully thought proposition inside… but I guess you can't always get what you wish for.)
Posted: 11/27/2006 12:14 PM
Quote
Maximus
Emulator Coder, Former player
Joined: 10/2/2005
Posts: 563
Location: Toronto, Ontario
Definitely sounds interesting, but if it's an RFC, shouldn't there be accompanying documentation to review? :P (j/k). If this were to be implemented, before you could use it effectively you'd still need to know how to locate memory addresses that would be mapped to variables. Sounds like an interesting project though
TAS Movie Editor v0-12-1 http://sourceforge.net/projects/tas-editor
Posted: 11/27/2006 1:56 PM
Quote
Truncated
Editor, Reviewer, Experienced player (969)
Joined: 4/17/2004
Posts: 3107
Location: Sweden
Arcade TAS of 2023 Sega TASer of 2021 Sega TAS of 2021
> ... before you could use it effectively you'd still need to know how to locate memory addresses that would be mapped to variables. Most (all?) of our emulators already have this functionality. The only one I'm not sure about is Mupen64. So that should not be an obstacle.
Posted: 11/27/2006 7:59 PM
Quote
miau
Joined: 3/26/2006
Posts: 42
Location: Germany
I've been planning to implement something like this into fceu, but I doubt I'll ever get motivated enough to actually realize that idea. A sequential way to write macros/scripts (unlike in BasicBot) would certainly be a lot more intuitive. Also, it would make writing more complex and versatile algorithms that could adapt to varying conditions etc. much easier. I guess its flexibility could make up for the lack of speed in many situations - if that'll ever be that much of an issue. Another problem lies in making the scripting as easy and intuitive as possible. I'm sure a lot more people would take advantage of BasicBot if they knew how to properly use it (although, at first glance it seems to be a naughty bitch ;) Well, my experiences are limited to fceu. I've always been afraid to touch any other emulators simply because they are lacking some of the tools fceu spoiled me with. So, enhancing emulators that are still in need of such tools with your idea would definitely be a great benefit.
Posted: 12/2/2006 1:03 PM
Quote
Yumiko
Joined: 10/29/2005
Posts: 31
Lua is an example of a language that's designed for integration like this, but I'm sure there are others like Io or Pawn that'd work.
There's Ruby, too. http://www.ruby-lang.org/
Posted: 12/3/2006 10:22 AM
Quote
IdeaMagnate
Player (80)
Joined: 3/11/2005
Posts: 352
Location: Oregon
The choice of language is up to the implementer, but I think smaller is better here. Ruby and the P's (Perl, Python, PHP) work well for general-purpose scripting but aren't designed to be embedded in other applications. Since Lua is designed to be embedded, much of the documentation and wiki covers what's required to embed it. It's also small (<200k stripped) and fast, so it would have less impact on executable size and robot overhead. That said, Ruby is a good language and seems to have a better C API than most. As long as someone didn't use a buggy, awkward and very slow custom language, there probably wouldn't be any complaints.
ideamagnate| .seen aqfaq <nothing happens> DK64_MASTER| .seen nesvideoagent * DK64_MASTER slaps forehead