FCEUX new build/source discussion #294
Replies: 3 comments 7 replies
-
|
Hmm! You're right. On careful observation, there is a very small difference in the emulation/performance of the two builds. And I think I know what's going on: the stock build is prioritising the emulation of video without a cap, unsynced with the audio, while the new build is keeping audio and video consistent/synced -- which is why the video refresh is a little slower on it. Both suffer from the same problem with the system/SDL video memory/rendering, and experience slow emulation on certain launches, but in the case of the old/stock build (which prioritises video at the cost of sound), this shows as stuttering/broken music/sound, while in the new build it shows as choppier video (but still smooth, un-broken sound). I think it comes down to how the emulation prioritisation was set up in these two builds (source codes). Unfortunately the source code to the old/stock build is actually lost, so we'll never know what was done there, exactly. But I have to say, I think the new build is actually more accurate in terms of emulation. I don't remember video being as smooth on my Famicom (NES) as it plays with the stock build (don't forget that TV screens of the time had a 25-30 FPS cap). And music/audio was certainly never choppy on the Famicom/NES. So overall I think the new build provides a more accurate emulation experience, even if video refresh is a tiny bit slower than in the stock build. Not sure I would want to change it, but you're welcome to (just fork the source). |
Beta Was this translation helpful? Give feedback.
-
|
This still leaves the question as to what's going on with the FPS counter in FCEUX. Because I doubt that the video refresh is 60 FPS in both builds. There is a small visible/feelable difference if you pay careful attention (even if we discount the occasional system/SDL bug/issue). Which suggests to me that the new build actually has an FPS of less than 60 FPS, not as displayed by the counter. Although the counter does occasionally drop to 55 FPS with the new build -- so that may be enough to notice the visual difference. And that means that the counter may be accurate after all -- except when encountering the system-wide/SDL slowdown bug/issue (which is not up to the emulator and its performance). I wonder what the native/set refresh rate of the IPS screens in the current Miyoo devices are, too. (Because that, too, counts.) |
Beta Was this translation helpful? Give feedback.
-
|
There is beta section on Main page, you can find there a few FCEUX builds which supposedly should improve performance/fix stuff but in reality people were reporting decrease in framerate and were coming back to stock build for better experience. |
Beta Was this translation helpful? Give feedback.
-
I've just checked. There's no source there, @Apaczer. Just compiled binaries. :/ Wherever I've asked, no-one seems to know where the source code for the bundled, stock build of FCEUX is -- it's lost. The "newer" source codes available online for FCEUX are not this source, they're actually an RG adaptation, which implements nothing new as it pertains to FCEUX on Miyoo, but instead tweaks/converts the original FCEUX code to be able to run on RG and other mobile devices. So there is no newer source for FCEUX (for the Miyoo) as we speak. This is all we have to work with. |
Beta Was this translation helpful? Give feedback.
-
|
We can have both worlds, lets just add another link in gmenu2x for second fork of FCEUX :). If you read RetroArch wiki, there is recommended option to set G-Sync/Freesync ON because it helps immensly with smooth video rendering (almost night/day difference). The purpouse of it is to sync any variable refresh rate of you screen to match the one being rendered by emulator. Some say that Miyoo's can only refresh at 40÷50Hz in current state, raising that value through software proven that it can produce some other issues (like static noise) |
Beta Was this translation helpful? Give feedback.
-
|
Considering quality of these displays, I'm truly shocked that they can even produce smooth video image in 60fps titles. |
Beta Was this translation helpful? Give feedback.
-
There's a reason for this: current Miyoo devices do not have hardware acceleration. There's no graphics card to speak of in them, just some limited RAM and an ARM processor. It's actually incredible what these emulators are capable of doing with so little. I still can't get over the fact that PCSX (PlayStation) is even a thing on Miyoo, even if it runs choppy. The screen tearing and flickering you're experiencing is largely for the same reason. Screen tearing happens in software-rendered displays (where the single ARM processor is doing all the work), and flickering is happening in emulated hardware displays (because there isn't any hardware to support it). Note that this screen tearing will happen on almost any low-cost mobile gaming device released on the market today. It's not exclusive to Miyoo devices. It's to be expected with low-cost hardware. Furthermore, once again, it's a bit of a new-age comfort/sensitivity in users/gamers. In the past no-one worried about screen tearing -- we didn't even notice it and pay attention to it. I'm sorry, but you guys have grown very picky. 😝
Hmm! Interesting! 😮 I would expect 60 Hz to be the standard for today's IPS screens -- even low-cost ones. I haven't looked into the screen's specs, yet, though. I'm interested to find out what's causing the 3D layering of colour, too, in it. :) (Blues are rendered on a lower physical layer, it seems -- producing some interesting, unique effects/experience in games.)
Yes, they are amazing, actually! To have such high quality, deep and vibrant screens in such low-cost devices is a first in history, and nothing short of incredible! *^_^* (It's thanks to widespread manufacture of mobile phones and advances in mobile phone technology.) |
Beta Was this translation helpful? Give feedback.
-
|
@Apaczer, just to give you a clearer picture -- get this: It turns out the original PlayStation did not only have a CPU and a GPU, but also an SPU, too! (One processor each for execution, graphics rendering, and audio/sound rendering!) https://en.wikipedia.org/wiki/PlayStation_technical_specifications Here, on Miyoo, we have 1 single-core (mobile phone) ARM processor, running at 533 MHz to 798 MHz to not only render all of this simultaneously, at the same time, but also to run the underlying Linux system and to emulate the whole PS system these software/ROMs require to run -- and a mere 32 MBs of DDR1 RAM! No GPU for 2D/3D graphics, no SPU for sound -- just the single, low-performance processor and the bare minumum of slow, integrated RAM. https://linux-sunxi.org/F1C100s It's nothing short of incredible how well these emulators actually run on this platform, how well optimised they are to make use of so little in terms of hardware, to run on ARM. Most 32-bit software these days require a lot more resources -- not to mention software that emulates another gaming system! So once you start to look at it this way, it becomes clear why the new-age PC/console standard of 60 FPS everywhere is a little much to expect from a system with this hardware, and how amazing it's actually doing -- able to render not only 2D smoothly (at 30-60 FPS), even when emulated, but also basic 3D as well! ^_^ And you can see why we have the occasional memory overfill related slowdown problem. 32 MBs of DDR1 RAM is really not a lot to work with for today's 32-bit software -- especially games and emulators. Linux (OpenDingux, the Miyoo OS) is actually doing a wonderful job at clearing/managing the working RAM/memory on-the-go (unlike Windows). Simply exiting and relaunching programs, and waiting a little bit between launches, clears up the working memory. So for the most part we don't even feel that the whole system is working with a mere 32 MBs of RAM. |
Beta Was this translation helpful? Give feedback.
-
Continuing the discussion regarding the new, updated build of the FCEUX that was started here: #260 (comment)
@Apaczer:
There's no hidden FPS capping. (You can check the source code.) That's actually the speed FCEUX is rendering the game at. (Which is why I said the performance is top-notch for NES games on current Miyoo devices, and that the frame skipping setting is completely useless and unnecessary.) The inconsistency that you see between the FPS rendered/displayed and what you see on screen is happening on the system/SDL side.
I'm putting this down to chance, to bad luck while you were testing it. There's no reason why the old build would work any better. They're using the same rendering mode (the only one available on Miyoo devices). They work exactly the same, emulation-wise. Give it another go and check. (I'll do the same using Ninja Gaiden.)
I don't understand. What do you mean decrease? The display/performance changes?
Beta Was this translation helpful? Give feedback.
All reactions