Daedalus R11 development status

[Raven]

Originally Posted by qj.net

[Only registered users can see links. ]

Here comes another update from homebrew developer [Only registered users can see links. ] on his pet project, [Only registered users can see links. ] R11. We already shared with you the other day [Only registered users can see links. ] 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 [Only registered users can see links. ] 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 64x64 texture mirrored along the S and T axes on the n64 will become a 128x128 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 [Only registered users can see links. ]; Dynamic Recompilation (used to over ride the setting in "roms.ini" if you're having problems with dynarec); Audio; Adjust Frequency; Controller.

[Only registered users can see links. ]
[Only registered users can see links. ] [Only registered users can see links. ] [Only registered users can see links. ]

[QueenB]

Looking forward to D11. I never bothered with D10, just stuck with #9 (nothing changed enough to convince me, but #11 seems pretty cool so I want it!).