Retroarch: What is happening?

[fr500]

Sorry to meddle but what is going on?
Why is the whole architecture of the program changing?

I'm far from an expert or even a proficient dev, and not part of the "team" but I still have some WIP things going on and these latest changes seem very concerning.

Is there any rationale or long term goals of rolling everything into retroarch.c?

[LazyBumHorse]

Here's an official answer: https://github.com/libretro/RetroArch/pull/8910#issuecomment-502708016

[fr500]

Thank you for responding.

In my opinion it's awful but like someone told me recently "not my circus, not my monkeys"
I'll stick to the current codebase until things stabilize.

[twinaphex]

It's how the original SSNES/RetroArch was like, with most of the code that was split into separate driver files inside one big runloop file.

This allows for better restructuring of the codebase by getting most global state in one central place, and less passing around of state everywhere.

Anyway, it's an iterative process, and it's done to make the program last and become more maintainable in the long run. We cannot get there with all these separate files in their current form with all sorts of global state all over the place. And as I keep maintaining, the majority of the code outside of retroarch.c and libretro-common should become 80 to 90% tasks, thread-safe and all. Anything global has to go into one centralized place, so that we can make order out of chaos. Not to mention it's more optimal this way as well. The code outside retroarch.c should become a lot more pure, no longer relying so much on global state everywhere, so that we can convert them easier into tasks. For this and other reasons, we need to do this drastic rebuilding.

[fr500]

We cannot get there with all these separate files in their current form with all sorts of global state all across the place

Of course you can, you use a branch, do it piecemeal until you are done.

Anyway, as I said, I'm no expert.
On the few programming classes I had this was the complete opposite of what I was taught.
Tasks are fine for certain things but are a huge headache when you need things to run in order.

I'm sticking for the 1.7.7 codebase for the stuff I'm implementing.

[twinaphex]

Branches are a non-issue, the refactors are already done piecemeal. Anyway, I'm the leader of this project, and I am making this decision to do it this way. The code more or less stayed the same anyway, it's a simple matter of the driver files being moved into one big file, and more functions turned static.

Tasks are fine for certain things but are a huge headache when you need things to run in order.

Of course they are a headache, but it eventually has to happen anyway. CPUs are only getting more cores instead of faster clock speeds so allowing for stuff to be put on multiple threads at the same time is a very definite help (for things that can be done out of sequence), the main UI cannot block, many of these tasks on the main thread do block, which is bad. It's bad for Android, iOS, it's bad for the A/V synchronization timer, etc. It's bad for platforms like UWP where synchronous file I/O is very heavily penalized. It's a simple case of dealing with the headache because this is the only way forward.

[twinaphex]

It was also an opportunity of getting rid of all these ctl functions (camera_driver_ctl, location_driver_ctl, audio_driver_ctl, etc). The ones that haven't already been gotten rid of, will be soon. There should be only one such function for all the driver stuff in retroarch.c, and that should be rarch_ctl. It was a bad design decision I made a few years ago to go for that approach, and themaister didn't like it either. So this is a way to correct that mistake.

[fr500]

It's just making it even harder for contributors to work in the codebase.
As I said before it's your call. I don't have any stake into this.

Just my opinion.

[twinaphex]

I think keeping it the way it was actually does that. Sure, a near-500Kb file is not ideal and things are a lot bigger than they were in the SSNES days, but I'm sure the total code size can be made far smaller. And all this state passing around was not helping performance either for certain. You might even notice a speedup or two.

Anyway, it's part of a longer-term redesign. It will pan out well.

[LazyBumHorse]

If it's in the name of performance, multithreading and also reducing code, it can't be that bad, all that global state had it coming anyways.

The maintainability might suffer a bit, but speaking as someone who just started contributing a few weeks ago, getting into it requires lots of debugging know-how anyways.
There's no easy "reading into it" (if you try starting with configuration.c, you will go bonkers), no "it's about this, so it's probably there" (for example: guess where the core init is called... retroarch.c? Nah, command.c), you basically only find stuff by starting with a log message and backtracking (good ol' printf debugging).
So in practical terms, putting more code in 1 place doesn't change much.

What I'm saying is: stay positive, if it turns out bad, it's not like we are now stuck with it forever but it'll give an idea of how to do it even better, and if it doesn't turn out bad, well, great!

Personally I think what's much more upsetting than the actual code changes are all these small commits, almost a whole page of them! Please aphex, squash more! :smile:

[twinaphex]

Thank you for the upbeat attitude @LazyBumHorse . And yeah you're right, the sourcecode is already not readable as is it for newcomers being splintered across so many files. It can only be improved really.