Update: StrmnNrmn’s “teaser trailer” changelog for Daedalus R9
It’s been a while since we’ve last heard from StrmnNrmn. A lot of you guys might have even already forgotten about his Daedalus N64 emulator. Well, to give you guys a recap, what we’re all expecting right now is his R9 release.
It’s been a long time coming, most definitely. However, sad to say, that release isn’t here just yet. Not today at least. Good news is that he’s planning to roll it out within the month, so you guys better keep a close watch here as we’d give you an update once it’s out.
So, if it’s not the actual release that we have today, then what do we have in store for you today? StrmnNrmn has indeed been busy developing his emulator (he wouldn’t have gone on an update hiatus without a valid reason, now would he?), and here’s proof of that. He’s posted an entry on his blog about what he’s been able to do so far.
This is what we can expect for R9. It’s a changelog – a “teaser trailer” of changelogs, so to speak – for the upcoming latest version:
- Added support for RGBA 4444 and 5551 textures, saving a bunch of memory in the front end.
- Tidied up all the texture conversion code, fixing a few bugs in the process
- Fixed the width/height of FillRect calls in 1 and 2 cycle mode (fixed a few small graphical issues)
- Fixed a blending bug (fixed a few small graphical issues)
- Use 16-bit textures on the PSP to represent 16-bit N64 textures. Saves time converting, saves memory, and faster rendering
And since we’re in the subject of “teaser trailers”, we’ve yet to tease you some more. The entire changelog is behind the “Full Article” link below. We highly suggest you take a look at it. Two items in the list have been bolded – two things that people have been asking for since the dawn of time (the dawn of Daedalus, at least). Clue: one of the bolded items starts with the letter “A” and rhymes with “udiosupport“. Hmmm…
Go ahead, click “Full Article” to see the changelog!
It’s been a while since we’ve last heard from StrmnNrmn. A lot of you guys might have even already forgotten about his Daedalus N64 emulator. Well, to give you guys a recap, what we’re all expecting right now is his R9 release.
It’s been a long time coming, most definitely. However, sad to say, that release isn’t here just yet. Not today at least. Good news is that he’s planning to roll it out within the month, so you guys better keep a close watch here as we’d give you an update once it’s out.
So, if it’s not the actual release that we have today, then what do we have in store for you today? StrmnNrmn has indeed been busy developing his emulator (he wouldn’t have gone on an update hiatus without a valid reason, now would he?), and here’s proof of that. He’s posted an entry on his blog about what he’s been able to do so far.
This is what we can expect for R9. It’s a changelog – a “teaser trailer” of changelogs, so to speak – for the upcoming latest version:
- Added support for RGBA 4444 and 5551 textures, saving a bunch of memory in the front end.
- Tidied up all the texture conversion code, fixing a few bugs in the process
- Fixed the width/height of FillRect calls in 1 and 2 cycle mode (fixed a few small graphical issues)
- Fixed a blending bug (fixed a few small graphical issues)
- Use 16-bit textures on the PSP to represent 16-bit N64 textures. Saves time converting, saves memory, and faster rendering
- Added mirrored texture support (this fixes lots of small graphical glitches)
- Fixed a LoadTile bug, allowing a couple of hacks to be removed (this also fixes various small graphical glitches)
- Added some new blend modes for various roms
- Fixed the Tri2 command for F3DLX microcodes
- Fixed a bug in busy-wait detection (this wasn’t working correctly with dynarec code, net result is a small speedup)
- Fixed a few dynarec stability issues (relating to exceptions occuring mid-trace)
- Added audio support 🙂
- Added the ability to dump textures (developer builds only at the moment)
- Fixed screenshots. Again.
- Implemented cmp.s, cvt.s, cvt.w, mtc1, mfc1, bc1f, bc1t, j, cfc1, ctc1, daddu, trunc.w.s, bc1t, bc1f, bc1tl, bcifl, bnel, beql, blezl, bgtzl, bltzl, blezl in dynarec (this gives a decent speedup)
- Avoid setting the branch delay flag and current PC in generated dynarec code unless absolutely necessary (this gives another small speedup)
- Much better memory access handling in dynamically recompiled code (this gives a BIG speedup) 🙂
- Use a second code buffer for generated dynarec code, to avoid polluting the instruction cache (this gives another small speedup)
- Further improve the memory access handling in generated dynarec code (another small speedup)
- Fix register usage analysis for lwc1/swc1/mfc1/mtc1 which was preventing base registers used in these instructions from being cached (another small speedup)
- Have compensation blocks restore nobbled registers, so on-trace code does’t need to reload (another small speedup)