Homebrew [RetroArch] Nightly builds here!

  • Thread starter Thread starter teampleb
  • Start date Start date
  • Views Views 847,465
  • Replies Replies 5,278
  • Likes Likes 29
Status
Not open for further replies.
CATSFC was designed to sacrifice accuracy for speed while maintaining a high level of compatibility. It was originally developed for the underpowered DSTwo flashcart which had its own CPU. It wasn't really up to the task, only running games with quite a high level of frameskip, but Libretro incorporated the core into their project for use on low powered systems such as the 3DS. Compatibility should be roughly the same as the equivalent version of Snes9x although with accuracy sacrificed for speed.

I think it's incredible that the core runs full speed on the New 3DS with relatively little 3DS-specific optimisation.
 
  • Like
Reactions: SLiV3R
CATSFC was designed to sacrifice accuracy for speed while maintaining a high level of compatibility. It was originally developed for the underpowered DSTwo flashcart which had its own CPU. It wasn't really up to the task, only running games with quite a high level of frameskip, but Libretro incorporated the core into their project for use on low powered systems such as the 3DS. Compatibility should be roughly the same as the equivalent version of Snes9x although with accuracy sacrificed for speed.

I think it's incredible that the core runs full speed on the New 3DS with relatively little 3DS-specific optimisation.

Yeah, I think it is incredible that both genesis plus GX and catsfc runs near perfect without months of optimisation! :)
 
GameYob allows the use of gbc_bios.bin so that when starting a Game, the GameBoy Color Splash goes across the Screen, and also will Colorize normal GB Games. Will this be possible with RetroArch GB Cores at some point?

Also, for RetroArch in general, does RA support entering RAW Codes? Encrypted or Decrypted?
 
Last edited by Smoker1,
GameYob allows the use of gbc_bios.bin so that when starting a Game, the GameBoy Color Splash goes across the Screen, and also will Colorize normal GB Games. Will this be possible with RetroArch GB Cores at some point?
If the core supports it, it would be supported. But Gambatte itself doesn't load the GBC bios file - it has the colorizing options implemented inside of it under core options for that reason. You can also load external custom palettes.
 
  • Like
Reactions: teampleb
Every core every Time i want to use savesstates it crashes ... Normal?
Suggest using the Build from 15 Aug 1523 Hrs. So far, I have not had any problem with that Build via .cia on my N3DS. Using this until there are better Versions that have better Features and more Compatibility.
 
they should be bale to get them to run full speed on the o3ds since theirs emulators running full speed on the psp and its even less powerful then old3ds
 
The PSP is more powerful than the 3DS in many ways, actually.

But it's irrelevent. The Retroarch cores are ported from other platforms. There's a limit to how much extra performance can be coaxed out of them before having to rewrite vast amounts of code. That's why blargSnes runs so well on even the O3DS - it was designed for the 3DS from the ground up rather than being a port.
 
The PSP is more powerful than the 3DS in many ways, actually.

But it's irrelevent. The Retroarch cores are ported from other platforms. There's a limit to how much extra performance can be coaxed out of them before having to rewrite vast amounts of code. That's why blargSnes runs so well on even the O3DS - it was designed for the 3DS from the ground up rather than being a port.

This is something that I've wondered about for a little bit. You know how many people complain about wanting a PSX or N64 emulator for the 3DS? Hypothetically, for a difficult project such as that, what would be the most efficient approach? Would it be better to start by porting something like the corresponding RetroArch core, without expecting anything playable due to framerate or whatever, and then rewriting to optimize from there, or just starting entirely from scratch? I keep hearing how porting something like an emulator won't have the same level of performance as a custom-built project, but as just an end-user with not nearly enough programming knowledge to do anything like this (I can write incredibly simple programs in Game Maker, and a scripting language that I'm told is very similar to C++), I've noticed the ported emulator working better than the custom-built one. (Special-chip games like SMRPG and StarFox work in RetroArch to a degree, while they don't even start in BlargSNES) I understand the theory behind it, but I've never noticed enough of a difference to make it apparent.

(I'm sorry if my question doesn't seem to come across well. I've probably re-written this post three or four times, to try and make it easier to understand.)
 
@Kurt91 It's not a straight line, but in some ways emulators sort of sit on a scale with speed on one end and accuracy (i.e. compatibility) on the other. blargSNES is less accurate than RetroArch cores like CatSFC or Snes9x-Next, but it's much faster. You might not notice this against CatSFC on a New 3DS where everything is much faster anyway, but to say blargSNES doesn't work as well as other emulators discounts the importance of running fast, especially for original 3DS owners.

Of course, it's not quite as simple as speed vs. compatibility; there are other things you can do to make your emulator faster without making it less accurate, such as writing it in native machine code, which essentially kills portability as the software is built for a particular architecture. RetroArch cores sit at the opposite end of the scale from native machine code, they're designed to run on everything, so there is generally little specialization (though there are several exceptions to this).

So, assuming infinite human resources (i.e. no constraints on the time, skill or interest of developers), the best way to get a (most importantly) fast and (secondarily important) accurate emulator running on a particular system would be to start from scratch developing that emulator to run on that platform; possibly using other emulators as an invaluable resource for learning how they do things in order to get your new emulator off the ground, as opposed to porting them.

In practice, though, this is really hard, time-consuming and frequently boring. So within reason, it's certainly possible--and marginally easier--to take a previous emulator and extensively rewrite it to run well on a platform as low-end as the 3DS, You can see something similar with jEnesisDS, the Genesis/Mega Drive emulator on the DS, which was ported from Java (very far to the "portability" end of the scale, far off targeting speed), to C, with a machine code core designed specifically for the DS to make it run well. Could it have been marginally faster if written from scratch for the DS? Probably, but it was fast enough for that not to be necessary.

So I guess the answer is that writing from scratch is the most difficult approach and thus the least likely to even be attempted, but with the best chance of achieving results (but also crushingly disappointing if you put in all this effort and don't meet your goals since your code is "stuck" on the platform you designed so heavily around), while porting and significantly rewriting is somewhat easier, with potentially more limited results which may or may not hamper your overall success (like jEnesisDS could have been faster but didn't need to be in order to it meet its aim). Sorry for not having a more conclusive answer, it's not really a situation where it's easy to say "this way is best", it's more about weighing up the benefits and drawbacks of each approach.
 
well the emulators on the ds ran full speed and the ds is way less powerful then a 3ds

Retroarch has not been ported on NDS so your comparison is irrelevant.
As for emulators running fullspeed on NDS, there aren't that much, really. Maybe NES and Master System. Jenesis run decently but there were huge resolution issues. CatSFC runs better on 3DS than NDS (hopefully).
If you talking about DSTWo, this is a different beast with its own processor.

Anyway, you have to understand that those emulators which run fullspeed were developped from the ground for the system they run on.
They use hardware-accelerated emulation that can only work on this specific system.
This is not what Retroarch is about, Retroarch is providing a frontend for portable emulators designed to run on all platforms (PSP, Wii, Xbox, PS3, 3DS, Android... etc, up to your PC)

This is something that I've wondered about for a little bit. You know how many people complain about wanting a PSX or N64 emulator for the 3DS? Hypothetically, for a difficult project such as that, what would be the most efficient approach? Would it be better to start by porting something like the corresponding RetroArch core, without expecting anything playable due to framerate or whatever, and then rewriting to optimize from there, or just starting entirely from scratch? I keep hearing how porting something like an emulator won't have the same level of performance as a custom-built project, but as just an end-user with not nearly enough programming knowledge to do anything like this (I can write incredibly simple programs in Game Maker, and a scripting language that I'm told is very similar to C++), I've noticed the ported emulator working better than the custom-built one. (Special-chip games like SMRPG and StarFox work in RetroArch to a degree, while they don't even start in BlargSNES) I understand the theory behind it, but I've never noticed enough of a difference to make it apparent.

Main reason is that speed optimization always comes down to a price for accuracy and compatibility. People might refuse to accept it or say they do not see that much difference (either because they don't play every games or because they don't play games long enough to see bugs) but that's a fact. Another thing is that to make your emulator hardware-accelerated, you usually end up rewriting most of the things from scratch because it generally means you have to rewrite lots of C/C++ code into target ASM and rewrite the video rendering code to use the hardware GPU, shaders, etc...
Most of hardware optimized emulators are based on portable emulators anyway (PocketSNES for example is initially derived from Snes9x) so nothing is never really entirely "built from scratch".

For example, you say "ported emulator working better than the custom-built one" but how do you define "better" ? If you mean game compatibility and accuracy of video/sound, off course they will always be "better", they are emulators that have been developped for MANY years, got a lot of users to report bugs and lots of talented devs working on it to fix bugs and improve the code. But if you are talking about speed, BlargSNES is definitively better than CatSFC and a lot better than Snes9x-next, it would be really hard not to notice it. The ideal is a mix of both but getting speed AND accuracy on very WEAK systems like the 3DS is just impossible (remember it only has a 268 MHz CPU to run things, do anyone remember how emulation was on an old Celeron P266 ?), no matter how much non-technical chatters tell you "everything is possible blah blah"

Now , New 3DS is a different beast since it apparently runs between 1,5x and 2x faster than old 3DS, which can get you up to 536 Mhz and is somehow on par with something like the Gamecube that had many accurate emulator ports running fullspeed (maybe even more, I saw a mention of 804 Mhz implying that it was 3x the raw power of one old 3DS core but I'm still not sure if that's the true speed or just some made up number).
 
Last edited by Jacobeian,
  • Like
Reactions: Vague Rant
Just pointing this out in case anybody didn't realise - the Retroarch cores actually support .zip roms. Most 3DS emulators don't so this is nice. Some of those GBA roms go down to a 1/3 the size.

But as far as githud reads, no 7zip support.
Also doesn't like readme files or cue + bin combos in zip-

--------------------- MERGED ---------------------------

well the emulators on the ds ran full speed and the ds is way less powerful then a 3ds

Because compilers, coding, optimization is hard, and porting doesn't mean you actually know how to optimize the code.
The state of documentation on the 3DS system is one thing as well, and devs being split between N3DS and O3DS also means something: Because if the N3DS devs see their stuff fullspeed, they pat themselves and go for the next thing or leave.
 
I hope you try to add dynarec on all these emulators. Then I will downgrade ninjhax 2.1 to 1.1b and use the cia versions :)
 
Status
Not open for further replies.

Site & Scene News

Popular threads in this forum