#DOOM EMULATOR MAC CODE#

As I've said though, I'd be more tempted to go with the existing C code at first - it might turn out to be too slow/ambitious but it'll be a lot easier to pull apart for a port. Reasons being with a Z80 to Z80 port some of the work is already done for you, I realise not that much 'in reality' as it would most likely have to be re-written, but the 'base' would be there rather than a blank window, if that makes sense.Д¬ompletely agree that starting from something that's already been done makes a lot of sense. I haven't looked at it but something like SDL Doom might be the easiest starting point as the screen, keyboard and sound APIs are all well defined so it's easy to spot what you have to convert. A 12K play area (128 x 192) would be even better but would obviously take longer to update. However, you'd probably get an acceptable frame rate just by updating the whole of the play area if it were reduced to something like 10K (say 128 x 160 pixels in mode 2) with a status area underneath. This is a bit more complicated when you're double buffering as you have to manage two frames worth of differences. I've got host-based ROM routines that plot whole rows or plot blocks of differences so the video wouldn't be too difficult. With the main game running on the Pi, you could double buffer a reasonably sized play area in mode 2 even on a standard Beeb.ДЇor my Pi-based Spectrum and CPC emulators, I send the screen differences across the TUBE.

It's then mainly a case of sorting out the video, sound and input routines. Porting C code to run on the Pi co-pro is pretty simple.

Doom emulator mac