Homebrew RetroArch - A new multi-system emulator

[LibretroRetroArc]

It appears this new version supports Sengoku 3 on the Neo Geo core! Has anyone tried other larger Neo Geo roms?

The previous one didn't? That's nice I guess.

I'm kind of curious about this now.

 

[Charco]

Nope. Weirdxeh? Another Neo Geo game is always a bonus as we will never get the larger ones on Wii.

 

[LibretroRetroArc]

Nope. Weirdxeh? Another Neo Geo game is always a bonus as we will never get the larger ones on Wii.

I'll try some other bigger ROMs to see if this was just a fluke.

 

[the_randomizer]

NO NO
Structure man, structure....

Hmm...methinks I should continue this via PM....

 

[Charco]

I'll try some other bigger ROMs to see if this was just a fluke.

Seems to be the only one so far, I left all the non working roms in my neo folder in the off chance that they would ever work.

 

[LibretroRetroArc]

Seems to be the only one so far, I left all the non working roms in my neo folder in the off chance that they would ever work.

You have tested Sengoku 3 yourself and verified that it is working?

 

[edwardbirkholz05]

I never edited ANYTHING that would make me look bad. If anything, I always try being truthful about everything. Unlike others, there's no ego to satiate here.

Then explain why the post in the second link doesn't match what was quoted by someone else - your "put up or shut up" comment somehow deleted itself?

That whole block of code (all the ang/mag/sin/cos crap) is redundant btw; the raw x and y values from the controller are available directly via ljs.pos.x, ljs.pos.y etc. The only difference is the polar values are adjusted according to the calibration data, but that's practically worthless for classic controllers since most of them don't have any hard-coded calibration values (you're meant to read the centered values on startup and track min/max in your own code).

 

[LibretroRetroArc]

Then explain why the post in the second link doesn't match what was quoted by someone else - your "put up or shut up" comment somehow deleted itself?

He put up, and I shut up - and did an about face. So removing that comment fit in the spirit of that. Good enough for you or do we need to protract this for much longer? I told youbefore - it didn't fix this central problem - so me "apologizing" for it is me being actually just honest and straightforward about it all when I didn't really have to.

That whole block of code (all the ang/mag/sin/cos crap) is redundant btw; the raw x and y values from the controller are available directly via ljs.pos.x, ljs.pos.y etc. The only difference is the polar values are adjusted according to the calibration data, but that's practically worthless for classic controllers since most of them don't have any hard-coded calibration values (you're meant to read the centered values on startup and track min/max in your own code).

I thought so too and it's good that you've verified that at least, but we were copying/pasting from pre-existing input code and assumed "it had to be there for a REASON". Since things are so badly documented in libogc land, you kinda have to just assume other people's code is reliable at face value - especially when your only reference point apparently is the "official" Revolution SDK docs (yes, somebody with some standing pretty much confirmed to me that - hey - if you need any documentation on libogc - just, errr, go read the Revolution/Gamecube SDK docs - and sure enough - it is nearly entirely the same - from every struct to thinly disguised variations on function prototypes - except for the usage of Wiiuse of course. Makes you wonder where all this stuff comes from huh...).

 

[Charco]

You have tested Sengoku 3 yourself and verified that it is working?

Yep, playing right now.

Tested all the others and none work. Sengoku 3 is 42.7MB zip file, strange how this works yet other roms like Real Bout Fatal Fury 2 and the Last Blade games don't but are 30MB zip files or less. If something could be deduced from this Sengoku 3 fluke it could prove useful for perhaps getting these games to run.

 

[LWares87]

Just to ask, LibretroRetroArc... could you possibly post the previous version of the main core for FBA please?

Thanks

Edit: Never mind... i found a link to the previous version on Wiibrew

 

[LibretroRetroArc]

Yep, playing right now.

Tested all the others and none work. Sengoku 3 is 42.7MB zip file, strange how this works yet other roms like Real Bout Fatal Fury 2 and the Last Blade games don't but are 30MB zip files or less. If something could be deduced from this Sengoku 3 fluke it could prove useful for perhaps getting these games to run.

Set 'Show Framerate' to ON in Settings and tell me the values for MEM1/MEM2. It should tell you how much RAM is being used.

 

[edwardbirkholz05]

I thought so too and it's good that you've verified that at least, but we were copying/pasting from pre-existing input code and assumed "it had to be there for a REASON". Since things are so badly documented in libogc land, you kinda have to just assume other people's code is reliable at face value - especially when your only reference point apparently is the "official" Revolution SDK docs (yes, somebody with some standing pretty much confirmed to me that - hey - if you need any documentation on libogc - just, errr, go read the Revolution/Gamecube SDK docs - and sure enough - it is nearly entirely the same - from every struct to thinly disguised variations on function prototypes - except for the usage of Wiiuse of course. Makes you wonder where all this stuff comes from huh...).

That was all thanks to shagkur back in the days before wii support was added. He basically asm2c'd the GC SDK (adding inline documentation from the same) and got it committed before anybody realized what it really was. If you look at the wii-specific stuff (SD, USB, BT, IOS) it's obviously original; that's all the stuff added by marcan, sven et al. When it become apparent what shagkur had done, pretty much all the useful people dropped any association with libogc (which is why it's silly to criticize them for it - they weren't the ones responsible and got tfo when they realized what was going on).

 

[Charco]

Set 'Show Framerate' to ON in Settings and tell me the values for MEM1/MEM2. It should tell you how much RAM is being used.

MEM1: 19042320 / 25165824
MEM2: 48234576 / 54124536

 

[Charco]

Can you let me know how per core configs work, I don't play GBA games so this is the only thing for me in 1.0 but I cannot get it to work.

Ok I think I have figured this out now, the path settings only save if you enter RGUI AFTER loading a rom. For example, load up Art of Fighting on the Neo core, then go to settings and set path for Neo Geo folder. Did this with CPS1 aswell and it now has the correct rom folders for both cores. Unintuitive though.

 

[Extrems]

I'll retract that - there was a source patch in the binary you linked to. Even still - this is 2014 - public repos are an absolute requirement - a source patch is just not a serious proposition at all if you want collaborative development.

Keyword: want
I'll agree the patch format has gotten rather unwieldy.

And I'd have to wonder against which base this should be applied against. If it's Wii64 - the last sourcecode release is from 2010 - so that would be an ancient version based on an already ancient version of Mupen64. There has been a TON of progress in mainline Mupen64 Plus since then - so that is a big waste of time ultimately to be basing a 'fork' around.

It's to be applied against the Wii64 public SVN.
The Wii64 Team hasn't rebased upon Mupen64Plus either. Backporting is trivial, and so we did.

 

[LibretroRetroArc]

Keyword: want
I'll agree the patch format has gotten rather unwieldy.


It's to be applied against the Wii64 public SVN.
The Wii64 Team hasn't rebased upon Mupen64Plus either. Backporting is trivial, and so we did.

I think the current maintainers of Mupen64 Plus would be amenable to wanting to push some of your Wii-specific changes/plugins upstream provided that it it meets some basic code quality standards (which I assume are all there).

It'd be the obvious road to take anyway - Mupen64Plus AE is doing this as well and I do it for certain key changes I make in Mupen64plus libretro as well.

 

[LibretroRetroArc]

That was all thanks to shagkur back in the days before wii support was added. He basically asm2c'd the GC SDK (adding inline documentation from the same) and got it committed before anybody realized what it really was. If you look at the wii-specific stuff (SD, USB, BT, IOS) it's obviously original; that's all the stuff added by marcan, sven et al. When it become apparent what shagkur had done, pretty much all the useful people dropped any association with libogc (which is why it's silly to criticize them for it - they weren't the ones responsible and got tfo when they realized what was going on).

I like the public disclosure at least - that was information I had not been privvy to but I suspected something like this from looking at the SDK. The only SDK / library I have seen as of late from homebrew consoles that really was built from the ground up was libxenon, and it definitely showed in some areas since it never really succeeded at replacing the XDK for devs in general. PSL1GHT was just a basic shim job from the PS3 SDK, and I just disliked the moral and intellectual doublethink around it when they would call this a "legal and open-source SDK for homebrew".

 

[Extrems]

I think the current maintainers of Mupen64 Plus would be amenable to wanting to push some of your Wii-specific changes/plugins upstream provided that it it meets some basic code quality standards (which I assume are all there).

If you were to look at the Wii64 source code, you could make out who worked on what by their coding style.

 

[LibretroRetroArc]

If you were to look at the Wii64 source code, you could make out who worked on what by their coding style.

I'm just suggesting that it might be better to start pushing code upstream to Mupen64plus instead of continuing to work in a fork repo. But I guess many core alterations had to be made along the way in a perhaps not too clean manner.

I'm in the same boat myself except I have to do these core alterations for the sake of increasing portability for all the various targets we have for libretro - one example being iOS requires certain changes made to the dynarec such as r9 save and restoring after callee uses it.

 

[OriginalHamster]

I see Retro Arch has a new "invader" icon
If someone wants to use it