Daedalus R11 development status

Here comes another update from homebrew developer StrmnNrmn on his pet project, Daedalus R11. We already shared with you the other day his hopes and plans for this release and this time, he took the opportunity and explained to fans what’s happening in the emulator’s development stage.

According to StrmnNrmn, he had already isolated the main culprit for eating up memory while the application is running. It is actually the mirrored texture support for 4- or 8-bit palettised textures. The developer explained that 64 4-bit palettised texture that took up 2KiB on the N64 would consume a huge 64KiB on the PlayStation Portable (PSP) and that’s a 32-fold increase.

Furthermore, StrmnNrmn attributed the problem to the following reasons:

• 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.
• 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 64×64 texture mirrored along the S and T axes on the n64 will become a 128×128 texture on the PSP.

The coder added that rewriting Daedalus’s texture handling so that it supports 4-bit and 8-bit palettised textures directly has taken more time than expected. Even so, he believes that the change should be implemented because aside from saving memory, it has a lot of performance benefits such as less cache usage as well as the fact that palettised textures are also a lot more efficient to render with.

StrmnNrmn shared as well that he is trying to split the application’s “daedalus.ini” into two files. Currently, Daedalus just has one file for this making it impossible for the coder to release a new version of daedalus.ini without wiping out people’s local preferences.

The first new file will be named “roms.ini” and it will contain global rom-specific details (e.g. rom’s name, save type, comments, etc.). A new version of roms.ini will be released every time there’s a new version of Daedalus. The next file will be “preferences.ini” and it will be generated when the first time you change some settings when playing a rom, and update it with any further changes that you make.

This means that whenever you run a new version of Daedalus, the following settings will be retained: Texture Update Check; Frameskip; Limit Framerate; Dynamic Recompilation (used to over ride the setting in “roms.ini” if you’re having problems with dynarec); Audio; Adjust Frequency; Controller.

Here comes another update from homebrew developer StrmnNrmn on his pet project, Daedalus R11. We already shared with you the other day his hopes and plans for this release and this time, he took the opportunity and explained to fans what’s happening in the emulator’s development stage.

According to StrmnNrmn, he had already isolated the main culprit for eating up memory while the application is running. It is actually the mirrored texture support for 4- or 8-bit palettised textures. The developer explained that 64 4-bit palettised texture that took up 2KiB on the N64 would consume a huge 64KiB on the PlayStation Portable (PSP) and that’s a 32-fold increase.

Furthermore, StrmnNrmn attributed the problem to the following reasons:

• 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.
• 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 64×64 texture mirrored along the S and T axes on the n64 will become a 128×128 texture on the PSP.

The coder added that rewriting Daedalus’s texture handling so that it supports 4-bit and 8-bit palettised textures directly has taken more time than expected. Even so, he believes that the change should be implemented because aside from saving memory, it has a lot of performance benefits such as less cache usage as well as the fact that palettised textures are also a lot more efficient to render with.

StrmnNrmn shared as well that he is trying to split the application’s “daedalus.ini” into two files. Currently, Daedalus just has one file for this making it impossible for the coder to release a new version of daedalus.ini without wiping out people’s local preferences.

The first new file will be named “roms.ini” and it will contain global rom-specific details (e.g. rom’s name, save type, comments, etc.). A new version of roms.ini will be released every time there’s a new version of Daedalus. The next file will be “preferences.ini” and it will be generated when the first time you change some settings when playing a rom, and update it with any further changes that you make.

This means that whenever you run a new version of Daedalus, the following settings will be retained: Texture Update Check; Frameskip; Limit Framerate; Dynamic Recompilation (used to over ride the setting in “roms.ini” if you’re having problems with dynarec); Audio; Adjust Frequency; Controller.