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.
Some you may have missed, popular articles from the last month:
The comments on this article are closed.
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
./citra: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `CXXABI_1.3.11' not found (required by ./citra)
BAD Problems in Debian
0 Likes
Quoting: freerunnerlive./citra: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.27' not found (required by ./citra)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.
./citra: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `CXXABI_1.3.11' not found (required by ./citra)
BAD Problems in Debian
0 Likes
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)Experienced the same thing. Also tried to build it but it seems it requires GCC 7. Current in stable is 6.3.
./citra: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `CXXABI_1.3.11' not found (required by ./citra)
BAD Problems in Debian
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.
0 Likes
It doesn't work in Ubuntu 17.10 too:
They should release it as AppImage, like rpcs3.
But I could successfully build and launch it with
Last edited by ageres on 15 March 2018 at 2:03 pm UTC
./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
makeLast edited by ageres on 15 March 2018 at 2:03 pm UTC
0 Likes
thought i had it going for awhile but had to throw in the towel in the end.
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
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
0 Likes
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!
0 Likes
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
1 Likes, Who?
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.
0 Likes
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
0 Likes
Patreon
PayPal
See more from me