How much further to go?


#1

so i have been following citra for quite a long time now, i’ve seen it grow from running ocarina of time on SW render mode (painful 4 fps) to the emulator it is today.

but this begs the question which is how far is it from being done?.

i see that the cpu emulation (dynarmic) is cruising nicely and that the gpu part is being heavily worked on as well (props to all contributors for their great work) some nice features are already added or are still being worked on such as the camera, the gyro sensor…QR code scanning…etc.

so is possible to say that this year might be citra’s year?


#2

Raven, who knows.
The 3DS is a console that, even through it’s been investigated and hacked lots of times, there’s still stuff that we don’t know about it (not to say that developing an emulator is not that easy), and that we’ll probably have to wait a bit more until an actual first stable version is released and then, they’ll work to fix more bugs of the emulator for future versions.


#3

Keep in mind that 2017 is the year of the Linux Desktop.

I don’t think we’ll see many new features in Citra this year either. A lot of features take at the very least 2-3 month to be worked on (in freetime) and then another month for integration and testing.
As Citra progresses the time for testing will increase to avoid any regressions / breaking of existing features.
So if you didn’t hear of a feature yet, it’s unlikely that it will be integrated before the end of the year. There are some exceptions to the rule, but generally don’t overestimate the speed of Open-Source projects.
(Citra’s version 1.0 was planned for a couple of years ago but it still hasn’t reached all required original goals!)

Some very basic features which are still necessary are (but not limited to): NFC / Amiibos, Mipmaps, Cubemaps, Geometry shaders, Emulation of different shader units, accurate Shader emulation (bit-level-accuracy), accurate emulation of the VFP flags (broken still), a good and stable Debug interface, a good software renderer, JITs for other architectures, basic conditional features to improve portability, common code to make platform specific UI easier, gamepad support, hardware tests, a hardware test infrastructure, …

Renderer wise (what I mostly worked on) I also think we should get rid of OpenGL and focus on Vulkan or other APIs. We currently add a lot of workarounds and increase complexity when we should just use more modern technology. This, however, is not possible because we don’t have portable and fast renderer. In fact, our software renderer is way behind the graphics renderer and is often unusable.

Also speaking with Dolphin developers: it’s easy to do emulation with a lack in architecture and design. So even if the emulation is okay, the emulator could still be a mess (which will pose problems in the future when portability or modularity is important).

There are also some non-technical challenges to overcome such as spending the donation money wisely and supporting developers (for example, by buying rare and local games, preserving and testing them).
We also still couldn’t find people to maintain a blog which should be a priority to attract more capable developers and freeing the support staff by answering the posts in a more central location.
Citra also struggles with community decentralization and fragmentation due to Pokemon users not caring about 3DS emulation but only Pokemon. Similarily there is a piracy scene which is too closely related to Citra which is probably not good for the project either.


Some non-goals also exist which I hope won’t be worked on in 2017 (but I fear we’ll get a lot of questions about these still). This includes code-refactors where a working solution exists, new video backends while maintaing the existing ones (especially proprietary solutions such as Metal and D3D), impossible features such as cheats or premature attempts to turn the HLE into LLE, ports to platforms which require massive code changes and the like.
Some of those should certainly happen in the future, but the pre-conditions are not met yet.


Something else to keep in mind is that we are aiming for “playable” and not “enjoyable”. I’d assume we’ll be at “playable” before 2019 for most games, but “enjoyable” for the majority is probably not going to happen before 2023 (and I’d say that’s quite optimistic)


#4

Citra is not even greatly optimize yet, a lot of bugs. And generally only for rich people who can afford to buy high end computer. Its a dream come true if citra will achieve what other emulator achieve like pcsx2,ppsspp,dolphin and desmume they are great emulators(greatly optimize emulators). I hope citra will have this great developers.


#5

I don’t want to get too offtopic, but you have to keep in mind that those emulators emulate less powerful systems. You can’t reduce these comparisons to “optimization”. If you just wait 5-10 years, chances are most PCs at the time will also be powerful enough to run more games full speed in the current versions of Citra even if we stopped development now.
Emulators also benefit from compiler and driver optimizations.

This is one of the reasons why we prefer accuracy over optimizations (amongst many other things) and don’t really care if users PC isn’t fast enough.

(Lately PC performance is increasing differently and emulators don’t benefit much from it anymore, but this used to be the case and these emus benefitted from it)


#6

It’ll be ready in about 16 and a half weeks.


#7

i see, so a lot of things are up in the air right now and there is a lack of contribution from the user community.


#8

Not necessarily: We can’t blame the community. Not everyone is made to help and we don’t have capacity to manage 100 people at once either.

But it’s important that the community understands that working on Citra takes a long time and that developers have very different goals from users (caring only about a single came can be counter-productive etc.).

Also if people are working on Citra (either in code or documentation) they should do so by using these central hot-spots instead of moving discussions to other communities (where information is usually indirect and sometimes fabricated / wishful thinking, rather than straight facts). It doesn’t help the project if people privately work on features / documentation but never make them available publicly or try to integrate them in the official version / documentation.


These kind of non-technical problems are important to get right. By creating good guidelines and a self-administrating community we can free other people and reduce support overhead.
It will also make it easier for new users / developers to get help (so they will keep using Citra) which might result in contributions later.

I believe a lot of things have improved in 2016 and it’s easier to get started with the project now. However, there is still a lack of centralization and self-administration.
So if you see forum posts which violate our guidelines: smash that “report button”. If documentation is unclear: fix it. If people violate our license: call them out. If you see Citra packed with illegal files: tell them to stop. If something doesn’t work in Citra: be patient or look into the problem yourself. If you find a solution: document it and make it available here or on the wiki. …


#9

Plus, consider something: Lots of emulators have taken a long time to arrive to where they are now, like Dolphin, DeSmuME or BSNES (AKA Higan), and probably they’re going to take more time until they emulate the original console and its games perfectly, so that’s probably what’s going to happen with Citra too.


#10

I apologize if this belongs elsewhere, but since you brought it up, are those basic features being worked on currently? And if so, how far has their development progressed? As I am aware that development in Citra is not focused on specific games, I don´t wish to be a bother, but surely features like Geometry shaders are essential or at least helpful in most games? I am aware there is an faq section, but as it doesn´t mention any detaills and since I am unaware of when it was last updated, I though to ask somebody in the know.

Either way, I´d still like to thank you for your hard work and for the provided information about the emulator´s state.


#11

These were only examples, but I might aswell give my knowledge about their state:

  • NFC / Amiibos: As far as I know, someone (wwylele?) looked into it but not sure if there is code yet
  • Mipmaps: Nothing yet
  • Cubemaps: Nothing yet, technically similar to Mipmaps. More HW research was done by fincs lately
  • Geometry shaders: Worked on by ds84182 and taken over by me. yuriks did some work recently to make this easier to integrate / integrated some parts similar to mine. WIP / halted while I’m busy with uni (feel free to continue. I have a more recent version locally but I don’t want it stolen by idiots for unofficial builds again)
  • Emulation of different shader units: Part of my GS work
  • accurate Shader emulation (bit-level-accuracy): Nothing yet, I have plans but no time to do it
  • accurate emulation of the VFP flags: broken still since I broke it. Nobody except me seems to care but I don’t have a good understanding of that code either, no hardware to test it etc. (This is known to break some games!) - still WIP / halted
  • a good and stable Debug interface: We have gdb but people repeatedly complain about it, the CPU debugger in Citra (not sure if we still have it) is a license violation and severly broken
  • a good software renderer: We have a sw-renderer which lacks more features than the hw-renderer (which is a situation you want to avoid like the plague)
  • JITs for other architectures: Nothing yet
  • basic conditional features to improve portability: WIP / halted as busy with other things
  • common code to make platform specific UI easier: Nothing yet
  • gamepad support: WIP / in review
  • hardware tests: Tests exist for some things but it’s just a loose collection which can’t be automated either
  • a hardware test infrastructure: Nothing yet
  • vulkan: Has been worked on by ILOVEPIE a long time ago but was never finished. Progress halted
  • android: Has been worked on by Kloen a long time ago but was never finished, seems still wip (I thought it was halted until writing this!)
  • compatibility list: Some ideas / work by flamesage and I believe lioncache wants to help, but nothing concrete yet
  • software keyboard: Some work by jroweboy, but no nice integration / GUI yet

Take all of this with a grain of salt - second hand information etc. Also it’s hard to get an overview in open-source projects.
Even if there is WIP I wouldn’t expect any of these before April (aside from the gamepad support).

//Edit: Corrected some things I got wrong. Cheers to @RavenHome for pointing it out.


Which step that would be of great help for Citra?
#12

you mean android instead of vulkan?, because afaik ilovepie was the one who started on vulkan but it seems to be abandoned right now.


#13

Just stop using it with a potato or a toaster and you will see is in a pretty good state right now

(Don’t be like those guys who gives bad steam reviews because the games don’t run on their 2005 laptop)


#14

I just thought of another basic feature we don’t have yet: our own shared-font / system files.
That’s something which should have been done years ago, unfortunately many people simply don’t care. But it would make legal emulation easier.


What's with the latest version of Bleeding Edge requiring extra files from all games?
#15

How “hard” would be for someone to create one custom shared font ? What are the contents of that file ?


#16

Creating the files (BCFNT) isn’t hard, getting the legal mumbo jumbo right is hard though. But I believe that deserves its own topic (Possibly also discuss it in a GitHub issue [there should be one already] as it’s development related).


#17

I hope i can play monster hunter3 u on it one day.