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.
It appears this new version supports Sengoku 3 on the Neo Geo core! Has anyone tried other larger Neo Geo roms?
Nope. Weirdxeh? Another Neo Geo game is always a bonus as we will never get the larger ones on Wii.
NO NO
Structure man, structure....
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.
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?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).
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.
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 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...).
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.
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.
Keyword: wantI'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.
It's to be applied against the Wii64 public SVN.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.
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.
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).
If you were to look at the Wii64 source code, you could make out who worked on what by their coding style.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.