When can we expect Pokemon Sun and Moon to be playable?


That’s a seperate issue / thread. However, it’s probably answered in our FAQ:
People often use unofficial builds (which we don’t support here) or change the playback speed of the video.

Be patient, don’t expect it working better anytime soon.


It’s mostly due to optimizing on the emulated gpu. Currently the gpu is decently accurate but there’s still a lot of work needed to improve accuricy and a lot more coverage. Things like Geometry Shaders, shadow mapping, cube mapping, procedural textures are missing.

Pokemon S/M as well as OR/AS have 3 main bottlenecks.

1st Texture caching is not being effective on them. @yuriks could explain it better though, he’s the expert.

2nd Vertex Shader JIT is not producing optimal code.

3rd the geometry pipeline could be optimized further without breaking accuricy.

When can you expect to play pokemon S/M at full speed? Maybe in a year or 2, the focus right now is on coverage and accuricy. Optimizations are secondary but it’s identified and will be worked on when the gpu emulation is more accurate.


1st [texcache]: it’s a texture RGBA <-> depth/stencil conversion issue which will be slow eitherway. It’s caused by the dark pixelated outlines (if we solve it those outlines will also look better probably)
2nd [jit]: mostly fine, but still room for improvement such as dynamic register allocation, optimization steps etc.
3rd [geom-pipe]: better caching is possible but the game will be slower again due to GS (which disables all caching and sacrifices some performance for accuracy)


on 3rd, I got some ideas mainly a refactor to reduce copying vertex data all over the place. Do you think it could possible to make the GS shaders generate indices instead of calling the primitive assembler?


@FernandoS27 possibly? but we should worry about this once we have a working GS implementation in the first place. I guess your intention is to emit new vertices into a longer buffer and then draw that array?

The VS moves data into the output registers [by design of the PICA], then there is one extra move into the geometry shader input registers [also by design], the EMIT instruction moves it into one of 3 (or 4?) output slots [again… by design] and from there the data is moved into the cache using AddTriangle.

I guess we could get rid of the output slots in EMIT and instead append data to an new list of vertices and index that (and save a couple of vertex moves + conversions). On the other hand, this would probably require a more complex rasterizer frontend because we currently don’t have a high-level way of drawing indexed [afair] (and for the sw-rast we wouldn’t really benefit either).
So until further optimizations are done and we have a better understanding of the PICA and GS: we shouldn’t do it. - the performance benefits are probably negligible in most cases anyway.

A quick and lightweight optimization might be to cache the converted OutputVertex in EMIT so the conversion doesn’t happen on vertex re-use.


It is playable, even if not on full speed. Playable = can be played from beg to end, and that’s the case.

I have a high spec PC, altough not the best one possible. Last gen of i5, gtx 970 and 16gb of ram. I was able to play from the very first mission until the end. The only issue that prevented me from finishing it without a major glitch was a black screen on final battle. I had to play the very last battle with only 3 pokemons to fix that. It’s a bummer, but considering that I was playing on an emulator, not bad at all.

Even with my PC I wasn’t able to play full speed. I’ve got 20fps outdoors and 70% of gamespeed. Indoors/battles are almost perfect. That lag was anoying at the beggining, but you won’t notice that after a few hours.

Not a perfect experience, but it’s quite playable as it is.


while it is playable the system is refusing to let me use the mystery gifts


That is an online feature, i.e. connecting to Nintendo’s servers. Citra does not emulate this feature.