Im neuesten Source-Update von MAME gibt es folgende Änderungen:
MAMETesters Bugs Fixed
- 00596: [DIP/Input] pocketrc: The car turns only to the right and
there is no way to calibrate controls. (smf)
- 02075: [DIP/Input] mooncrgx: Cabinet DIP setting is duplicated.
- 02137: [DIP/Input] rockduck: DIP...
Release von Dual Orb 2 Version 1.5 um 20:05:36 von Nemu
Nightcrawler's Translation Corporation hat einen neuen Patch für das SNES Rollenspiel "Dual Orb 2" freigegeben.
Out of the blue comes a polished up and improved Dual Orb 2 Patch! Interesting little story here. After listening to byuu parade around Dual Orb 2 for years as an example of a translation patch not working properly on the SNES with the Yes/No bug, I decided...
Im neusten Sourceupdate des Arcade Emulators gibt es folgende Neuerungen:
MAMETesters Bugs Fixed
01650: [Gameplay] ridgerac: Unstable Freezes that ends with Crash
and needs totally reboot under XP (Aaron Giles)
01542: [Graphics] 3wonders, 3wonderu, wonder3: Wrong colour of
background in game selection and start screens (Nic...
WinUAE v1.4.4 Public Beta 4 um 23:40:36 von McDuck
Eine neue Beta des bekannten Amiga Emulators. Neu ist:
ACTION_EXAMINE_ALL_END implemented (forgot in b2..)
directory filesystem on the fly mount implemented without need for spare empty devices. (I lied again, it was really simple after all..) "empty slot" drives removed. USB memory sticks etc will always mount on the fly automagically n...
Eine neue Version des ZX SPECTRUM +3, ZX Spectrum 128, ZX Spectrum 48, Arcade, NES, Game Boy Emulators DSP Emulator ist erschienen. Die Neuerungen sind:
+BUG: NEC765 - Fixed a bug in reading command when reading the ID of the sector ('Tintin on the Moon' and 'Into the Eagle's Nest' works).
+BUG: NEC765 - Fixed a bug in the search of a sector when i...
shash hat in seinem Blog ein kleines WIP Update zum DS Emulator DeSmuME geschrieben:
For a long time, I've been using a texture cache I coded for my own builds, that hasn't been uploaded to the CVS yet (neither I know it will be) as it needs a cleanup and uses some C++ only stuff which would be time consuming to port.
The main benefit you get from using a cache is uploading to openGL as little as possible per frame. In fact, it's rather simple: whenever a texture is going to be uploaded, you get some sort of magic number from the texture (I currently use some type of CRC) to be used as an identifier, if it's already in the cache you just enable it, if not, it's just a matter of uploading it to openGL and then adding it to the cache for further use.
In my current implementation I lack one important feature that wouldn't be hard to add: flushing unused textures. Dynamic textures or textures not longer used (from the previous level, menu or else) remain in the cache and, more important, in graphic cards memory. Right now is not that much of a problem, but I'm sure it would be after a few hours of gameplay.
I also toyed a bit with checking directly the palette texture formats prior to conversion, so I can save some precious cycles, but it's lacking serious testing: with paletted formats you've way less data, and CRC's are likely to collide easily, thus giving false matches while checking if cached, and glitching rendering. Anyway, seems like something important, as it can save quite a lot of CPU time.
Today's screenshot is based on some optimizations on the CRC creation, as some profiling showed it was taking too much time to compute. I changed a bit the way it works (and expect it to work as good as in the past :P) so I could get a bit more of performance. Along with some optimizations here and there, that's what I got:
That's running on the same configuration as the previous screenshots, a Northwood Pentium4 at 2.6ghz with a Geforce FX5600. I expect to get a bit more of speed in the future, but I'm not sure how much, as I've been unable to work on desmume in the 5-6 days. Oh, and the emulator menu is different from previous screenshots, as I'm using a build I use to develop stuff and then merge into the CVS: I never cared to change the menus from the base source code yopyop released.
Vom N64 Emulator Daedalus gibt es folgende WIP News.
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.
*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 :)