-cpu-delay 0 -no-boot-anim -cache ./cache -avd avd_name
the first two are obvious. the third one will make the memory of the emulator kind of persistent. you can point it to any file that does not get destroyed by boot (such happens with /tmp) it's like a always-on hibernating device.
Try to use a smaller resolution for your emulator as for example HVGA. The emulator gets slower the more pixels its needs to render as it is using software rendering.
Also if you have sufficient memory on your computer, add at least 1 GB of memory to your emulator. This is the value "Device ram size" during the creation of the AVD.
Also set the flag "Enabled" for Snapshots. This will save the state of the emulator and let it start much faster.
The emulator is running actual ARM opcodes. It uses
which is a virtualization system akin to a VirtualBox or VMWare, to accomplish this. That approach maximizes the fidelity between the emulator and real-world devices. Its cost is the ARM->Intel opcode conversion. The only way to significantly speed that up
is to speed up the CPU that runs the emulator.
I have not done an exhaustive analysis, but I do not get the sense that qemu and the emulator use multiple cores. Hence, "a faster computer" is governed more by the speed of a single core than how many cores it has.
To the extent possible, I would develop "games and visual effects" on actual Android hardware, using the emulator for testing configurations that you do not own (e.g., QVGA). For example, I've done a reasonable amount of work on video playback apps, and I only
bother developing those on hardware, because video playback (and presumably some games) requires graphics acceleration to work well, and
not have a graphics accelerator AFAICT.