Unfortunately, I haven't been following emulator development much for the past few months. I was excited when I heard that
FCEUX, Snes9x and Gens now have a Lua scripting interface.
This means you can write custom scripts running alongside a rom. They can read and modify ram contents and draw additional stuff on screen.
It really came in handy when debugging my game, I wrote a script that printed all game objects' important variables at their actual position on screen. Far more convenient than browsing through FCEUX's hex editor.
That's just one of Lua's many possible applications, though.
After that, I quickly decided to suspend work on my game project and instead delve into Lua a bit more. What I've come up with since isn't nearly as practical, but... see for yourself.
Super Mario Bros 3. Rainbow Riding
Mega Man 2 LASER EYES
F-Zero SNES + Wii Wheel
Gradius goes bullet hell
Wow, this is just hilarious to watch! I really look forward to trying these crazy "ROM script hacks" (we need a new name for them, don't we?) out!
I've been prototyping my puzzle game intended for the NES in Python due to the complicated algorithms I've been needing to try out in a more debug-friendly environment. But after reading this post, I really think I'll switch to using Lua and FCEUX instead! Besides, Lua is being used at my new work, so I'll probably need to learn it sooner or later anyway. :)
The idea of integrating a high-level language into a NES emulator has always intrigued me, and It's awesome that it's finally happened!
I wonder how efficient a Lua interpreter for the NES itself could be. There are plenty of BASIC interpreters for NES-class hardware.
That's the first I've heard of any of this. It does sound good for debugging.
Nice videos, the laser eyes were cool.
Yeah, I loved the SMB3 hack to turn it into a Kirby DS-like game. I haven't looked at your implementation (if you've even posted it). It'd be neat to have an emulator that you could use as a subordinate for making a super game hack. It would allow you to run frames and routines individually, put breakpoints where you get control back so the script can do whatever it likes. The breakpoints could go beyond mere program counter, with things like certain register values, values in memory, etc.
blargg wrote:
Yeah, I loved the SMB3 hack to turn it into a Kirby DS-like game. I haven't looked at your implementation (if you've even posted it). It'd be neat to have an emulator that you could use as a subordinate for making a super game hack. It would allow you to run frames and routines individually, put breakpoints where you get control back so the script can do whatever it likes. The breakpoints could go beyond mere program counter, with things like certain register values, values in memory, etc.
I was considering doing something like this for a Zelda Oracle of Ages Level Editor...
Apparently you can at least intercept writes to memory in FCEUX by declaring a hooking function and telling the emulator about it.
It's still buggy, but hopefully they'll fix it in the next official version.
That would increase debugging possibilities even more.
But yeah, more advanced breakpoint capabilities would be even cooler!
Got some cleaning up to do on the code of these scripts, probably releasing them when the new version of FCEUX is out.
tepples wrote:
I wonder how efficient a Lua interpreter for the NES itself could be. There are plenty of BASIC interpreters for NES-class hardware.
Yeah, Lua is popular for having a relatively small memory footprint and fast code execution since it translates the script into tight byte-code which it then interprets.
However,
relatively small and
fast could easily become
ridiculously HUGE and
"might as well go and make coffee until this hello world script has finished execution" when applied to the NES.
It would be a neat proof-of-concept, though.
tepples wrote:
There are plenty of BASIC interpreters for NES-class hardware.
Wrong! There are 2 of them, Family Basic is too limited, and the problem with the BASIC interperter (NBasic/NESASM) we have now is the incompatibility with the real NES. I wish a new compiler comes, like a Batari basic for NES. Although not compatible with Atari, Containing PPU and APU constants instead of TIA constants (
http://bataribasic.com/) but this is a concept
wow.. that mario hack turns it into a whole new game!
FCEUX 2.1 has been released yesterday. It comes with a variety of fun and interesting Lua scripts including those I've posted videos of.
It also has a documentation on Lua scripting and a list of functions now.
http://www.youtube.com/watch?v=NnZz5A9Z6A8
This is mine.
Debugging features are fairly limited, though, but it's really useful for making sense of RAM addresses quickly or giving visual feedback that isn't "87".
Just to clear things up, is this Lua scripting executed over the ROM, so it would be more like modifying the system instead of the ROM itself?
Exactly. Lua acts as a second independent PPU and processor that has access to the original processor's memory space.
There's no way (yet?) to modify rom contents from within Lua.
Heeey, could this be used to rapidly prototype an original NES game?
Not really. Suppose it could be used as some debug tools. Unless theres something i'm not thinking of
I believe the idea was to write most of the game in Lua, then port pieces to 6502 assembly one by one.
Exactly. I was hoping the emulator could run a script without loading an existing rom.
Then start with an SNROM that just displays a green screen. I'd guess you can have the Lua part of the game communicate with the already-ported part through PRG RAM.
Just dont call it a nes game......Its a lua script game that only runs in emulators.
Correct, it's a Lua game, not that there's anything wrong with that. If more parts get ported to NES with each release, at least an intent is clear.
[23:57:51] <miau>
http://www.youtube.com/watch?v=LT1eiLiMWkk
[23:58:03] * miau hides in teh corner again
[23:58:03] <B00daW> haahah
[23:58:04] <ui> oh noes, that video again
[23:59:11] <B00daW> mwow
[23:59:13] <B00daW> nice
[23:59:52] <miau> you wanna post that in the lua scripting thread at nesdev this time b00d?
[00:00:04] <miau> it's 6 am and I'm lacking words to write
[00:00:10] <miau>
Posted to tetrisconcept.com.
tepples wrote:
Correct, it's a Lua game, not that there's anything wrong with that. If more parts get ported to NES with each release, at least an intent is clear.
Ya dont call it a nes game till you ported it all. (as to avoid flames)
B00daW wrote:
Wow. I really hope the Lua socket code used there isn't *truly* sending TCP packets with a single byte as payload.... *cringe*
koitsu wrote:
B00daW wrote:
Wow. I really hope the Lua socket code used there isn't *truly* sending TCP packets with a single byte as payload.... *cringe*
Yes, it is. That < 1kB/sec really is slow!
Is that TCP collation/buffering algorithm(Nagle's?) turned off in that example? The "ping", however it's calculated, looks way too high.
Xkeeper: You're forgetting all the packet overhead. TCP+IP+others. And the large number of packets per second could be hard on routers.
Mednafen wrote:
Is that TCP collation/buffering algorithm(Nagle's?) turned off in that example? The "ping", however it's calculated, looks way too high.
Xkeeper: You're forgetting all the packet overhead. TCP+IP+others. And the large number of packets per second could be hard on routers.
The "ping" is off regardless (it's another packet that it just times a response to), and even on localhost it reads "15ms", so yes, it's broken.
Ping should be taken with a grain of salt. It will never go below 15ms because the network code runs, as does everything else, only 60 times per second.
Updates aren't sent every frame, though, and oops! It really seems like LuaSocket does no tcp buffering at all? However, it shouldn't be too hard to manually implement simple buffering for data.
Nevertheless, take the whole thing merely as a proof-of-concept. I'm not a networking guru and don't claim to be. Your comments led me to take a more in-depth look at tcp/ip which I'm glad I did. Understanding how things work on a low level = invaluable.
miau, let me know if you need any assistance in understanding how TCP works on a networking level. I cannot help with Lua's socket implementation (I did purchase a Lua book this week though :-) ), and I'm not sure what degree of control it has over the underlying socket implementation the OS (Windows, *IX, etc.) provides, but I can always help with network analysis.
One tool you might find very useful is Wireshark. That will give you the best idea of what exactly is going across the wire (on an IP/TCP level) and what's being seen. Make sure you install WinPcap when prompted.
Thanks for the offer, I really appreciate it and will likely get back to it sooner or later. It's always good to know people proficient in a subject like this.
Oh, I've been using Wireshark before. It's neat, gave me a vague idea of what's going on just from looking closely at its captured packets.
I also remember hating WinPcap for not letting me capture local traffic which, if I remember correctly, actually is a MS Windows limitation of some sort.
miau wrote:
I also remember hating WinPcap for not letting me capture local traffic which, if I remember correctly, actually is a MS Windows limitation of some sort.
Maybe it's no longer a problem? Or maybe
Microsoft Network Monitor doesn't have that problem? (I have it installed, but I haven't tested if it can capture local traffic.)
miau wrote:
Thanks for the offer, I really appreciate it and will likely get back to it sooner or later. It's always good to know people proficient in a subject like this.
Oh, I've been using Wireshark before. It's neat, gave me a vague idea of what's going on just from looking closely at its captured packets.
I also remember hating WinPcap for not letting me capture local traffic which, if I remember correctly, actually is a MS Windows limitation of some sort. :)
If by "local" you mean traffic that has an IP dst of the same physical machine -- that's called "loopback" in the networking world. There's an actual device (software-implemented) which handles that situation based on the local routing table.
Here's your solution.
Hope this helps. :-)
To OP:
Bravo, sir.
Bravo.
LUA Scripting for the NES... It holds incredible potential.