it's the same thing with PS3? cfw PS3 can't read PS3 backup files?
it's the same thing with PS3? cfw PS3 can't read PS3 backup files?

@TotalInsanity4 I bet with this option NSMBU will work at 60FPS(if not more), with EFB Copies set to RAM, NSMBW runs at less than half the speed, but when set to texture, it runs at more than 60FPSI think that problem occurs to things like.... animated "?" blocks in NSMBU(if you don't know what I mean, take a close look at my signature)... This also occurs in dolphin if frame-skipping is enabled, a fix to that is to stop/cancel the animations!
To do that in dolphin you have to "store EFB Copies to Texture only", I think it's automatically stored to RAM in CEMU.
No we havent figured out wii u yet on drive encriptionit's the same thing with PS3? cfw PS3 can't read PS3 backup files?

Nintendo eshopThis is not the place to be asking.

![]()
![]()
But yeah, optimisations are not present at all in the emulator as of now.
im really interested in this emulator because i want to play Xenoblade Chronicles X (i played twice Xenoblade Chronicles on Dolphin emulator and 1 million times Xenogears): im new in this page/forum, but i want to share to all of you what i've reached with the last update of this emulator (Main Menu and Character Creation): i wish the best for this team and i expect a lot of progress for this emulator in next year
This is basically what modern emulation does. The problem is that it's slightly slower because the calls cannot be mapped 1:1, and generally aren't as bare metal as console APIs so require extra checks or conversions. (dx12 and vulkan have the potential to improve this)Two questions. Since the Wii U likely communicates with it's GPU via a driver, is there really all that much GPU and audio emulation? It seems like it would be mostly converting Wii U APIs to Windows APIs, and thus the GPUs we use won't have to be two much more capable then the Wii U's.
The host system needs to simulate each thread as is given to it, which for a tri-core console, generally won't be more than 3 intense threads and a bunch of small ones for I/O. It's impossible to automatically parallelize arbitrary code. The main reason most things run slowly is similar to above, where code is generally Just In Time recompiled to the host's machine language (PPC -> x86), but the instructions do not map 1:1 and extra steps need to be added for the code to even work correctly. Pretty much the simplest way to put it.Also, what exactly prevents something that's obviously CPU bound, like CEMU, from using CPUs more in situations where it obviously needs the extra performance. Is it because the lack of optimizations is preventing the CPU from using it's execution units efficiently?
opengl it's self is a bug sorry to say it's not the best api for a emulator even dx11 does better in dophin and ps2 emulatorNvidia bugs/amd bugs is about 1.16
Nvidia users/amd users is over 1.5 (I'm sure we can go over 2!)
So there are less bugs on Nvidia than on amd![]()

Not true it depends on the video card and which backend has the most optimizations.opengl it's self is a bug sorry to say it's not the best api for a emulator even dx11 does better in dophin and ps2 emulator
you obviously haven't programmed using both then, lol. every library is as powerful as the person's knowledge of said library.opengl it's self is a bug sorry to say it's not the best api for a emulator even dx11 does better in dophin and ps2 emulator
http://wiiudaily.com/wii-u-system-specs/Correct me if im wrong but i think the wiiu os uses a core while a game is running, so the game only has 2 cores to use.
Pretty sure whatever the active program is will use all three cores. Background system stuff uses an ARM core on the GPU that people call the Starbuck.Correct me if im wrong but i think the wiiu os uses a core while a game is running, so the game only has 2 cores to use.
Well at least the GPU hardware doesn't need to be emulated. It looks like the GPU emulation should be somewhat easier than on Dolphin for instance since the Wii U is less concerned with the intricacies of the hardware.This is basically what modern emulation does. The problem is that it's slightly slower because the calls cannot be mapped 1:1, and generally aren't as bare metal as console APIs so require extra checks or conversions. (dx12 and vulkan have the potential to improve this)
I'm talking about the emulator not making full use of any of the cores though. Emulating the Espresso should be like emulating three instances of the Broadway on three different cores(if available) in Dolphin but at a higher clock. I'm not surprised that the games are running slowly, I'm just surprised my CPU isn't maxing out any of it's cores to try to get them to run better.The host system needs to simulate each thread as is given to it, which for a tri-core console, generally won't be more than 3 intense threads and a bunch of small ones for I/O. It's impossible to automatically parallelize arbitrary code. The main reason most things run slowly is similar to above, where code is generally Just In Time recompiled to the host's machine language (PPC -> x86), but the instructions do not map 1:1 and extra steps need to be added for the code to even work correctly. Pretty much the simplest way to put it.
Yes i was lol, the wii u holds 2 cpus, a 3-core for the games, and an ARM processor for the OSdid u correct me?![]()
kk, hahaYes i was lol, the wii u holds 2 cpus, a 3-core for the games, and an ARM processor for the OS
Got this issue on my laptop using the nvidia 745M,Here is Super Mario 3D World![]()
ive done work with opengl and it's one of the worst graphic api's i have ever worked with mantle was the best so far and dx12 is ok need workNot true it depends on the video card and which backend has the most optimizations.





