Aller au contenu

[News] Daedalus R10 dispo

kenji_16

Par kenji_16,
dans Playstation Portable

 Partager

Messages recommandés

kenji_16 Newbie

kenji_16

Posté(e)
Posté(e)

Daedalus R10

 

test de jeux par Thairacer : ICI

 

This is a few hours later than I'd hoped, but here's R10:

 

http://downloads.sourceforge.net/dae...p_R10_v100.zip

http://downloads.sourceforge.net/dae...p_R10_v150.zip

http://downloads.sourceforge.net/dae...sp_R10_src.zip

 

This is the changelist:

 

 

[+] Added frameskip option.

[+] Added framerate limiting option.

[+] Added adjustable stick deadzone.

[+] Allow pause menu to be activated even when rom emulation has hung.

[!] Fix crash when no roms found, added explanatory message.

[!] Fix flickering when small number of roms found.

[^] Fix texture hash frequency check.

[^] Finally got code compiling with -O3 optimisation flag in GCC.

[^] Use VFPU for InvSqrt (thanks hlide!)

[^] Improved VFPU code for clipping and tnl (thanks Raphael!)

[^] Improved inlining of AddTri.

[^] Reduced time spent searching for overridden blend modes.

[~] Remove debug console in public release builds (smaller footprint and slight speedup.)

 

 

 

I'll post tomorrow with details on what I want to work on for R11. In the meantime, enjoy!

 

-StrmnNrmn

 

 

 

 

 

[30/03/07=NEWS]

R10 countdown

 

I'm in the process of tidying up my current build so that I can release R10 over the next few days.

 

There are a number of features/optimisations still on my TODO list, but as I promised last month, I'd like to release R10 by the end of March. I think frequent, small updates are better than keeping everyone waiting months between releases.

 

Although R10 will be a smaller update than R9, there are some great improvements (most of which I've already talked about):

 

 

* An approximate 10-15% speedup

* Frameskip, framerate limiting and stick deadzone tuning

* Various small bugfixes

 

 

 

I'm hoping to have everything ready by Sunday afternoon at the latest.

 

One feature which might not make it is the Expansion Pak support. I mentioned that I'd finally fixed the bug that was preventing this from working, but I've been having difficulty resolving the various memory issues that it causes when enabled. Rather than delay R10, I'd prefer to disable the Expansion Pak support for now and release R11 early - as soon as I've fixed the underlying problem. I'll keep you posted.

 

-StrmnNrmn

 

 

Weekend Update

 

"It's been a busy week at work, what with catching up after my week off and GDC, so I've not managed to post as many updates as I'd have liked.

 

On Daedalus I've been starting to take a look at the list of potential optimisations I listed and working out what to tackle first. To help me do this my first job is to do some work on Daedalus's profiler, to try and figure out where the biggest wins are going to come from. Hopefully I'll be able to report back with some interesting findings this weekend.

 

On a related note, I've spent the morning looking at converting the source control I'm using at sourceforge from CVS to Subversion. I've been meaning to do this for some time. I've never really been a fan of CVS, and as I'm using Subversion for other projects at work and at home I thought it made sense to migrate Daedalus over too.

 

So you can now access the latest Daedalus source* through Subversion:

 

 

svn co https://daedalus-n64.svn.sourceforge.net/svnroot/daedalus-n64/trunk daedalus-n64

 

 

With CVS I usually only updated the source alongside every release. Ideally the repository would contain an up-to-date copy of my local build, but I've had problems in the past where people have distributed 'intermediate' builds of Daedalus PSP, bugs and all. I only ever release new builds when I think there are enough new features and its stable enough to make it worthwhile for people to download and install; updating a source a bit less frequently gives me a bit more control and helps prevent everyone's time being wasted with intermediate builds. I think that I'm going to continue with this policy for the time being. We'll see how it goes.

 

-StrmnNrmn

 

*This is still just the R8 source which I lifted from CVS today. I'm in the process of testing whether this compiles OK, then I'll refresh the repository with all the changes from R9. I'll update this post when the R9 source is available.

 

Edit: R9 source commited to Subversion, all seems to be compiling OK."

 

StrmnNrmn de retour de vacances, nous fait part de son plan d'action concernant la release 10 (R10) de son émulateur N64 pour PSP

 

"R10 Plan of Action,

 

Before I went away on holiday I asked you what you thought I should look at working on for the next release of Daedalus. Over 200 of you replied, and I've greatly enjoyed reading what you've had to say. There were some brilliant suggestions, so many thanks for your contributions.

 

It seems pretty clear to me that speed is the single biggest issue that most people want to see addressed. Many people also mentioned compatibility and savestate or save game support, but in nowhere near the same kind of numbers as those wanting speed improvements.

 

Based on your feedback my current plan is to release Daedalus R10 at the end of March, focusing mostly on speed improvements. If I can fit in any easy compatibility fixes, I'll do this too*.

 

Several people have asked what possibilities remain for optimisation. Here's a short list of things I know need more work:

 

* In many games, a lot of the time spent executing dynamically recompiled code is doing things which can potentially be emulated at a high level. For instance, over 5% of the time spent executing dynarec code in Mario64 is just converting matrices from floating point to fixed point format. Another 4-5% of the time is spent in a loop invalidating areas of the data cache (which is irrelevent in an emulator.)

* Some of the most expensive fragments are those which branch to themselves (i.e. those doing many loops). I can optimise for this to avoid loading and flushing cached registers on each iteration through the loop.

* I can implement a frameskip option (I had intended to implement this for R9, but forgot!)

* I can make use of the Media Engine (as Exophase suggested in conversation, as the ME can't access VRAM, it might make more sense to execute Audio and Display Lists on the main CPU, and run the N64 CPU emulation on the PSP ME)

* There are certain situations where I fail to create fragments in the dynamic recompiler - for instance if the code being recompiled writes to a hardware register, this triggers an interrupt and causes fragment generation to be aborted. I should be able to deal with situations such as this more gracefully.

* The fragment generator can do a lot more to improve register caching, and eliminating redundant 64-bit operations.

* There are many situations where N64 roms busy wait. I detect very simple occurances of this, but not all of them. If I manually identify more complex examples I can have the fragment generator optimise them away.

* Some roms are causing the dynarec fragment cache to be repeatedly dumped and recreated (I think Banjo Kazooie is one example of this). Fixing this may just involve tweaking a couple of magic numbers.

* I currently optimise memory accesses under the assumption that most accesses are in the range 0x80000000 - 0x80800000, which is incorrect in the case of roms that make heavy use of virtual memory, or access RAM through the mirrored range at 0xa0000000. I can improve the trace recorder to collect information on which range a memory access fell in, and generate code to speculatively optimise for this.

* Now that the dynarec engine is producing much better code, the cost of display list processing is becoming more significant, and may finally be worth profiling and optimising.

 

That's quite a big list, so I doubt I'll be able to work on these things before the end of March, but I think it shows there's still a lot of scope for further optimisation.

 

-StrmnNrmn

 

*Just this morning, I figured out why the Expansion Pak support was broken, so Majora's Mask and a couple of other games relying on this are booting correctly now :)

 

StrmnNrmn est de retour à travers son blog et pendant son absence, il a pas chomé^^

 

voici les liens pour daedalus R9, enjoy^^

 

Daedalus PSP R9 for v1.00 Firmware

Daedalus PSP R9 for v1.50+ Firmware

Daedalus PSP R9 Extras

Daedalus PSP R9 Source

 

"Wow, it's been a long time since the last update. A really long time. How did that happen?

 

I've always found it quite hard to find the time to update the blog. Usually when I have some free time in the evenings (that's free time spent doing things other than eating, socialising, and getting stuff ready for work), the choices I have are:

 

* Do some new development on Daedalus

* Play games/watch TV/relax

* Reply to a few emails/comments, post a new entry here

 

Unfortunately over the past half year or so the first two bullet points have won out. So, apologies for neglecting the 'outside world' for so long. On the plus side, the existance of the first bullet points means that I have lots of exciting new developments to talk about over the next few days :)

 

I'm going to finish off this reintroduction with a broad overview of some of the stuff I've been working on. This is all stuff that will be present in R9, which I'd like to release this month.

 

* 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)

 

 

There's quite a lot in that list, so I highlighted the two most significant points. In summary R9 will be much faster, with audio support. I'll write a bit more about these changes in particular over the next few days (promise!)

 

-StrmnNrmn"

source : http://strmnnrmn.blogspot.com/

 

On retiendra surtout l'apport du son dans son émulateur et un bon level up de la vitesse (qui était déjà honorable lors de la R8), bref vivement la release^^

Lien vers le commentaire
Partager sur d’autres sites

Veuillez vous connecter pour commenter

Vous pourrez laisser un commentaire après vous êtes connecté.



Connectez-vous maintenant
 Partager
Aller sur la liste des sujets

  • Statistiques des membres

    23 028
    Total des membres
    1 033
    Maximum en ligne
    Subaru
    Membre le plus récent
    Subaru
    Inscription

  • Statistiques des forums

    128,1 k
    Total des sujets
    1,7 M
    Total des messages
×
×
  • Créer...