I've made another update to Frodo, version 7 with the following changes:

* Make binding joystick directions to other buttons as well (to be able to jump with e.g., 1)
* The direction buttons can also be bound to keyboard keys
* Exit with SYS_RETURNTOMENU to make WAD's work
* Some restructuring and minor bug fixes here and there
* Lots and lots of new code which won't get executed :-)

MahJongg Wii is a Mahjongg solitaire tiles game written specifically for the Wii, developed with devkitPro tools and using the GRRLib for rendering, sndlib for music and sound, and wiiuse for wiimote.

v0.8 23/02/09
Download - Mahjongg Wii v0.8

Added multiple tilesets!
Added character voices on 2 player versus mode
Re-encoded and removed cracklys from the sound effects
Added graphic when two player game ends as a draw
Tidied up and fixed bugs around the placing of tiles / shuffling
Fixed bug where saved music volume was not being used on startup
Changed screenshot function to output filenames with date and time instead of just one
Cleaned up the code that deals with memory allocation of textures in the menus
Added new menu music + other music tracks for the different tilesets/themes during the game
Fixed some memory allocation problems that may have caused memory to be held onto when mahjongg is exited and could have caused problems moving between the menu and the game if done numerous times
Added pressing A button on already selected tile deselects it
Added proper support for widescreen including options to turn it on or off
Changed config loading and saving to include widescreen and tileset selections. Does in a way that is backwards compatible with version 0.7 config files
Added Norwegian language support
Changed internationalisation code to fully support utf8 encoding thus giving the use of non-ASCII characters without the need for mapping
Change to auto detect whether the game has been loaded from a loader or not and exit accordingly (either reset to menu or back to loader)
Fixed even more bugs

As its been a while since our last binary release, we wanted to clarify why its been so long and what we’re waiting for for our next release. Early on in development we were making relatively big changes which significantly improved the emulator; however, we’ve gotten to the point where a lot of the big things have been done, and only need perfecting (with the exception of the dynarec). Thus, we haven’t felt the need to make several binary releases as most of the users who aren’t interested in compiling the source themselves are mostly uninterested in the kinds of changes that have been made. We do indeed have a milestone for our next release planned: a working, stable dynarec. Most of the work that has gone into the emulator since our last release has been focusing on the dynarec, and since we still don’t have a completely working dynarec, there haven’t been many noticeable changes. So we’re holding out for a dynarec which supports at least most games without crashing before we make our next release. After getting it running initially, there will likely be more room for optimization if there are still any performance issues. In that case, we will likely have frequent releases once again as there will be noticeable improvements with each optimization that is made. As always, please be patient. We’re working hard to make the next release something worth the wait.

On an unrelated technical note, we have managed to free up 1.75MB in RAM by consolidating the various memory LUTs (look-up tables) into a single LUT for all memory operations. In Mupen64, there are 8 different memory LUTs which are used to determine how to handle memory accesses at different addresses. These 8 are split up by read/write byte/half-word/word/double. Instead of having 8 large LUTs, I created one LUT for all memory operations which points to smaller LUTs which handle the different memory operations in the specified segment. Memory operations only require an additional load for the second level LUT so there is no performance impact by this change. We are still looking into other ways to further reduce our memory usage to make sure that we have plenty of room in memory for recompiled code produced by the dynarec.

As its been a while since our last binary release, we wanted to clarify why its been so long and what we’re waiting for for our next release. Early on in development we were making relatively big changes which significantly improved the emulator; however, we’ve gotten to the point where a lot of the big things have been done, and only need perfecting (with the exception of the dynarec). Thus, we haven’t felt the need to make several binary releases as most of the users who aren’t interested in compiling the source themselves are mostly uninterested in the kinds of changes that have been made. We do indeed have a milestone for our next release planned: a working, stable dynarec. Most of the work that has gone into the emulator since our last release has been focusing on the dynarec, and since we still don’t have a completely working dynarec, there haven’t been many noticeable changes. So we’re holding out for a dynarec which supports at least most games without crashing before we make our next release. After getting it running initially, there will likely be more room for optimization if there are still any performance issues. In that case, we will likely have frequent releases once again as there will be noticeable improvements with each optimization that is made. As always, please be patient. We’re working hard to make the next release something worth the wait.

On an unrelated technical note, we have managed to free up 1.75MB in RAM by consolidating the various memory LUTs (look-up tables) into a single LUT for all memory operations. In Mupen64, there are 8 different memory LUTs which are used to determine how to handle memory accesses at different addresses. These 8 are split up by read/write byte/half-word/word/double. Instead of having 8 large LUTs, I created one LUT for all memory operations which points to smaller LUTs which handle the different memory operations in the specified segment. Memory operations only require an additional load for the second level LUT so there is no performance impact by this change. We are still looking into other ways to further reduce our memory usage to make sure that we have plenty of room in memory for recompiled code produced by the dynarec.