Hi, I am new around here but one thought that has been lingering is why do some wii games require fast speeds to the point where you might have to overclock them?
I am in no way tech savy but could someone shed some light in this area (layman's term or not) as to why I can run current gen games beautifully around the 2nd best settings (averaging 49-60fps depending on game) but I can hardly play say Last Story without audio hiccups such as out of sync audio. At first I thought maybe it's because it's an emulated game but then I've read topics where people have managed to sort out the issues (audio, fps or both) and they all have a faster cpu obviously but that's why I get stumped, the wii doesn't even have close to those speeds and I know my cpu is faster than a wii, throw in what I mentioned earlier about me being able to play current gen games and I'm left scratching my head. Thank you for reading.
-My specs are-
Motherboard: GIGABYTE GA-M68MT-S2
Graphics: AMD Radeon HD6850 1GB
CPU: AMD FX-Series FX-8120 Zambezi 3.1GHz
Ram: 8GB (4GB x2) DDR3 1333
OS: Windows 7 Home Premium (64-Bit)
(06-10-2013, 06:42 PM)Puniasterus Wrote: [ -> ]Because PC games are build to run great in a PC and GC/Wii are not, so the CPU instructions have to be translated.
In the FAQ is better explained:
http://dolphin-emu.org/docs/faq/?nocr=tr...late-old-c
Alright, thanks for shedding light on this area.
Not only do CPU instructions have to be translated, but some of the graphics emulation work has to be done on the CPU because there's so much goddamn crazy stuff in the GC/Wii GPU that we can't directly/easily/properly emulate it all on a PC GPU. For example, EFB emulation, to which I will look to a comment in Source/Core/VideoCommon/TextureCacheBase.cpp to explain:
Quote:// Emulation methods:
//
// - EFB to RAM:
// Encodes the requested EFB data at its native resolution to the emulated RAM using shaders.
// Load() decodes the data from there again (using TextureDecoder) if the EFB copy is being used as a texture again.
// Advantage: CPU can read data from the EFB copy and we don't lose any important updates to the texture
// Disadvantage: Encoding+decoding steps often are redundant because only some games read or modify EFB copies before using them as textures.
//
// - EFB to texture:
// Copies the requested EFB data to a texture object in VRAM, performing any color conversion using shaders.
// Advantage: Works for many games, since in most cases EFB copies aren't read or modified at all before being used as a texture again.
// Since we don't do any further encoding or decoding here, this method is much faster.
// It also allows enhancing the visual quality by doing scaled EFB copies.
//
// - Hybrid EFB copies:
// 1a) Whenever this function gets called, encode the requested EFB data to RAM (like EFB to RAM)
// 1b) Set type to TCET_EC_DYNAMIC for all texture cache entries in the destination address range.
// If EFB copy caching is enabled, further checks will (try to) prevent redundant EFB copies.
// 2) Check if a texture cache entry for the specified dstAddr already exists (i.e. if an EFB copy was triggered to that address before):
// 2a) Entry doesn't exist:
// - Also copy the requested EFB data to a texture object in VRAM (like EFB to texture)
// - Create a texture cache entry for the target (type = TCET_EC_VRAM)
// - Store a hash of the encoded RAM data in the texcache entry.
// 2b) Entry exists AND type is TCET_EC_VRAM:
// - Like case 2a, but reuse the old texcache entry instead of creating a new one.
// 2c) Entry exists AND type is TCET_EC_DYNAMIC:
// - Only encode the texture to RAM (like EFB to RAM) and store a hash of the encoded data in the existing texcache entry.
// - Do NOT copy the requested EFB data to a VRAM object. Reason: the texture is dynamic, i.e. the CPU is modifying it. Storing a VRAM copy is useless, because we'd always end up deleting it and reloading the data from RAM anyway.
// 3) If the EFB copy gets used as a texture, compare the source RAM hash with the hash you stored when encoding the EFB data to RAM.
// 3a) If the two hashes match AND type is TCET_EC_VRAM, reuse the VRAM copy you created
// 3b) If the two hashes differ AND type is TCET_EC_VRAM, screw your existing VRAM copy. Set type to TCET_EC_DYNAMIC.
// Redecode the source RAM data to a VRAM object. The entry basically behaves like a normal texture now.
// 3c) If type is TCET_EC_DYNAMIC, treat the EFB copy like a normal texture.
// Advantage: Non-dynamic EFB copies can be visually enhanced like with EFB to texture.
// Compatibility is as good as EFB to RAM.
// Disadvantage: Slower than EFB to texture and often even slower than EFB to RAM.
// EFB copy cache depends on accurate texture hashing being enabled. However, with accurate hashing you end up being as slow as without a copy cache anyway.
//
// Disadvantage of all methods: Calling this function requires the GPU to perform a pipeline flush which stalls any further CPU processing.
//
// For historical reasons, Dolphin doesn't actually implement "pure" EFB to RAM emulation, but only EFB to texture and hybrid EFB copies.