Idle hands are the Devil's playthings ... or they end up making some pretty neat crafts. In this case, Will D'Angelo of TheWiicast.com, made a pretty nifty homage to Donkey Kong with this clock. The timepiece combines images easily found using a Google search -- in this case Donkey Kong and Big Mario from Super Paper Mario -- with some basic materials from a craft store. D'Angelo says you need, with approximate costs:

Clock kit from Michaels craft store ($8)
The vintage sign kit, which includes a shallow frame and plywood backing ($1)
Tube of acrylic black paint ($1.75)
Replacement hands for clock kit ($3)
Clear matte spray ($5)
The most expensive part of the project is probably purchasing the glossy photo-quality paper to print out the images, which D'Angelo already had around. He was thinking his next attempt would be a Centipede style clock. Now that he's done it once he has a recommendation for other people attempting the same style clock, "I would suggest to make it easier to pick up one of those cheapy wallpaper rollers for the air bubbles so that you don't touch it with your hands." A nice gamer craft project with lots of image possibilities.

Idle hands are the Devil's playthings ... or they end up making some pretty neat crafts. In this case, Will D'Angelo of TheWiicast.com, made a pretty nifty homage to Donkey Kong with this clock. The timepiece combines images easily found using a Google search -- in this case Donkey Kong and Big Mario from Super Paper Mario -- with some basic materials from a craft store. D'Angelo says you need, with approximate costs:

Clock kit from Michaels craft store ($8)
The vintage sign kit, which includes a shallow frame and plywood backing ($1)
Tube of acrylic black paint ($1.75)
Replacement hands for clock kit ($3)
Clear matte spray ($5)
The most expensive part of the project is probably purchasing the glossy photo-quality paper to print out the images, which D'Angelo already had around. He was thinking his next attempt would be a Centipede style clock. Now that he's done it once he has a recommendation for other people attempting the same style clock, "I would suggest to make it easier to pick up one of those cheapy wallpaper rollers for the air bubbles so that you don't touch it with your hands." A nice gamer craft project with lots of image possibilities.

R11 Update

Wow, it's been far longer than I'd intended to give this update. I had a great time in Spain, and came back and spent a few evenings playing through Crackdown. It was quite nice to take a break for a few days

Since then I've been working on the various features I promised for R11.

I talked a bit about the texture cache being the main culprit for gobbling up memory while the emulator is running. When I started profiling this in detail, I realised that one of the worst offenders for memory consumption was mirrored texture support for 4 or 8-bit palettised textures. There were actually two main problems which were exacerbating the problem.

Firstly, I've never handled palettised textures directly in Daedalus. By that, I mean that rather than converting the palettised texture on the n64 to a palettised texture on the PSP, I've been converting it to a 32-bit RGBA texture. This means that on the n64, a 64x64 pixel 4-bit palettised texture would take up 2KiB. By converting this up to a 32-bit RGBA texture on the PSP, it takes 16KiB - an eightfold increase in memory usage.

The second issue which was compounding the problem was that the PSP doesn't have support for mirrored textures. In order to support this feature I have to manually duplicate and mirror the texture. This means that a 64x64 texture mirrored along the S and T axes on the n64 will become a 128x128 texture on the PSP.

The main problem I was getting due to running out of memory was due to the heavy use of mirrored 4-bit palettised textures in some games. A 64x64 4-bit palettised texture that took up 2KiB on the n64 would consume a huge 64KiB on the PSP - a 32-fold increase! The problem was that certain games were using dozens of such textures in a single display list, and the available memory was rapidly being exhausted.

So over the past couple of weeks I've been working on rewriting Daedalus's texture handling so that it supports 4-bit and 8-bit palettised textures directly. This has taken a lot more time than I'd anticipated because of the number of places in the codebase which have to fiddle around with texture data directly. I also spent a week trying to track down two horrible bugs (both of which turned out to be brain-dead logic errors on my part).

The great thing about this work is that not only does supporting palettised textures directly save a lot of memory, it also has a number of small performance benefits. Generating less texture data generally means a bit less work for the CPU (well, less cache usage), so converting palettised textures is now a bit quicker. Palettised textures are also a lot more efficient to render with (mostly due to the fact that they consume less bus bandwidth and can make better use of the PSP's texture cache.)

The other big chunk of work I've been bashing away at is improving the way that I handle preferences for individual roms. One of the big problems with the current setup with Daedalus is that the main daedalus.ini file consists of both global rom-specific details (such as the rom's name, save type, comments etc) and local user-defined preferences (such as whether to enable speed sync, disable dynarec etc). This means that I can't ship a new version of daedalus.ini without wiping out people's local preferences.

What I've done now is split daedalus.ini into two files. roms.ini will contain global rom-specific details, and an updated version will be distributed with every version of Daedalus from now on. If I know dynarec causes a certain rom to fail to run, I can add a setting for this in roms.ini, and everyone will be able to pick up the change in the next release. Another good example is the SaveType field; every version of Super Mario 64 uses a 4k EEPROM, and so once this is set up in roms.ini it should never need tweaking.

The other file I created is called preferences.ini. This file won't ship with Daedalus - the emulator will create this the first time you change some settings when playing a rom, and update it with any further changes that you make. This means that when you copy a fresh build of Daedalus across to your memory stick, the new build will pick up your existing preferences.ini file and so remember all of your settings.

The settings that Daedalus will currently remember for each rom are:


* Texture Update Check
* Frameskip
* Limit Framerate
* Dynamic Recompilation (used to override the setting in roms.ini if you're having problems with dynarec)
* Audio
* Adjust Frequency
* Controller



I'll be adding to this list over the coming months, as more options become configurable.

One other thing that will be stored in preferences.ini (which I've not coded yet) is all of