You are not logged in.

Read the FAQ and Knowledge Base before posting.
We won't make a 3DS/2DS emulator.

#1 Re: Support » Desmume optimisation to run closer to the DS cpu threashhold? » 2019-03-01 17:39:11

Sigh... OF COURSE DeSmuME could be further optimized, just like every other piece of software that exists out there.

I don't think you appreciate how fast DeSmuME actually runs at this point. As of the current commit git#4281747, DeSmuME handily beats ALL other NDS emulators in terms of performance in all areas (yes, this includes even No$GBA!), with the exception of DraStic. And even with DraStic, the performance difference is about 10%-30%. So while this difference is significant, this should not be a problem at all if you are running DeSmuME on any PC since, say, 2012.

fintogive, do you have any specific examples that are slowing down too much for you? What game? In what scene? Running DeSmuME on what hardware?

I have a sneaking suspicion that you are running your performance tests incorrectly, and thereby getting poor results from the settings that you're using.

#2 Re: Support » Small Bug With Fast Forward » 2019-01-11 06:06:36

There was a regression from commit git#abc0649 that could cause graphical glitches when running custom resolutions on multicore CPU systems. The bug involved frameskip, and fast forwarding with frameskip enabled made the bug very obvious.

From our Downloads page, try the nightly for git#f5d90a7 to see if that resolves your issue.

#3 Re: Support » volume control doesnt pass over to avi dumped video. » 2018-09-24 03:51:10

"Blared out audio"? What are you talking about?

DeSmuME's SPU emulation simply outputs the internally mixed audio to the client app in 44.1kHz 16-bit stereo. If the sound is clipping or otherwise sounds "bad", then that is DeSmuME faithfully emulating the game's bad sound. There is no way around this -- you are getting exactly what the game is outputting. I also know that the sound interpolators and sound synchronizer DO NOT affect the sound amplitude. If the game programmers did proper testing, then they would never allow the audio from their games to clip under normal circumstances. According to my testing, I've never heard any game's audio actually clip.

fintogive, I think you need to be more specific about your problem. Is this a problem of the sound quality itself? Or is it excessively loud audio levels that are apparently reducing your sound quality? If it's the latter, then you might want to check your audio equipment to see if they can handle the SPL. Or perhaps you might be using a special audio recording driver that is throwing your system out of whack.

Another thing is that the audio level detector in most video editing software tends to run very conservative. In reality, it doesn't matter if Premier Pro's audio level indicator constantly runs in the red -- just as long as the audio doesn't clip, you're fine. Again, I've never heard any game's audio actually clip, but if you've heard it, I'd like to know which game is doing it so that its behavior can be documented.

#4 Re: Support » DeSmuME-Reloaded : DS emulator with WiFi support » 2018-09-23 05:29:32

No, it cannot. All of the Wi-Fi functionality is presently in a broken state where it doesn't do anything useful.

All the current Wi-Fi code can do is compile successfully and make intermittent connections to either another DeSmuME instance or to the AltWFC server. However, it cannot maintain any connections as of yet or actually participate in any real multiplayer games.

#5 Re: Support » DeSmuME Wii Emulation Slow-Down Problem - Help Needed Please! » 2018-09-10 16:45:17

Wiferni, you misinterpret zeromus' words.

- He didn't mean, "We don't make an emulator that emulates the Wii console."
- What he meant was, "We don't make a DeSmuME port that runs on the Wii." Ergo, find the third-party website that makes the Wii DeSmuME port. Or better yet, just use one of the officially provided DeSmuME ports for the PC.

#6 Re: Technical » Desmume 0.9.12 with working WiFi » 2018-08-10 17:26:34

Thanks to retr0s4ge's WiFi work, I'm currently reworking the WiFi API in DeSmuME to be easier to use for front-end integration and more feature-rich for better usage. In this first round of reworks, it is simple refactoring of code from C to C++ without any added features or any emulation changes. This is being done to modernize this section of the codebase to make it easier for future work.

After the WiFi API is modernized, anything goes from there!

#7 Re: Technical » Desmume 0.9.12 with working WiFi » 2018-08-10 16:22:01

Wait a minute... so in src/frontend/windows/main.cpp, using WSAStartup() in main.cpp:2992 and WSACleanup() in main.cpp:3620 are insufficient for Ad-hoc mode? Because it seems to work for me. (Although, as you already mentioned, Ad-hoc mode only allows DeSmuME to detect other players, but disconnects them after that.)

#8 Re: Support » Emulator edges are glitched » 2018-08-09 00:39:59

You are using an old commit from January. We have made changes to DeSmuME's graphics system and Windows GUI since that time.

Try using the latest nightly from our Downloads page to see if that resolves your issue:

#9 Re: Support » Sands Of Destruction minor layering issue » 2018-08-01 20:48:54

Fixed in commit git#36ee247, but for SoftRasterizer only. Applying the same fix for OpenGL is still being researched.

#10 Re: Support » Sands Of Destruction minor layering issue » 2018-08-01 19:48:05

I can confirm that Luigi's fix does work. I modified SoftRasterizer to perform a LEQUAL depth test based on the polygon facing conditions, and Sands of Destruction seems to be rendering the status screens correctly now.

I will submit a commit for this fix later, after I've cleaned up the code a bit to be less confusing.

Now... getting this same fix to work in OpenGL will be the real trick. Unfortunately, this fix only works by reading and writing to the destination framebuffer, which is a big no-no in OpenGL. I'm gonna have to take a real deep think about this.


#11 Re: General » macOS will remove OpenGL - will DeSmuME continue to be supported? » 2018-06-09 16:48:04

macOS 10.14 Mojave will still support OpenGL, although it is supposed to be the last macOS to do so. macOS Mojave hasn't been released yet, but following Apple's typical release schedule, Mojave will probably be released in September of this year, and then will the next macOS will be released in September of 2019.

You should have nothing to fear from upgrading to Mojave. DeSmuME will continue to work in macOS Mojave. And then in the nightly builds, the Cocoa port does support a Metal-based frontend, and so the next DeSmuME release will support future macOS releases.

The only remaining concern at this point is the emulated 3D renderer. Of course, the Cocoa port supports SoftRasterizer, which works on any computer, including one running a future macOS release. However, OpenGL is the only hardware-based 3D renderer, and on strong GPUs, OpenGL can greatly improve performance for a lot of rendering scenarios. Since having a hardware-based 3D renderer is an extremely popular DeSmuME feature, it is far more likely that I would be writing a Metal-based 3D renderer specifically for the Cocoa port rather than using Vulkan.

My reasons for using Metal over Vulkan are the following:
1. I have existing experience writing Metal code. I have no experience with Vulkan.
2. Related to the experience issue, Metal is an API that is easier to use than Vulkan. Metal still does some hand-holding things it does for the programmer, which is something I do appreciate coming from OpenGL. Vulkan literally makes you do everything, and I don't feel comfortable dealing with all of that stuff.
3. Testing is much much much easier for Metal since it is limited only to Apple Mac computers. However, Vulkan would be expected to work on multiple platforms, and so the testing scenarios increase exponentially. Combined with the fact that Vulkan makes you do everything, this also means that the additional code complexity further increases testing needs. (The reason why we can get away with OpenGL being a cross-platform API is because OpenGL does a lot of hand-holding for you, and so we can write much more simplified code that is much easier to test, and then blame the third-party GPU drivers when things go wrong.)
4. I don't want users to have to deal with third-party extensions like MoltenVK. I want DeSmuME for Mac to work right out of the box, just like in Windows.

Of course, I'm not denying anyone who wants to contribute a Vulkan-based emulated 3D renderer -- this is an open-source project after all. In fact, it should be easier now than it ever has for people to write new 3D backends. However, if it does fall to me to get DeSmuME to support future macOS releases, then this is the reasoning going on in my mind for why I would do things the way I do.

#12 Re: General » Missing Nightly Builds » 2018-05-17 19:34:53

Sorry. I'm the one who makes the Official Nightly Builds on the Downloads page, but I've been very busy as of late. I haven't had much time to work on DeSmuME, and it looks like I've dropped the ball on this.

I just updated the nightly builds with the latest commit (as of April 18, 2018). Note that there haven't been any significant changes to the Mac build since March 4th, and so whatever Mac build you were using from March 4th will be virtually identical to the new one I made for April 18th.

I'm curious to know why you think the build instructions are unclear. I can't say anything about the Windows and Linux build instructions, but I strongly believe that the Mac build instructions are both highly detailed and very straightforward. If you think that this is not the case, then I'm open to suggestions on how the Mac build instructions can be improved.

#13 Re: Compatibility » How i emulate that i have closed the Nintendo DS? » 2018-03-27 22:27:15

The input you need is called "Lid". It will toggle the open/closed state of the NDS.

The location for which the inputs for "Lid" are shown will vary between DeSmuME ports, but if you're on Windows, then it will be shown in the Config > Control Config menu.

#14 Re: Technical » seamless AVI files for x64 builds » 2018-03-01 17:10:33

fintogive wrote:

so now that the avi dumping has been improved greatly

What about  seamless recording with avi (as in files arn't split every few GBs) with x64 builds and possibly x86 builds?
is that possible to do at least for x64 builds?

As the code currently stands, our AVI dumping is completely reliant on the ancient Video for Windows API, which sets hard limits on file sizes. For safety's sake, we use the 2 GB file limit for best compatibility. … e-avi-file

And yes, it would be obviously be better if we got away from the VfW API and used a more modern API. We would have more encoding options, better performance in many cases, and cross-platform support. Not to mention file sizes greater than 2 GB! Yeah, using something like ffmpeg would be nice...

Edit: Oh yeah, try commit git#db1a19a. This version increases the written file size of AVI segments to be much closer to the 2 GB limit, whereas previous versions held back from the limit a good bit. It should help you get a few more frames in per AVI segment.

#16 Re: Support » Image Quality Question » 2017-12-13 22:42:45

The difference in the images is between running a Nearest Neighbor filter vs. a Bilinear filter on your video output.

See the FAQ for more details: … _output.3F

#17 Re: Support » Slowdowns on laptop with i7 7700hq » 2017-12-12 07:37:55

I did read the entire thread, and I was trying to help you out. It was clear that you didn't experiment with the settings very much, and I was trying to give you some friendly advice in demystifying DeSmuME's many many many options. Relax.

In any case, it's extremely difficult to believe that you are getting poor performance on the Sands of Destruction intro when running SoftRasterizer. On my MacBook Pro 2012, which has a Intel i7-3820QM and Nvidia GeForce GT 650M, I'm getting the following numbers.

- Frame rate limiter OFF
- Frame skip OFF
- Magnification Filter NORMAL
- Advanced Bus-Level Timing OFF
- Dynamic Recompiler ON w/ Block Size 12
- SoftRasterizer
- 18-bit color depth

1x GPU Scaling: 100 FPS
2x GPU Scaling: 80 FPS
3x GPU Scaling: 60 FPS

You said that you weren't running "insanely high resolutions", so that's what I tested while running on hardware that is inferior to yours. Your slowdowns are very confusing. You should be easily hitting at least 60 FPS on the Sands of Destruction intro on your hardware (assuming that your GPU Scaling Factor isn't set too high).

"Starting from scratch" essentially means that your .ini file got reset, which means that you would be running SoftRasterizer with 18-bit color depth and 1x GPU Scaling, which is why things are running faster for you. You could have just changed your 3D Settings in order to achieve the same result.

Finally, when it comes to "heavy emulators", you should know that PS2/Wii/GC/WiiU are not as heavy as you might think because they are pure 3D systems that use somewhat modern design paradigms, which makes such systems more relatable to modern PC hardware. An NDS, which uses two different and distinct CPUs, two separate screens, and has a mish-mashed 2D+3D graphics system, makes it very different from how a modern PC works. Because of the many differences, emulating an NDS is much heavier than you would think.

#18 Re: Support » Slowdowns on laptop with i7 7700hq » 2017-12-12 06:29:17

The opening scene in Sands of Destruction is notorious for changing polygon states a lot. And I mean A LOT. This polygon state changing slows down OpenGL due to the fact that OpenGL does not like constant state changes. There is nothing that can be done about this -- our OpenGL renderer is as optimized as can possibly be in minimizing state changes as much as possible.

It is recommended that you run SoftRasterizer for Sands of Destruction. SoftRasterizer is much less sensitive to polygon state changes compared to OpenGL.

Judging an entire emulator to be slow based on a single game while running a specific configuration isn't really a fair assessment. There are many games that run much faster with OpenGL, while there are other games (such as Sands of Destruction) that run faster with SoftRasterizer. Each 3D renderer has its own strengths and weaknesses, which is why both of them are provided. Different games have different performance characteristics, so it is your responsibility as the user to determine which settings work best for you.

#19 Re: Support » star fox command slow frame rate in openGL » 2017-11-30 07:41:19

That's because the texture handling system has had a significant rework since your original post from early 2016 to help boost its performance.

#20 Re: Support » A couple of glitches with the SoftRasterizer » 2017-11-23 19:36:41

I'm assuming that you set the GPU Color Depth to 24-bit.

SoftRasterizer only supports up to 18-bit. If you choose 24-bit color depth, SoftRasterizer will render a 3D layer of 18-bit color, which is later upsampled to 24-bit. The color banding you're seeing is due to SoftRasterizer only rendering at 18-bit. Do note that a hardware NDS also uses 18-bit color depth.

OpenGL can render to 24-bit color natively, which is why the color gradations are perfectly smooth. But just like zeromus mentioned, a hardware NDS can't actually produce this kind of color, since it is only limited to 18-bit.

#21 Re: Support » star fox command slow frame rate in openGL » 2017-11-11 20:34:28

Possibly. It really depends on what causes StarFox Command to texture thrash.

If texture trashing is due to palette changes, then it is possible to reduce the number of texture data uploads to the GPU by performing the palette swap on the GPU instead of the CPU. However, if texture thrashing is occurring because the actual image data itself is changing per frame, then there is no hope of ever speeding this up. I haven't done any major testing on StarFox Command to determine which scenario is going on.

Note that any further changes to the texture loading system are not planned for this release cycle. You will have to wait for a future release.

#22 Re: Support » what is the bottle neck with desmume at larger resolutions and opengl? » 2017-11-11 20:29:33

Texture dumping will not happen in this release cycle.

When texture dumping comes along, it will exist as a byproduct of a new custom texture replacement feature that will be coming in a future release.

#23 Re: Compatibility » golden sun dark dawn djinn bug » 2017-11-10 19:59:21

Very strange.

The djinn are sprites that are drawn in the OBJ layer. When debugging, it appears that these sprites are using the Transparent OBJ mode, which is forcing the sprites to draw transparent. Under normal circumstances, this is the intended behavior.

However, it looks like Golden Sun: Dark Dawn is doing something strange here, because even though Transparent OBJ mode is being used, the sprites are being drawn as opaque. I have no idea what kind of special rule the NDS is using in this case. Or maybe we're just using a faulty implementation of the Transparent OBJ mode.

It really is all very strange.

#24 Re: Support » what is the bottle neck with desmume at larger resolutions and opengl? » 2017-11-07 20:22:08

fintogive wrote:

So one more question is there any chance with future development on desmume that it will become faster in openGL mode using higher resolution's? or has it reached its limit and will depend on when cpus become more power as newer technology is developed?

For rendering the 3D layer itself, it is possible to make some general performance improvements for the OpenGL renderer by improving texture loading times. A couple of things that could be done are:
- Unpacking textures on the GPU rather than the CPU
- For Texture Desposterization and Texture Upscaling, running these filters on the GPU rather than the CPU

Note that these texture loading improvements aren't affected by resolution, but can still help by reducing CPU load. However, most games (but not all) are well-behaved in that they load all their textures all at once, and so DeSmuME caches these textures so that the user usually never notices the texture loading times anyways. This improvement really only helps with ill-behaved games that thrash textures often.

There aren't any more improvements that could be made in minimizing OpenGL state changes -- they are optimized as best as can possibly be, especially in OpenGL 3.2, where all state changes that could possibly be moved to the shader are copied all at once at the beginning of the render.

If there is any improvement that could possibly made that would be directly affected by resolution, it would probably be improving the shaders that emulate the NDS hardware. But even if these shaders were to be optimized to their very best, I don't foresee a lot of performance gain due to the fact that the shader itself is relatively simple.

Any major performance improvements that OpenGL could make that would be noticeable at high resolutions is by moving as much of the 2D graphics emulation to the GPU. However, this would require a major rewrite of the entire graphics system. This would essentially be a research project unto itself, because there are many aspects of the NDS 2D emulation that MUST be processed on the CPU (such as any interactions with emulated VRAM). Not only that, but we would have to emulate the NDS scanline-based compositing on a GPU that wants to work with entire framebuffers. In fact, the way the NDS works with 2D graphics is completely foreign to how GPUs actually work, and so I'm not too sure about how much work can be moved from the CPU to the GPU. Well... it would be a research project.

So in short:
1. Has the OpenGL renderer reached its limits in terms of performance? No, there are still some minor improvements that could be made. However, those improvements would be relatively small, and those improvements wouldn't even be noticeable in many games.
2. Would a better optimized OpenGL renderer significantly improve performance at higher resolutions? Yes, but it would only be a small improvement, since the OpenGL renderer is already very well optimized as it is. (Despite what people might think, emulating the unique NDS 3D graphics hardware is no easy feat on a GPU that doesn't work the same way an NDS does, which causes 3D performance to be lower than it should be.)
3. If portions of the 2D graphics system were emulated on the GPU rather than on the CPU, would that improve overall graphics performance? Yes, and it would be a very significant performance improvement were this to happen. However, this requires a major rewrite of the entire graphics system, which is not reasonable to do during this release cycle.
4. Are more powerful CPUs required for improving graphics performance, especially at higher resolutions? Yes, and having a strong CPU is always going to be a hard requirement for emulating the NDS graphics system any reasonable accuracy. No matter how much emulation work we push to the GPU, there will always be work that MUST be done on the CPU. Having the fastest CPU possible will always be the most important point when trying to run higher resolutions.

#25 Re: Support » what is the bottle neck with desmume at larger resolutions and opengl? » 2017-11-06 18:05:48

All those systems you just mentioned (N64, Gamecube/Wii (Dolphin), PS2 and PS1) are naturally 3D systems, which makes it much easier for them to run all their graphics natively through a modern PC's GPU. For those emulators, a good GPU always has a lot of influence over the overall emulator performance.

However, an NDS is naturally a 2D system that just so happens to have a 3D subsystem attached to it. Therefore, the 3D subsystem can easily be run through a modern PC's GPU, but the overall 2D-based graphics system must still be run through the CPU. For DeSmuME, a good GPU might have some influence over the overall emulator performance, but this is purely dependent on how individual games decide to use the NDS hardware. Some NDS games make a lot of use of the 3D subsystem, and others make very little use of it. And then there are other games that make no use of the 3D subsystem at all, relying purely on the 2D parts of the NDS hardware.

DeSmuME runs its 3D subsystem in parallel with the 2D system, and then reads out of the 3D layer only when necessary. Therefore, the CPU can be a potential bottleneck if the 2D runs slower than the 3D. It is also possible that the GPU could be a potential bottleneck if the 3D runs slower than the 2D. But in practice, the 2D system usually runs slower than the 3D subsystem, making the CPU the bottleneck more often than not.

And finally, the 3D subsystem can be run through either SoftRasterizer (a purely CPU-based 3D renderer) or OpenGL (a CPU+GPU-based 3D renderer). Obviously, if the user uses SoftRasterizer, that will consume massive CPU resources. But if the user uses OpenGL, that doesn't automatically assume that ONLY the GPU is being used. It still takes some CPU processing to feed NDS data into formats that OpenGL likes. Not only that, but the NDS can change rendering states for every polygon, which incurs a CPU-expensive OpenGL state validation each time this happens. In fact, some games do this per-polygon state changing so much that OpenGL's own state validation makes OpenGL run just as slow as SoftRasterizer!

So in short:
1. The systems you mentioned are naturally 3D systems, which makes the GPU have more influence over the overall graphics processing performance. However, the NDS is naturally a 2D system with a 3D subsystem attached to it, making the GPU have less influence over the overall graphics processing performance compared to other consoles.
2. Individual games can utilize how much or how little they use the 2D or 3D parts of the NDS hardware, making the GPU have a variable influence over the overall performance. In practice, the CPU will be utilized more than the GPU in the vast majority of games.
3. Running the 3D subsystem using the OpenGL renderer is not CPU-free because there is still quite a bit of CPU processing involved in OpenGL.

Board footer

Powered by FluxBB