Oh wait is this true? Huh, that explains why I wasn't getting over 9 frames with all the speed up tipsthe stable 1.36 doesn't support dynarec as far as I have heard
Oh wait is this true? Huh, that explains why I wasn't getting over 9 frames with all the speed up tips
I compiled the Vecx (GCE-Vectrex) core.
The games run at full speed so far.
I also recompiled the Stella (Atari2600) core.
This has a unique ID which doesn't install over the 'retroarch.cia'
I've included the corresponding .core files for detection by other cores.
Place them in: SD:/retroarch/cores/
Thanks..... For this
Can you upload .3dsx ?? Please
Ohh !! thanks for cias and core
Here's the ProSystem (Atari 7800) core. Full speed.
Unfortunately i have some trouble compiling a .3dsx. Have to look into that.
I had a look at the GBA's dynarec code, and the real problem there is that, at least from my point of view, it's sort of a mess. It's the sort of code that only its author could really grasp. I don't know who exactly would be willing to go through the trouble of really understanding WTF is there.it is negative cause they seem to fix things while breaking others that worked very well. though thats not a thing thats new, as users, we've had complaints for over a year when we had weeks of broken releases and were still reverting to a year old version that mostly worked with issues, and we mostly understood that lacking the hardware to test this, there was little to be done about the 3ds version.
then they got the hacked hardware (i'm not sure but I believe it was gifted to them too) and things didn't really get better for another few months.
then the new stable (oh its more of a beta kinda deal) comes with additions that make sense on a ps3 or a high res high performance smartphone that really doesn't make sense on the 3ds version, like all of that empty space in the menues.
i get that the 3ds is only one of the platforms they support and with its limited hardware, requires additional work, or at least some consideration when implementing some things, but come on, they had years to fuss over smartphones and the other consoles.
i agree that keeping it identical over all instances doesn't really work and yes, there should be a fork for low power hardware like psp, 3ds and wii (if thats still in development).
for our all sake, take the gba core.
chances are the community isn't really capable of doing this on its own, things have changed since the wii days, developers and coders are rare and getting rarer.
and at least as far as emulation is concerned, the existence of retroarch seems to have pulled away interest from making emulators in general.
because why would someone waste time on writing or porting (or dare i say optimizing) their own thing when there's already retroarch.
granted 1000$ sounds like a lot but it really isn't. however, once money is involved, its understandable people start expecting more
which is, assumingly, the reason it likes to crash so much.I had a look at the GBA's dynarec code, and the real problem there is that, at least from my point of view, it's sort of a mess. It's the sort of code that only its author could really grasp. I don't know who exactly would be willing to go through the trouble of really understanding WTF is there.
I really don't see a point of using retroarch for GBA when the GBA virtual console works much betterI had a look at the GBA's dynarec code, and the real problem there is that, at least from my point of view, it's sort of a mess. It's the sort of code that only its author could really grasp. I don't know who exactly would be willing to go through the trouble of really understanding WTF is there.
Save states, filters, proper sleep mode, and automatic ghosting patches and brightness makes gpsp look and work amazing.I really don't see a point of using retroarch for GBA when the GBA virtual console works much better
no save states makes me feel like im playing on my gba again which I like, you can mod most gba roms to use a proper sleep mode, it takes 5 seconds to make a VC with no ghosting and proper brightness, vc performance is much better than gpspSave states, filters, proper sleep mode, and automatic ghosting patches and brightness makes gpsp look and work amazing.
no save states makes me feel like im playing on my gba again which I like, you can mod most gba roms to use a proper sleep mode, it takes 5 seconds to make a VC with no ghosting and proper brightness, vc performance is much better than gpsp
what if I want to see the actual boxart when I select the games and think it looks nice having them all in a folder on my 3ds?What if, instead of installing games individually as cias, I want to load them as .GBA files from the SD Card?
but the funny thing is, its one of the best GBA emulators for 3ds at the moment (aside from crashing, and particularly on O3ds)which is, assumingly, the reason it likes to crash so much.
were you looking at the gpsp core? considering how its a fork of a fork of a differently languaged fork for an entirely different console, it wouldn't surprise me if its really confusing
what if I want to see the actual boxart when I select the games and think it looks nice having them all in a folder on my 3ds?
if you like an emulator that isn't accurate with subpar performance sure I'll stick with my non-emulated simulated GBA VCAnd that's why I think we should have more than 1 alternative (VC), everyone wins.
if you like an emulator that isn't accurate with subpar performance sure I'll stick with my non-emulated simulated GBA VC