You can sign up to get a daily email of our articles, see the Mailing List page.
We do often include affiliate links to earn us some pennies. See more here.

For those who love emulation, you might want to know about Citra [Official Site], a work in progress Nintendo 3DS emulator that we've never written about here before. It seems they've been hard at work too!

Unlike the Dolphin emulator for the GameCube and the Wii, Citra is not currently moving towards Vulkan. Instead, they've poured a lot of work into their current OpenGL renderer to improve performance and fix rendering issues and from what they've shown, it's getting quite impressive.

They've said that the new update is giving approximately 2x speed performance boost tested across various hardware configurations. Now, Citra will do the entire GPU emulation on the host GPU instead of the CPU.

On top of that, they've also rewritten texture forwarding support (to avoid a costly synchronization of textures between emulated 3DS memory and the host GPU memory) which not only increases the performance of many games, it also fixes some issue when upscaling the rendering to improve the actual look of the game like this example:

Then they showed off a few charts to show the improvement, like this one which shows just how much performance has improved.

Those are some huge gains and it sounds like it was quite a lot of effort, especially with OpenGL drivers varying across Linux, Mac and Windows in terms of performance and OS-specific issues. They've also been dealing with cases where the OpenGL documentation isn't great with ambiguous wording. That's a complaint I've heard a few times, which is why there's been such a big focus on good documentation for Vulkan.

You can read about the update on the official blog post here.

I'm now following their RSS feed, so I will hopefully be able to keep you up to date on their progress as it comes in.

Thanks for the tip, MaCroX95!

Article taken from GamingOnLinux.com.
12 Likes
About the author -
author picture
I am the owner of GamingOnLinux. After discovering Linux back in the days of Mandrake in 2003, I constantly came back to check on the progress of Linux until Ubuntu appeared on the scene and it helped me to really love it. You can reach me easily by emailing GamingOnLinux directly. Find me on Mastodon.
See more from me
The comments on this article are closed.
15 comments
Page: 1/2»
  Go to:

freerunnerlive Mar 14, 2018
./citra: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.27' not found (required by ./citra)
./citra: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `CXXABI_1.3.11' not found (required by ./citra)


BAD Problems in Debian
tuubi Mar 14, 2018
View PC info
  • Supporter
Quoting: freerunnerlive./citra: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.27' not found (required by ./citra)
./citra: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `CXXABI_1.3.11' not found (required by ./citra)


BAD Problems in Debian
Ubuntu users will have the same problem I think, unless they're running the latest beta of 18.04. You'll have to build from source unless you find someone else who already did.
chris.echoz Mar 14, 2018
Quoting: freerunnerlive./citra: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.27' not found (required by ./citra)
./citra: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `CXXABI_1.3.11' not found (required by ./citra)


BAD Problems in Debian
Experienced the same thing. Also tried to build it but it seems it requires GCC 7. Current in stable is 6.3.
Compiling got to about 30-40% and then threw some errors about invalid conversions from const void* to void*. Likely caused by the older GCC not supporting whatever feature it was trying to use.
ageres Mar 15, 2018
It doesn't work in Ubuntu 17.10 too:
./citra-qt: /usr/lib/x86_64-linux-gnu/libcurl.so.4: version `CURL_OPENSSL_4' not found (required by ./citra-qt)
./citra-qt: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.27' not found (required by ./citra-qt)

They should release it as AppImage, like rpcs3.

But I could successfully build and launch it with
git clone --recursive https://github.com/citra-emu/citra
cd citra
mkdir build && cd build
cmake .. -DCMAKE_BUILD_TYPE=Release -DUSE_SYSTEM_CURL=1
make



Last edited by ageres on 15 March 2018 at 2:03 pm UTC
frakswe Mar 15, 2018
thought i had it going for awhile but had to throw in the towel in the end.

In file included from /source/citra/src/core/hle/service/ac/ac.cpp:9:0:
/source/citra/src/./core/hle/ipc_helpers.h: In member function ‘Kernel::SharedPtr<Kernel::Object> IPC::RequestParser::PopGenericObject()’:
/source/citra/src/./core/hle/ipc_helpers.h:401:10: error: expected unqualified-id before ‘[’ token
     auto [handle] = PopHLEHandles<1>();
          ^
/citra/src/./core/hle/ipc_helpers.h:402:39: error: ‘handle’ was not declared in this scope
     return context->GetIncomingHandle(handle);


edit: should add that i replaced the fmt library in the "externals" directory with the one on the fmt library homepage, most likely that has something to do why "handle" isn't declared.seems they have altered fmt lib with their own functions,which doesn't work with my system.


Last edited by frakswe on 15 March 2018 at 10:31 pm UTC
Scorpiove Mar 16, 2018
I had the same problem here on Arch, so I just downloaded the libc2.7 source and built it on my machine (make sure to not do the "make install" part). I then took the libm.so library that was built and placed it in the ~/.citra/canary/ folder, and from there I then ran the emulator with "LD_PRELOAD=~/.citra/canary/libm.so ./citra-qt". Everything worked fine afterwards. Also the new build is awesome!
x_wing Mar 19, 2018
Quoting: frakswethought i had it going for awhile but had to throw in the towel in the end.

In file included from /source/citra/src/core/hle/service/ac/ac.cpp:9:0:
/source/citra/src/./core/hle/ipc_helpers.h: In member function ‘Kernel::SharedPtr<Kernel::Object> IPC::RequestParser::PopGenericObject()’:
/source/citra/src/./core/hle/ipc_helpers.h:401:10: error: expected unqualified-id before ‘[’ token
     auto [handle] = PopHLEHandles<1>();
          ^
/citra/src/./core/hle/ipc_helpers.h:402:39: error: ‘handle’ was not declared in this scope
     return context->GetIncomingHandle(handle);


edit: should add that i replaced the fmt library in the "externals" directory with the one on the fmt library homepage, most likely that has something to do why "handle" isn't declared.seems they have altered fmt lib with their own functions,which doesn't work with my system.

By the error you get, seems like they're using C++17 and your compiler doesn't support it yet (if you're using gcc, check the man).

I believe that the problematic code is just a syntax sugar for: u32 handle = PopHLEHandles<1>()[0];

Try replacing that line and hope for the best :P
frakswe Mar 19, 2018
i will try it out,thanks x_wing
frakswe Mar 20, 2018
your solution worked, but there's more errors later regarding fmt functions that isn't there. suspected as much,replacing fmt lib wasn't a good idea but i had to give it a shot.
x_wing Mar 20, 2018
Quoting: fraksweyour solution worked, but there's more errors later regarding fmt functions that isn't there. suspected as much,replacing fmt lib wasn't a good idea but i had to give it a shot.

Well, that could be happening due that you clone the repository without "--recursive" option in order to fetch the externals/submodules. Check @ageres comment, think he gave you the right step by step (out of the C++17 problem).

Yesterday I went back to see my gcc for ubuntu 16.04 (gcc version 5.4.0) and found out that it has experimental support for C++17. From the man:

       -std=
           Determine the language standard.   This option is currently only supported when compiling C or C++.

           The compiler can accept several base standards, such as c90 or c++98, and GNU dialects of those standards, such as gnu90 or gnu++98.  When a base standard is specified, the compiler accepts all programs following that
           standard plus those using GNU extensions that do not contradict it.  For example, -std=c90 turns off certain features of GCC that are incompatible with ISO C90, such as the "asm" and "typeof" keywords, but not other GNU
           extensions that do not have a meaning in ISO C90, such as omitting the middle term of a "?:" expression. On the other hand, when a GNU dialect of a standard is specified, all features supported by the compiler are
           enabled, even when those features change the meaning of the base standard.  As a result, some strict-conforming programs may be rejected.  The particular standard is used by -Wpedantic to identify which features are GNU
           extensions given that version of the standard. For example -std=gnu90 -Wpedantic warns about C++ style // comments, while -std=gnu99 -Wpedantic does not.

           A value for this option must be provided; possible values are

           c90
           c89
           iso9899:1990
               Support all ISO C90 programs (certain GNU extensions that conflict with ISO C90 are disabled). Same as -ansi for C code.

           iso9899:199409
               ISO C90 as modified in amendment 1.

           c99
           c9x
           iso9899:1999
           iso9899:199x
               ISO C99.  This standard is substantially completely supported, modulo bugs and floating-point issues (mainly but not entirely relating to optional C99 features from Annexes F and G).  See
               <http://gcc.gnu.org/c99status.html> for more information.  The names c9x and iso9899:199x are deprecated.

           c11
           c1x
           iso9899:2011
               ISO C11, the 2011 revision of the ISO C standard.  This standard is substantially completely supported, modulo bugs, floating-point issues (mainly but not entirely relating to optional C11 features from Annexes F
               and G) and the optional Annexes K (Bounds-checking interfaces) and L (Analyzability).  The name c1x is deprecated.

           gnu90
           gnu89
               GNU dialect of ISO C90 (including some C99 features).

           gnu99
           gnu9x
               GNU dialect of ISO C99.  The name gnu9x is deprecated.

           gnu11
           gnu1x
               GNU dialect of ISO C11.  This is the default for C code.  The name gnu1x is deprecated.

           c++98
           c++03
               The 1998 ISO C++ standard plus the 2003 technical corrigendum and some additional defect reports. Same as -ansi for C++ code.

           gnu++98
           gnu++03
               GNU dialect of -std=c++98.  This is the default for C++ code.

           c++11
           c++0x
               The 2011 ISO C++ standard plus amendments.  The name c++0x is deprecated.

           gnu++11
           gnu++0x
               GNU dialect of -std=c++11.  The name gnu++0x is deprecated.

           c++14
           c++1y
               The 2014 ISO C++ standard plus amendments.  The name c++1y is deprecated.

           gnu++14
           gnu++1y
               GNU dialect of -std=c++14.  The name gnu++1y is deprecated.

           c++1z
               The next revision of the ISO C++ standard, tentatively planned for 2017.  Support is highly experimental, and will almost certainly change in incompatible ways in future releases.

           gnu++1z
               GNU dialect of -std=c++1z.  Support is highly experimental, and will almost certainly change in incompatible ways in future releases.


So, maybe with "export CXXFLAGS=-std=c++1z" before running makefile is the final trick (in case there are others C++17 related issues).


Last edited by x_wing on 20 March 2018 at 2:10 pm UTC
While you're here, please consider supporting GamingOnLinux on:

Reward Tiers: Patreon. Plain Donations: PayPal.

This ensures all of our main content remains totally free for everyone! Patreon supporters can also remove all adverts and sponsors! Supporting us helps bring good, fresh content. Without your continued support, we simply could not continue!

You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
The comments on this article are closed.