The next step in emudev, with most compiled/systems languages at least, would be to create macros (such as OP_LD or OP_ADD) that generates static instructions at compilation. Another, cleanish method, in C is to generate a 256-length function pointer (void*) based static array and map those generated functions to that, to make the dispatch step simpler. Small trade off, performance-wise, but rarely matters for 8-bit CPU's (where you would usually use an opcode table over an instruction decoder).
For Z80 emulation the most efficient method I found was indeed a big nested switch-case statement. Compilers turn this into a jump table (or several if there are gaps), but don't need the function entry/exit boilerplate if each instruction code block would be its own C function referenced through a function-pointer-table. The switch-case code is generated with a python script which uses the 'algorithmic decoding approach' described here: http://z80.info/decoding.htm
Here's what such a code-generated instruction decoder looks like: https://github.com/floooh/chips/blob/master/chips/_z80_decod... (this is for a "real" Z80 with all undocumented opcodes, so it has a lot more cases to handle than the simple Gameboy Z80 variant).
The Gameboy CPU shares the same octal-structured opcode format as the Z80 from which it was derived, so it is possible to decode it even more concisely: http://www.z80.info/decoding.htm
You can see that in octal, 1xx are all moves while 2xx is all ALU ops.
Oh, it's definitely decodable. Most CPU's can be (though x86 post-386 wouldn't be fun), since that's what they're usually doing internally. But, with 8-bit CPU's, the opcode space is usually limited to a byte, which makes tables very doable and very efficient.
My rust-based GB emulator uses a decoder based on those very docs, in fact. Though, modified slightly since the GB's CPU only supports the CB-extended range operations.
Krita's just lacking a OSX build. I've been using the windows build for a while. Krita's focus is on digital painting. I would say Krita is more comparable to Corel's Painter instead of Photoshop.
Krita is actually built on Qt libraries, just like VLC and even some of Photoshop. Which makes it look native on most platforms, and AFAIK won't require X11 on OS X -- because Qt uses Cocoa there.
The other workaround I can think of is to use Krita in VMPlayer(Fusion?) with Ubuntu. Sounds clunky but I'm doing that with the devel version of MyPaint . Wacom usb pass through on Virtualbox isn't working well.
great tutorial. I was able to get through all of it this evening. it was fun having a data set to play around with the whole time. everything was well explained and it was easy to read.
and looks like working for the city of chicago is the thing to do...not bad salaries out there :D
