LÖVE

So, one day I got really bored in modded Minecraft, and thought it would be neat to try to write a Gameboy emulator in ComputerCraft. That idea fell apart shortly after I started trying to get graphics code working and realized it's not possible to draw a full resolution gameboy in the mod, so I quickly ported what I had to Love2D and kept going.

This is the result, in its first alpha release. It's capable of playing most Gameboy games, includes full Color support (no Super Gameboy though) and, for being written in Lua, is surprisingly performant. I plan to continue improving it over time, but I decided to polish it up and get it out in the wild in some form for greater feed back and critique.

https://github.com/zeta0134/LuaGB

Games are loaded from Love2D's save location, a folder icon in the main interface acts as a shortcut to there for easy file copies. Sound is supported but lags behind a bit due to limitations in Love2D's audio implementation. I understand a planned QueueableAudio type is coming down the line which should make this issue vanish. Saves and Save States are supported, and there's a rather extensive debug feature, press D to activate that if you're feeling adventurous, it'll print out the rest of the keymaps onscreen.

I'm pretty happy with this. Critique, and especially bug reports welcome!

-Zeta

Performance is good because LÖVE uses LuaJIT - it compiles some (or all) Lua code into native assembly. Not as efficient as C++ but good nonetheless. There are number of general perofrmance guidelines:

• save reference table to a local variable to access it directly, as opposed to access over a chain of tables
• in general, use locals over globals - every global goes to special table, and there's table lookup overhead
• for tables with known and rigid structure, define a FFI C struct
• instead of discarding a table that needs all its data modified, modify it in place
• avoid producing new strings such as by concatenation, this is a slow process and each existing unique string makes it slower
• don't use language functions that are not compiled by LuaJIT, most notably pairs/ipairs

Just nitpicking, but ipairs is compiled. Here's a list of what's compiled and what isn't.

Nixola wrote: ↑Tue Apr 11, 2017 6:44 am Just nitpicking, but ipairs is compiled. Here's a list of what's compiled and what isn't.

I could have sworn it wasn't compiled before... oh well, this is a positive thing

Impressive!

Awesome work! I saw a post about this on /r/Lua and was wondering when and if you'll post it here! Amazing work! It runs pretty well too!
Don't mind me, but I'll just dissect your code to find its inner-workings.
How did you figure out the emulation process? Are there online docs about it, or did you go through the code of something like GBAboy?

zeta0134 wrote: ↑Tue Apr 11, 2017 3:36 am...

If you don't want to wait until 0.11 gets released, there are already nightlies that are stable with regards to the new audio features (at least i've been making use of them, and the base stuff you'd probably use too are probably not gonna change in the public interface department )

(Win32 builds here, linux packages exist as well, but i don't use them so don't have a link of those at hand right now)

Also, i implemented a module player that uses queuable sources, maybe you might find the implementation useful.

raidho36 wrote: ↑Tue Apr 11, 2017 6:09 am

• for tables with known and rigid structure, define a FFI C struct

Don't use FFI if you want to release this on handhelds too, since JIT compilation is disabled on android because of bugs, and IOS doesn't allow it... besides, performance won't be that much faster anyway, in general.

Whoa, this is pretty rad. I remember being halfway through a gameboy CPU interpreter on lua a while back, but I lost it when they formatted my machine without permission. Yea. That happens 'round here.
Serves as lesson to put everything on some code versioning system..

zorg wrote: ↑Tue Apr 11, 2017 1:06 pm Don't use FFI if you want to release this on handhelds too, it's disabled on android because of bugs, and IOS doesn't allow it... besides, performance won't be that much faster anyway, in general.

It's not disabled on either Android or iOS, nor on any target platform that LuaJIT supports. The Just In Time compilation is disabled by default on Android and iOS, on Android because its memory allocator conflicts with LuaJIT's memory allocation policy, resulting in slowdown by factor of 5 or thereabouts compared to interpreted Lua, and on iOS due to the App Store policies. On Android however that's a very old problem and both its kernel and LuaJIT have been updating since, so you can try your luck and enable JIT in runtime. You can do the same in iOS but that would be App Store policy violation. No one has to know you do that, though.

As for performance improvement, depending on the calculations you're doing it's anywhere between factor of 2 and 50. But only when JIT is enabled. Otherwise it's a significant slowdown.

Great!
I'm here crashing my brain trying to create a little and simple game while someone is creating something so complex like this!